From lizhong.jin@zte.com.cn Fri Jul 1 04:47:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1A21F868F; Fri, 1 Jul 2011 04:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM3gjh+8MZ2R; Fri, 1 Jul 2011 04:47:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 400C921F8689; Fri, 1 Jul 2011 04:47:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643314101978; Fri, 1 Jul 2011 19:46:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.7481467973; Fri, 1 Jul 2011 19:47:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p61Bl5Dc009505; Fri, 1 Jul 2011 19:47:05 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: lamberto.sterling@gmail.com, maillist.ed@gmail.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 1 Jul 2011 19:46:34 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-01 19:47:07, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-01 19:47:07, Serialize complete at 2011-07-01 19:47:07, S/MIME Sign failed at 2011-07-01 19:47:07: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-01 19:47:09, Serialize complete at 2011-07-01 19:47:09 Content-Type: multipart/alternative; boundary="=_alternative 0040BD56482578C0_=" X-MAIL: mse02.zte.com.cn p61Bl5Dc009505 Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , tictoc@ietf.org Subject: Re: [mpls] Request comments for HSMP LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 11:47:22 -0000 This is a multipart message in MIME format. --=_alternative 0040BD56482578C0_= Content-Type: text/plain; charset="US-ASCII" Hi Edward, Lamberto and all, Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root. We have updated the draft with more clarification of the use cases, and added new use case of VPLS application. You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03 Thank you. Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Jan 2011 02:50:16 +0100 > From: Lamberto Sterling > Subject: Re: [mpls] Request comments for HSMP LSP > To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn > Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , > tictoc@ietf.org, N.Leymann@telekom.de > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi guys, > Sorry for the email subject. Change it now. > > Lamberto > > On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling < > lamberto.sterling@gmail.com> wrote: > > > Hi Lizhong, Edward, > > It seems that it is a good idea to apply HSMP LSP to VPLS, and the > > broadcast/unicast/unknow packet would be optimized. However, the path from > > leaf to root may not be the best path compared with current VPLS using P2P > > LSP, which is not a critical issue. > > > > Thanks > > Lamberto > > > > > > > >> > >> ------------------------------ > >> > >> > >> Date: Wed, 5 Jan 2011 15:50:45 +0800 > >> From: lizhong.jin@zte.com.cn > >> Subject: Re: [mpls] Request comments for HSMP LSP > >> To: Ed > >> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , > >> N.Leymann@telekom.de, tictoc@ietf.org > >> Message-ID: > >> < > >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hi Edward, > >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with > >> the application you proposed, and in order to improve the scalability of > >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually > >> this is a good application case for P2MP PW with reverse path (section > >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this > >> use case. > >> > >> Regards > >> Lizhong > >> > >> > >> Ed wrote on 2011-01-05 15:05:30: > >> > >> > Hi Lizhong, > >> > > >> > I think one possible application for HSMP LSPs is to reduce the > >> > overall broadcast/multicast utilization on a VPLS. In current VPLS > >> > implementations with a full mesh of P2P LSPs between PEs, broadcast, > >> > multicast and unknown traffic are not efficiently propagated on the > >> > physical links between PEs and Ps. > >> > > >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals > >> > a HSMP LSP with itself as a root to all other PEs in the VPLS. > >> > Thereafter, all broadcast/multicast/unknown traffic from this PE > >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g. > >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using > >> > the HSMP LSP where PE2 is the root. > >> > > >> > This simplifies the VPLS implementation by: > >> > - Reducing traffic utilization from broadcast, multicast > >> > and unknown traffic > >> > - Reducing the total number of LSPs maintained by each PE > >> > (i.e. instead of requiring a full mesh of LSPs, now only require one > >> > HSMP LSP per PE). > >> > > >> > This is similar to the idea expressed in draft-key-l2vpn-etree- > >> > frwk-03.txt (in a more general sense). > >> > > >> > What do you think? Would HSMP LSP be suitable for this? > >> > > >> > Regards, > >> > Edward > >> > > >> > > >> > > >> > On Wed, Jan 5, 2011 at 5:24 PM, wrote: > >> > > >> > Hi all, > >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS > >> session. > >> > HSMP LSP has several use cases described in the draft, e.g, time > >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would > >> > be appreciated if you could give more scenarios for HSMP LSP. Please > >> > review the draft, and any comments are welcome. > >> > > >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- > >> > mldp-hsmp-01 > >> > > >> > Thank you. > >> > Authors of draft-hsmp. > >> > -------------------------------------------------------- > >> > > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/mpls/attachments/20110109/e5b476e5/attachment.html> > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 81, Issue 12 > ************************************ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0040BD56482578C0_= Content-Type: text/html; charset="US-ASCII"
Hi Edward, Lamberto and all,
Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root.

We have updated the draft with more clarification of the use cases, and added new use case of VPLS application.
You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03

Thank you.
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Jan 2011 02:50:16 +0100
> From: Lamberto Sterling <lamberto.sterling@gmail.com>
> Subject: Re: [mpls] Request comments for HSMP LSP
> To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn
> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice <ice@cisco.com>,
>    tictoc@ietf.org,   N.Leymann@telekom.de
> Message-ID:
>    <AANLkTi=CbhP10iM7=wXcb=e9oV0cqwaTKjY7ArZquoW1@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys,
> Sorry for the email subject. Change it now.
>
> Lamberto
>
> On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling <
> lamberto.sterling@gmail.com> wrote:
>
> > Hi Lizhong, Edward,
> > It seems that it is a good idea to apply HSMP LSP to VPLS, and the
> > broadcast/unicast/unknow packet would be optimized. However, the path from
> > leaf to root may not be the best path compared with current VPLS using P2P
> > LSP, which is not a critical issue.
> >
> > Thanks
> > Lamberto
> >
> >
> >
> >>
> >> ------------------------------
> >>
> >>
> >> Date: Wed, 5 Jan 2011 15:50:45 +0800
> >> From: lizhong.jin@zte.com.cn
> >> Subject: Re: [mpls] Request comments for HSMP LSP
> >> To: Ed <maillist.ed@gmail.com>
> >> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice <ice@cisco.com>,
> >>        N.Leymann@telekom.de,   tictoc@ietf.org
> >> Message-ID:
> >>        <
> >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> Hi Edward,
> >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with
> >> the application you proposed, and in order to improve the scalability of
> >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
> >> this is a good application case for P2MP PW with reverse path (section
> >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
> >> use case.
> >>
> >> Regards
> >> Lizhong
> >>
> >>
> >> Ed <maillist.ed@gmail.com> wrote on 2011-01-05 15:05:30:
> >>
> >> > Hi Lizhong,
> >> >
> >> > I think one possible application for HSMP LSPs is to reduce the
> >> > overall broadcast/multicast utilization on a VPLS. In current VPLS
> >> > implementations with a full mesh of P2P LSPs between PEs, broadcast,
> >> > multicast and unknown traffic are not efficiently propagated on the
> >> > physical links between PEs and Ps.
> >> >
> >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals
> >> > a HSMP LSP with itself as a root to all other PEs in the VPLS.
> >> > Thereafter, all broadcast/multicast/unknown traffic from this PE
> >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> >> > the HSMP LSP where PE2 is the root.
> >> >
> >> > This simplifies the VPLS implementation by:
> >> > -          Reducing traffic utilization from broadcast, multicast
> >> > and unknown traffic
> >> > -          Reducing the total number of LSPs maintained by each PE
> >> > (i.e. instead of requiring a full mesh of LSPs, now only require one
> >> > HSMP LSP per PE).
> >> >
> >> > This is similar to the idea expressed in  draft-key-l2vpn-etree-
> >> > frwk-03.txt (in a more general sense).
> >> >
> >> > What do you think? Would HSMP LSP be suitable for this?
> >> >
> >> > Regards,
> >> > Edward
> >> >
> >> >
> >> >
> >> > On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin@zte.com.cn> wrote:
> >> >
> >> > Hi all,
> >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
> >> session.
> >> > HSMP LSP has several use cases described in the draft, e.g, time
> >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> >> > be appreciated if you could give more scenarios for HSMP LSP. Please
> >> > review the draft, and any comments are welcome.
> >> >
> >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> >> > mldp-hsmp-01
> >> >
> >> > Thank you.
> >> > Authors of draft-hsmp.
> >> > --------------------------------------------------------
> >> >
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/mpls/attachments/20110109/e5b476e5/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 81, Issue 12
> ************************************
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0040BD56482578C0_=-- From jmh@joelhalpern.com Fri Jul 1 06:08:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BB111E82DB; Fri, 1 Jul 2011 06:08:04 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK0fUZFKCo2Y; Fri, 1 Jul 2011 06:08:04 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE211E82F7; Fri, 1 Jul 2011 06:08:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E5367325B2B9; Fri, 1 Jul 2011 06:07:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-33.clppva.btas.verizon.net [71.161.50.33]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 67BC2325B2B7; Fri, 1 Jul 2011 06:07:33 -0700 (PDT) Message-ID: <4E0DC68F.2060306@joelhalpern.com> Date: Fri, 01 Jul 2011 09:07:27 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF discussion list , "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:08:04 -0000 In performing a gen-art review of this document, which seems quite good over all, I noticed a minor question, but did not remember to include it in my gen-art review. The defines a Tunnel-Identifier, identifying the end-point of a tunnel within a node. That identifier is defined as 16 bits. In one sense, that seems sufficient. But it is more restrictive than the number of parallel LSPs that the node could be an end-point for (by a factor of 16.) So it seems that there ought to at least be an explanation for the mismatch. Thank you, Joel From huubatwork@gmail.com Fri Jul 1 07:00:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA741F0C61 for ; Fri, 1 Jul 2011 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0WZrs5gIC1y for ; Fri, 1 Jul 2011 07:00:26 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9C881F0C4F for ; Fri, 1 Jul 2011 07:00:21 -0700 (PDT) Received: by ewy19 with SMTP id 19so1349035ewy.31 for ; Fri, 01 Jul 2011 07:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4qJrPJqEAYcM6F12rqCJ2SVcCw4flamz3ZBI27Jk/kw=; b=PL17KQ8iITvCXmI7ri7hVqcBAv+al8C0ccgYdp1wRVCAj+dq2wCM7DVBf2AvHy8uIy CqeDQGQ9lVxXvRFwIpibM/vN+g0J6fFibFW4aXm25q3eQ4FbA/+XBmgTQ8Ut7JY3T3Sd b3YYFxidNmzANUkU2B12VSXPnZOXQYVh2CYSw= Received: by 10.14.28.68 with SMTP id f44mr230944eea.57.1309528820572; Fri, 01 Jul 2011 07:00:20 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id z14sm2540086eef.27.2011.07.01.07.00.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 07:00:19 -0700 (PDT) Message-ID: <4E0D9AA6.3060504@gmail.com> Date: Fri, 01 Jul 2011 12:00:06 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: George Swallow References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org, Huub van Helvoort , "BUSI, ITALO \(ITALO\)" Subject: Re: [mpls] ICC and CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:00:28 -0000 Hello George, On 17-06-11 you wrote: > And if so, do you have a suggestion for the combined fields? Yes. After discussing the MEG-ID format on the Q10 list we have the following format definition, the identifier >- consists of 13 characters, which contain: >- ICC (1 to 6 characters) as defined in rec. M.1400 >- "/" >- CC (2 characters) as defined in ISO 3166-1 alpha-2 >- UMC with trailing NULLs All used characters are as defined in rec. T.50. > I thought ICC stood for _International_ Carrier Code. M.1600 does not > expand the acronym. This acronym is expanded in M.1400, which is referenced in the identifiers draft, as "ITU-T Carrier Code". The CC above is "Country Code". And UMC is "Unique MEG ID Code". Regards, Huub. > On 6/17/11 9:19 AM, "George Swallow" wrote: > > Huub, Italo, Malcolm, > > I look to you guys as the authority on this. Should I prefix the ICC > with a CC? > > Thanks, > > ...George > ------------------------------------------------------------------------ > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 我爱外点一七三一 From nurit.sprecher@nsn.com Fri Jul 1 07:52:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BA99E8017 for ; Fri, 1 Jul 2011 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-vqJco-KK3u for ; Fri, 1 Jul 2011 07:52:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 236BA9E800E for ; Fri, 1 Jul 2011 07:52:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p61EqNwJ007336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 16:52:23 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p61EqMpt020098; Fri, 1 Jul 2011 16:52:22 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jul 2011 16:52:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 1 Jul 2011 16:52:21 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264041178E5@DEMUEXC014.nsn-intra.net> In-Reply-To: <4E0D9AA6.3060504@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] ICC and CC Thread-Index: Acw390e6dQcT+P3zR2e4QUiRlrQaHAABrjvQ References: <4E0D9AA6.3060504@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "George Swallow" X-OriginalArrivalTime: 01 Jul 2011 14:52:22.0822 (UTC) FILETIME=[7BFBC460:01CC37FE] Cc: mpls@ietf.org, Huub van Helvoort , "BUSI, ITALO \(ITALO\)" Subject: Re: [mpls] ICC and CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:52:34 -0000 SHViLA0KSSBkaWQgbm90IHNlZSB5ZXQgYW4gYWdyZWVtZW50IG9uIHRoZSBwcm9wb3NhbCBpbiBR MTAuDQpJIGRvIG5vdCB0aGluayB5b3VyIG1haWwgcmVwcmVzZW50cyB0aGUgSVRVLVQuDQpCZXN0 IHJlZ2FyZHMsDQpOdXJpdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZXh0IEh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBGcmlkYXksIEp1bHkgMDEsIDIwMTEg MTowMCBQTQ0KVG86IEdlb3JnZSBTd2FsbG93DQpDYzogbXBsc0BpZXRmLm9yZzsgSHV1YiB2YW4g SGVsdm9vcnQ7IEJVU0ksSVRBTE8gKElUQUxPKQ0KU3ViamVjdDogUmU6IFttcGxzXSBJQ0MgYW5k IENDDQoNCkhlbGxvIEdlb3JnZSwNCg0KT24gMTctMDYtMTEgeW91IHdyb3RlOg0KDQo+IEFuZCBp ZiBzbywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGUgY29tYmluZWQgZmllbGRzPw0K DQpZZXMuIEFmdGVyIGRpc2N1c3NpbmcgdGhlIE1FRy1JRCBmb3JtYXQgb24gdGhlIFExMCBsaXN0 IHdlIGhhdmUNCnRoZSBmb2xsb3dpbmcgZm9ybWF0IGRlZmluaXRpb24sIHRoZSBpZGVudGlmaWVy DQoNCiA+LSBjb25zaXN0cyBvZiAxMyBjaGFyYWN0ZXJzLCB3aGljaCBjb250YWluOg0KID4tIElD QyAoMSB0byA2IGNoYXJhY3RlcnMpIGFzIGRlZmluZWQgaW4gcmVjLiBNLjE0MDANCiA+LSAiLyIN CiA+LSBDQyAoMiBjaGFyYWN0ZXJzKSBhcyBkZWZpbmVkIGluIElTTyAzMTY2LTEgYWxwaGEtMg0K ID4tIFVNQyB3aXRoIHRyYWlsaW5nIE5VTExzDQoNCkFsbCB1c2VkIGNoYXJhY3RlcnMgYXJlIGFz IGRlZmluZWQgaW4gcmVjLiBULjUwLg0KDQo+IEkgdGhvdWdodCBJQ0Mgc3Rvb2QgZm9yIF9JbnRl cm5hdGlvbmFsXyBDYXJyaWVyIENvZGUuIE0uMTYwMCBkb2VzIG5vdA0KPiBleHBhbmQgdGhlIGFj cm9ueW0uDQoNClRoaXMgYWNyb255bSBpcyBleHBhbmRlZCBpbiBNLjE0MDAsIHdoaWNoIGlzIHJl ZmVyZW5jZWQgaW4NCnRoZSBpZGVudGlmaWVycyBkcmFmdCwgYXMgIklUVS1UIENhcnJpZXIgQ29k ZSIuDQpUaGUgQ0MgYWJvdmUgaXMgIkNvdW50cnkgQ29kZSIuDQpBbmQgVU1DIGlzICJVbmlxdWUg TUVHIElEIENvZGUiLg0KDQpSZWdhcmRzLCBIdXViLg0KDQoNCj4gT24gNi8xNy8xMSA5OjE5IEFN LCAiR2VvcmdlIFN3YWxsb3ciIDxzd2FsbG93QGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+ICAgICBI dXViLCBJdGFsbywgTWFsY29sbSwNCj4NCj4gICAgIEkgbG9vayB0byB5b3UgZ3V5cyBhcyB0aGUg YXV0aG9yaXR5IG9uIHRoaXMuIFNob3VsZCBJIHByZWZpeCB0aGUgSUNDDQo+ICAgICB3aXRoIGEg Q0M/DQo+DQo+ICAgICBUaGFua3MsDQo+DQo+ICAgICAuLi5HZW9yZ2UNCj4gICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gICAgIG1wbHMgbWFpbGluZyBsaXN0DQo+ICAgICBtcGxzQGlldGYub3JnDQo+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4NCj4NCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBt YWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0KDQotLSANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICAgICAg ICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From swallow@cisco.com Fri Jul 1 11:39:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8725211E8160; Fri, 1 Jul 2011 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go2mKgB64xYW; Fri, 1 Jul 2011 11:39:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 99DCE11E8155; Fri, 1 Jul 2011 11:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=2976; q=dns/txt; s=iport; t=1309545582; x=1310755182; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=ktvI87/7QxpdUHJ0OIypNafkVxzs7TYc05ksGpmdHfQ=; b=Xc9afFpspG2brY2XgnyWZwYPsRJTO3rTfTUCRAeYjgaPiFoak4REw3R7 +JuANdIQk+QW5tIhpcsPOrWssEVGNJkf7ZZzV/8TPRKISent9I7YhM70G Nk6LB8PIwUKFnz2bHpG6NvmKMTqVL/wb3SwYZV7F5hR0A4CttadY2Fk7X A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAgTDk6tJXG+/2dsb2JhbABSglGkQm53iHmjIZ1shjIEkjKEf4tO X-IronPort-AV: E=Sophos;i="4.65,460,1304294400"; d="scan'208,217";a="351609598" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 18:39:42 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61IdfDK011177; Fri, 1 Jul 2011 18:39:41 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 13:39:41 -0500 Received: from 10.86.244.99 ([10.86.244.99]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jul 2011 18:39:41 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 01 Jul 2011 14:39:40 -0400 From: George Swallow To: "Joel M. Halpern" , IETF discussion list , Message-ID: Thread-Topic: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier Thread-Index: Acw37/Of5BdGrxOFR9KA3LaJwlR13QALkjBa In-Reply-To: <4E0DC68F.2060306@joelhalpern.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392375980_148694742" X-OriginalArrivalTime: 01 Jul 2011 18:39:41.0398 (UTC) FILETIME=[3D354F60:01CC381E] Subject: Re: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 18:39:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392375980_148694742 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The primary motivation is to allow for a compact form for the Tunnel MEP_ID. A secondary motivation is compatibility with existing MPLS/GMPLS Session objects. ...George On 7/1/11 9:07 AM, "Joel M. Halpern" wrote: > In performing a gen-art review of this document, which seems quite good > over all, I noticed a minor question, but did not remember to include it > in my gen-art review. > > The defines a Tunnel-Identifier, identifying the end-point of a tunnel > within a node. > That identifier is defined as 16 bits. > In one sense, that seems sufficient. But it is more restrictive than > the number of parallel LSPs that the node could be an end-point for (by > a factor of 16.) So it seems that there ought to at least be an > explanation for the mismatch. > > Thank you, > Joel > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --B_3392375980_148694742 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identif= ier The primary motivation is to allow for a compact form for the Tunnel MEP_I= D.  A secondary motivation is compatibility with existing MPLS/GMPLS Se= ssion objects.

...George


On 7/1/11 9:07 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

<= SPAN STYLE=3D'font-size:10pt'>In performing a gen-art review of this document,= which seems quite good
over all, I noticed a minor question, but did not remember to include it in my gen-art review.

The defines a Tunnel-Identifier, identifying the end-point of a tunnel
within a node.
That identifier is defined as 16 bits.
In one sense, that seems sufficient.  But it is more restrictive than<= BR> the number of parallel LSPs that the node could be an end-point for (by
a factor of 16.)  So it seems that there ought to at least be an
explanation for the mismatch.

Thank you,
Joel

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

--B_3392375980_148694742-- From swallow@cisco.com Fri Jul 1 15:15:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E12C11E809B for ; Fri, 1 Jul 2011 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJxSd9NDgigV for ; Fri, 1 Jul 2011 15:15:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id EE0A811E8085 for ; Fri, 1 Jul 2011 15:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=15510; q=dns/txt; s=iport; t=1309558543; x=1310768143; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=UWvLamG7Rc4KavPJypwLbO6ECdpVQ+VAnPDu/qBw5i8=; b=KQ/vCzu3uaD4DDwyue6/9GI5b/MHpt6vA4Ax5tGKFRHBhEvDDQx7Vkkg L4zqqCcLb60lw9J0DeAzbZf01h8C3PzMiTI+naYc4mJfInIXX66hykKlY 614mF6PgncddkbsFcAr5rN9y7ntT66D9jlxLF326ske+SE3+cOy1B1vIS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAN9FDk6tJXG8/2dsb2JhbABSglGVe45HbneIeaNanVkChjAEkCuCB4R/i04 X-IronPort-AV: E=Sophos;i="4.65,460,1304294400"; d="scan'208,217";a="390329141" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 22:15:42 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p61MFg1j013648; Fri, 1 Jul 2011 22:15:42 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 17:15:42 -0500 Received: from 10.86.244.99 ([10.86.244.99]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jul 2011 22:15:42 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 01 Jul 2011 18:15:39 -0400 From: George Swallow To: Xinchun Guo , Loa Andersson , , Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlq57z2Yieu+sT1qv11A4xrFRrgF9U4SAAAVBXrAAk0N8oBsTliXa In-Reply-To: <000001cbcbf4$a8cd32b0$fa679810$@com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392388939_149508971" X-OriginalArrivalTime: 01 Jul 2011 22:15:42.0345 (UTC) FILETIME=[6A88DF90:01CC383C] Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:15:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392388939_149508971 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Xinchun - This restriction was not intended. The draft has been updated to make it clear that it is applicable to both. ,,,George On 2/13/11 11:09 PM, "Xinchun Guo" wrote: > Hi authors and all > > About this document, I have another question expect to be clarification. I > am not very clear about the specific application of Fault management > message. > > In section 2 of this document, it said " Fault OAM messages are generated by > intermediate nodes where an LSP is switched". Does it mean that the fault > message can only be used for alarm suppress of LSP layer? Could not this > fault management function be used for PW layer, especially for the MS-PW > conditions. Take the following hiberarchy scenario for example, PW1 and PW2 > are two segments of the MS-PW which is client of the LSP layer. if the > server layer of LSP fails, such as Link1, node2 will initiate AIS message > and sent it to LSP1 end point node3. As MS-PW is client of LSP1, for this > condition, whether Node3 will further initiate Fault management message to > MS-PW end point Node4 to notify the failure of LSP1 to suppress alarm of the > end to end pw service. IMO, Fault management function should cover these PW > conditions. > > - MS-PW - > - +---------AIS/LKR-------------->>- > -<-----------------PW1-------------------->|-----------------PW2------------ >> >- > - +----AIS/LKR---->> - > -<-------LSP1---------+-------------------><--------------LSP2-------------- > ->- > - |AIS/LKR - > -<--- Link1---------->|<--- > Link2------><--------Link3--------------------->- > Node1 Node2 Node3 Node4 > > > Hope authors could clarify this point and detail the Fault function process > about PW scenarios in this document. > > Best Regards > Xinchun > > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Xinchun Guo > Sent: Friday, February 11, 2011 5:52 PM > To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > > Other 3 edit comments, see below. > > 1.section 2.2, there is overlapping between the last sentence of the first > paragraph and the first sentence of the second paragraph about " The purpose > of the LKR message is to suppress alarms in the MPLS-TP layer network above > the level at which the defect occurs" . Simplify it will be more smart. > > 2.section 4.1.2, the first sentence" This TLV carries the Interface > Identifier as defined ......", "the Interface Identifier" should be "the > Global Identifier". right? > > 3. section 5.3, there are two "that" in the first sentence, one is > redundancy. > > Regards > Xinchun > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Xinchun Guo > Sent: Friday, February 11, 2011 9:39 AM > To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > > Dear authors > > After read the document, I have a question about the FM massage procedure. > > In the section 5.1, the third paragraph, it said "The message is then sent. > The message MUST be refreshed two more times at an interval of one second. > Further refreshes are sent according to the value of the refresh timer." I > don't know why the refreshing massage must be first sent two more times in > one second and then sent as the refresh timer interval. Is it ok if the > refreshing massage is sent only according to the value of the refresh timer? > If it is not, what problem may be introduced? Hope authors could explain it > for me. > > In addition, figure 2 is about the fault management massage format, so I > think naming the figure" MPLS-TP fault Management Message Format " other > than" MPLS-TP OAM Message Format " is more suitable. > > Best Regards > Xinchun > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Thursday, February 03, 2011 7:37 PM > To: mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > > Working Group, > > this is to start a four week working group last call > on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). > > Please send comments to the mpls-tp@ietf.org mailing list. > > This working group last call ends on February 28, 2011. > > > > Loa, George and Ross > > MPLS wg co-chairs > > -- > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --B_3392388939_149508971 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Xinchun -

This restriction was not intended.  The draft has been updated to make= it clear that it is applicable to both.

,,,George


On 2/13/11 11:09 PM, "Xinchun Guo" <guoxinchun@huawei.com> wrote:

<= SPAN STYLE=3D'font-size:10pt'>Hi authors and all

About this document, I have another question expect to be clarification. I<= BR> am not very clear about the specific application of Fault management
message.

In section 2 of this document, it said " Fault OAM messages are genera= ted by
intermediate nodes where an LSP is switched".  Does it mean that = the fault
message can only be used for alarm suppress of LSP layer?  Could not t= his
fault management function be used for PW layer, especially for the MS-PW conditions.  Take the following hiberarchy scenario for example, PW1 a= nd PW2
are two segments of the MS-PW which is client of the LSP layer.  if th= e
server layer of LSP fails, such as Link1, node2 will initiate AIS message and sent it to LSP1 end point node3.  As MS-PW is client of LSP1, for = this
condition, whether Node3 will further initiate Fault management message to<= BR> MS-PW end point Node4 to notify the failure of LSP1 to suppress alarm of th= e
end to end pw service.  IMO, Fault management function should cover th= ese PW
conditions.

-             &= nbsp;          MS-PW  = ;            &nb= sp;    -
-             &= nbsp;            = ; +---------AIS/LKR-------------->>-
-<-----------------PW1-------------------->|-----------------PW2-----= -------
>-
-             &= nbsp;+----AIS/LKR---->>        &nbs= p;            -<= BR> -<-------LSP1---------+-------------------><--------------LSP2----= ----------
->-
-             &= nbsp;|AIS/LKR           &n= bsp;            =     -
-<--- Link1---------->|<---
Link2------><--------Link3--------------------->-
Node1       Node2     &nb= sp; Node3           &= nbsp;    Node4


Hope authors could clarify this point and detail the Fault function process=
about PW scenarios in this document.

Best Regards
Xinchun


-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] O= n Behalf
Of Xinchun Guo
Sent: Friday, February 11, 2011 5:52 PM
To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Other 3 edit comments, see below.

1.section 2.2, there is overlapping between the last sentence of the first<= BR> paragraph and the first sentence of the second paragraph about " The p= urpose
of the LKR message is to suppress alarms in the MPLS-TP layer network above=
the level at which the defect occurs" . Simplify it will be more smart= .

2.section 4.1.2, the first sentence" This TLV carries the Interface Identifier as defined ......", "the Interface Identifier" sh= ould be "the
Global Identifier". right?

3. section 5.3, there are two "that" in the first sentence, one i= s
redundancy.

Regards
Xinchun

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] O= n Behalf
Of Xinchun Guo
Sent: Friday, February 11, 2011 9:39 AM
To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Dear authors

After read the document, I have a question about the FM massage procedure.<= BR>
In the section 5.1, the third paragraph, it said "The message is then = sent.
The message MUST be refreshed two more times at an interval of one second.<= BR> Further refreshes are sent according to the value of the refresh timer.&quo= t;  I
don't know why the refreshing massage must be first sent two more times in<= BR> one second and then sent as the refresh timer interval.  Is it ok if t= he
refreshing massage is sent only according to the value of the refresh timer= ?
If it is not, what problem may be introduced? Hope authors could explain it=
for me.

In addition, figure 2 is about the fault management massage format, so I think naming the figure" MPLS-TP fault Management Message Format "= ; other
than" MPLS-TP OAM Message Format " is more suitable.

Best Regards
Xinchun

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] O= n Behalf
Of Loa Andersson
Sent: Thursday, February 03, 2011 7:37 PM
To: mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

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

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.co= m
Sr Strategy and Standards Manager        = ;    loa@pi.nu
Ericsson Inc           &n= bsp;            =   phone: +46 10 717 52 13
            &nb= sp;            &= nbsp;            = ;        +46 767 72 92 13



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



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



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



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

--B_3392388939_149508971-- From yaacov.weingarten@nsn.com Sun Jul 3 04:36:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D6121F86FA for ; Sun, 3 Jul 2011 04:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clEwX+LSGdds for ; Sun, 3 Jul 2011 04:36:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DC10421F86F7 for ; Sun, 3 Jul 2011 04:36:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p63BajHv012864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Jul 2011 13:36:45 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p63Bai8p005907; Sun, 3 Jul 2011 13:36:44 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Jul 2011 13:36:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jul 2011 13:36:38 +0200 Message-ID: In-reply-to: <20110505183003.11091.93881.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments regarding draft-ietf-mpls-tp-fault-04.txt Thread-index: AcwLUzV3yacpGCtMQwq3AcunSjovvAuGzi5g References: <20110505183003.11091.93881.idtracker@ietfa.amsl.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 03 Jul 2011 11:36:44.0478 (UTC) FILETIME=[7C361DE0:01CC3975] Cc: draft-ietf-mpls-tp-fault@tools.ietf.org Subject: [mpls] Comments regarding draft-ietf-mpls-tp-fault-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 11:36:55 -0000 Hi all, I have some comments concerning the I-D on Fault Management for MPLS-TP Editorial comments: 1. In section 1: Change "When a disruption occurs on any link or node along the path of such a transport circuit, OAM are generated ..." to read "OAM indications are generated" (Note: OAM is a class of functionality and I don't think that they are generated, either OAM messages or indications could be generated) 2.In section 2.1.1 third paragraph: "...the LDI flag may be ignored." Shouldn't this be a normative MAY? (considering that in the next sentence you use a normative SHOULD) 3.Section 2.2: "...has been administratively locked to communicated that condition ..." Not sure what the intention was - either change /communicated/communication,/ or change /locked to communicated/locked, to communicate/ 4.Section 3: change "The FM Channel does not use ACH TLVs and MUST not..." to "and MUST NOT ..." 5.Section 5.3 change "to ensure that that" to "to ensure that" 6. Section 6: change "are optional to implement" to "are OPTIONAL to implement" 7. Section 8.1: change "0xHHHH" to "0xHH" to align with the other occurrences (even though this will eventually be changed by the RFC Editor) Questions for clarification: 1. In section 2 it states that "The messages are sent to the client MEPs by inserting them in the affected LSPs in the direction opposite to the detecting MEP's peer server MEP(s)." While I know that this has been discussed between the IETF and the ITU-T, I am not sure that I understand how the client MIP that is actually sending the OAM message knows which direction is "opposite to the detecting..." is there some indication that is included in the indication (or is this out-of-scope to this I-D and part of some external document?). 2. Section 2.1.1 It is unclear to me from reading this section when you are referring to protection switching at the Server layer and when to protection/recovery at the Client level. For example, in reference to the LDI flag you state - "However if the protection switch was unsuccessful in restoring the link ..., the LDI flag MUST be set." Which level is performing the protection switch that was unsuccessful? Earlier (at the end of Section 2.1) you state that "When the LDI is set, ... to trigger recovery mechanisms" is this at the Client layer? Later you speak of the LDI flag being dependent upon whether the Server layer is protected or not. 3. Section 4.1.1-3 deal with the encoding of different identifier TLVs - wouldn't it be safer to just reference the mpls-tp-identifiers draft? In light of the recent discussion shouldn't section 4.1.3 be clarified regarding the use of Country Codes in the Global ICC? 4. Section 5.2 states that "Other fields of the FM message SHOULD NOT be modified." Yet in section 5.3 it states that a FM message with the R-flag set is ignored if the Msg Type field and Interface Identifier TLV do not match an existing condition. In light of this, shouldn't it be stated that these two fields SHALL NOT be modified? Also shouldn't there be more normative text in the second paragraph of section 5.3? Thanx and Best regards, Yaacov -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, May 05, 2011 9:30 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-fault-04.txt A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Fault Management OAM Author(s) : G. Swallow, et al Filename : draft-ietf-mpls-tp-fault-04.txt Pages : 15 Date : 2011-04-26 =20 This draft specifies OAM messages to indicate service disruptive conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From loa@pi.nu Mon Jul 4 00:01:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FB321F861D for ; Mon, 4 Jul 2011 00:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAPyjfPTGfgz for ; Mon, 4 Jul 2011 00:01:50 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7D45321F861F for ; Mon, 4 Jul 2011 00:01:50 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2B8ED514044; Mon, 4 Jul 2011 09:01:47 +0200 (CEST) Message-ID: <4E116559.3040206@pi.nu> Date: Mon, 04 Jul 2011 09:01:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org References: <4DF9B561.6050806@pi.nu> In-Reply-To: <4DF9B561.6050806@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closed: Re: working group last call on draft-ietf-mpls-tp-mib-management-overview-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 07:01:51 -0000 All, this working group last call is closed. There has been comments, can the authors please update the draft and republish it. /Loa for the mpls wg chairs On 2011-06-16 09:48, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-mib-management-overview-04.txt > > Please send your comments to the mpls@ietf.org mailing list. > > This working group last call ends on June 30th 2011. > > > /Loa > > for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From stbryant@cisco.com Mon Jul 4 04:29:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38021F86E6 for ; Mon, 4 Jul 2011 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fUBet7s8zQK for ; Mon, 4 Jul 2011 04:29:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3158E21F86E5 for ; Mon, 4 Jul 2011 04:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2731; q=dns/txt; s=iport; t=1309778979; x=1310988579; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=DHICBqYG1SfCcdlMPoV0XHg1fJk2+h26X2qqLP9WKF0=; b=ml2f97U1LtniBcoQnrtIn4SCqRo9CKmRi6LB3zGaoErNvuhGI69mMouH oz9LHSAwtkxinoJ5s5Z7OkfKXFG1fBC7D8/ZH9WSav4+sLE2Ki7KRLL7+ y/8nzNkuDZRorA4JIQH5z1cgQFjWYXFgZCSmIUr6pWk6hl+eVaY7D4+T1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAEOjEU6Q/khR/2dsb2JhbABShEKUSI5zd601gxUPAYlygVeOSIUqgQwEkjaQNw X-IronPort-AV: E=Sophos;i="4.65,471,1304294400"; d="scan'208,217";a="40480724" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 04 Jul 2011 11:29:35 +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 p64BTZeQ001516 for ; Mon, 4 Jul 2011 11:29:35 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p64BTYeM012929; Mon, 4 Jul 2011 12:29:35 +0100 (BST) Message-ID: <4E11A471.1080508@cisco.com> Date: Mon, 04 Jul 2011 12:30:57 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: mpls@ietf.org References: <4E0D9AA6.3060504@gmail.com> In-Reply-To: <4E0D9AA6.3060504@gmail.com> Content-Type: multipart/alternative; boundary="------------040200090507080504010400" Subject: Re: [mpls] ICC and CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 11:29:40 -0000 This is a multi-part message in MIME format. --------------040200090507080504010400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have been away for a few days and so have only just had time to read the thread. Here is what I posted to the ITU list: I pulled up a copy of Y.1731-2008 Y.1731-2008 defines MEG ID type 32 It says length MUST be 13 It says MEG ID MUST be 7 to 12 characters It says that everything that follows the last alpha/numeric MUST be a NULL. An implementation can expect that this definition of type 32 is definitive and that any thing else is an error. It is impossible to do an exhaustive investigation of all existing implementations and implementations in progress. Thus to change the definition of type 32 is unsafe. Therefore the only safe way to introduce an ICC that contains a country code is to define a new MEG ID type. A new MEG ID type is not constrained by the definition of type 32. - Stewart (no hats on) --------------040200090507080504010400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have been away for a few days and so have only just had time to read the thread. Here is what I posted to the ITU list:

I pulled up a copy of Y.1731-2008

Y.1731-2008 defines MEG ID type 32

It says length MUST be 13

It says MEG ID MUST be 7 to 12 characters

It says that everything that follows the last alpha/numeric MUST be a NULL.

An implementation can expect that this definition of type 32 is definitive and that any thing else is an error.

It is impossible to do an exhaustive investigation of all existing implementations and implementations in progress. Thus to change the definition of type 32 is unsafe.

Therefore the only safe way to introduce an ICC that contains a country code is to define a new MEG ID type.

A new MEG ID type  is not constrained by the definition of type 32.

- Stewart (no hats on)



--------------040200090507080504010400-- From huubatwork@gmail.com Mon Jul 4 04:57:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447081F0C40 for ; Mon, 4 Jul 2011 04:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94XdFWuke1sF for ; Mon, 4 Jul 2011 04:57:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEC1F0C34 for ; Mon, 4 Jul 2011 04:57:24 -0700 (PDT) Received: by ewy19 with SMTP id 19so2119511ewy.31 for ; Mon, 04 Jul 2011 04:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Hc1+SdahU2OjpO/07qJxmkCrQoHNN/wGglfawwgTEZM=; b=pA8/r2mR+lJqttmSX0WwZaI/w9buabEo+GZfbBEGLh8d1C96e8H1kinlaWVDpV6w2h jwzZUJi8DtSixEXSR21Y663JDgxT2kF1lMgOyDtTyO1VZ6ndCY9ifu994fyYOKsQE0M8 YBJY5CYksGjMESrDBTOVjg2yS7czlEwvdHHZE= Received: by 10.213.35.202 with SMTP id q10mr1378351ebd.64.1309780642860; Mon, 04 Jul 2011 04:57:22 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id b9sm4558809een.8.2011.07.04.04.57.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 04:57:21 -0700 (PDT) Message-ID: <4E11AAA0.1010401@gmail.com> Date: Mon, 04 Jul 2011 13:57:20 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <4E0D9AA6.3060504@gmail.com> <4E11A471.1080508@cisco.com> In-Reply-To: <4E11A471.1080508@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] ICC and CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 11:57:25 -0000 Hello Stewart, You wrote: > I have been away for a few days and so have only just had time to > read the thread. (Maybe you skipped a few messages) The request from George was for the definition of a global unique ICC for *MPLS-TP*. The answer is: To make it globally unique use the format: [ICC]/[CC] where [ICC] is the 1-6 character ITU-T Carrier Code, and [CC] is the 2 character ISO Country Code. > Here is what I posted to the ITU list: > > I pulled up a copy of Y.1731-2008 This addresses Y.1731 and is not relevant to the question from George. Regards, Huub. From malcolm.betts@zte.com.cn Mon Jul 4 07:30:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051BD21F8745; Mon, 4 Jul 2011 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlhpq2yMJUde; Mon, 4 Jul 2011 07:30:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2021F8710; Mon, 4 Jul 2011 07:30:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321784411434; Mon, 4 Jul 2011 22:26:37 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.3558939487; Mon, 4 Jul 2011 22:30:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p64EUc3E075286; Mon, 4 Jul 2011 22:30:38 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <4E11A471.1080508@cisco.com> References: <4E0D9AA6.3060504@gmail.com> <4E11A471.1080508@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-KeepSent: 503BBE61:ACD95364-852578C3:004F9370; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Mon, 4 Jul 2011 10:30:35 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-04 22:30:41, Serialize complete at 2011-07-04 22:30:41 Content-Type: multipart/alternative; boundary="=_alternative 004FB5A1852578C3_=" X-MAIL: mse01.zte.com.cn p64EUc3E075286 Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] ICC and CC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 14:30:56 -0000 This is a multipart message in MIME format. --=_alternative 004FB5A1852578C3_= Content-Type: text/plain; charset="US-ASCII" Stewart, Why did you post this on the mpls list, this only impacts G.8013/Y.1731 i.e. Ethernet. It has no impact on MPLS-TP. Regards, Malcolm Stewart Bryant Sent by: mpls-bounces@ietf.org 04/07/2011 07:30 AM Please respond to stbryant@cisco.com To mpls@ietf.org cc Subject Re: [mpls] ICC and CC I have been away for a few days and so have only just had time to read the thread. Here is what I posted to the ITU list: I pulled up a copy of Y.1731-2008 Y.1731-2008 defines MEG ID type 32 It says length MUST be 13 It says MEG ID MUST be 7 to 12 characters It says that everything that follows the last alpha/numeric MUST be a NULL. An implementation can expect that this definition of type 32 is definitive and that any thing else is an error. It is impossible to do an exhaustive investigation of all existing implementations and implementations in progress. Thus to change the definition of type 32 is unsafe. Therefore the only safe way to introduce an ICC that contains a country code is to define a new MEG ID type. A new MEG ID type is not constrained by the definition of type 32. - Stewart (no hats on) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 004FB5A1852578C3_= Content-Type: text/html; charset="US-ASCII" Stewart,

Why did you post this on the mpls list, this only impacts G.8013/Y.1731 i.e. Ethernet.  It has no impact on MPLS-TP.

Regards,

Malcolm



Stewart Bryant <stbryant@cisco.com>
Sent by: mpls-bounces@ietf.org

04/07/2011 07:30 AM
Please respond to
stbryant@cisco.com
To
mpls@ietf.org
cc
Subject
Re: [mpls] ICC and CC





I have been away for a few days and so have only just had time to read the thread. Here is what I posted to the ITU list:

I pulled up a copy of Y.1731-2008

Y.1731-2008 defines MEG ID type 32

It says length MUST be 13

It says MEG ID MUST be 7 to 12 characters

It says that everything that follows the last alpha/numeric MUST be a NULL.

An implementation can expect that this definition of type 32 is definitive and that any thing else is an error.

It is impossible to do an exhaustive investigation of all existing implementations and implementations in progress. Thus to change the definition of type 32 is unsafe.

Therefore the only safe way to introduce an ICC that contains a country code is to define a new MEG ID type.

A new MEG ID type  is not constrained by the definition of type 32.

- Stewart (no hats on)


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 004FB5A1852578C3_=-- From RCosta@ptinovacao.pt Mon Jul 4 15:02:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373081F0C42; Mon, 4 Jul 2011 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyXzKojjnqtO; Mon, 4 Jul 2011 15:02:35 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCDF1F0C3B; Mon, 4 Jul 2011 15:02:35 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Mon, 4 Jul 2011 23:02:33 +0100 From: Rui Costa To: "ietf@ietf.org" , IETF-Announce Date: Mon, 4 Jul 2011 23:02:31 +0100 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWg Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> In-Reply-To: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:02:39 -0000 IMHO and for the record:=09 ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent.=09 Several service providers regarded this draft as not meeting their transpor= t networks' needs.=09 [The v03 draft was published in Feb and went to WG LC.=09 The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up).=09 When was the WG LC launched, to verify LC comments resolution?]=09 Regards,=09 Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From fu.xihua@zte.com.cn Mon Jul 4 20:25:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BEB11E8088; Mon, 4 Jul 2011 20:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.299 X-Spam-Level: X-Spam-Status: No, score=-97.299 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+boVSp+-uy1; Mon, 4 Jul 2011 20:25:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C207111E8072; Mon, 4 Jul 2011 20:25:48 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322623888924; Tue, 5 Jul 2011 11:21:26 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.5883294140; Tue, 5 Jul 2011 11:25:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p653Ox7X052164; Tue, 5 Jul 2011 11:24:59 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <4E127CA3.1060607@labn.net> To: Lou Berger , Ross Callon , Acee Lindem MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Tue, 5 Jul 2011 11:24:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-05 11:24:59, Serialize complete at 2011-07-05 11:24:59 Content-Type: multipart/alternative; boundary="=_alternative 0012C477482578C4_=" X-MAIL: mse01.zte.com.cn p653Ox7X052164 Cc: OSPF WG List , CCAMP , "mpls-chairs@tools.ietf.org" , MPLS WG List Subject: Re: [mpls] [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 03:25:50 -0000 This is a multipart message in MIME format. --=_alternative 0012C477482578C4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91LCBSb3NzDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZS4NCg0KQmFzZWQgb24g ZW1haWxzIGZyb20geW91IGFuZCBteSB1bmRlcnN0YW5kaW5nLCB0aGVzZSB3b3JrcyBzaG91bGQg YmUgZG9uZSANCmluIE1QTFMgV0cuDQpZZXN0ZXJkYXkgbmlnaHQsIHdlIHVwbG9hZGVkIGZyYW1l d29yay9yZXF1aXJlbWVudCBkb2N1bWVudCB0byBDQ0FNUC9SVEdXRyANCmFuZCByc3ZwLXRlIHRv IENDQU1QLiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZ1eGgtY2NhbXAtZGVs YXktbG9zcy10ZS1mcmFtZXdvcmstMDANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWZ1eGgtcnRnd2ctZGVsYXktbG9zcy10ZS1mcmFtZXdvcmstMDANCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWZ1eGgtY2NhbXAtZGVsYXktbG9zcy1yc3ZwLXRlLWV4dC0wMA0KSXQg ZG9lc24ndCBtZWFucyB3ZSBhcmUgZ29pbmcgdG8gdmlvbGF0ZSBjaGFpcnMnIGRlY2lzaW9uLg0K QXMgeW91IHN1Z2dlc3QsIHdlIHdpbGwgZml4IGRyYWZ0IG5hbWUgaGF2aW5nIHRoZSB3b3JkIKGw TVBMU6GxIGluIHRoZSANCnRpdGxlIGFuZCBwb3N0IHRvIE1QTFMgV0cgYXQgYSBsYXRlciBkYXRl Lg0KV2Ugd2lsbCByZXF1ZXN0IHRpbWUgc2xvdHMgdG8gcHJlc2VudCB0d28gZG9jdW1lbnRzIGZv ciB0aGUgdXBjb21pbmcgODFzdCANCm1lZXRpbmcuDQpTbyBpdCBpcyBhIGdvb2QgbmV3cyBmb3Ig dXMgdG8gaGF2ZSBjb21wbGV0ZSBzb2x1dGlvbiBvZiBsYXRlbmN5IGFuZCBsb3NzIA0KVEUgYXBw bGljYXRpb24gYmFzZWQgb24gZnJhbWV3b3JrL3JlcXVpcmVtZW50LCANCmRyYWZ0LWdpYWNhbG9u ZS1vc3BmLXRlLWV4cHJlc3MtcGF0aCBhbmQgcnN2cC10ZSBkb2N1bWVudC4NCg0KWGlodWEgRnUN Cg0KDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0KMjAxMS0wNy0wNSDJz87nIDEw OjUzDQoNCsrVvP7Iyw0KZnUueGlodWFAenRlLmNvbS5jbg0Ks63LzQ0KQWNlZSBMaW5kZW0gPGFj ZWUubGluZGVtQGVyaWNzc29uLmNvbT4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZz4sIA0KIm1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnIiA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBPU1BG IFdHIExpc3QgDQo8b3NwZkBpZXRmLm9yZz4sIFZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZA Z21haWwuY29tPg0K1vfM4g0KUmU6IFtDQ0FNUF0gW09TUEZdIGRyYWZ0LWdpYWNhbG9uZS1vc3Bm LXRlLWV4cHJlc3MtcGF0aC0wMQ0KDQoNCg0KDQoNCg0KRm9yIG5vdywgdGhlIGZyYW1ld29yay9y ZXF1aXJlbWVudCBhbmQgcnN2cC10ZSBkb2N1bWVudCBzaG91bGQgYmUNCnByZXNlbnRlZCBpbiBN UExTLiAgRG9uJ3Qgd29ycnkgYWJvdXQgdGhlIGRyYWZ0IG5hbWVzIGFzIHRoYXQgY2FuIGJlDQpm aXhlZCBhdCBhIGxhdGVyIGRhdGUuDQoNCkxvdQ0KDQpPbiA3LzQvMjAxMSA3OjE1IEFNLCBmdS54 aWh1YUB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGkgTG91DQo+IA0KPiBXb3VsZCB5b3UgbGlr ZSB0byBpbmZvcm0gdXMgdGhlIGRlY2lzaW9uPw0KPiBUb25pZ2h0IGlzIHRoZSBkZWFkbGluZSBm b3IgMDAtZHJhZnQgdXBsb2FkaW5nLiBJZiBjaGFpcnMgZGVjaWRlIHRoaXMNCj4gd29yayBzaG91 bGQgYmUgcG9zdGVkIHRvIG90aGVyIFdHcy4gU28gd2Ugd2lsbCBwb3N0IHRoZW0gdG8gYSBwcm9w ZXIgV0cuDQo+IE90aGVyd2lzZSAgd2UgaGF2ZSB0byBwb3N0IGZyYW1ld29yay9yZXF1aXJlbWVu dCBhbmQgcnN2cC10ZSBkb2N1bWVudCB0bw0KPiBDQ0FNUC4gVGhlIHdvcmsgaXMgcmVsYXRlZCBi b3RoIHBhY2tldCAoZS5nLiwgTVBMUykgYW5kIHRkbSAoZS5nLiwgT1ROKQ0KPiANCj4gWGlodWEN Cj4gDQo+IA0KPiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+IA0KPiAyMDExLTA2 LTMwIM/CzucgMDg6MTkNCj4gDQo+IA0KPiDK1bz+yMsNCj4gICAgICAgICAgICAgICAgZnUueGlo dWFAenRlLmNvbS5jbg0KPiCzrcvNDQo+ICAgICAgICAgICAgICAgIFZpc2h3YXMgTWFucmFsIDx2 aXNod2FzLmlldGZAZ21haWwuY29tPiwgQWNlZSBMaW5kZW0NCj4gPGFjZWUubGluZGVtQGVyaWNz c29uLmNvbT4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZz4sIE9TUEYgV0cgTGlzdA0KPiA8b3NwZkBp ZXRmLm9yZz4sICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgDQo8bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+DQo+INb3zOINCj4gICAgICAgICAgICAgICAgUmU6IFtDQ0FNUF0gW09TUEZd IA0KZHJhZnQtZ2lhY2Fsb25lLW9zcGYtdGUtZXhwcmVzcy1wYXRoLTAxDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gWGlodWEsDQo+ICAgICAgICAgICAgICAgICBGb3IgYXQgbGVh c3Qgbm93LCB0aGUgT1NQRiB3b3JrIHNob3VsZCBiZSBkb25lIGluIHRoZQ0KPiBPU1BGIFdHLiAg VGhlDQo+IGNoYWlycyBvZiB0aGUgdmFyaW91cyBjYW5kaWRhdGUgV0cgYXJlIGhhdmluZyBzb21l IG9mZi1saW5lIGRpc2N1c3Npb25zDQo+IG9uIHdlcmUgdGhlIHJlcXVpcmVtZW50cy9SU1ZQIHdv cmsgYmVsb25ncy4gIFdlIHNob3VsZCBoYXZlIGFuIGFuc3dlcg0KPiBmb3IgeW91IGJ5IGVhcmx5 IG5leHQgd2Vlay4NCj4gDQo+IExvdQ0KPiANCj4gUFMgUGxlYXNlIGRvbid0IGNjIGNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcgb24gbWFpbCB5b3Ugc2VuZCwgaXQgbWFrZXMgdGhlDQo+IG1haWwgc3lz dGVtIHRoaW5rIHlvdXIgbWFpbCBpcyBhIGJvdW5jZSENCj4gDQo+IE9uIDYvMjkvMjAxMSA5OjQ0 IFBNLCBmdS54aWh1YUB6dGUuY29tLmNuIHdyb3RlOg0KPj4gSSBoYXZlIGEgcXVlc3Rpb24gdG8g Y2hhaXJzIGFuZCB0aGUgYXV0aG9ycy4gQmVjYXVzZSB0aGVyZSBhcmUgbW9yZSBhbmQNCj4+IG1v cmUgZG9jdW1lbnRzIGFwcGVhcmluZywgd2Ugc2hvdWxkIHRoaW5rIGFib3V0IGhvdyB0byBtb3Zl IGZvcndhcmQNCj4+IHRoZXNlIHdvcmsuDQo+PiBXaGF0J3MgeW91ciBvcGluaW9uPyANCj4gDQo+ IA0KDQoNCg0K --=_alternative 0012C477482578C4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdSwgUm9zczwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5 b3VyIHJlc3BvbnNlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QmFzZWQgb24gZW1haWxzIGZyb20geW91IGFuZCBteSB1bmRlcnN0YW5kaW5nLA0KdGhl c2Ugd29ya3Mgc2hvdWxkIGJlIGRvbmUgaW4gTVBMUyBXRy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllc3RlcmRheSBuaWdodCwgd2UgdXBsb2FkZWQgZnJhbWV3 b3JrL3JlcXVpcmVtZW50DQpkb2N1bWVudCB0byBDQ0FNUC9SVEdXRyBhbmQgcnN2cC10ZSB0byBD Q0FNUC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdXhoLWNjYW1wLWRlbGF5LWxvc3MtdGUtZnJhbWV3 b3JrLTAwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdXhoLXJ0Z3dnLWRlbGF5LWxvc3MtdGUtZnJhbWV3 b3JrLTAwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdXhoLWNjYW1wLWRlbGF5LWxvc3MtcnN2cC10ZS1l eHQtMDA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IGRvZXNu J3QgbWVhbnMgd2UgYXJlIGdvaW5nIHRvIHZpb2xhdGUNCmNoYWlycycgZGVjaXNpb24uPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyB5b3Ugc3VnZ2VzdCwgd2Ug d2lsbCBmaXggZHJhZnQgbmFtZQ0KaGF2aW5nIHRoZSB3b3JkIKGwTVBMU6GxIGluIHRoZSB0aXRs ZSBhbmQgcG9zdCB0byBNUExTIFdHIGF0IGEgbGF0ZXINCmRhdGUuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSB3aWxsIHJlcXVlc3QgdGltZSBzbG90cyB0byBw cmVzZW50DQp0d28gZG9jdW1lbnRzIGZvciB0aGUgdXBjb21pbmcgODFzdCBtZWV0aW5nLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gaXQgaXMgYSBnb29kIG5l d3MgZm9yIHVzIHRvIGhhdmUNCmNvbXBsZXRlIHNvbHV0aW9uIG9mIGxhdGVuY3kgYW5kIGxvc3Mg VEUgYXBwbGljYXRpb24gYmFzZWQgb24gZnJhbWV3b3JrL3JlcXVpcmVtZW50LA0KZHJhZnQtZ2lh Y2Fsb25lLW9zcGYtdGUtZXhwcmVzcy1wYXRoIGFuZCByc3ZwLXRlIGRvY3VtZW50LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WGlodWEgRnU8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdl ciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0wNSDJz87nIDEwOjUzPC9mb250Pg0KPHRkIHdpZHRo PTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmZ1LnhpaHVhQHp0ZS5jb20u Y248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkFjZWUgTGluZGVtICZsdDthY2VlLmxpbmRlbUBlcmljc3Nv bi5jb20mZ3Q7LA0KQ0NBTVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OywgJnF1b3Q7bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0 OywNCk9TUEYgV0cgTGlzdCAmbHQ7b3NwZkBpZXRmLm9yZyZndDssIFZpc2h3YXMgTWFucmFsICZs dDt2aXNod2FzLmlldGZAZ21haWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FN UF0gW09TUEZdIGRyYWZ0LWdpYWNhbG9uZS1vc3BmLXRlLWV4cHJlc3MtcGF0aC0wMTwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Rm9yIG5v dywgdGhlIGZyYW1ld29yay9yZXF1aXJlbWVudCBhbmQgcnN2cC10ZSBkb2N1bWVudA0Kc2hvdWxk IGJlPGJyPg0KcHJlc2VudGVkIGluIE1QTFMuICZuYnNwO0Rvbid0IHdvcnJ5IGFib3V0IHRoZSBk cmFmdCBuYW1lcyBhcyB0aGF0IGNhbg0KYmU8YnI+DQpmaXhlZCBhdCBhIGxhdGVyIGRhdGUuPGJy Pg0KPGJyPg0KTG91PGJyPg0KPGJyPg0KT24gNy80LzIwMTEgNzoxNSBBTSwgZnUueGlodWFAenRl LmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgTG91PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFdvdWxkIHlvdSBsaWtlIHRvIGluZm9ybSB1cyB0aGUgZGVjaXNpb24/PGJyPg0KJmd0 OyBUb25pZ2h0IGlzIHRoZSBkZWFkbGluZSBmb3IgMDAtZHJhZnQgdXBsb2FkaW5nLiBJZiBjaGFp cnMgZGVjaWRlIHRoaXM8YnI+DQomZ3Q7IHdvcmsgc2hvdWxkIGJlIHBvc3RlZCB0byBvdGhlciBX R3MuIFNvIHdlIHdpbGwgcG9zdCB0aGVtIHRvIGEgcHJvcGVyDQpXRy48YnI+DQomZ3Q7IE90aGVy d2lzZSAmbmJzcDt3ZSBoYXZlIHRvIHBvc3QgZnJhbWV3b3JrL3JlcXVpcmVtZW50IGFuZCByc3Zw LXRlDQpkb2N1bWVudCB0bzxicj4NCiZndDsgQ0NBTVAuIFRoZSB3b3JrIGlzIHJlbGF0ZWQgYm90 aCBwYWNrZXQgKGUuZy4sIE1QTFMpIGFuZCB0ZG0gKGUuZy4sDQpPVE4pPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFhpaHVhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKkxvdSBCZXJnZXIg Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7Kjxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDExLTA2LTMw IM/CzucgMDg6MTk8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IMrVvP7Iyzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtmdS54aWh1YUB6dGUuY29tLmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1Zpc2h3YXMNCk1hbnJhbCAmbHQ7dmlzaHdhcy5pZXRmQGdtYWlsLmNvbSZndDssIEFj ZWUgTGluZGVtPGJyPg0KJmd0OyAmbHQ7YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tJmd0OywgQ0NB TVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OywgT1NQRg0KV0cgTGlzdDxicj4NCiZndDsgJmx0O29z cGZAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZxdW90OyAm bHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JlOg0KW0NDQU1QXSBbT1NQRl0gZHJhZnQtZ2lhY2Fsb25lLW9zcGYtdGUtZXhwcmVz cy1wYXRoLTAxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBY aWh1YSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRm9yIGF0IGxlYXN0DQpub3csIHRoZSBPU1BGIHdvcmsgc2hvdWxkIGJl IGRvbmUgaW4gdGhlPGJyPg0KJmd0OyBPU1BGIFdHLiAmbmJzcDtUaGU8YnI+DQomZ3Q7IGNoYWly cyBvZiB0aGUgdmFyaW91cyBjYW5kaWRhdGUgV0cgYXJlIGhhdmluZyBzb21lIG9mZi1saW5lIGRp c2N1c3Npb25zPGJyPg0KJmd0OyBvbiB3ZXJlIHRoZSByZXF1aXJlbWVudHMvUlNWUCB3b3JrIGJl bG9uZ3MuICZuYnNwO1dlIHNob3VsZCBoYXZlIGFuDQphbnN3ZXI8YnI+DQomZ3Q7IGZvciB5b3Ug YnkgZWFybHkgbmV4dCB3ZWVrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7IDxi cj4NCiZndDsgUFMgUGxlYXNlIGRvbid0IGNjIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgb24gbWFp bCB5b3Ugc2VuZCwgaXQgbWFrZXMNCnRoZTxicj4NCiZndDsgbWFpbCBzeXN0ZW0gdGhpbmsgeW91 ciBtYWlsIGlzIGEgYm91bmNlITxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA2LzI5LzIwMTEgOTo0 NCBQTSwgZnUueGlodWFAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBJIGhhdmUgYSBx dWVzdGlvbiB0byBjaGFpcnMgYW5kIHRoZSBhdXRob3JzLiBCZWNhdXNlIHRoZXJlIGFyZQ0KbW9y ZSBhbmQ8YnI+DQomZ3Q7Jmd0OyBtb3JlIGRvY3VtZW50cyBhcHBlYXJpbmcsIHdlIHNob3VsZCB0 aGluayBhYm91dCBob3cgdG8gbW92ZSBmb3J3YXJkPGJyPg0KJmd0OyZndDsgdGhlc2Ugd29yay48 YnI+DQomZ3Q7Jmd0OyBXaGF0J3MgeW91ciBvcGluaW9uPyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0012C477482578C4_=-- From lizhong.jin@zte.com.cn Mon Jul 4 23:15:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2EB11E80A6 for ; Mon, 4 Jul 2011 23:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjUnAvX1JoNY for ; Mon, 4 Jul 2011 23:15:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3112D11E8074 for ; Mon, 4 Jul 2011 23:15:25 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 13132806486374; Tue, 5 Jul 2011 14:10:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 75229.3584101308; Tue, 5 Jul 2011 14:15:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p656FGcX097073; Tue, 5 Jul 2011 14:15:16 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 5 Jul 2011 14:15:11 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-05 14:15:17, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-05 14:15:17, Serialize complete at 2011-07-05 14:15:17, S/MIME Sign failed at 2011-07-05 14:15:17: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-05 14:15:17 Content-Type: multipart/alternative; boundary="=_alternative 00225BD9482578C4_=" X-MAIL: mse01.zte.com.cn p656FGcX097073 Subject: [mpls] Questions for RFC5561 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 06:15:27 -0000 This is a multipart message in MIME format. --=_alternative 00225BD9482578C4_= Content-Type: text/plain; charset="US-ASCII" Hi all, RFC 5561 does not explicitly describe the LDP advertisement procedure of capability withdraw. Then if one LDP speaker decides to withdraw one capability, there are two options: 1. withdraw the FEC advertisement first, then capability negotiation with the peer. But what if negotiation failed? 2. capability negotiation with the peer first, then withdraw the FEC. But if capability is disable, how to withdraw the FEC. Which one should be used then? Hope to see the clarification. Thank you Lizhong -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00225BD9482578C4_= Content-Type: text/html; charset="US-ASCII"
Hi all,
RFC 5561 does not explicitly describe the LDP advertisement procedure of capability withdraw. Then if one LDP speaker decides to withdraw one capability, there are two options:
1. withdraw the FEC advertisement first, then capability negotiation with the peer. But what if negotiation failed?
2. capability negotiation with the peer first, then withdraw the FEC. But if capability is disable, how to withdraw the FEC.
Which one should be used then? Hope to see the clarification.

Thank you
Lizhong
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00225BD9482578C4_=-- From Thomas.Beckhaus@telekom.de Tue Jul 5 00:10:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF221F853E for ; Tue, 5 Jul 2011 00:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDHJVz3HG6N1 for ; Tue, 5 Jul 2011 00:10:28 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6221F853D for ; Tue, 5 Jul 2011 00:10:26 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jul 2011 09:10:15 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.22]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Jul 2011 09:10:15 +0200 From: To: Date: Tue, 5 Jul 2011 09:10:14 +0200 Thread-Topic: New Version Notification for draft-beckhaus-ldp-dod-00.txt Thread-Index: Acw6VHYIHNFf+Fb5Teay5xq7QioyiAAjANlw Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: bruno.decraene@francetelecom.com Subject: [mpls] FW: New Version Notification for draft-beckhaus-ldp-dod-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 07:10:29 -0000 SGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iZWNraGF1cy1sZHAtZG9kLTAwKSB0aGF0IGRlc2NyaWJlcyB0aGUgTERQ IERvd25zdHJlYW0tb24tRGVtYW5kIChEb0QpIGRlc2lnbiBpbiB0aGUgU2VhbWxlc3MgTVBMUyBh cHByb2FjaC4NCg0KSXQgY2xhcmlmaWVzIHNvbWUgb3BlbiBpc3N1ZXMgd2UgaGF2ZSBpZGVudGlm aWVkIGluIFJGQzUwMzYsIGlmIExEUCBEb0QgaXMgdXNlZCBvbiB0aGUgZWRnZSBvZiB0aGUgU2Vh bWxlc3MgTVBMUyBuZXR3b3JrIGJldHdlZW4gdGhlIGFjY2VzcyBub2RlKHMpIChBTikgYW5kIHRo ZSBmaXJzdCBhZ2dyZWdhdGlvbiBub2RlIChBR04xIGluIHRoZSBTZWFtbGVzcy1NUExTIGRlc2ln bikuDQoNCldlJ2QgYXBwcmVjaWF0ZSB0byByZWNlaXZlIHlvdXIgY29tbWVudHMhDQoNCkJlc3Qg cmVnYXJkcywNCg0KVGhvbWFzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQ0KPiBTZW50OiBNb25kYXksIEp1bHkgMDQsIDIwMTEgNDoxMiBQTQ0KPiBUbzogQmVja2hh dXMsIFRob21hcw0KPiBDYzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLWZ0Z3JvdXAuY29tOyBtYWNp ZWtAanVuaXBlci5uZXQ7DQo+IEJlY2toYXVzLCBUaG9tYXM7IGtpc2hvcmV0QGp1bmlwZXIubmV0 DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVja2hhdXMt bGRwLWRvZC0wMC50eHQNCj4NCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlY2toYXVz LWxkcC1kb2QtMDAudHh0IGhhcyBiZWVuDQo+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGhv bWFzIEJlY2toYXVzIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4NCj4g RmlsZW5hbWU6ICAgICAgZHJhZnQtYmVja2hhdXMtbGRwLWRvZA0KPiBSZXZpc2lvbjogICAgICAw MA0KPiBUaXRsZTogICAgICAgICAgICAgICAgIExEUCBEb3duc3RyZWFtLW9uLURlbWFuZCBpbiBT ZWFtbGVzcyBNUExTDQo+IENyZWF0aW9uIGRhdGU6ICAgICAgICAgMjAxMS0wNy0wNA0KPiBXRyBJ RDogICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFn ZXM6IDIxDQo+DQo+IEFic3RyYWN0Og0KPiAgICBTZWFtbGVzcyBNUExTIGRlc2lnbiBlbmFibGVz IGEgc2luZ2xlIElQL01QTFMgbmV0d29yayB0byBzY2FsZSBvdmVyDQo+ICAgIGNvcmUsIG1ldHJv IGFuZCBhY2Nlc3MgcGFydHMgb2YgYSBsYXJnZSBuZXR3b3JrDQo+IGluZnJhc3RydWN0dXJlIHVz aW5nDQo+ICAgIHN0YW5kYXJkaXplZCBJUC9NUExTIHByb3RvY29scy4gIE9uZSBvZiB0aGUga2V5 IGdvYWxzIG9mIFNlYW1sZXNzDQo+ICAgIE1QTFMgaXMgdG8gbWVldCByZXF1aXJlbWVudHMgc3Bl Y2lmaWMgdG8gYWNjZXNzIGRldmljZXMsIGJhc2VkIG9uDQo+ICAgIHRoZWlyIHBvc2l0aW9uIGlu IHRoZSBuZXR3b3JrIHRvcG9sb2d5IGFuZCB0aGVpciBjb21wdXRlIGFuZCBtZW1vcnkNCj4gICAg Y29uc3RyYWludHMgbGltaXQgdGhlIGFtb3VudCBvZiBzdGF0ZSB0aGV5IGNhbiBob2xkLiAgVGhp cyBjYW4gYmUNCj4gICAgYWNoaWV2ZWQgd2l0aCBMRFAgRG93bnN0cmVhbS1vbi1EZW1hbmQgKExE UCBEb0QpIGFzDQo+IHNwZWNpZmllZCBpbiBSRkMNCj4gICAgNTAzNiBbUkZDNTAzNl0uICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBMRFAgRG9EIHVzZSBjYXNlcw0KPiBhbmQgbGlzdHMNCj4gICAg TERQIERvRCBwcm9jZWR1cmVzIGluIHRoZSBjb250ZXh0IG9mIFNlYW1sZXNzIE1QTFMgZGVzaWdu Lg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0K From loa@pi.nu Tue Jul 5 08:11:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCE711E8224; Tue, 5 Jul 2011 08:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsbhUDUPhgwv; Tue, 5 Jul 2011 08:11:43 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFC311E80CD; Tue, 5 Jul 2011 08:11:36 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 83BDB514044; Tue, 5 Jul 2011 17:11:32 +0200 (CEST) Message-ID: <4E1329A4.6030908@pi.nu> Date: Tue, 05 Jul 2011 17:11:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: statements@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: loa.andersson@ericsson.com, mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, lear@cisco.com, yoichi.maeda@ttc.or.jp, ahmpls-tp@lists.itu.int, "tsbsg15@itu.int" , rcallon@juniper.net, hhelvoort@huawei.com, elisa.bellagamba@ericsson.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison: Response to liaison with comments on "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview" (ref #055.03) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:11:44 -0000 For Information. SG15, Q9, Q10, Q12 and Q14 Thank you for your liaison with comments on draft-ietf-mpls-tp-mib-management-overview-04.txt. The comments has been brought to the attention of the authors and will be resolved as part of the process resolving all comments received during the working group last call. Loa Andersson George Swallow Ross Callon MPLS Working Group co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From skraza@cisco.com Tue Jul 5 08:34:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574C711E80B9 for ; Tue, 5 Jul 2011 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t6x39GNq4dJ for ; Tue, 5 Jul 2011 08:34:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED511E8074 for ; Tue, 5 Jul 2011 08:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=7695; q=dns/txt; s=iport; t=1309880091; x=1311089691; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=rMWLkdqVEbiJYqE4T9LVSyDmJTY+qEpJQeibZJYAfjw=; b=hyHI1QERZFJyjjEyocku/oU/OSnUAobgkMVKQqCF6uG6KztNTqFvaSOx zmHLFd5Zg25J/wfASoQJ+Q2fMC9jRwBofBjmXUjza7LROqY4JsrOil5xc P9XBxjBGh67zb0ThX/2O6T1cpGexTlqojBXVufn/ZGGs9Divdgl1+xxm/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQHAP4tE06tJV2c/2dsb2JhbABNBoJRpEZuAneIeqQDnW+DO4J7BJI2hQGHQIQR X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208,217";a="267336" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jul 2011 15:34:50 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p65FYoOK032679; Tue, 5 Jul 2011 15:34:50 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 10:34:50 -0500 Received: from 161.44.212.216 ([161.44.212.216]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 5 Jul 2011 15:34:50 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 05 Jul 2011 11:34:51 -0400 From: Kamran Raza To: , Message-ID: Thread-Topic: Questions for RFC5561 Thread-Index: Acw7KRR3ZnjdGauX/EyhBOh2+W0kOg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392710491_25881026" X-OriginalArrivalTime: 05 Jul 2011 15:34:50.0384 (UTC) FILETIME=[1419E100:01CC3B29] Subject: Re: [mpls] Questions for RFC5561 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:34:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392710491_25881026 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Lizhong, The RFC5561 just provides a framework for capabilities and the detailed procedure for withdrawing a particular capability are to be stated in the capability document itself. For instance, The I-D draft-raza-mpls-ldp-olf-00.txt section 4.4.2 states LDP OLF procedures on capability changes/withdraws. Please see further inline for [skraza] On 11-07-05 2:15 AM, "lizhong.jin@zte.com.cn" wrote: >=20 > Hi all,=20 > RFC 5561 does not explicitly describe the LDP advertisement procedure of > capability withdraw. Then if one LDP speaker decides to withdraw one > capability, there are two options: > 1. withdraw the FEC advertisement first, then capability negotiation with= the > peer. But what if negotiation failed? >=20 > [skraza]: The capability withdrawal should implicitly remove any state (e= .g. > FEC) associated with it, without a need to explicitly remove/withdraw it.= BTW, > once capability is negotiated, its withdrawal should not fail. Can u plea= se > elaborate what do you mean by =B3negotiation failed=B2 at the capability > withdrawal time ? >=20 > =20 > 2. capability negotiation with the peer first, then withdraw the FEC. But= if > capability is disable, how to withdraw the FEC. > Which one should be used then? Hope to see the clarification. >=20 > [skraza]: Again, what exactly the term =B3negotiation=B2 means here ? If you = are > just withdrawing already a negotiated capability, why would this withdraw= al > fail ? If there are capability specific scenarios, then they must be cove= r in > capability documents. >=20 > Thanks. > --=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 >=20 >=20 > Thank you=20 > Lizhong >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. >=20 --B_3392710491_25881026 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Questions for RFC5561 Hi Lizhong,

The RFC5561 just provides a framework for capabilities and the detailed pro= cedure for withdrawing a particular capability are to be stated in the capab= ility document itself. For instance,
The I-D draft-raza-mpls-ldp-olf-00.txt section 4.4.2= states LDP OLF procedures on capability changes/withdraws.

Please see further inline for [skraza]

On 11-07-05 2:15 AM, "lizhong.jin@zte= .com.cn" <lizhong.jin@zte.com.c= n> wrote:

<= SPAN STYLE=3D'font-size:11pt'>
Hi all,
RFC 5561 does not explicitly describe the LDP advertisement procedure of ca= pability withdraw. Then if one LDP speaker decides to withdraw one capabilit= y, there are two options:
1. withdraw the FEC advertisement first, then capability negotiation with t= he peer. But what if negotiation failed?

[skraza]: The capability withdrawal should implicitly= remove any state (e.g. FEC) associated with it, without a need to explicitl= y remove/withdraw it. BTW, once capability is negotiated, its withdrawal sho= uld not fail. Can u please elaborate what do you mean by “negotiation = failed” at the capability withdrawal time ?

 
2. capability negotiation with the peer first, then withdraw the FEC. But i= f capability is disable, how to withdraw the FEC.
Which one should be used then? Hope to see the clarification.

[skraza]: Again, what exactly the term “negotia= tion” means here ? If you are just withdrawing already a negotiated ca= pability, why would this withdrawal fail ? If there are capability specific = scenarios, then they must be cover in capability documents.

Thanks.
--
=        &nbs= p;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


Thank you
Lizhong

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is con= fidential. Recipients named above are obligated to maintain secrecy and are = not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. I= f you have received this email in error please notify the originator of the = message. Any views expressed in this message are those of the individual sen= der.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

=




--B_3392710491_25881026-- From alessandro.dalessandro@telecomitalia.it Wed Jul 6 01:16:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9521F841D; Wed, 6 Jul 2011 01:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZi9vevlktyY; Wed, 6 Jul 2011 01:16:28 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4221F84D5; Wed, 6 Jul 2011 01:16:13 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Jul 2011 10:16:10 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Wed, 6 Jul 2011 10:16:10 +0200 From: D'Alessandro Alessandro Gerardo To: "ietf@ietf.org" Date: Wed, 6 Jul 2011 10:16:09 +0200 Thread-Topic: [mpls] Last Call: (MPLS-TP Identifiers) to Proposed Standard Thread-Index: Acw1F+fy2cc2fqAsQjWUdW71y7nF9QGmM/rQ Message-ID: References: <20110627221611.11293.46784.idtracker@ietfa.amsl.com> In-Reply-To: <20110627221611.11293.46784.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] R: Last Call: (MPLS-TP Identifiers) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 08:16:28 -0000 Dear all, I have the following comments: Sect 7: " A maintenance point is either a Maintenance Entity Group End-point (MEP) or a Maintenance Entity Group Intermediate Point (MIP). Maintenance points are uniquely associated with a MEG." >This is true for MEP. MIP, as currently defined, are not uniquely associat= ed with a MEG. Sec 7.4 " At a cross-connect point, in order to automatically generate MIP_= IDs for MPLS-TP, we simply use the IF_IDs of the two interfaces which are cross-connected" > the above given definition refers to "intermediate node". It should be ex= tended to cover also the case of "end nodes" because MIPs could be located = in such nodes when per-interface MEPs model is applied (e.g. draft-ietf-mpl= s-tp-oam-framework and Yoshinori's contributions) >a reference to sect 4, where IF_ID are defined, should be added Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di The I= ESG Inviato: marted=EC 28 giugno 2011 00:16 A: IETF-Announce Cc: mpls@ietf.org Oggetto: [mpls] Last Call: (MPLS-TP= Identifiers) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Identifiers' 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 2011-07-11. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions suitable to IP/MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From lizhong.jin@zte.com.cn Wed Jul 6 02:05:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EDD21F8743 for ; Wed, 6 Jul 2011 02:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.962 X-Spam-Level: X-Spam-Status: No, score=-100.962 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V-YXmC7rjJA for ; Wed, 6 Jul 2011 02:05:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87B21F86F7 for ; Wed, 6 Jul 2011 02:05:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 13132806486374; Wed, 6 Jul 2011 17:00:15 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 73013.3584101308; Wed, 6 Jul 2011 17:05:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6695Pg4062930; Wed, 6 Jul 2011 17:05:25 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Kamran Raza MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 6 Jul 2011 17:05:15 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-06 17:05:26, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-06 17:05:26, Serialize complete at 2011-07-06 17:05:26, S/MIME Sign failed at 2011-07-06 17:05:26: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-06 17:05:26 Content-Type: multipart/alternative; boundary="=_alternative 0031EFDB482578C5_=" X-MAIL: mse01.zte.com.cn p6695Pg4062930 Cc: mpls@ietf.org Subject: Re: [mpls] Questions for RFC5561 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 09:05:43 -0000 This is a multipart message in MIME format. --=_alternative 0031EFDB482578C5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2FtcmFuLA0KVGhhbmtzIGZvciB0aGUgcmVwbHkuIEkgcmVhZCB0aGUgZHJhZnQtcmF6YS1t cGxzLWxkcC1vbGYsIGFuZCBpdCBpcyBxdWl0ZSANCmNsZWFyIGZvciB0aGUgY2FwYWJpbGl0eSBj aGFuZ2UgcHJvY2VkdXJlLiBCdXQgbWFueSBvZiBvdGhlciBkcmFmdHMgZG8gbm90IA0KZGVzY3Jp YmUgdGhlIHdpdGhkcmF3IHByb2NlZHVyZS4NCkFuZCB5b3UgYXJlIHJpZ2h0LCB0aGVyZSBpcyBu byB3aXRoZHJhd2FsIGZhaWx1cmUuIFJlZmVycmluZyB0byB5b3VyIG5ldyANCmRyYWZ0LCBhbmQg dGFrZSBmb3IgTERQIHVwdHJlYW0gY2FwYWJpbGl0eSBmb3IgZXhhbXBsZSwgaWYgTFNSMSBkaXNh YmxlIA0KdGhpcyBjYXBhYmlsaXR5IGFuZCBzZW5kIGNhcGFiaWxpdHkgbWVzc2FnZSB0byBwZWVy IExTUjIuIE9uIExTUjEsIHRoZSBMRFAgDQp1cHN0cmVhbSBjYXBhYmlsaXR5IChtZWFucyBzb21l IExEUCB1cHN0cmVhbSBsYWJlbCBhc3NpZ25tZW50IHByb2NlZHVyZSkgDQpzaG91bGQgc3RpbGwg YmUgcmV0YWluZWQgZm9yIHNvbWUgdGltZSwgdG8gd2l0aGRyYXcgdGhlIHVwc3RyZWFtIGxhYmVs IA0KYWR2ZXJzdGlzZW1lbnQsIGFuZCB0byByZWxlYXNlL3RvIHdhaXQgdG8gYmUgd2l0aGRyYXdl ZCB0aGUgcmVxdWVzdGVkIEZFQyANCmFkdmVydGlzZW1lbnQuIE9uIExTUjIsIHdoZW4gcmVjZWl2 aW5nIHRoZSBjYXBhYmlsaXR5IG1lc3NhZ2UsIGRvIHRoZSBzYW1lIA0KYXMgTFNSMSwgcmlnaHQ/ DQoNCk5vdyBtdWNoIGNsZWFyIGZvciBtZS4gQlRXLCBSRkM1NTYxIHNlY3Rpb24gMi4xIGRvZXMg bm90IHJlcXVpcmUgdG8gDQpkZXNjcmliZSB0aGUgcHJvY2VkdXJlIG9mIGNhcGFiaWxpdHkgd2l0 aGRyYXcuDQoNClRoYW5rIHlvdS4NCkxpemhvbmcNCg0KIA0KDQpLYW1yYW4gUmF6YSA8c2tyYXph QGNpc2NvLmNvbT4gd3JvdGUgb24gMjAxMS0wNy0wNSAyMzozNDo1MToNCg0KPiBIaSBMaXpob25n LA0KPiANCj4gVGhlIFJGQzU1NjEganVzdCBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgY2FwYWJp bGl0aWVzIGFuZCB0aGUgDQo+IGRldGFpbGVkIHByb2NlZHVyZSBmb3Igd2l0aGRyYXdpbmcgYSBw YXJ0aWN1bGFyIGNhcGFiaWxpdHkgYXJlIHRvIGJlDQo+IHN0YXRlZCBpbiB0aGUgY2FwYWJpbGl0 eSBkb2N1bWVudCBpdHNlbGYuIEZvciBpbnN0YW5jZSwgDQo+IFRoZSBJLUQgZHJhZnQtcmF6YS1t cGxzLWxkcC1vbGYtMDAudHh0IHNlY3Rpb24gNC40LjIgc3RhdGVzIExEUCBPTEYgDQo+IHByb2Nl ZHVyZXMgb24gY2FwYWJpbGl0eSBjaGFuZ2VzL3dpdGhkcmF3cy4NCj4gDQo+IFBsZWFzZSBzZWUg ZnVydGhlciBpbmxpbmUgZm9yIFtza3JhemFdDQo+IA0KPiBPbiAxMS0wNy0wNSAyOjE1IEFNLCAi bGl6aG9uZy5qaW5AenRlLmNvbS5jbiIgPGxpemhvbmcuamluQHp0ZS5jb20uY24+IA0Kd3JvdGU6 DQoNCj4gDQo+IEhpIGFsbCwgDQo+IFJGQyA1NTYxIGRvZXMgbm90IGV4cGxpY2l0bHkgZGVzY3Jp YmUgdGhlIExEUCBhZHZlcnRpc2VtZW50IA0KPiBwcm9jZWR1cmUgb2YgY2FwYWJpbGl0eSB3aXRo ZHJhdy4gVGhlbiBpZiBvbmUgTERQIHNwZWFrZXIgZGVjaWRlcyB0bw0KPiB3aXRoZHJhdyBvbmUg Y2FwYWJpbGl0eSwgdGhlcmUgYXJlIHR3byBvcHRpb25zOiANCj4gMS4gd2l0aGRyYXcgdGhlIEZF QyBhZHZlcnRpc2VtZW50IGZpcnN0LCB0aGVuIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24NCj4gd2l0 aCB0aGUgcGVlci4gQnV0IHdoYXQgaWYgbmVnb3RpYXRpb24gZmFpbGVkPw0KPiANCj4gW3NrcmF6 YV06IFRoZSBjYXBhYmlsaXR5IHdpdGhkcmF3YWwgc2hvdWxkIGltcGxpY2l0bHkgcmVtb3ZlIGFu eSANCj4gc3RhdGUgKGUuZy4gRkVDKSBhc3NvY2lhdGVkIHdpdGggaXQsIHdpdGhvdXQgYSBuZWVk IHRvIGV4cGxpY2l0bHkgDQo+IHJlbW92ZS93aXRoZHJhdyBpdC4gQlRXLCBvbmNlIGNhcGFiaWxp dHkgaXMgbmVnb3RpYXRlZCwgaXRzIA0KPiB3aXRoZHJhd2FsIHNob3VsZCBub3QgZmFpbC4gQ2Fu IHUgcGxlYXNlIGVsYWJvcmF0ZSB3aGF0IGRvIHlvdSBtZWFuIA0KPiBieSChsG5lZ290aWF0aW9u IGZhaWxlZKGxIGF0IHRoZSBjYXBhYmlsaXR5IHdpdGhkcmF3YWwgdGltZSA/IA0KPiANCj4gDQo+ IDIuIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gd2l0aCB0aGUgcGVlciBmaXJzdCwgdGhlbiB3aXRo ZHJhdyB0aGUgDQo+IEZFQy4gQnV0IGlmIGNhcGFiaWxpdHkgaXMgZGlzYWJsZSwgaG93IHRvIHdp dGhkcmF3IHRoZSBGRUMuIA0KPiBXaGljaCBvbmUgc2hvdWxkIGJlIHVzZWQgdGhlbj8gSG9wZSB0 byBzZWUgdGhlIGNsYXJpZmljYXRpb24uIA0KPiANCj4gW3NrcmF6YV06IEFnYWluLCB3aGF0IGV4 YWN0bHkgdGhlIHRlcm0gobBuZWdvdGlhdGlvbqGxIG1lYW5zIGhlcmUgPyBJZg0KPiB5b3UgYXJl IGp1c3Qgd2l0aGRyYXdpbmcgYWxyZWFkeSBhIG5lZ290aWF0ZWQgY2FwYWJpbGl0eSwgd2h5IHdv dWxkIA0KPiB0aGlzIHdpdGhkcmF3YWwgZmFpbCA/IElmIHRoZXJlIGFyZSBjYXBhYmlsaXR5IHNw ZWNpZmljIHNjZW5hcmlvcywgDQo+IHRoZW4gdGhleSBtdXN0IGJlIGNvdmVyIGluIGNhcGFiaWxp dHkgZG9jdW1lbnRzLg0KPiANCj4gVGhhbmtzLg0KPiAtLSANCj4gICAgICAgICBTeWVkIEthbXJh biBSYXphDQo+ICAgICBUZWNobmljYWwgTGVhZGVyLCBTUFJTRyBJT1MtWFIgUm91dGluZyAoTVBM UykNCj4gICAgIENpc2NvIFN5c3RlbXMsIEluYy4sIA0KPiAgICAgS2FuYXRhLCBPTiwgSzJLIDNF OCwgQ2FuYWRhIA0KPiAgICAgUGg6ICsxICg2MTMpIDI1NC00NTIwDQo+IGh0dHA6Ly93d3cuY2lz Y28uY29tIA0KPiANCj4gDQo+IFRoYW5rIHlvdSANCj4gTGl6aG9uZw0KPiANCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0031EFDB482578C5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthbXJhbiw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIHJlcGx5Ljwv Zm9udD48dHQ+PGZvbnQgc2l6ZT0yPg0KSSByZWFkIHRoZSBkcmFmdC1yYXphLW1wbHMtbGRwLW9s ZiwgYW5kIGl0IGlzIHF1aXRlIGNsZWFyIGZvciB0aGUgY2FwYWJpbGl0eQ0KY2hhbmdlIHByb2Nl ZHVyZS4gQnV0IG1hbnkgb2Ygb3RoZXIgZHJhZnRzIGRvIG5vdCBkZXNjcmliZSB0aGUgd2l0aGRy YXcNCnByb2NlZHVyZS48L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QW5kIHlvdSBhcmUgcmlnaHQsIHRoZXJlIGlzIG5vPC9mb250Pjx0dD48Zm9udCBzaXpl PTI+DQp3aXRoZHJhd2FsIGZhaWx1cmUuIFJlZmVycmluZyB0byB5b3VyIG5ldyBkcmFmdCwgYW5k IHRha2UgZm9yIExEUCB1cHRyZWFtDQpjYXBhYmlsaXR5IGZvciBleGFtcGxlLCBpZiBMU1IxIGRp c2FibGUgdGhpcyBjYXBhYmlsaXR5IGFuZCBzZW5kIGNhcGFiaWxpdHkNCm1lc3NhZ2UgdG8gcGVl ciBMU1IyLiBPbiBMU1IxLCB0aGUgTERQIHVwc3RyZWFtIGNhcGFiaWxpdHkgKG1lYW5zIHNvbWUN CkxEUCB1cHN0cmVhbSBsYWJlbCBhc3NpZ25tZW50IHByb2NlZHVyZSkgc2hvdWxkIHN0aWxsIGJl IHJldGFpbmVkIGZvciBzb21lDQp0aW1lLCB0byB3aXRoZHJhdyB0aGUgdXBzdHJlYW0gbGFiZWwg YWR2ZXJzdGlzZW1lbnQsIGFuZCB0byByZWxlYXNlL3RvDQp3YWl0IHRvIGJlIHdpdGhkcmF3ZWQg dGhlIHJlcXVlc3RlZCBGRUMgYWR2ZXJ0aXNlbWVudC4gT24gTFNSMiwgd2hlbiByZWNlaXZpbmcN CnRoZSBjYXBhYmlsaXR5IG1lc3NhZ2UsIGRvIHRoZSBzYW1lIGFzIExTUjEsIHJpZ2h0PzwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Tm93IG11Y2ggY2xlYXIgZm9yIG1l LiBCVFcsIFJGQzU1NjEgc2VjdGlvbiAyLjEgZG9lcw0Kbm90IHJlcXVpcmUgdG8gZGVzY3JpYmUg dGhlIHByb2NlZHVyZSBvZiBjYXBhYmlsaXR5IHdpdGhkcmF3LjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmsgeW91LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+TGl6aG9uZzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+S2FtcmFu IFJhemEgJmx0O3NrcmF6YUBjaXNjby5jb20mZ3Q7IHdyb3RlIG9uIDIwMTEtMDctMDUNCjIzOjM0 OjUxOjxicj4NCjxicj4NCiZndDsgSGkgTGl6aG9uZyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhl IFJGQzU1NjEganVzdCBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgY2FwYWJpbGl0aWVzIGFuZCB0 aGUgPGJyPg0KJmd0OyBkZXRhaWxlZCBwcm9jZWR1cmUgZm9yIHdpdGhkcmF3aW5nIGEgcGFydGlj dWxhciBjYXBhYmlsaXR5IGFyZSB0bw0KYmU8YnI+DQomZ3Q7IHN0YXRlZCBpbiB0aGUgY2FwYWJp bGl0eSBkb2N1bWVudCBpdHNlbGYuIEZvciBpbnN0YW5jZSwgPGJyPg0KJmd0OyBUaGUgSS1EIGRy YWZ0LXJhemEtbXBscy1sZHAtb2xmLTAwLnR4dCBzZWN0aW9uIDQuNC4yIHN0YXRlcyBMRFAgT0xG DQo8YnI+DQomZ3Q7IHByb2NlZHVyZXMgb24gY2FwYWJpbGl0eSBjaGFuZ2VzL3dpdGhkcmF3cy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIHNlZSBmdXJ0aGVyIGlubGluZSBmb3IgW3NrcmF6 YV08YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTEtMDctMDUgMjoxNSBBTSwgJnF1b3Q7bGl6aG9u Zy5qaW5AenRlLmNvbS5jbiZxdW90OyAmbHQ7bGl6aG9uZy5qaW5AenRlLmNvbS5jbiZndDsNCndy b3RlOjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyBSRkMgNTU2MSBkb2VzIG5vdCBleHBsaWNpdGx5IGRlc2Ny aWJlIHRoZSBMRFAgYWR2ZXJ0aXNlbWVudCA8YnI+DQomZ3Q7IHByb2NlZHVyZSBvZiBjYXBhYmls aXR5IHdpdGhkcmF3LiBUaGVuIGlmIG9uZSBMRFAgc3BlYWtlciBkZWNpZGVzDQp0bzxicj4NCiZn dDsgd2l0aGRyYXcgb25lIGNhcGFiaWxpdHksIHRoZXJlIGFyZSB0d28gb3B0aW9uczogPGJyPg0K Jmd0OyAxLiB3aXRoZHJhdyB0aGUgRkVDIGFkdmVydGlzZW1lbnQgZmlyc3QsIHRoZW4gY2FwYWJp bGl0eSBuZWdvdGlhdGlvbjxicj4NCiZndDsgd2l0aCB0aGUgcGVlci4gQnV0IHdoYXQgaWYgbmVn b3RpYXRpb24gZmFpbGVkPzxicj4NCiZndDsgPGJyPg0KJmd0OyBbc2tyYXphXTogVGhlIGNhcGFi aWxpdHkgd2l0aGRyYXdhbCBzaG91bGQgaW1wbGljaXRseSByZW1vdmUgYW55IDxicj4NCiZndDsg c3RhdGUgKGUuZy4gRkVDKSBhc3NvY2lhdGVkIHdpdGggaXQsIHdpdGhvdXQgYSBuZWVkIHRvIGV4 cGxpY2l0bHkNCjxicj4NCiZndDsgcmVtb3ZlL3dpdGhkcmF3IGl0LiBCVFcsIG9uY2UgY2FwYWJp bGl0eSBpcyBuZWdvdGlhdGVkLCBpdHMgPGJyPg0KJmd0OyB3aXRoZHJhd2FsIHNob3VsZCBub3Qg ZmFpbC4gQ2FuIHUgcGxlYXNlIGVsYWJvcmF0ZSB3aGF0IGRvIHlvdSBtZWFuDQo8YnI+DQomZ3Q7 IGJ5IKGwbmVnb3RpYXRpb24gZmFpbGVkobEgYXQgdGhlIGNhcGFiaWxpdHkgd2l0aGRyYXdhbCB0 aW1lID8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg Jm5ic3A7PGJyPg0KJmd0OyAyLiBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIHdpdGggdGhlIHBlZXIg Zmlyc3QsIHRoZW4gd2l0aGRyYXcgdGhlIDxicj4NCiZndDsgRkVDLiBCdXQgaWYgY2FwYWJpbGl0 eSBpcyBkaXNhYmxlLCBob3cgdG8gd2l0aGRyYXcgdGhlIEZFQy4gPGJyPg0KJmd0OyBXaGljaCBv bmUgc2hvdWxkIGJlIHVzZWQgdGhlbj8gSG9wZSB0byBzZWUgdGhlIGNsYXJpZmljYXRpb24uIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBbc2tyYXphXTogQWdhaW4sIHdoYXQgZXhhY3RseSB0aGUgdGVy bSChsG5lZ290aWF0aW9uobEgbWVhbnMgaGVyZQ0KPyBJZjxicj4NCiZndDsgeW91IGFyZSBqdXN0 IHdpdGhkcmF3aW5nIGFscmVhZHkgYSBuZWdvdGlhdGVkIGNhcGFiaWxpdHksIHdoeSB3b3VsZA0K PGJyPg0KJmd0OyB0aGlzIHdpdGhkcmF3YWwgZmFpbCA/IElmIHRoZXJlIGFyZSBjYXBhYmlsaXR5 IHNwZWNpZmljIHNjZW5hcmlvcywNCjxicj4NCiZndDsgdGhlbiB0aGV5IG11c3QgYmUgY292ZXIg aW4gY2FwYWJpbGl0eSBkb2N1bWVudHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcy48YnI+ DQomZ3Q7IC0tIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU3llZCBLYW1yYW4gUmF6YTxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBUZWNobmljYWwgTGVhZGVyLCBTUFJTRyBJT1MtWFIgUm91dGluZyAoTVBMUyk8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgQ2lzY28gU3lzdGVtcywgSW5jLiwgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IEthbmF0YSwgT04sIEsySyAzRTgsIENhbmFkYSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgUGg6ICsxICg2MTMpIDI1NC00NTIwPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IGh0dHA6Ly93d3cuY2lzY28uY29tIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRoYW5rIHlvdSA8YnI+DQomZ3Q7IExpemhvbmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0031EFDB482578C5_=-- From david.i.allan@ericsson.com Wed Jul 6 06:58:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CCE21F85D9; Wed, 6 Jul 2011 06:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iss-LtO1Aq2z; Wed, 6 Jul 2011 06:58:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id BE68221F85E1; Wed, 6 Jul 2011 06:58:05 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p66Dw49P012490; Wed, 6 Jul 2011 08:58:05 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 6 Jul 2011 09:57:57 -0400 From: David Allan I To: Rui Costa , "ietf@ietf.org" , IETF-Announce Date: Wed, 6 Jul 2011 09:57:57 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgAF5iQcA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52212CB94E@EUSAACMS0703.eamcs.ericsson.se> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 13:58:06 -0000 Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well a= s those collected from the MPLS WG was presented at the last IETF. My sprea= dsheet from which that report was generated and has been augmented to inclu= de the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last= -Call-Comments.xls So you know... Dave -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rui= Costa Sent: Monday, July 04, 2011 3:03 PM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard IMHO and for the record:=09 ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent.=09 Several service providers regarded this draft as not meeting their transpor= t networks' needs.=09 [The v03 draft was published in Feb and went to WG LC.=09 The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up).=09 When was the WG LC launched, to verify LC comments resolution?]=09 Regards,=09 Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Jul 6 08:44:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB56121F87B6; Wed, 6 Jul 2011 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdFjL4ZKr2dA; Wed, 6 Jul 2011 08:44:12 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5D62321F860E; Wed, 6 Jul 2011 08:44:12 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C6249514044; Wed, 6 Jul 2011 17:44:09 +0200 (CEST) Message-ID: <4E1482C8.6020701@pi.nu> Date: Wed, 06 Jul 2011 17:44:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Rui Costa References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:44:13 -0000 All, Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without doubt that no comments been ignored. Loa mpls wg document shepherd On 2011-07-05 00:02, Rui Costa wrote: > IMHO and for the record: > > ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. > > Several service providers regarded this draft as not meeting their transport networks' needs. > > [The v03 draft was published in Feb and went to WG LC. > The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). > When was the WG LC launched, to verify LC comments resolution?] > > Regards, > Rui > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: quinta-feira, 30 de Junho de 2011 14:47 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From erminio.ottone_69@libero.it Wed Jul 6 10:26:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0511F21F8865; Wed, 6 Jul 2011 10:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCylgDjXPZiU; Wed, 6 Jul 2011 10:26:31 -0700 (PDT) Received: from outrelay03.libero.it (outrelay03.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC521F85B9; Wed, 6 Jul 2011 10:26:30 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020A.4E149AC0.019C,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail39 (172.31.0.228) by outrelay03.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF1D02531A3D; Wed, 6 Jul 2011 19:26:24 +0200 Message-ID: <15271688.742501309973184714.JavaMail.defaultUser@defaultHost> Date: Wed, 6 Jul 2011 19:26:24 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , Rui Costa MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.31.158.220 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:26:32 -0000 > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC comments were correctly with minor comments. It also says: The comments has been carefully discussed between the authors and people making the comments and has been resolved. But it seems that some comments have not been discussed with the authors of the comments. When ITU-T Q10/15 has been involved in discussing its comments? >----Messaggio originale---- >Da: loa@pi.nu >Data: 6-lug-2011 17.44 >A: "Rui Costa" >Cc: "mpls@ietf.org", "ietf@ietf.org", "IETF- Announce" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >All, > >Since someone has commented about the process used for resolving >questions on >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >process is: > >On February 3rd 2011 the working group last call was issued >on version -03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > >The authors compiled a list of all comments received as part the MPLS >working group last call; these comments - and the intended resolution - >is included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD working > group to do a separate working group last callfor the BFD working > group > >The (BFD) working group last call was started on March 30th and ran >for 13 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some > issue has been brought to the working group mailing list for > resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editorial > comments. Version -05 was published on June 29 and the IETF last call > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiable at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows without >doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > >On 2011-07-05 00:02, Rui Costa wrote: >> IMHO and for the record: >> >> ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. >> >> Several service providers regarded this draft as not meeting their transport networks' needs. >> >> [The v03 draft was published in Feb and went to WG LC. >> The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). >> When was the WG LC launched, to verify LC comments resolution?] >> >> Regards, >> Rui >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label Switching WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 2011-07-14. 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 >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed Jul 6 10:34:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2D21F8903; Wed, 6 Jul 2011 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGdVvDjwRmv7; Wed, 6 Jul 2011 10:34:03 -0700 (PDT) Received: from outrelay03.libero.it (outrelay03.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id A262F21F88F0; Wed, 6 Jul 2011 10:34:01 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020A.4E149C86.0126,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail39 (172.31.0.228) by outrelay03.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF1D025345C7; Wed, 6 Jul 2011 19:33:58 +0200 Message-ID: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> Date: Wed, 6 Jul 2011 19:33:58 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "ietf@ietf.org" , IETF-Announce MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.31.158.220 Cc: "mpls@ietf.org" Subject: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:03 -0000 The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been resolved. >Several service providers regarded this draft as not meeting their transport networks' needs. This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. >----Messaggio originale---- >Da: RCosta@ptinovacao.pt >Data: 5-lug-2011 0.02 >A: "ietf@ietf.org", "IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record: > >ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. > >Several service providers regarded this draft as not meeting their transport networks' needs. > >[The v03 draft was published in Feb and went to WG LC. >The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). >When was the WG LC launched, to verify LC comments resolution?] > >Regards, >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From david.i.allan@ericsson.com Wed Jul 6 10:35:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7121F893B; Wed, 6 Jul 2011 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSV1SlarQFxx; Wed, 6 Jul 2011 10:35:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06521F892D; Wed, 6 Jul 2011 10:35:44 -0700 (PDT) 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 p66HZfF6026070; Wed, 6 Jul 2011 12:35:43 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 6 Jul 2011 13:35:36 -0400 From: David Allan I To: "erminio.ottone_69@libero.it" , "loa@pi.nu" , Rui Costa Date: Wed, 6 Jul 2011 13:35:35 -0400 Thread-Topic: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw8AeQS0u6Io4DfRNinXiLBndDNcQAACzKQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD52212CBBDC@EUSAACMS0703.eamcs.ericsson.se> References: <15271688.742501309973184714.JavaMail.defaultUser@defaultHost> In-Reply-To: <15271688.742501309973184714.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:35:49 -0000 Hi Erminio: Two of the three document editors were present at SG15 plenary in February = where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. Cheers Dave=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Wednesday, July 06, 2011 10:26 AM To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: [mpls] R: Re: Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent =20 > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC commen= ts were correctly with minor comments.=20 It also says: The comments has been carefully discussed between the authors and people making the c= omments and has been resolved. But it seems that some comments have not been discussed with the authors of= the comments. When ITU-T Q10/15 has been involved in discussing its commen= ts? >----Messaggio originale---- >Da: loa@pi.nu >Data: 6-lug-2011 17.44 >A: "Rui Costa" >Cc: "mpls@ietf.org", "ietf@ietf.org",=20 >"IETF- Announce" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>=09 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >All, > >Since someone has commented about the process used for resolving=20 >questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details=20 >below. > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group review=20 >process is: > >On February 3rd 2011 the working group last call was issued on version=20 >-03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > >The authors compiled a list of all comments received as part the MPLS=20 >working group last call; these comments - and the intended resolution=20 >- is included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD working =20 > group to do a separate working group last callfor the BFD working =20 > group > >The (BFD) working group last call was started on March 30th and ran for=20 >13 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some issue=20 > has been brought to the working group mailing list for resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent =20 > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editorial =20 > comments. Version -05 was published on June 29 and the IETF last call =20 > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiable at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows=20 >without doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > >On 2011-07-05 00:02, Rui Costa wrote: >> IMHO and for the record:=09 >> >> ITU-T comments regarding this draft haven't been discussed with ITU-T=20 >> but were simply ignored. No LS describing these comments' resolution was sent.= =09 >> >> Several service providers regarded this draft as not meeting their transport networks' needs.=09 >> >> [The v03 draft was published in Feb and went to WG LC.=09 >> The v04 draft addressing WG LC comments was published on the 28th=20 >> June (same date as the proto write-up).=09 >> When was the WG LC launched, to verify LC comments resolution?]=09 >> >> Regards,=09 >> Rui >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 >> Of The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: =20 >> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication fo= r MPLS Transport Profile) to Proposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label=20 >> Switching WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits=20 >> final comments on this action. Please send substantive comments to=20 >> the ietf@ietf.org mailing lists by 2011-07-14. Exceptionally,=20 >> comments may be sent to iesg@ietf.org instead. In either case, please=20 >> retain the beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13=20 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Wed Jul 6 11:24:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5173421F890F; Wed, 6 Jul 2011 11:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilUXmnQYEfbQ; Wed, 6 Jul 2011 11:24:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7F33621F8917; Wed, 6 Jul 2011 11:24:58 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p66IOuAH003866; Wed, 6 Jul 2011 13:24:58 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 6 Jul 2011 14:24:55 -0400 From: David Allan I To: "erminio.ottone_69@libero.it" , "RCosta@ptinovacao.pt" , "ietf@ietf.org" , IETF-Announce Date: Wed, 6 Jul 2011 14:24:54 -0400 Thread-Topic: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw8AvlCLDZgm+U5SBqkN4NxEuu8YgAAIlJQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD52212CBC63@EUSAACMS0703.eamcs.ericsson.se> References: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> In-Reply-To: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:24:59 -0000 Hi Erminio: >Several service providers regarded this draft as not meeting their=20 >transport networks' needs.=09 E> This is a true statement: the solution in this draft is useless for many= MPLS- TP deployments. The two statements do not necessarily follow.=20 What we established during discussions at the SG15 plenary in February was = that the issue some service providers had was that the IETF BFD solution ex= ceeded their requirements in that there was additional functionality they d= id not see a need for, and that they considered any additional functionalit= y parasitic. However this is a consequence of adapting an existing technology to a new a= pplication. I do not see any way around that. And the entire joint project = was based on the premise of engineering re-use not greenfield design. That = is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mai= nstream, so it is a bit late to cry foul.... My 2 cents Dave >----Messaggio originale---- >Da: RCosta@ptinovacao.pt >Data: 5-lug-2011 0.02 >A: "ietf@ietf.org",=20 >"IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>=09 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record:=09 > >ITU-T comments regarding this draft haven't been discussed with ITU-T=20 >but were simply ignored. No LS describing these comments' resolution was sent.= =09 > >Several service providers regarded this draft as not meeting their=20 >transport networks' needs.=09 > >[The v03 draft was published in Feb and went to WG LC.=09 >The v04 draft addressing WG LC comments was published on the 28th June=20 >(same date as the proto write-up).=09 >When was the WG LC launched, to verify LC comments resolution?]=09 > >Regards,=09 >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 >The IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: =20 >(Proactive Connectivity Verification, Continuity Check and Remote Defect indication fo= r MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switching=20 >WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits=20 >final comments on this action. Please send substantive comments to the=20 >ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may=20 >be sent to iesg@ietf.org instead. In either case, please retain the=20 >beginning of the Subject line to allow automated sorting. > >Abstract > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Jul 6 12:57:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A21F89C5 for ; Wed, 6 Jul 2011 12:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.707 X-Spam-Level: X-Spam-Status: No, score=-102.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKRymeiG6Tgc for ; Wed, 6 Jul 2011 12:57:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCC21F89B6 for ; Wed, 6 Jul 2011 12:57:25 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 04BB2514044; Wed, 6 Jul 2011 21:57:20 +0200 (CEST) Message-ID: <4E14BE1E.9020003@pi.nu> Date: Wed, 06 Jul 2011 21:57:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Liaison Statement Management Tool References: <20110706194341.29710.96750@ietfa.amsl.com> In-Reply-To: <20110706194341.29710.96750@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Multiprotocol Label Switching Discussion List , Greg Jones , lear@cisco.com, yoichi.maeda@ttc.or.jp, ahmpls-tp@lists.itu.int, tsbsg15@itu.int, Ross Callon , ghani.abbas@ericsson.com, elisa.bellagamba@ericsson.com, hhelvoort@huawei.com, Stewart Bryant Subject: [mpls] mail flood ?? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:57:25 -0000 All, I might be that you will see more mails than usual for a liaison for the IETF response to the Q10 liaison on the the mib managements overview. This is due to that we'd problems with the liaison statement tool. Sorry for duplicates? triplicates? quadruplicates? /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From nurit.sprecher@nsn.com Thu Jul 7 02:59:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AD921F8699; Thu, 7 Jul 2011 02:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=5.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKMj8uREEE5u; Thu, 7 Jul 2011 02:59:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26A21F85C2; Thu, 7 Jul 2011 02:59:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p679xJkI002144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 11:59:19 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p679xC8i012016; Thu, 7 Jul 2011 11:59:18 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jul 2011 11:59:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 11:59:12 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640415A55F@DEMUEXC014.nsn-intra.net> In-Reply-To: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Thread-Index: Acw8AvNmmGk+VU+zQLq6ipU76LivNgAf+uzg References: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , , , "IETF-Announce" X-OriginalArrivalTime: 07 Jul 2011 09:59:13.0322 (UTC) FILETIME=[864D90A0:01CC3C8C] Cc: mpls@ietf.org Subject: Re: [mpls] R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:59:25 -0000 Erminio, I do not think the history is relevant for this specific discussion...=20 Also I find it inappropriate to give statements with no justifications behind.=20 You say: "the solution in this draft is useless for many MPLS-TP deployments.". in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point.=20 Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext erminio.ottone_69@libero.it Sent: Wednesday, July 06, 2011 8:34 PM To: RCosta@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: [mpls] R: Re: LastCall: (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair=20 because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by=20 several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been=20 resolved. >Several service providers regarded this draft as not meeting their transport=20 networks' needs.=09 This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. >----Messaggio originale---- >Da: RCosta@ptinovacao.pt >Data: 5-lug-2011 0.02 >A: "ietf@ietf.org", "IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>=09 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record:=09 > >ITU-T comments regarding this draft haven't been discussed with ITU-T but=20 were simply ignored. No LS describing these comments' resolution was sent.=09 > >Several service providers regarded this draft as not meeting their transport=20 networks' needs.=09 > >[The v03 draft was published in Feb and went to WG LC.=09 >The v04 draft addressing WG LC comments was published on the 28th June (same=20 date as the proto write-up).=09 >When was the WG LC launched, to verify LC comments resolution?]=09 > >Regards,=09 >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The=20 IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: (Proactive=20 Connectivity Verification, Continuity Check and Remote Defect indication for=20 MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Thu Jul 7 04:40:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6E21F8811; Thu, 7 Jul 2011 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=4.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jbyy9dDmlJv; Thu, 7 Jul 2011 04:40:35 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C239421F880C; Thu, 7 Jul 2011 04:40:34 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p67BeP16027363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 13:40:25 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p67BeM2p004226; Thu, 7 Jul 2011 13:40:24 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jul 2011 13:40:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 13:40:22 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640415A674@DEMUEXC014.nsn-intra.net> In-Reply-To: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Thread-Index: Acw8AvNmmGk+VU+zQLq6ipU76LivNgAf+uzg References: <14289796.745031309973638587.JavaMail.defaultUser@defaultHost> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , , , "IETF-Announce" X-OriginalArrivalTime: 07 Jul 2011 11:40:24.0319 (UTC) FILETIME=[A8E630F0:01CC3C9A] Cc: mpls@ietf.org Subject: Re: [mpls] R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:40:36 -0000 Erminio, I do not think the history is relevant for this specific discussion...=20 Also I find it inappropriate to give statements with no justifications behind.=20 You say: "the solution in this draft is useless for many MPLS-TP deployments.". in order to seriously consider your comment, you have to show why it is useless and which requirements are not satisfied. Otherwise you cannot expect anyone to refer to your point.=20 Best regards, Nurit P.s. did you mean that the document is useless to available non-standard deployments, e.g. T-MPLS? =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext erminio.ottone_69@libero.it Sent: Wednesday, July 06, 2011 8:34 PM To: RCosta@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: [mpls] R: Re: LastCall: (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair=20 because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by=20 several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been=20 resolved. >Several service providers regarded this draft as not meeting their transport=20 networks' needs.=09 This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. >----Messaggio originale---- >Da: RCosta@ptinovacao.pt >Data: 5-lug-2011 0.02 >A: "ietf@ietf.org", "IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>=09 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record:=09 > >ITU-T comments regarding this draft haven't been discussed with ITU-T but=20 were simply ignored. No LS describing these comments' resolution was sent.=09 > >Several service providers regarded this draft as not meeting their transport=20 networks' needs.=09 > >[The v03 draft was published in Feb and went to WG LC.=09 >The v04 draft addressing WG LC comments was published on the 28th June (same=20 date as the proto write-up).=09 >When was the WG LC launched, to verify LC comments resolution?]=09 > >Regards,=09 >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The=20 IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: (Proactive=20 Connectivity Verification, Continuity Check and Remote Defect indication for=20 MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Thu Jul 7 12:15:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6C1F0CD6 for ; Thu, 7 Jul 2011 12:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.445 X-Spam-Level: X-Spam-Status: No, score=-97.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gopn7HDE2D5Q for ; Thu, 7 Jul 2011 12:15:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4F1F0CD4 for ; Thu, 7 Jul 2011 12:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=4934; q=dns/txt; s=iport; t=1310066157; x=1311275757; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=IVZRFVWAu+qoJNR1tUgAhEBG4eGjeJLuVIvKQbnVauM=; b=MQemeV2eoRKEIhCqpZAVaaF2jkmctNSddQvn+apRtyGzlJkPVaHMJGmG BdiHf3uslmHag6WQOi7V1IsLZr/6ObeQQxbybW3VikvaVUAPbD7lCj0ia x/Z/QuStnuFA5WM6W3Om1pOgiAXmYppPO8WGc2sRBvyQWHjh/vC505gVS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEMAKUEFk6tJV2c/2dsb2JhbABTMIIhpABjAneIe6RanXCGOASSRoUGh0OEFA X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208,217";a="783109" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jul 2011 19:15:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p67JFu1I007636; Thu, 7 Jul 2011 19:15:56 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 14:15:55 -0500 Received: from 161.44.113.58 ([161.44.113.58]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jul 2011 19:15:56 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 01 Jul 2011 14:27:16 -0400 From: George Swallow To: Adrian Farrel , Message-ID: Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-identifiers Thread-Index: Acw1Epl1e9a+4No9S6KI0ZM/JsUxMgDCed0t In-Reply-To: <066b01cc3512$9f0721f0$dd1565d0$@olddog.co.uk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392896555_159740833" X-OriginalArrivalTime: 07 Jul 2011 19:15:55.0869 (UTC) FILETIME=[4BC5C0D0:01CC3CDA] Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:15:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392896555_159740833 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Adrian - On 6/27/11 5:38 PM, "Adrian Farrel" wrote: > Hi, > > I have done my AD review of this document. In view of the fact that my > comments > are quite small, could you please handle them as part of the IETF last call > which I will start forthwith. > > Thanks, > Adrian > > --- > > You seem to be missing a section on MEP_IDs for MPLS_TP Sections. > Insert before 7.2.1? > Added the following section: 7.2.1. MPLS-TP Section MEP_IDs IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs of each end of the section. For example, for a section whose MEG_ID is A1-IF_ID::Z9-IF_ID the Section MEP_ID at A1 would be A1-IF_ID and the Section MEP_ID at Z9 would be Z9-IF_ID. Where the Section MEP_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus a globally unique Section MEP_ID becomes Global_ID::IF_ID. > > --- > > Nits > > 1.3 > > OLD > The notation does define a preferred ordering of the fields. > NEW > The notation defines a preferred ordering of the fields. > END > Done. > > OLD > Z9 is used to indicated the > NEW > Z9 is used to indicate the > END > Done. ...George > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --B_3392896555_159740833 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers Adrian -


On 6/27/11 5:38 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

<= SPAN STYLE=3D'font-size:10pt'>Hi,

I have done my AD review of this document. In view of the fact that my comm= ents
are quite small, could you please handle them as part of the IETF last call=
which I will start forthwith.

Thanks,
Adrian

---
  
You seem to be missing a section on MEP_IDs for MPLS_TP Sections.
Insert before 7.2.1?

= Added the following section:

7.2.1.  MPLS-TP Section MEP_IDs

   IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs o= f each end
   of the section.  For example, for a section whose ME= G_ID is

      A1-IF_ID::Z9-IF_ID

   the Section MEP_ID at A1 would be

      A1-IF_ID

   and the Section MEP_ID at Z9 would be

      Z9-IF_ID.

   Where the Section MEP_ID needs to be globally unique, thi= s is
   accomplished by using globally unique Node_IDs as defined= above.
   Thus a globally unique Section MEP_ID becomes

      Global_ID::IF_ID.

<= SPAN STYLE=3D'font-size:10pt'>
---

Nits

1.3

OLD
The notation does define a preferred ordering of the fields.
NEW
The notation defines a preferred ordering of the fields.
END

= Done.
<= SPAN STYLE=3D'font-size:10pt'>
OLD
 Z9 is used to indicated the
NEW
 Z9 is used to indicate the
END

= Done.

...George
<= SPAN STYLE=3D'font-size:10pt'>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

--B_3392896555_159740833-- From gregory.mirsky@ericsson.com Thu Jul 7 14:58:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4556D21F8908 for ; Thu, 7 Jul 2011 14:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzXFljk1AV5k for ; Thu, 7 Jul 2011 14:58:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EE21F8903 for ; Thu, 7 Jul 2011 14:58:23 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p67LwL3r026718; Thu, 7 Jul 2011 16:58:22 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 7 Jul 2011 17:58:16 -0400 From: Gregory Mirsky To: George Swallow , Adrian Farrel , "draft-ietf-mpls-tp-identifiers@tools.ietf.org" Date: Thu, 7 Jul 2011 17:58:14 -0400 Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-identifiers Thread-Index: Acw1Epl1e9a+4No9S6KI0ZM/JsUxMgDCed0tATSftOA= Message-ID: References: <066b01cc3512$9f0721f0$dd1565d0$@olddog.co.uk> 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_FE60A4E52763E84B935532D7D9294FF121F4B63C26EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:58:24 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F4B63C26EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, I have a question to new Section MEP-ID. In MPLS-TP a Section can be either= physical link or logical, section layer LSP, link. I think that listed Sec= tion MEP_ID addresses the former case. Would Section MEP-ID in the latter c= ase be the LSP MEP-ID? I think that both cases must be identified and their= Section MEP-IDs listed. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Friday, July 01, 2011 11:27 AM To: Adrian Farrel; draft-ietf-mpls-tp-identifiers@tools.ietf.org Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers Adrian - On 6/27/11 5:38 PM, "Adrian Farrel" wrote: Hi, I have done my AD review of this document. In view of the fact that my comm= ents are quite small, could you please handle them as part of the IETF last call which I will start forthwith. Thanks, Adrian --- You seem to be missing a section on MEP_IDs for MPLS_TP Sections. Insert before 7.2.1? Added the following section: 7.2.1. MPLS-TP Section MEP_IDs IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs of each end of the section. For example, for a section whose MEG_ID is A1-IF_ID::Z9-IF_ID the Section MEP_ID at A1 would be A1-IF_ID and the Section MEP_ID at Z9 would be Z9-IF_ID. Where the Section MEP_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus a globally unique Section MEP_ID becomes Global_ID::IF_ID. --- Nits 1.3 OLD The notation does define a preferred ordering of the fields. NEW The notation defines a preferred ordering of the fields. END Done. OLD Z9 is used to indicated the NEW Z9 is used to indicate the END Done. ...George _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF121F4B63C26EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers</= TITLE> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18457" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D937074421-07072011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Hi George,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D937074421-07072011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I have a question to new Section MEP-ID. In MPLS-T= P a=20 Section can be either physical link or logical, section layer LSP, link. I = think=20 that listed Section MEP_ID addresses the former case. Would Section MEP-ID = in=20 the latter case be the LSP MEP-ID? I think that both cases must be identifi= ed=20 and their Section MEP-IDs listed.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D937074421-07072011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D937074421-07072011>  &n= bsp; <FONT=20 face=3DArial color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D937074421-07072011>        <FONT= =20 face=3DArial color=3D#0000ff size=3D2>Greg</FONT></SPAN></DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] <B>On Behalf Of </B>George=20 Swallow<BR><B>Sent:</B> Friday, July 01, 2011 11:27 AM<BR><B>To:</B> Adrian= =20 Farrel; draft-ietf-mpls-tp-identifiers@tools.ietf.org<BR><B>Cc:</B>=20 mpls@ietf.org; mpls-chairs@tools.ietf.org<BR><B>Subject:</B> Re: [mpls] AD= =20 review of draft-ietf-mpls-tp-identifiers<BR></FONT><BR></DIV> <DIV></DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt">Adrian -<BR><BR><BR>On 6/27/11 5:38 PM, "Adrian F= arrel"=20 <<A href=3D"adrian@olddog.co.uk">adrian@olddog.co.uk</A>>=20 wrote:<BR><BR></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt">Hi,<BR><BR>I have done my AD review of this doc= ument.=20 In view of the fact that my comments<BR>are quite small, could you please= =20 handle them as part of the IETF last call<BR>which I will start=20 forthwith.<BR><BR>Thanks,<BR>Adrian<BR><BR>---<BR>  <BR>You see= m to=20 be missing a section on MEP_IDs for MPLS_TP Sections.<BR>Insert before=20 7.2.1?<BR><BR></SPAN></FONT></BLOCKQUOTE><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 10pt"= >Added=20 the following section:<BR><BR>7.2.1.  MPLS-TP Section=20 MEP_IDs<BR><BR>   IP compatible MEP_IDs for MPLS-TP are simp= ly=20 the IF_IDs of each end<BR>   of the section.  For examp= le,=20 for a section whose MEG_ID=20 is<BR><BR>      A1-IF_ID::Z9-IF_ID<BR><BR>&nb= sp;  the=20 Section MEP_ID at A1 would=20 be<BR><BR>      A1-IF_ID<BR><BR>  &= nbsp;and=20 the Section MEP_ID at Z9 would=20 be<BR><BR>      Z9-IF_ID.<BR><BR>  =  Where=20 the Section MEP_ID needs to be globally unique, this=20 is<BR>   accomplished by using globally unique Node_IDs as=20 defined above.<BR>   Thus a globally unique Section MEP_ID=20 becomes<BR><BR>      Global_ID::IF_ID.<BR><BR= ></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt"><BR>---<BR><BR>Nits<BR><BR>1.3<BR><BR>OLD<BR>Th= e=20 notation does define a preferred ordering of the fields.<BR>NEW<BR>The=20 notation defines a preferred ordering of the=20 fields.<BR>END<BR><BR></SPAN></FONT></BLOCKQUOTE><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt">Done.<BR></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt"><BR>OLD<BR> Z9 is used to indicated=20 the<BR>NEW<BR> Z9 is used to indicate=20 the<BR>END<BR><BR></SPAN></FONT></BLOCKQUOTE><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt">Done.<BR><BR>...George<BR></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 10pt"><BR>___________________________________________= ____<BR>mpls=20 mailing list<BR><A href=3D"mpls@ietf.org">mpls@ietf.org</A><BR><A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR><BR></SPAN></FONT></BLOCKQUOTE></BODY></HTML> --_000_FE60A4E52763E84B935532D7D9294FF121F4B63C26EUSAACMS0715e_-- From RCosta@ptinovacao.pt Thu Jul 7 17:14:53 2011 Return-Path: <RCosta@ptinovacao.pt> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3521F883A; Thu, 7 Jul 2011 17:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3HL8tZ7FXFj; Thu, 7 Jul 2011 17:14:51 -0700 (PDT) Received: from owa.ptinovacao.pt (webmail.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id DACED21F8838; Thu, 7 Jul 2011 17:14:45 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Fri, 8 Jul 2011 01:14:43 +0100 From: Rui Costa <RCosta@ptinovacao.pt> To: David Allan I <david.i.allan@ericsson.com>, Stewart Bryant <stbryant@cisco.com> Date: Fri, 8 Jul 2011 01:14:42 +0100 Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEA= Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jul 2011 00:14:53 -0000 David,=09 Reading something, keeping it on record, without effect in the draft and "i= gnoring comments" have IMHO similar outcomes. As author of the draft you ar= e free to do it. These standards have a great impact in our work, so i'm al= so free to write what i did.=09 Stewart,=09 My technical concerns regarding this draft were expressed...=09 ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe)= ;=09 ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary = meeting;=09 ...in a comparison session that took place during that same ITU-T meeting.= =09 Some:=09 CC/CV=09 I don't understand the need for 2 types of packets: a single type allows CC= ; mismatching identifiers in the same CC packets allow CV.=09 Besides adding complexity, we whether always activate both or potentiate un= detected mismerges.=09 (BTW: can't understand how we propose one ACH codepoint to CC, another for = CV, [counting other drafts, another for frame loss ...] but don't consider = assigning 1 single ACH protocol identifier codepoint as requested by ITU-T)= =09 Uni P2P / P2MP=09 I can't see how BFD will support unidir and hence P2MP other than...=09 ...eliminating the session "state variable" (down, init, up), aiming just t= he state variables we really need, bringing us to something similar to 1731= , eventually with other bits on the wire or...=09 ...using IP to create the reverse way, which we cannot assume per requireme= nts;=09 Will we create a complete different tool for that?=09 (BFD's B=3D"bidirectional")=09 Provisioning list=09 This is an MPLS profile/subset (and i heard) achievable through a particula= r configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that pr= ofile/configuration. However, i keep seeing references f.i. to IP encapsula= tions unexpected under TP's OAM.=09 I don't thus understand what the aim is: do we expect this in TP, are we ta= lking about MPLS in general?... The TP profile is never quite delimited.=09 Does chapter 4 contain ALL the configurable parameters list agreed to provi= de in the comparison session?=09 Backwards compatibility=09 This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a b= etter argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment= plus coherence with SDH, OTN, as defended by ITU-T.=09 For reasons like the above, however, MPLS-TP BFD won't be backwards compati= ble with previous BFD (even considering just CC/CV). They don't even share = the same codepoint.=09 Simplicity=09 Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler:= in each flow, a standard defined nr of constant heartbeat signals (with st= andard constant or provisioned period - no auto/negotiated -) means OK. A s= tandard defined number of misses means lost Rx connection. An RDI, the only= articulation between Rx and Tx flows, meaningful in bidirectional applicat= ions, allows each pear to identify Tx problems.=09 This OAM simplicity is the key for reliable fail finger pointing, performan= ce reports and protection. Also to allow scaling, more implementation oppor= tunities/manufacturers, which is valuable for operators.=09 IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more diffi= cult to tell which is which.=09 Regards,=09 Rui=09 -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>= (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: <snipped> >Several service providers regarded this draft as not meeting their=20 >transport networks' needs.=09 E> This is a true statement: the solution in this draft is useless for many= MPLS- TP deployments. The two statements do not necessarily follow.=20 What we established during discussions at the SG15 plenary in February was = that the issue some service providers had was that the IETF BFD solution ex= ceeded their requirements in that there was additional functionality they d= id not see a need for, and that they considered any additional functionalit= y parasitic. However this is a consequence of adapting an existing technology to a new a= pplication. I do not see any way around that. And the entire joint project = was based on the premise of engineering re-use not greenfield design. That = is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mai= nstream, so it is a bit late to cry foul.... My 2 cents Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>= (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February = where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it]=20 Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair= =20 because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by= =20 several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been=20 resolved. >Several service providers regarded this draft as not meeting their transpo= rt=20 networks' needs.=09 This is a true statement: the solution in this draft is useless for many MP= LS- TP deployments. -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it]=20 Sent: quarta-feira, 6 de Julho de 2011 18:26 To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC commen= ts=20 were correctly with minor comments.=20 It also says: The comments has been carefully discussed between the authors and people making the=20 comments and has been resolved. But it seems that some comments have not been discussed with the authors of= =20 the comments. When ITU-T Q10/15 has been involved in discussing its comment= s? -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: quarta-feira, 6 de Julho de 2011 16:44 To: Rui Costa Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving=20 questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without=20 doubt that no comments been ignored. Loa mpls wg document shepherd -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: quarta-feira, 6 de Julho de 2011 14:58 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well a= s those collected from the MPLS WG was presented at the last IETF. My sprea= dsheet from which that report was generated and has been augmented to inclu= de the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last= -Call-Comments.xls So you know...=09 Dave -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui= Costa Sent: segunda-feira, 4 de Julho de 2011 23:03 To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard IMHO and for the record:=09 ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent.=09 Several service providers regarded this draft as not meeting their transpor= t networks' needs.=09 [The v03 draft was published in Feb and went to WG LC.=09 The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up).=09 When was the WG LC launched, to verify LC comments resolution?]=09 Regards,=09 Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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 2011-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From neil.2.harrison@bt.com Fri Jul 8 00:16:06 2011 Return-Path: <neil.2.harrison@bt.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE3821F87B1; Fri, 8 Jul 2011 00:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGGk2vg0nWkC; Fri, 8 Jul 2011 00:16:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id D2EDA21F887C; Fri, 8 Jul 2011 00:16:03 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 08:16:01 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.186]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 8 Jul 2011 08:16:02 +0100 From: <neil.2.harrison@bt.com> To: <RCosta@ptinovacao.pt>, <david.i.allan@ericsson.com>, <stbryant@cisco.com> Date: Fri, 8 Jul 2011 08:15:57 +0100 Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAAkhZucA== Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, ietf-announce@ietf.org Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jul 2011 07:16:06 -0000 Got to say I agree with Rui on much of what he says here. And I absolutely= resonate with his point on the need for simplicity. The reason OAM needs = to be as simple as possible is because it must be super reliable....we do n= ot want to consciously build in weaknesses, esp unnecessary ones.... this a= lso implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a C= V function...the ATM OAM in I.610 suffers from this problem (and few others= like AIS and the assumed use of request/response MLT to diagnose leaking/m= ismerging traffic...request/response OAM won't work with unidirectional def= ects). - all packet layer networks should not have an AIS OAM message....ver= y obvious for the cl-ps mode of course. The co-ps mode is also not like th= e co-cs mode. One has to consciously manufacture AIS messages and target t= hem to specific clients in the co-ps mode....who may have taken action in t= heir own layer network and 'moved elsewhere' anyway, ie a total waste of ti= me now. AIS is actually unnecessary wrt providing information anyway, it s= imply represents an in-built weakness of just something else to go wrong wh= ich itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO= . It is far smarter to simply create a single end-end OAM CV (and when req= uired PM) flow and tap this off at intermediate nodes on the *rare* occasio= ns one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rui Costa > Sent: 08 July 2011 01:15 > To: David Allan I; Stewart Bryant > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > David, > > Reading something, keeping it on record, without effect in the draft > and "ignoring comments" have IMHO similar outcomes. As author of the > draft you are free to do it. These standards have a great impact in our > work, so i'm also free to write what i did. > > > > > Stewart, > > My technical concerns regarding this draft were expressed... > ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > believe); > ...in operators' meetings' that took place during ITU-T's Feb/2011 > plenary meeting; > ...in a comparison session that took place during that same ITU-T > meeting. > Some: > > CC/CV > I don't understand the need for 2 types of packets: a single type > allows CC; mismatching identifiers in the same CC packets allow CV. > Besides adding complexity, we whether always activate both or > potentiate undetected mismerges. > (BTW: can't understand how we propose one ACH codepoint to CC, another > for CV, [counting other drafts, another for frame loss ...] but don't > consider assigning 1 single ACH protocol identifier codepoint as > requested by ITU-T) > > Uni P2P / P2MP > I can't see how BFD will support unidir and hence P2MP other than... > > ...eliminating the session "state variable" (down, init, up), aiming > just the state variables we really need, bringing us to something > similar to 1731, eventually with other bits on the wire or... > ...using IP to create the reverse way, which we cannot assume per > requirements; > Will we create a complete different tool for that? > (BFD's B=3D"bidirectional") > > Provisioning list > This is an MPLS profile/subset (and i heard) achievable through a > particular configuration. So, i expect each draft-ietf-mpls-TP-* to > focus on that profile/configuration. However, i keep seeing references > f.i. to IP encapsulations unexpected under TP's OAM. > I don't thus understand what the aim is: do we expect this in TP, are > we talking about MPLS in general?... The TP profile is never quite > delimited. > Does chapter 4 contain ALL the configurable parameters list agreed to > provide in the comparison session? > > Backwards compatibility > This was the main argument risen to ground MPLS-TP OAM on BFD. It's not > a better argument than grounding MPLS-TP OAM on 1731 due to its ETH > deployment plus coherence with SDH, OTN, as defended by ITU-T. > For reasons like the above, however, MPLS-TP BFD won't be backwards > compatible with previous BFD (even considering just CC/CV). They don't > even share the same codepoint. > > Simplicity > Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > simpler: in each flow, a standard defined nr of constant heartbeat > signals (with standard constant or provisioned period - no > auto/negotiated -) means OK. A standard defined number of misses means > lost Rx connection. An RDI, the only articulation between Rx and Tx > flows, meaningful in bidirectional applications, allows each pear to > identify Tx problems. > This OAM simplicity is the key for reliable fail finger pointing, > performance reports and protection. Also to allow scaling, more > implementation opportunities/manufacturers, which is valuable for > operators. > > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more > difficult to tell which is which. > > Regards, > Rui > > > > > > > > > > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: quarta-feira, 6 de Julho de 2011 19:25 > To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > Announce > Cc: mpls@ietf.org > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Hi Erminio: > > <snipped> > >Several service providers regarded this draft as not meeting their > >transport networks' needs. > > E> This is a true statement: the solution in this draft is useless for > many MPLS- TP deployments. > > The two statements do not necessarily follow. > > What we established during discussions at the SG15 plenary in February > was that the issue some service providers had was that the IETF BFD > solution exceeded their requirements in that there was additional > functionality they did not see a need for, and that they considered any > additional functionality parasitic. > > However this is a consequence of adapting an existing technology to a > new application. I do not see any way around that. And the entire joint > project was based on the premise of engineering re-use not greenfield > design. That is what it said on the tin up front, and IMO why when the > IETF started down this path packet transport transitioned from being a > minority sport to mainstream, so it is a bit late to cry foul.... > > My 2 cents > Dave > > > > > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: quarta-feira, 6 de Julho de 2011 18:36 > To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Hi Erminio: > > Two of the three document editors were present at SG15 plenary in > February where the comments originated. The revised meeting schedule > resulted in a day spent going through the document with the editors. > IMO there were lots of discussion and legitimate issues with the > document identified and corrected so it was a useful session. The > liaison of same was in many ways *after the fact*. > > Cheers > Dave > > > > > -----Original Message----- > From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] > Sent: quarta-feira, 6 de Julho de 2011 18:34 > To: Rui Costa; ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > The way this draft has been developed is a bit strange. > > The poll for its adoption as a WG document was halted by the MPLS WG > chair > because "it is not possible to judge consensus": > > http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > The lack of consensus was motivated by serious technical concerns > raised by > several transport experts during the poll. > > Nevertheless the MPLS WG chair decided to adopt the draft as a WG > document: > > http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > After several WG revisions and WG LCs, the technical issues have not > been > resolved. > > >Several service providers regarded this draft as not meeting their > transport > networks' needs. > > This is a true statement: the solution in this draft is useless for > many MPLS- > TP deployments. > > > -----Original Message----- > From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] > Sent: quarta-feira, 6 de Julho de 2011 18:26 > To: loa@pi.nu; Rui Costa > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > Version -04 of the document was published June 28th. > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > > June 29th. > > > > So when the WG LC to confirm the LC comment resolution has been > launched? > > The proto write-up says: > > It has also passed a working roup call to verify that LC > comments > were correctly with minor comments. > > It also says: > > The comments has been > carefully discussed between the authors and people making > the > comments and > has been resolved. > > But it seems that some comments have not been discussed with the > authors of > the comments. When ITU-T Q10/15 has been involved in discussing its > comments? > > > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: quarta-feira, 6 de Julho de 2011 16:44 > To: Rui Costa > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > All, > > Since someone has commented about the process used for resolving > questions on > draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > > The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > process is: > > On February 3rd 2011 the working group last call was issued > on version -03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > > The authors compiled a list of all comments received as part the MPLS > working group last call; these comments - and the intended resolution > - > is included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD working > group to do a separate working group last callfor the BFD working > group > > The (BFD) working group last call was started on March 30th and ran > for 13 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some > issue has been brought to the working group mailing list for > resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editorial > comments. Version -05 was published on June 29 and the IETF last call > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiable at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows > without > doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > > > > > > > > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: quarta-feira, 6 de Julho de 2011 14:58 > To: Rui Costa; ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Hi Rui: > > The comments were not ignored, the resolution of the Q10 comments as > well as those collected from the MPLS WG was presented at the last > IETF. My spreadsheet from which that report was generated and has been > augmented to include the BFD WG comments is available at > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > So you know... > Dave > > > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Rui Costa > Sent: segunda-feira, 4 de Julho de 2011 23:03 > To: ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > IMHO and for the record: > > ITU-T comments regarding this draft haven't been discussed with ITU-T > but were simply ignored. No LS describing these comments' resolution > was sent. > > Several service providers regarded this draft as not meeting their > transport networks' needs. > > [The v03 draft was published in Feb and went to WG LC. > The v04 draft addressing WG LC comments was published on the 28th June > (same date as the proto write-up). > When was the WG LC launched, to verify LC comments resolution?] > > Regards, > Rui > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > The IESG > Sent: quinta-feira, 30 de Junho de 2011 14:47 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching > WG > (mpls) to consider the following document: > - 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Fri Jul 8 06:30:28 2011 Return-Path: <jdrake@juniper.net> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5DA21F8A72; Fri, 8 Jul 2011 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDaWHTjiaYWR; Fri, 8 Jul 2011 06:30:27 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id B9BBD21F8A6A; Fri, 8 Jul 2011 06:30:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKThcGaHkJNGMWt8NOt5gFakIFFvy/IzGv@postini.com; Fri, 08 Jul 2011 06:30:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 8 Jul 2011 06:25:57 -0700 From: John E Drake <jdrake@juniper.net> To: "neil.2.harrison@bt.com" <neil.2.harrison@bt.com>, "RCosta@ptinovacao.pt" <RCosta@ptinovacao.pt>, "david.i.allan@ericsson.com" <david.i.allan@ericsson.com>, "stbryant@cisco.com" <stbryant@cisco.com> Date: Fri, 8 Jul 2011 06:25:55 -0700 Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAAkhZucAANiFrQ Message-ID: <5E893DB832F57341992548CDBB333163A0A8FAF79B@EMBX01-HQ.jnpr.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "ietf-announce@ietf.org" <ietf-announce@ietf.org> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jul 2011 13:30:28 -0000 Neil, I have a question for clarification. Have you actually read draft-ietf-mpl= s-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it i= s considered good form to read something before commenting on it. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > neil.2.harrison@bt.com > Sent: Friday, July 08, 2011 12:16 AM > To: RCosta@ptinovacao.pt; david.i.allan@ericsson.com; > stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Got to say I agree with Rui on much of what he says here. And I > absolutely resonate with his point on the need for simplicity. The > reason OAM needs to be as simple as possible is because it must be > super reliable....we do not want to consciously build in weaknesses, > esp unnecessary ones.... this also implies minimal config. We could > all do better on this. For example: > > - Rui is dead right a CC function is fairly useless, we only need > a CV function...the ATM OAM in I.610 suffers from this problem (and few > others like AIS and the assumed use of request/response MLT to diagnose > leaking/mismerging traffic...request/response OAM won't work with > unidirectional defects). > > - all packet layer networks should not have an AIS OAM > message....very obvious for the cl-ps mode of course. The co-ps mode > is also not like the co-cs mode. One has to consciously manufacture > AIS messages and target them to specific clients in the co-ps > mode....who may have taken action in their own layer network and 'moved > elsewhere' anyway, ie a total waste of time now. AIS is actually > unnecessary wrt providing information anyway, it simply represents an > in-built weakness of just something else to go wrong which itself will > create problems. > > - creating preconfigured TCM sublayers is just asking for trouble > IMO. It is far smarter to simply create a single end-end OAM CV (and > when required PM) flow and tap this off at intermediate nodes on the > *rare* occasions one wants to do. > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rui Costa > > Sent: 08 July 2011 01:15 > > To: David Allan I; Stewart Bryant > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > David, > > > > Reading something, keeping it on record, without effect in the draft > > and "ignoring comments" have IMHO similar outcomes. As author of the > > draft you are free to do it. These standards have a great impact in > our > > work, so i'm also free to write what i did. > > > > > > > > > > Stewart, > > > > My technical concerns regarding this draft were expressed... > > ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > > believe); > > ...in operators' meetings' that took place during ITU-T's Feb/2011 > > plenary meeting; > > ...in a comparison session that took place during that same ITU-T > > meeting. > > Some: > > > > CC/CV > > I don't understand the need for 2 types of packets: a single type > > allows CC; mismatching identifiers in the same CC packets allow CV. > > Besides adding complexity, we whether always activate both or > > potentiate undetected mismerges. > > (BTW: can't understand how we propose one ACH codepoint to CC, > another > > for CV, [counting other drafts, another for frame loss ...] but don't > > consider assigning 1 single ACH protocol identifier codepoint as > > requested by ITU-T) > > > > Uni P2P / P2MP > > I can't see how BFD will support unidir and hence P2MP other than... > > > > ...eliminating the session "state variable" (down, init, up), aiming > > just the state variables we really need, bringing us to something > > similar to 1731, eventually with other bits on the wire or... > > ...using IP to create the reverse way, which we cannot assume per > > requirements; > > Will we create a complete different tool for that? > > (BFD's B=3D"bidirectional") > > > > Provisioning list > > This is an MPLS profile/subset (and i heard) achievable through a > > particular configuration. So, i expect each draft-ietf-mpls-TP-* to > > focus on that profile/configuration. However, i keep seeing > references > > f.i. to IP encapsulations unexpected under TP's OAM. > > I don't thus understand what the aim is: do we expect this in TP, are > > we talking about MPLS in general?... The TP profile is never quite > > delimited. > > Does chapter 4 contain ALL the configurable parameters list agreed to > > provide in the comparison session? > > > > Backwards compatibility > > This was the main argument risen to ground MPLS-TP OAM on BFD. It's > not > > a better argument than grounding MPLS-TP OAM on 1731 due to its ETH > > deployment plus coherence with SDH, OTN, as defended by ITU-T. > > For reasons like the above, however, MPLS-TP BFD won't be backwards > > compatible with previous BFD (even considering just CC/CV). They > don't > > even share the same codepoint. > > > > Simplicity > > Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > > simpler: in each flow, a standard defined nr of constant heartbeat > > signals (with standard constant or provisioned period - no > > auto/negotiated -) means OK. A standard defined number of misses > means > > lost Rx connection. An RDI, the only articulation between Rx and Tx > > flows, meaningful in bidirectional applications, allows each pear to > > identify Tx problems. > > This OAM simplicity is the key for reliable fail finger pointing, > > performance reports and protection. Also to allow scaling, more > > implementation opportunities/manufacturers, which is valuable for > > operators. > > > > > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more > > difficult to tell which is which. > > > > Regards, > > Rui > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: quarta-feira, 6 de Julho de 2011 19:25 > > To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > > Announce > > Cc: mpls@ietf.org > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Hi Erminio: > > > > <snipped> > > >Several service providers regarded this draft as not meeting their > > >transport networks' needs. > > > > E> This is a true statement: the solution in this draft is useless > for > > many MPLS- TP deployments. > > > > The two statements do not necessarily follow. > > > > What we established during discussions at the SG15 plenary in > February > > was that the issue some service providers had was that the IETF BFD > > solution exceeded their requirements in that there was additional > > functionality they did not see a need for, and that they considered > any > > additional functionality parasitic. > > > > However this is a consequence of adapting an existing technology to a > > new application. I do not see any way around that. And the entire > joint > > project was based on the premise of engineering re-use not greenfield > > design. That is what it said on the tin up front, and IMO why when > the > > IETF started down this path packet transport transitioned from being > a > > minority sport to mainstream, so it is a bit late to cry foul.... > > > > My 2 cents > > Dave > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: quarta-feira, 6 de Julho de 2011 18:36 > > To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Hi Erminio: > > > > Two of the three document editors were present at SG15 plenary in > > February where the comments originated. The revised meeting schedule > > resulted in a day spent going through the document with the editors. > > IMO there were lots of discussion and legitimate issues with the > > document identified and corrected so it was a useful session. The > > liaison of same was in many ways *after the fact*. > > > > Cheers > > Dave > > > > > > > > > > -----Original Message----- > > From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > > Sent: quarta-feira, 6 de Julho de 2011 18:34 > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > Cc: mpls@ietf.org > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > The way this draft has been developed is a bit strange. > > > > The poll for its adoption as a WG document was halted by the MPLS WG > > chair > > because "it is not possible to judge consensus": > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > > > The lack of consensus was motivated by serious technical concerns > > raised by > > several transport experts during the poll. > > > > Nevertheless the MPLS WG chair decided to adopt the draft as a WG > > document: > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > > > After several WG revisions and WG LCs, the technical issues have not > > been > > resolved. > > > > >Several service providers regarded this draft as not meeting their > > transport > > networks' needs. > > > > This is a true statement: the solution in this draft is useless for > > many MPLS- > > TP deployments. > > > > > > -----Original Message----- > > From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > > Sent: quarta-feira, 6 de Julho de 2011 18:26 > > To: loa@pi.nu; Rui Costa > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > Version -04 of the document was published June 28th. > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > > > June 29th. > > > > > > > So when the WG LC to confirm the LC comment resolution has been > > launched? > > > > The proto write-up says: > > > > It has also passed a working roup call to verify that LC > > comments > > were correctly with minor comments. > > > > It also says: > > > > The comments has been > > carefully discussed between the authors and people making > > the > > comments and > > has been resolved. > > > > But it seems that some comments have not been discussed with the > > authors of > > the comments. When ITU-T Q10/15 has been involved in discussing its > > comments? > > > > > > > > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: quarta-feira, 6 de Julho de 2011 16:44 > > To: Rui Costa > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > All, > > > > Since someone has commented about the process used for resolving > > questions on > > draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > > > > The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > > process is: > > > > On February 3rd 2011 the working group last call was issued > > on version -03 > > > > This was copied to the the Ad Hoc Team List > > and liaised to SG15 also on February 3rd > > > > This working group last call ended om Feb 28 > > > > > > On Feb 28 we also received a liaison with comments from SG15 > > > > > > The authors compiled a list of all comments received as part the > MPLS > > working group last call; these comments - and the intended > resolution > > - > > is included in the meeting minutes from the Prague meeting: > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > During the IETF meeting in Prague, we agreed with the BFD working > > group to do a separate working group last callfor the BFD working > > group > > > > The (BFD) working group last call was started on March 30th and ran > > for 13 days. The last call ended on April 11th. > > > > The authors have since worked hard to resolve comments, some > > issue has been brought to the working group mailing list for > > resolution. > > > > Version -04 of the document was published June 28th. > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > > June 29th. > > > > The AD review resulted in a "New ID needed" due to mostly editorial > > comments. Version -05 was published on June 29 and the IETF last > call > > started as soon as the new ID was avaialbe. > > > > The current list of Last Call Comments resoltion is also avaiable > at: > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > The list of issues that the authors kept very carefully, shows > > without > > doubt > > that no comments been ignored. > > > > Loa > > mpls wg document shepherd > > > > > > > > > > > > > > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: quarta-feira, 6 de Julho de 2011 14:58 > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > Hi Rui: > > > > The comments were not ignored, the resolution of the Q10 comments as > > well as those collected from the MPLS WG was presented at the last > > IETF. My spreadsheet from which that report was generated and has > been > > augmented to include the BFD WG comments is available at > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > So you know... > > Dave > > > > > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > Of > > Rui Costa > > Sent: segunda-feira, 4 de Julho de 2011 23:03 > > To: ietf@ietf.org; IETF-Announce > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > IMHO and for the record: > > > > ITU-T comments regarding this draft haven't been discussed with ITU-T > > but were simply ignored. No LS describing these comments' resolution > > was sent. > > > > Several service providers regarded this draft as not meeting their > > transport networks' needs. > > > > [The v03 draft was published in Feb and went to WG LC. > > The v04 draft addressing WG LC comments was published on the 28th > June > > (same date as the proto write-up). > > When was the WG LC launched, to verify LC comments resolution?] > > > > Regards, > > Rui > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > The IESG > > Sent: quinta-feira, 30 de Junho de 2011 14:47 > > To: IETF-Announce > > Cc: mpls@ietf.org > > Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > The IESG has received a request from the Multiprotocol Label > Switching > > WG > > (mpls) to consider the following document: > > - 'Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile' > > <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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 2011-07-14. 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 > > > > Continuity Check, Proactive Connectivity Verification and Remote > > Defect Indication functionalities are required for MPLS-TP OAM. > > > > Continuity Check monitors the integrity of the continuity of the > > label switched path for any loss of continuity defect. > Connectivity > > verification monitors the integrity of the routing of the label > > switched path between sink and source for any connectivity issues. > > Remote defect indication enables an End Point to report, to its > > associated End Point, a fault or defect condition that it detects > on > > a pseudo wire, label switched path or Section. > > > > This document specifies methods for proactive continuity check, > > continuity verification, and remote defect indication for MPLS-TP > > label switched paths, pseudo wires and Sections using > Bidirectional > > Forwarding Detection. > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Fri Jul 8 06:37:13 2011 Return-Path: <neil.2.harrison@bt.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512921F86C9; Fri, 8 Jul 2011 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9xl34RGXGGF; Fri, 8 Jul 2011 06:37:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 01E6F21F86C5; Fri, 8 Jul 2011 06:37:10 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 14:37:09 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.186]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 8 Jul 2011 14:37:09 +0100 From: <neil.2.harrison@bt.com> To: <jdrake@juniper.net>, <RCosta@ptinovacao.pt>, <david.i.allan@ericsson.com>, <stbryant@cisco.com> Date: Fri, 8 Jul 2011 14:37:05 +0100 Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAAkhZucAANiFrQAABE91A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405A7555DD@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> <5E893DB832F57341992548CDBB333163A0A8FAF79B@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A8FAF79B@EMBX01-HQ.jnpr.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jul 2011 13:37:13 -0000 Not recently John. But my comments are general and not specific to this dr= aft. But it seems you are implying that the draft recognises my points. I= f so I will look forward to reading it later today when I get chance and se= eing AIS deprecated, TCM deprecated, CC functions deprecated, ability to ta= p off end-end CV/PM flows at intermediate nodes. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: 08 July 2011 14:26 > To: Harrison,N,Neil,DKQ7 R; RCosta@ptinovacao.pt; > david.i.allan@ericsson.com; stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Neil, > > I have a question for clarification. Have you actually read draft- > ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but > generally it is considered good form to read something before > commenting on it. > > Thanks, > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > neil.2.harrison@bt.com > > Sent: Friday, July 08, 2011 12:16 AM > > To: RCosta@ptinovacao.pt; david.i.allan@ericsson.com; > > stbryant@cisco.com > > Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > Got to say I agree with Rui on much of what he says here. And I > > absolutely resonate with his point on the need for simplicity. The > > reason OAM needs to be as simple as possible is because it must be > > super reliable....we do not want to consciously build in weaknesses, > > esp unnecessary ones.... this also implies minimal config. We could > > all do better on this. For example: > > > > - Rui is dead right a CC function is fairly useless, we only > need > > a CV function...the ATM OAM in I.610 suffers from this problem (and > few > > others like AIS and the assumed use of request/response MLT to > diagnose > > leaking/mismerging traffic...request/response OAM won't work with > > unidirectional defects). > > > > - all packet layer networks should not have an AIS OAM > > message....very obvious for the cl-ps mode of course. The co-ps mode > > is also not like the co-cs mode. One has to consciously manufacture > > AIS messages and target them to specific clients in the co-ps > > mode....who may have taken action in their own layer network and > 'moved > > elsewhere' anyway, ie a total waste of time now. AIS is actually > > unnecessary wrt providing information anyway, it simply represents an > > in-built weakness of just something else to go wrong which itself > will > > create problems. > > > > - creating preconfigured TCM sublayers is just asking for > trouble > > IMO. It is far smarter to simply create a single end-end OAM CV (and > > when required PM) flow and tap this off at intermediate nodes on the > > *rare* occasions one wants to do. > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > > confidential. > > It's meant only for the individual(s) or entity named above. If > you're > > not the intended > > recipient, note that disclosing, copying, distributing or using this > > information > > is prohibited. If you've received this email in error, please let me > > know immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Rui Costa > > > Sent: 08 July 2011 01:15 > > > To: David Allan I; Stewart Bryant > > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > David, > > > > > > Reading something, keeping it on record, without effect in the > draft > > > and "ignoring comments" have IMHO similar outcomes. As author of > the > > > draft you are free to do it. These standards have a great impact in > > our > > > work, so i'm also free to write what i did. > > > > > > > > > > > > > > > Stewart, > > > > > > My technical concerns regarding this draft were expressed... > > > ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > > > believe); > > > ...in operators' meetings' that took place during ITU-T's Feb/2011 > > > plenary meeting; > > > ...in a comparison session that took place during that same ITU-T > > > meeting. > > > Some: > > > > > > CC/CV > > > I don't understand the need for 2 types of packets: a single type > > > allows CC; mismatching identifiers in the same CC packets allow CV. > > > Besides adding complexity, we whether always activate both or > > > potentiate undetected mismerges. > > > (BTW: can't understand how we propose one ACH codepoint to CC, > > another > > > for CV, [counting other drafts, another for frame loss ...] but > don't > > > consider assigning 1 single ACH protocol identifier codepoint as > > > requested by ITU-T) > > > > > > Uni P2P / P2MP > > > I can't see how BFD will support unidir and hence P2MP other > than... > > > > > > ...eliminating the session "state variable" (down, init, up), > aiming > > > just the state variables we really need, bringing us to something > > > similar to 1731, eventually with other bits on the wire or... > > > ...using IP to create the reverse way, which we cannot assume per > > > requirements; > > > Will we create a complete different tool for that? > > > (BFD's B=3D"bidirectional") > > > > > > Provisioning list > > > This is an MPLS profile/subset (and i heard) achievable through a > > > particular configuration. So, i expect each draft-ietf-mpls-TP-* to > > > focus on that profile/configuration. However, i keep seeing > > references > > > f.i. to IP encapsulations unexpected under TP's OAM. > > > I don't thus understand what the aim is: do we expect this in TP, > are > > > we talking about MPLS in general?... The TP profile is never quite > > > delimited. > > > Does chapter 4 contain ALL the configurable parameters list agreed > to > > > provide in the comparison session? > > > > > > Backwards compatibility > > > This was the main argument risen to ground MPLS-TP OAM on BFD. It's > > not > > > a better argument than grounding MPLS-TP OAM on 1731 due to its ETH > > > deployment plus coherence with SDH, OTN, as defended by ITU-T. > > > For reasons like the above, however, MPLS-TP BFD won't be backwards > > > compatible with previous BFD (even considering just CC/CV). They > > don't > > > even share the same codepoint. > > > > > > Simplicity > > > Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > > > simpler: in each flow, a standard defined nr of constant heartbeat > > > signals (with standard constant or provisioned period - no > > > auto/negotiated -) means OK. A standard defined number of misses > > means > > > lost Rx connection. An RDI, the only articulation between Rx and Tx > > > flows, meaningful in bidirectional applications, allows each pear > to > > > identify Tx problems. > > > This OAM simplicity is the key for reliable fail finger pointing, > > > performance reports and protection. Also to allow scaling, more > > > implementation opportunities/manufacturers, which is valuable for > > > operators. > > > > > > > > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > more > > > difficult to tell which is which. > > > > > > Regards, > > > Rui > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > Sent: quarta-feira, 6 de Julho de 2011 19:25 > > > To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > > > Announce > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv- > rdi- > > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > Hi Erminio: > > > > > > <snipped> > > > >Several service providers regarded this draft as not meeting their > > > >transport networks' needs. > > > > > > E> This is a true statement: the solution in this draft is useless > > for > > > many MPLS- TP deployments. > > > > > > The two statements do not necessarily follow. > > > > > > What we established during discussions at the SG15 plenary in > > February > > > was that the issue some service providers had was that the IETF BFD > > > solution exceeded their requirements in that there was additional > > > functionality they did not see a need for, and that they considered > > any > > > additional functionality parasitic. > > > > > > However this is a consequence of adapting an existing technology to > a > > > new application. I do not see any way around that. And the entire > > joint > > > project was based on the premise of engineering re-use not > greenfield > > > design. That is what it said on the tin up front, and IMO why when > > the > > > IETF started down this path packet transport transitioned from > being > > a > > > minority sport to mainstream, so it is a bit late to cry foul.... > > > > > > My 2 cents > > > Dave > > > > > > > > > > > > > > > -----Original Message----- > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > Sent: quarta-feira, 6 de Julho de 2011 18:36 > > > To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv- > rdi- > > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > Hi Erminio: > > > > > > Two of the three document editors were present at SG15 plenary in > > > February where the comments originated. The revised meeting > schedule > > > resulted in a day spent going through the document with the > editors. > > > IMO there were lots of discussion and legitimate issues with the > > > document identified and corrected so it was a useful session. The > > > liaison of same was in many ways *after the fact*. > > > > > > Cheers > > > Dave > > > > > > > > > > > > > > > -----Original Message----- > > > From: erminio.ottone_69@libero.it > > [mailto:erminio.ottone_69@libero.it] > > > Sent: quarta-feira, 6 de Julho de 2011 18:34 > > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > > Cc: mpls@ietf.org > > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > The way this draft has been developed is a bit strange. > > > > > > The poll for its adoption as a WG document was halted by the MPLS > WG > > > chair > > > because "it is not possible to judge consensus": > > > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > > > > > The lack of consensus was motivated by serious technical concerns > > > raised by > > > several transport experts during the poll. > > > > > > Nevertheless the MPLS WG chair decided to adopt the draft as a WG > > > document: > > > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > > > > > After several WG revisions and WG LCs, the technical issues have > not > > > been > > > resolved. > > > > > > >Several service providers regarded this draft as not meeting their > > > transport > > > networks' needs. > > > > > > This is a true statement: the solution in this draft is useless for > > > many MPLS- > > > TP deployments. > > > > > > > > > -----Original Message----- > > > From: erminio.ottone_69@libero.it > > [mailto:erminio.ottone_69@libero.it] > > > Sent: quarta-feira, 6 de Julho de 2011 18:26 > > > To: loa@pi.nu; Rui Costa > > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > > Version -04 of the document was published June 28th. > > > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > > > June 29th. > > > > > > > > > > So when the WG LC to confirm the LC comment resolution has been > > > launched? > > > > > > The proto write-up says: > > > > > > It has also passed a working roup call to verify that > LC > > > comments > > > were correctly with minor comments. > > > > > > It also says: > > > > > > The comments has been > > > carefully discussed between the authors and people > making > > > the > > > comments and > > > has been resolved. > > > > > > But it seems that some comments have not been discussed with the > > > authors of > > > the comments. When ITU-T Q10/15 has been involved in discussing its > > > comments? > > > > > > > > > > > > > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.nu] > > > Sent: quarta-feira, 6 de Julho de 2011 16:44 > > > To: Rui Costa > > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > All, > > > > > > Since someone has commented about the process used for resolving > > > questions on > > > draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > > > > > > The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > > > process is: > > > > > > On February 3rd 2011 the working group last call was issued > > > on version -03 > > > > > > This was copied to the the Ad Hoc Team List > > > and liaised to SG15 also on February 3rd > > > > > > This working group last call ended om Feb 28 > > > > > > > > > On Feb 28 we also received a liaison with comments from SG15 > > > > > > > > > The authors compiled a list of all comments received as part the > > MPLS > > > working group last call; these comments - and the intended > > resolution > > > - > > > is included in the meeting minutes from the Prague meeting: > > > > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > > > > During the IETF meeting in Prague, we agreed with the BFD working > > > group to do a separate working group last callfor the BFD working > > > group > > > > > > The (BFD) working group last call was started on March 30th and ran > > > for 13 days. The last call ended on April 11th. > > > > > > The authors have since worked hard to resolve comments, some > > > issue has been brought to the working group mailing list for > > > resolution. > > > > > > Version -04 of the document was published June 28th. > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > > June 29th. > > > > > > The AD review resulted in a "New ID needed" due to mostly > editorial > > > comments. Version -05 was published on June 29 and the IETF last > > call > > > started as soon as the new ID was avaialbe. > > > > > > The current list of Last Call Comments resoltion is also avaiable > > at: > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > The list of issues that the authors kept very carefully, shows > > > without > > > doubt > > > that no comments been ignored. > > > > > > Loa > > > mpls wg document shepherd > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > Sent: quarta-feira, 6 de Julho de 2011 14:58 > > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > Hi Rui: > > > > > > The comments were not ignored, the resolution of the Q10 comments > as > > > well as those collected from the MPLS WG was presented at the last > > > IETF. My spreadsheet from which that report was generated and has > > been > > > augmented to include the BFD WG comments is available at > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > So you know... > > > Dave > > > > > > > > > -----Original Message----- > > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf > > Of > > > Rui Costa > > > Sent: segunda-feira, 4 de Julho de 2011 23:03 > > > To: ietf@ietf.org; IETF-Announce > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > IMHO and for the record: > > > > > > ITU-T comments regarding this draft haven't been discussed with > ITU-T > > > but were simply ignored. No LS describing these comments' > resolution > > > was sent. > > > > > > Several service providers regarded this draft as not meeting their > > > transport networks' needs. > > > > > > [The v03 draft was published in Feb and went to WG LC. > > > The v04 draft addressing WG LC comments was published on the 28th > > June > > > (same date as the proto write-up). > > > When was the WG LC launched, to verify LC comments resolution?] > > > > > > Regards, > > > Rui > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > The IESG > > > Sent: quinta-feira, 30 de Junho de 2011 14:47 > > > To: IETF-Announce > > > Cc: mpls@ietf.org > > > Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > > > > The IESG has received a request from the Multiprotocol Label > > Switching > > > WG > > > (mpls) to consider the following document: > > > - 'Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile' > > > <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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 2011-07-14. 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 > > > > > > Continuity Check, Proactive Connectivity Verification and Remote > > > Defect Indication functionalities are required for MPLS-TP OAM. > > > > > > Continuity Check monitors the integrity of the continuity of the > > > label switched path for any loss of continuity defect. > > Connectivity > > > verification monitors the integrity of the routing of the label > > > switched path between sink and source for any connectivity > issues. > > > Remote defect indication enables an End Point to report, to its > > > associated End Point, a fault or defect condition that it > detects > > on > > > a pseudo wire, label switched path or Section. > > > > > > This document specifies methods for proactive continuity check, > > > continuity verification, and remote defect indication for MPLS- > TP > > > label switched paths, pseudo wires and Sections using > > Bidirectional > > > Forwarding Detection. > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Fri Jul 8 06:37:56 2011 Return-Path: <swallow@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6B21F8AA0 for <mpls@ietfa.amsl.com>; Fri, 8 Jul 2011 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKr0XPV9cjsC for <mpls@ietfa.amsl.com>; Fri, 8 Jul 2011 06:37:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3111D21F86D6 for <mpls@ietf.org>; Fri, 8 Jul 2011 06:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=8025; q=dns/txt; s=iport; t=1310132275; x=1311341875; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=eW+zwhBcjJZA+wJ8TaVfjklQXwh9iGh+F0m8CSsgrOo=; b=iZZNI9BYuJLeCM1haWXAw9RGbAd93Su0+LS5f3L6q/homd+pjvzke8rB UYW5B4xeBdZETbhqwuXwOlAgewK11HsaRZPkhnDo6mWkK3cTfDFPCfSJG ycvjrnmqX0xHCFlvTOLAHJsbdJosaOOUGcFsK0DLkUiNeCwnn2m0eizmt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAKkHF06tJV2b/2dsb2JhbABSglGVPY5TZHeIe6RwnX6GOASHHYsvhQaLWg X-IronPort-AV: E=Sophos;i="4.65,499,1304294400"; d="scan'208,217";a="1041863" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2011 13:37:54 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68Dbs3G000785; Fri, 8 Jul 2011 13:37:54 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 08:37:54 -0500 Received: from 10.86.244.217 ([10.86.244.217]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jul 2011 13:37:54 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 08 Jul 2011 09:37:52 -0400 From: George Swallow <swallow@cisco.com> To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Adrian Farrel <adrian@olddog.co.uk>, "draft-ietf-mpls-tp-identifiers@tools.ietf.org" <draft-ietf-mpls-tp-identifiers@tools.ietf.org> Message-ID: <CA3C8070.11822%swallow@cisco.com> Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-identifiers Thread-Index: Acw1Epl1e9a+4No9S6KI0ZM/JsUxMgDCed0tATSftOAAIU8V8Q== In-Reply-To: <FE60A4E52763E84B935532D7D9294FF121F4B63C26@EUSAACMS0715.eamcs.ericsson.se> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392962673_160475616" X-OriginalArrivalTime: 08 Jul 2011 13:37:54.0183 (UTC) FILETIME=[3D5BD170:01CC3D74] Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org> Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jul 2011 13:37:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392962673_160475616 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks, I=B9ll fix that. ...George On 7/7/11 5:58 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote: > Hi George, > I have a question to new Section MEP-ID. In MPLS-TP a Section can be eith= er > physical link or logical, section layer LSP, link. I think that listed Se= ction > MEP_ID addresses the former case. Would Section MEP-ID in the latter case= be > the LSP MEP-ID? I think that both cases must be identified and their Sect= ion > MEP-IDs listed. > =20 > Regards, > Greg >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of G= eorge > Swallow > Sent: Friday, July 01, 2011 11:27 AM > To: Adrian Farrel; draft-ietf-mpls-tp-identifiers@tools.ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers >=20 > Adrian - >=20 >=20 > On 6/27/11 5:38 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote: >=20 >> Hi, >>=20 >> I have done my AD review of this document. In view of the fact that my >> comments >> are quite small, could you please handle them as part of the IETF last = call >> which I will start forthwith. >>=20 >> Thanks, >> Adrian >>=20 >> --- >> =20 >> You seem to be missing a section on MEP_IDs for MPLS_TP Sections. >> Insert before 7.2.1? >>=20 > Added the following section: >=20 > 7.2.1. MPLS-TP Section MEP_IDs >=20 > IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs of each end > of the section. For example, for a section whose MEG_ID is >=20 > A1-IF_ID::Z9-IF_ID >=20 > the Section MEP_ID at A1 would be >=20 > A1-IF_ID >=20 > and the Section MEP_ID at Z9 would be >=20 > Z9-IF_ID. >=20 > Where the Section MEP_ID needs to be globally unique, this is > accomplished by using globally unique Node_IDs as defined above. > Thus a globally unique Section MEP_ID becomes >=20 > Global_ID::IF_ID. >=20 >>=20 >> --- >>=20 >> Nits >>=20 >> 1.3 >>=20 >> OLD >> The notation does define a preferred ordering of the fields. >> NEW >> The notation defines a preferred ordering of the fields. >> END >>=20 > Done. >>=20 >> OLD >> Z9 is used to indicated the >> NEW >> Z9 is used to indicate the >> END >>=20 > Done. >=20 > ...George >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 --B_3392962673_160475616 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers Thanks,  I’ll fix that.

...George


On 7/7/11 5:58 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote:

Hi George,
I have a question to new Section MEP-ID. In MPLS-TP a Section can be either= physical link or logical, section layer LSP, link. I think that listed Sect= ion MEP_ID addresses the former case. Would Section MEP-ID in the latter cas= e be the LSP MEP-ID? I think that both cases must be identified and their Se= ction MEP-IDs listed.
    Reg= ards,
   =      Greg

From: mpls-bounces@= ietf.org [mailto:mpls-bounces@iet= f.org] On Behalf Of George Swallow
Sent: Friday, July 01, 2011 11:27 AM
To: Adrian Farrel; draft-ietf-mpls-tp-identifiers@tools.ietf.org
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-identifiers

Adrian -


On 6/27/11 5:38 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

Hi,

I have done my AD review of this document.  In view of the fact that m= y comments
are quite small, could you please  handle them as part of the IETF las= t call
which I will start  forthwith.

Thanks,
Adrian

---
  
You seem to  be missing a section on MEP_IDs for MPLS_TP Sections.
Insert before  7.2.1?

Added the following section:

7.2.1.  MPLS-TP Section MEP_IDs

   IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs o= f each end
   of the section.  For example, for a section whose ME= G_ID is

      A1-IF_ID::Z9-IF_ID

   the Section MEP_ID at A1 would be

      A1-IF_ID

   and the Section MEP_ID at Z9 would be

      Z9-IF_ID.

   Where the Section MEP_ID needs to be globally unique, thi= s is
   accomplished by using globally unique Node_IDs as defined= above.
   Thus a globally unique Section MEP_ID becomes

      Global_ID::IF_ID.


---

Nits

1.3

OLD
The  notation does define a preferred ordering of the fields.
NEW
The  notation defines a preferred ordering of the  fields.
END

Done.

OLD
 Z9 is used to indicated  the
NEW
 Z9 is used to indicate the
END

Done.

...George

_______________________________________________
mpls  mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls


--B_3392962673_160475616-- From swallow@cisco.com Fri Jul 8 06:39:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A059F21F8A9D; Fri, 8 Jul 2011 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.901 X-Spam-Level: X-Spam-Status: No, score=-104.901 tagged_above=-999 required=5 tests=[AWL=-2.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sg7HY5rTjS2; Fri, 8 Jul 2011 06:39:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A114721F86D6; Fri, 8 Jul 2011 06:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=4678; q=dns/txt; s=iport; t=1310132388; x=1311341988; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=OUwE7mFBnkEf9TjCfHl/rZzCLnlztl7CAqGYuq5JNkQ=; b=UIxNjv8jKy4YS89Sw29wXknLdYIXF6IfyustRYdJXgGshgv2G8lH9f5x QcsHAh1hfvuwsWGKbUNE2ZeCuiGINQW8t21s0uXv7NZv+oU1mhiIXcom9 +t3SHXCIfQxA1kdj7tPyok0Ri9OPJ26h6WML5kBEVmgcgVUIOdgKdIM2p s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKkHF06tJXG8/2dsb2JhbABMBqdFd4h7pHCdfgKDOoJ8BIcdiy+FBota X-IronPort-AV: E=Sophos;i="4.65,499,1304294400"; d="scan'208";a="1042446" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 13:39:48 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p68DdlSB007050; Fri, 8 Jul 2011 13:39:48 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 08:39:47 -0500 Received: from 10.86.244.217 ([10.86.244.217]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jul 2011 13:39:47 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 08 Jul 2011 09:39:46 -0400 From: George Swallow To: "D'Alessandro Alessandro Gerardo" , "ietf@ietf.org" Message-ID: Thread-Topic: R: [mpls] Last Call: (MPLS-TP Identifiers) to Proposed Standard Thread-Index: Acw1F+fy2cc2fqAsQjWUdW71y7nF9QGmM/rQAHDyCYo= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Jul 2011 13:39:47.0561 (UTC) FILETIME=[80EFED90:01CC3D74] Cc: "mpls@ietf.org" Subject: Re: [mpls] R: Last Call: (MPLS-TP Identifiers) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 13:39:49 -0000 Alessandro - Thanks for the comments. Will incorporate in next rev. ...George On 7/6/11 4:16 AM, "D'Alessandro Alessandro Gerardo" wrote: > Dear all, > I have the following comments: >=20 > Sect 7: " A maintenance point is either a Maintenance > Entity Group End-point (MEP) or a Maintenance Entity Group > Intermediate Point (MIP). Maintenance points are uniquely associated > with a MEG." >> This is true for MEP. MIP, as currently defined, are not uniquely associ= ated >> with a MEG. >=20 > Sec 7.4 " At a cross-connect point, in order to automatically generate MI= P_IDs > for MPLS-TP, we simply use the IF_IDs of the two interfaces which are > cross-connected" >> the above given definition refers to "intermediate node". It should be >> extended to cover also the case of "end nodes" because MIPs could be loc= ated >> in such nodes when per-interface MEPs model is applied (e.g. >> draft-ietf-mpls-tp-oam-framework and Yoshinori's contributions) >> a reference to sect 4, where IF_ID are defined, should be added >=20 > Best regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 >=20 > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di The= IESG > Inviato: marted=EC 28 giugno 2011 00:16 > A: IETF-Announce > Cc: mpls@ietf.org > Oggetto: [mpls] Last Call: (MPLS-= TP > Identifiers) to Proposed Standard >=20 >=20 > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'MPLS-TP Identifiers' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the ietf@iet= f.org > mailing lists by 2011-07-11. 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. >=20 > Abstract >=20 > This document specifies an initial set of identifiers to be used in > the Transport Profile of Multiprotocol Label Switching (MPLS-TP). > The MPLS-TP requirements (RFC 5654) require that the elements and > objects in an MPLS-TP environment are able to be configured and > managed without a control plane. In such an environment many > conventions for defining identifiers are possible. This document > defines identifiers for MPLS-TP management and OAM functions suitable > to IP/MPLS conventions. >=20 > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge > (PWE3) architectures to support the capabilities and functionalities > of a packet transport network as defined by the ITU-T. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From tnadeau@lucidvision.com Fri Jul 8 08:26:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9642E21F8AFC; Fri, 8 Jul 2011 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+2GhRzo209m; Fri, 8 Jul 2011 08:26:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D7BF221F8AD5; Fri, 8 Jul 2011 08:26:37 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B5E851C37658; Fri, 8 Jul 2011 11:26:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> Date: Fri, 8 Jul 2011 11:26:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1084) Cc: mpls@ietf.org, ietf@ietf.org, ietf-announce@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:26:39 -0000 On Jul 8, 2011, at 3:15 AM, wrote: > Got to say I agree with Rui on much of what he says here. And I = absolutely resonate with his point on the need for simplicity. The = reason OAM needs to be as simple as possible is because it must be super = reliable....we do not want to consciously build in weaknesses, esp = unnecessary ones.... this also implies minimal config. We could all do = better on this. For example: >=20 > - Rui is dead right a CC function is fairly useless, we only = need a CV function...the ATM OAM in I.610 suffers from this problem (and = few others like AIS and the assumed use of request/response MLT to = diagnose leaking/mismerging traffic...request/response OAM won't work = with unidirectional defects). While you are entitled to your opinion, I personally think there = are enough requirements elsewhere to have both CC and CV functions. But = we digress. Are you actually asking that the CC functionality be removed = from the draft or just making a general comment? > - all packet layer networks should not have an AIS OAM = message....very obvious for the cl-ps mode of course. The co-ps mode is = also not like the co-cs mode. One has to consciously manufacture AIS = messages and target them to specific clients in the co-ps mode....who = may have taken action in their own layer network and 'moved elsewhere' = anyway, ie a total waste of time now. AIS is actually unnecessary wrt = providing information anyway, it simply represents an in-built weakness = of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in = question? > - creating preconfigured TCM sublayers is just asking for = trouble IMO. It is far smarter to simply create a single end-end OAM CV = (and when required PM) flow and tap this off at intermediate nodes on = the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in = question? --tom >=20 > regards, Neil >=20 > This email contains BT information, which may be privileged or = confidential. > It's meant only for the individual(s) or entity named above. If you're = not the intended > recipient, note that disclosing, copying, distributing or using this = information > is prohibited. If you've received this email in error, please let me = know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> Rui Costa >> Sent: 08 July 2011 01:15 >> To: David Allan I; Stewart Bryant >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> David, >>=20 >> Reading something, keeping it on record, without effect in the draft >> and "ignoring comments" have IMHO similar outcomes. As author of the >> draft you are free to do it. These standards have a great impact in = our >> work, so i'm also free to write what i did. >>=20 >>=20 >>=20 >>=20 >> Stewart, >>=20 >> My technical concerns regarding this draft were expressed... >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i >> believe); >> ...in operators' meetings' that took place during ITU-T's Feb/2011 >> plenary meeting; >> ...in a comparison session that took place during that same ITU-T >> meeting. >> Some: >>=20 >> CC/CV >> I don't understand the need for 2 types of packets: a single type >> allows CC; mismatching identifiers in the same CC packets allow CV. >> Besides adding complexity, we whether always activate both or >> potentiate undetected mismerges. >> (BTW: can't understand how we propose one ACH codepoint to CC, = another >> for CV, [counting other drafts, another for frame loss ...] but don't >> consider assigning 1 single ACH protocol identifier codepoint as >> requested by ITU-T) >>=20 >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other than... >>=20 >> ...eliminating the session "state variable" (down, init, up), aiming >> just the state variables we really need, bringing us to something >> similar to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume per >> requirements; >> Will we create a complete different tool for that? >> (BFD's B=3D"bidirectional") >>=20 >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through a >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to >> focus on that profile/configuration. However, i keep seeing = references >> f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP, are >> we talking about MPLS in general?... The TP profile is never quite >> delimited. >> Does chapter 4 contain ALL the configurable parameters list agreed to >> provide in the comparison session? >>=20 >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's = not >> a better argument than grounding MPLS-TP OAM on 1731 due to its ETH >> deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards >> compatible with previous BFD (even considering just CC/CV). They = don't >> even share the same codepoint. >>=20 >> Simplicity >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is >> simpler: in each flow, a standard defined nr of constant heartbeat >> signals (with standard constant or provisioned period - no >> auto/negotiated -) means OK. A standard defined number of misses = means >> lost Rx connection. An RDI, the only articulation between Rx and Tx >> flows, meaningful in bidirectional applications, allows each pear to >> identify Tx problems. >> This OAM simplicity is the key for reliable fail finger pointing, >> performance reports and protection. Also to allow scaling, more >> implementation opportunities/manufacturers, which is valuable for >> operators. >>=20 >>=20 >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more >> difficult to tell which is which. >>=20 >> Regards, >> Rui >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 19:25 >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- >> Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >>=20 >> Hi Erminio: >>=20 >> >>> Several service providers regarded this draft as not meeting their >>> transport networks' needs. >>=20 >> E> This is a true statement: the solution in this draft is useless = for >> many MPLS- TP deployments. >>=20 >> The two statements do not necessarily follow. >>=20 >> What we established during discussions at the SG15 plenary in = February >> was that the issue some service providers had was that the IETF BFD >> solution exceeded their requirements in that there was additional >> functionality they did not see a need for, and that they considered = any >> additional functionality parasitic. >>=20 >> However this is a consequence of adapting an existing technology to a >> new application. I do not see any way around that. And the entire = joint >> project was based on the premise of engineering re-use not greenfield >> design. That is what it said on the tin up front, and IMO why when = the >> IETF started down this path packet transport transitioned from being = a >> minority sport to mainstream, so it is a bit late to cry foul.... >>=20 >> My 2 cents >> Dave >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 18:36 >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >>=20 >> Hi Erminio: >>=20 >> Two of the three document editors were present at SG15 plenary in >> February where the comments originated. The revised meeting schedule >> resulted in a day spent going through the document with the editors. >> IMO there were lots of discussion and legitimate issues with the >> document identified and corrected so it was a useful session. The >> liaison of same was in many ways *after the fact*. >>=20 >> Cheers >> Dave >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: erminio.ottone_69@libero.it = [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:34 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: R: Re: [mpls] Last Call: = >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> The way this draft has been developed is a bit strange. >>=20 >> The poll for its adoption as a WG document was halted by the MPLS WG >> chair >> because "it is not possible to judge consensus": >>=20 >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html >>=20 >> The lack of consensus was motivated by serious technical concerns >> raised by >> several transport experts during the poll. >>=20 >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG >> document: >>=20 >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html >>=20 >> After several WG revisions and WG LCs, the technical issues have not >> been >> resolved. >>=20 >>> Several service providers regarded this draft as not meeting their >> transport >> networks' needs. >>=20 >> This is a true statement: the solution in this draft is useless for >> many MPLS- >> TP deployments. >>=20 >>=20 >> -----Original Message----- >> From: erminio.ottone_69@libero.it = [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:26 >> To: loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: R: Re: [mpls] Last Call: = >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >>> Version -04 of the document was published June 28th. >>>=20 >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >>> June 29th. >>>=20 >>=20 >> So when the WG LC to confirm the LC comment resolution has been >> launched? >>=20 >> The proto write-up says: >>=20 >> It has also passed a working roup call to verify that LC >> comments >> were correctly with minor comments. >>=20 >> It also says: >>=20 >> The comments has been >> carefully discussed between the authors and people making >> the >> comments and >> has been resolved. >>=20 >> But it seems that some comments have not been discussed with the >> authors of >> the comments. When ITU-T Q10/15 has been involved in discussing its >> comments? >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: quarta-feira, 6 de Julho de 2011 16:44 >> To: Rui Costa >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> All, >>=20 >> Since someone has commented about the process used for resolving >> questions on >> draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. >>=20 >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >> process is: >>=20 >> On February 3rd 2011 the working group last call was issued >> on version -03 >>=20 >> This was copied to the the Ad Hoc Team List >> and liaised to SG15 also on February 3rd >>=20 >> This working group last call ended om Feb 28 >>=20 >>=20 >> On Feb 28 we also received a liaison with comments from SG15 >>=20 >>=20 >> The authors compiled a list of all comments received as part the = MPLS >> working group last call; these comments - and the intended = resolution >> - >> is included in the meeting minutes from the Prague meeting: >>=20 >>=20 >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf >>=20 >>=20 >> During the IETF meeting in Prague, we agreed with the BFD working >> group to do a separate working group last callfor the BFD working >> group >>=20 >> The (BFD) working group last call was started on March 30th and ran >> for 13 days. The last call ended on April 11th. >>=20 >> The authors have since worked hard to resolve comments, some >> issue has been brought to the working group mailing list for >> resolution. >>=20 >> Version -04 of the document was published June 28th. >>=20 >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >> June 29th. >>=20 >> The AD review resulted in a "New ID needed" due to mostly editorial >> comments. Version -05 was published on June 29 and the IETF last = call >> started as soon as the new ID was avaialbe. >>=20 >> The current list of Last Call Comments resoltion is also avaiable = at: >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >>=20 >> The list of issues that the authors kept very carefully, shows >> without >> doubt >> that no comments been ignored. >>=20 >> Loa >> mpls wg document shepherd >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 14:58 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> Hi Rui: >>=20 >> The comments were not ignored, the resolution of the Q10 comments as >> well as those collected from the MPLS WG was presented at the last >> IETF. My spreadsheet from which that report was generated and has = been >> augmented to include the BFD WG comments is available at >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >>=20 >> So you know... >> Dave >>=20 >>=20 >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of >> Rui Costa >> Sent: segunda-feira, 4 de Julho de 2011 23:03 >> To: ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> IMHO and for the record: >>=20 >> ITU-T comments regarding this draft haven't been discussed with ITU-T >> but were simply ignored. No LS describing these comments' resolution >> was sent. >>=20 >> Several service providers regarded this draft as not meeting their >> transport networks' needs. >>=20 >> [The v03 draft was published in Feb and went to WG LC. >> The v04 draft addressing WG LC comments was published on the 28th = June >> (same date as the proto write-up). >> When was the WG LC launched, to verify LC comments resolution?] >>=20 >> Regards, >> Rui >>=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >>=20 >> The IESG has received a request from the Multiprotocol Label = Switching >> WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2011-07-14. 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. >>=20 >> Abstract >>=20 >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >>=20 >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects = on >> a pseudo wire, label switched path or Section. >>=20 >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From jdrake@juniper.net Fri Jul 8 08:33:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2294B21F872D; Fri, 8 Jul 2011 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qKAdRTHS5eu; Fri, 8 Jul 2011 08:32:58 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 871E221F8706; Fri, 8 Jul 2011 08:32:57 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKThcjIQVEyrz6soZ1CNdu9F+/66h+rrKZ@postini.com; Fri, 08 Jul 2011 08:32:57 PDT 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, 8 Jul 2011 08:30:38 -0700 From: John E Drake To: "neil.2.harrison@bt.com" , "RCosta@ptinovacao.pt" , "david.i.allan@ericsson.com" , "stbryant@cisco.com" Date: Fri, 8 Jul 2011 08:30:37 -0700 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAAkhZucAANiFrQAABE91AAA+mDYA== Message-ID: <5E893DB832F57341992548CDBB333163A0A8FAF8BB@EMBX01-HQ.jnpr.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> <5E893DB832F57341992548CDBB333163A0A8FAF79B@EMBX01-HQ.jnpr.net> <6D3D47CB84BDE349BC23BF1C94E316E4405A7555DD@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405A7555DD@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:33:00 -0000 Neil, AIS and CC are ITU requirements but I personally agree with you regarding t= heir utility. TCM is an ITU concept that doesn't really apply in an MPLS c= ontext because of the way the label stack works, and as I have told you bef= ore, the tap-off function you mention is sensible but it is strictly an imp= lementation issue - no protocol work is required. Thanks, John Sent from my iPhone > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, July 08, 2011 6:37 AM > To: John E Drake; RCosta@ptinovacao.pt; david.i.allan@ericsson.com; > stbryant@cisco.com > Cc: mpls@ietf.org; ietf@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Not recently John. But my comments are general and not specific to > this draft. But it seems you are implying that the draft recognises my > points. If so I will look forward to reading it later today when I get > chance and seeing AIS deprecated, TCM deprecated, CC functions > deprecated, ability to tap off end-end CV/PM flows at intermediate > nodes. > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: 08 July 2011 14:26 > > To: Harrison,N,Neil,DKQ7 R; RCosta@ptinovacao.pt; > > david.i.allan@ericsson.com; stbryant@cisco.com > > Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > > Subject: RE: [mpls] Last Call: > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > Neil, > > > > I have a question for clarification. Have you actually read draft- > > ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but > > generally it is considered good form to read something before > > commenting on it. > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > neil.2.harrison@bt.com > > > Sent: Friday, July 08, 2011 12:16 AM > > > To: RCosta@ptinovacao.pt; david.i.allan@ericsson.com; > > > stbryant@cisco.com > > > Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > > > Subject: Re: [mpls] Last Call: 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > Got to say I agree with Rui on much of what he says here. And I > > > absolutely resonate with his point on the need for simplicity. The > > > reason OAM needs to be as simple as possible is because it must be > > > super reliable....we do not want to consciously build in > weaknesses, > > > esp unnecessary ones.... this also implies minimal config. We > could > > > all do better on this. For example: > > > > > > - Rui is dead right a CC function is fairly useless, we only > > need > > > a CV function...the ATM OAM in I.610 suffers from this problem (and > > few > > > others like AIS and the assumed use of request/response MLT to > > diagnose > > > leaking/mismerging traffic...request/response OAM won't work with > > > unidirectional defects). > > > > > > - all packet layer networks should not have an AIS OAM > > > message....very obvious for the cl-ps mode of course. The co-ps > mode > > > is also not like the co-cs mode. One has to consciously > manufacture > > > AIS messages and target them to specific clients in the co-ps > > > mode....who may have taken action in their own layer network and > > 'moved > > > elsewhere' anyway, ie a total waste of time now. AIS is actually > > > unnecessary wrt providing information anyway, it simply represents > an > > > in-built weakness of just something else to go wrong which itself > > will > > > create problems. > > > > > > - creating preconfigured TCM sublayers is just asking for > > trouble > > > IMO. It is far smarter to simply create a single end-end OAM CV > (and > > > when required PM) flow and tap this off at intermediate nodes on > the > > > *rare* occasions one wants to do. > > > > > > regards, Neil > > > > > > This email contains BT information, which may be privileged or > > > confidential. > > > It's meant only for the individual(s) or entity named above. If > > you're > > > not the intended > > > recipient, note that disclosing, copying, distributing or using > this > > > information > > > is prohibited. If you've received this email in error, please let > me > > > know immediately > > > on the email address above. Thank you. > > > We monitor our email system, and may record your emails. > > > British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ > > > Registered in England no: 1800000 > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > Of > > > > Rui Costa > > > > Sent: 08 July 2011 01:15 > > > > To: David Allan I; Stewart Bryant > > > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > David, > > > > > > > > Reading something, keeping it on record, without effect in the > > draft > > > > and "ignoring comments" have IMHO similar outcomes. As author of > > the > > > > draft you are free to do it. These standards have a great impact > in > > > our > > > > work, so i'm also free to write what i did. > > > > > > > > > > > > > > > > > > > > Stewart, > > > > > > > > My technical concerns regarding this draft were expressed... > > > > ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, > i > > > > believe); > > > > ...in operators' meetings' that took place during ITU-T's > Feb/2011 > > > > plenary meeting; > > > > ...in a comparison session that took place during that same ITU-T > > > > meeting. > > > > Some: > > > > > > > > CC/CV > > > > I don't understand the need for 2 types of packets: a single type > > > > allows CC; mismatching identifiers in the same CC packets allow > CV. > > > > Besides adding complexity, we whether always activate both or > > > > potentiate undetected mismerges. > > > > (BTW: can't understand how we propose one ACH codepoint to CC, > > > another > > > > for CV, [counting other drafts, another for frame loss ...] but > > don't > > > > consider assigning 1 single ACH protocol identifier codepoint as > > > > requested by ITU-T) > > > > > > > > Uni P2P / P2MP > > > > I can't see how BFD will support unidir and hence P2MP other > > than... > > > > > > > > ...eliminating the session "state variable" (down, init, up), > > aiming > > > > just the state variables we really need, bringing us to something > > > > similar to 1731, eventually with other bits on the wire or... > > > > ...using IP to create the reverse way, which we cannot assume per > > > > requirements; > > > > Will we create a complete different tool for that? > > > > (BFD's B=3D"bidirectional") > > > > > > > > Provisioning list > > > > This is an MPLS profile/subset (and i heard) achievable through a > > > > particular configuration. So, i expect each draft-ietf-mpls-TP-* > to > > > > focus on that profile/configuration. However, i keep seeing > > > references > > > > f.i. to IP encapsulations unexpected under TP's OAM. > > > > I don't thus understand what the aim is: do we expect this in TP, > > are > > > > we talking about MPLS in general?... The TP profile is never > quite > > > > delimited. > > > > Does chapter 4 contain ALL the configurable parameters list > agreed > > to > > > > provide in the comparison session? > > > > > > > > Backwards compatibility > > > > This was the main argument risen to ground MPLS-TP OAM on BFD. > It's > > > not > > > > a better argument than grounding MPLS-TP OAM on 1731 due to its > ETH > > > > deployment plus coherence with SDH, OTN, as defended by ITU-T. > > > > For reasons like the above, however, MPLS-TP BFD won't be > backwards > > > > compatible with previous BFD (even considering just CC/CV). They > > > don't > > > > even share the same codepoint. > > > > > > > > Simplicity > > > > Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC > is > > > > simpler: in each flow, a standard defined nr of constant > heartbeat > > > > signals (with standard constant or provisioned period - no > > > > auto/negotiated -) means OK. A standard defined number of misses > > > means > > > > lost Rx connection. An RDI, the only articulation between Rx and > Tx > > > > flows, meaningful in bidirectional applications, allows each pear > > to > > > > identify Tx problems. > > > > This OAM simplicity is the key for reliable fail finger pointing, > > > > performance reports and protection. Also to allow scaling, more > > > > implementation opportunities/manufacturers, which is valuable for > > > > operators. > > > > > > > > > > > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > > more > > > > difficult to tell which is which. > > > > > > > > Regards, > > > > Rui > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > Sent: quarta-feira, 6 de Julho de 2011 19:25 > > > > To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > > > > Announce > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] R: Re: Last Call: > rdi- > > > > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > > Standard > > > > > > > > Hi Erminio: > > > > > > > > > > > > >Several service providers regarded this draft as not meeting > their > > > > >transport networks' needs. > > > > > > > > E> This is a true statement: the solution in this draft is > useless > > > for > > > > many MPLS- TP deployments. > > > > > > > > The two statements do not necessarily follow. > > > > > > > > What we established during discussions at the SG15 plenary in > > > February > > > > was that the issue some service providers had was that the IETF > BFD > > > > solution exceeded their requirements in that there was additional > > > > functionality they did not see a need for, and that they > considered > > > any > > > > additional functionality parasitic. > > > > > > > > However this is a consequence of adapting an existing technology > to > > a > > > > new application. I do not see any way around that. And the entire > > > joint > > > > project was based on the premise of engineering re-use not > > greenfield > > > > design. That is what it said on the tin up front, and IMO why > when > > > the > > > > IETF started down this path packet transport transitioned from > > being > > > a > > > > minority sport to mainstream, so it is a bit late to cry foul.... > > > > > > > > My 2 cents > > > > Dave > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > Sent: quarta-feira, 6 de Julho de 2011 18:36 > > > > To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > > Subject: RE: [mpls] R: Re: Last Call: > rdi- > > > > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > > Standard > > > > > > > > Hi Erminio: > > > > > > > > Two of the three document editors were present at SG15 plenary in > > > > February where the comments originated. The revised meeting > > schedule > > > > resulted in a day spent going through the document with the > > editors. > > > > IMO there were lots of discussion and legitimate issues with the > > > > document identified and corrected so it was a useful session. The > > > > liaison of same was in many ways *after the fact*. > > > > > > > > Cheers > > > > Dave > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: erminio.ottone_69@libero.it > > > [mailto:erminio.ottone_69@libero.it] > > > > Sent: quarta-feira, 6 de Julho de 2011 18:34 > > > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > > > Cc: mpls@ietf.org > > > > Subject: R: Re: [mpls] Last Call: > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > The way this draft has been developed is a bit strange. > > > > > > > > The poll for its adoption as a WG document was halted by the MPLS > > WG > > > > chair > > > > because "it is not possible to judge consensus": > > > > > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > > > > > > > The lack of consensus was motivated by serious technical concerns > > > > raised by > > > > several transport experts during the poll. > > > > > > > > Nevertheless the MPLS WG chair decided to adopt the draft as a WG > > > > document: > > > > > > > > http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > > > > > > > After several WG revisions and WG LCs, the technical issues have > > not > > > > been > > > > resolved. > > > > > > > > >Several service providers regarded this draft as not meeting > their > > > > transport > > > > networks' needs. > > > > > > > > This is a true statement: the solution in this draft is useless > for > > > > many MPLS- > > > > TP deployments. > > > > > > > > > > > > -----Original Message----- > > > > From: erminio.ottone_69@libero.it > > > [mailto:erminio.ottone_69@libero.it] > > > > Sent: quarta-feira, 6 de Julho de 2011 18:26 > > > > To: loa@pi.nu; Rui Costa > > > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > > Subject: R: Re: [mpls] Last Call: > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > Version -04 of the document was published June 28th. > > > > > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > > sent > > > > > June 29th. > > > > > > > > > > > > > So when the WG LC to confirm the LC comment resolution has been > > > > launched? > > > > > > > > The proto write-up says: > > > > > > > > It has also passed a working roup call to verify that > > LC > > > > comments > > > > were correctly with minor comments. > > > > > > > > It also says: > > > > > > > > The comments has been > > > > carefully discussed between the authors and people > > making > > > > the > > > > comments and > > > > has been resolved. > > > > > > > > But it seems that some comments have not been discussed with the > > > > authors of > > > > the comments. When ITU-T Q10/15 has been involved in discussing > its > > > > comments? > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.nu] > > > > Sent: quarta-feira, 6 de Julho de 2011 16:44 > > > > To: Rui Costa > > > > Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > > Subject: Re: [mpls] Last Call: > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > All, > > > > > > > > Since someone has commented about the process used for resolving > > > > questions on > > > > draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > > > > > > > > The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > > > > process is: > > > > > > > > On February 3rd 2011 the working group last call was issued > > > > on version -03 > > > > > > > > This was copied to the the Ad Hoc Team List > > > > and liaised to SG15 also on February 3rd > > > > > > > > This working group last call ended om Feb 28 > > > > > > > > > > > > On Feb 28 we also received a liaison with comments from > SG15 > > > > > > > > > > > > The authors compiled a list of all comments received as part the > > > MPLS > > > > working group last call; these comments - and the intended > > > resolution > > > > - > > > > is included in the meeting minutes from the Prague meeting: > > > > > > > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > > > > > > > During the IETF meeting in Prague, we agreed with the BFD > working > > > > group to do a separate working group last callfor the BFD > working > > > > group > > > > > > > > The (BFD) working group last call was started on March 30th and > ran > > > > for 13 days. The last call ended on April 11th. > > > > > > > > The authors have since worked hard to resolve comments, some > > > > issue has been brought to the working group mailing list for > > > > resolution. > > > > > > > > Version -04 of the document was published June 28th. > > > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > > sent > > > > June 29th. > > > > > > > > The AD review resulted in a "New ID needed" due to mostly > > editorial > > > > comments. Version -05 was published on June 29 and the IETF > last > > > call > > > > started as soon as the new ID was avaialbe. > > > > > > > > The current list of Last Call Comments resoltion is also > avaiable > > > at: > > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > > > The list of issues that the authors kept very carefully, shows > > > > without > > > > doubt > > > > that no comments been ignored. > > > > > > > > Loa > > > > mpls wg document shepherd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > Sent: quarta-feira, 6 de Julho de 2011 14:58 > > > > To: Rui Costa; ietf@ietf.org; IETF-Announce > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] Last Call: > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > Hi Rui: > > > > > > > > The comments were not ignored, the resolution of the Q10 comments > > as > > > > well as those collected from the MPLS WG was presented at the > last > > > > IETF. My spreadsheet from which that report was generated and has > > > been > > > > augmented to include the BFD WG comments is available at > > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > > > So you know... > > > > Dave > > > > > > > > > > > > -----Original Message----- > > > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > > Behalf > > > Of > > > > Rui Costa > > > > Sent: segunda-feira, 4 de Julho de 2011 23:03 > > > > To: ietf@ietf.org; IETF-Announce > > > > Cc: mpls@ietf.org > > > > Subject: RE: [mpls] Last Call: > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > IMHO and for the record: > > > > > > > > ITU-T comments regarding this draft haven't been discussed with > > ITU-T > > > > but were simply ignored. No LS describing these comments' > > resolution > > > > was sent. > > > > > > > > Several service providers regarded this draft as not meeting > their > > > > transport networks' needs. > > > > > > > > [The v03 draft was published in Feb and went to WG LC. > > > > The v04 draft addressing WG LC comments was published on the 28th > > > June > > > > (same date as the proto write-up). > > > > When was the WG LC launched, to verify LC comments resolution?] > > > > > > > > Regards, > > > > Rui > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > Of > > > > The IESG > > > > Sent: quinta-feira, 30 de Junho de 2011 14:47 > > > > To: IETF-Announce > > > > Cc: mpls@ietf.org > > > > Subject: [mpls] Last Call: > > > > (Proactive Connectivity Verification, Continuity Check and Remote > > > > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > > > > The IESG has received a request from the Multiprotocol Label > > > Switching > > > > WG > > > > (mpls) to consider the following document: > > > > - 'Proactive Connectivity Verification, Continuity Check and > Remote > > > > Defect indication for MPLS Transport Profile' > > > > 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 2011-07-14. 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 > > > > > > > > Continuity Check, Proactive Connectivity Verification and > Remote > > > > Defect Indication functionalities are required for MPLS-TP > OAM. > > > > > > > > Continuity Check monitors the integrity of the continuity of > the > > > > label switched path for any loss of continuity defect. > > > Connectivity > > > > verification monitors the integrity of the routing of the > label > > > > switched path between sink and source for any connectivity > > issues. > > > > Remote defect indication enables an End Point to report, to > its > > > > associated End Point, a fault or defect condition that it > > detects > > > on > > > > a pseudo wire, label switched path or Section. > > > > > > > > This document specifies methods for proactive continuity > check, > > > > continuity verification, and remote defect indication for > MPLS- > > TP > > > > label switched paths, pseudo wires and Sections using > > > Bidirectional > > > > Forwarding Detection. > > > > > > > > > > > > The file can be obtained via > > > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > > Ietf mailing list > > > > Ietf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Fri Jul 8 08:34:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297F621F8B62; Fri, 8 Jul 2011 08:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=3.167, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b15yd6KOj4Z; Fri, 8 Jul 2011 08:34:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8627421F8B5A; Fri, 8 Jul 2011 08:34:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p68FXwL7015803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 17:33:58 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p68FXw9x004046; Fri, 8 Jul 2011 17:33:58 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jul 2011 17:33:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 17:33:53 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264041913F1@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g4ClkK2Lfv4zTLmOgxFNsD9RdAAADFOA References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com><6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Thomas Nadeau" , X-OriginalArrivalTime: 08 Jul 2011 15:33:55.0886 (UTC) FILETIME=[72DB64E0:01CC3D84] Cc: mpls@ietf.org, ietf@ietf.org, ietf-announce@ietf.org, stbryant@cisco.com Subject: Re: [mpls] LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:34:06 -0000 Hi, Just to make it clear, this is not a discussion on the requirements. I would like to encourage this kind of discussion but in the right context. The CC-CV-RDI draft aims to satisfy the OAM requirements which are specified in RFC 5860. One of the requirements there is to provide a tool for CC as well as for CV.=20 In the context of this LC, we should focus now on the proposed solution. Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Friday, July 08, 2011 6:27 PM To: neil.2.harrison@bt.com Cc: mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org; stbryant@cisco.com Subject: Re: [mpls] LastCall: (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, wrote: > Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliable....we do not want to consciously build in weaknesses, esp unnecessary ones.... this also implies minimal config. We could all do better on this. For example: >=20 > - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions. But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment? > - all packet layer networks should not have an AIS OAM message....very obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps mode....who may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. What does that comment have to do with the actual draft in question? > - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. Again, what does this have to do with the actual draft in question? --tom >=20 > regards, Neil >=20 > This email contains BT information, which may be privileged or confidential. > It's meant only for the individual(s) or entity named above. If you're not the intended > recipient, note that disclosing, copying, distributing or using this information > is prohibited. If you've received this email in error, please let me know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rui Costa >> Sent: 08 July 2011 01:15 >> To: David Allan I; Stewart Bryant >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> David, >>=20 >> Reading something, keeping it on record, without effect in the draft >> and "ignoring comments" have IMHO similar outcomes. As author of the >> draft you are free to do it. These standards have a great impact in our >> work, so i'm also free to write what i did. >>=20 >>=20 >>=20 >>=20 >> Stewart, >>=20 >> My technical concerns regarding this draft were expressed... >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i >> believe); >> ...in operators' meetings' that took place during ITU-T's Feb/2011 >> plenary meeting; >> ...in a comparison session that took place during that same ITU-T >> meeting. >> Some: >>=20 >> CC/CV >> I don't understand the need for 2 types of packets: a single type >> allows CC; mismatching identifiers in the same CC packets allow CV. >> Besides adding complexity, we whether always activate both or >> potentiate undetected mismerges. >> (BTW: can't understand how we propose one ACH codepoint to CC, another >> for CV, [counting other drafts, another for frame loss ...] but don't >> consider assigning 1 single ACH protocol identifier codepoint as >> requested by ITU-T) >>=20 >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other than... >>=20 >> ...eliminating the session "state variable" (down, init, up), aiming >> just the state variables we really need, bringing us to something >> similar to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume per >> requirements; >> Will we create a complete different tool for that? >> (BFD's B=3D"bidirectional") >>=20 >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through a >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to >> focus on that profile/configuration. However, i keep seeing references >> f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP, are >> we talking about MPLS in general?... The TP profile is never quite >> delimited. >> Does chapter 4 contain ALL the configurable parameters list agreed to >> provide in the comparison session? >>=20 >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not >> a better argument than grounding MPLS-TP OAM on 1731 due to its ETH >> deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards >> compatible with previous BFD (even considering just CC/CV). They don't >> even share the same codepoint. >>=20 >> Simplicity >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is >> simpler: in each flow, a standard defined nr of constant heartbeat >> signals (with standard constant or provisioned period - no >> auto/negotiated -) means OK. A standard defined number of misses means >> lost Rx connection. An RDI, the only articulation between Rx and Tx >> flows, meaningful in bidirectional applications, allows each pear to >> identify Tx problems. >> This OAM simplicity is the key for reliable fail finger pointing, >> performance reports and protection. Also to allow scaling, more >> implementation opportunities/manufacturers, which is valuable for >> operators. >>=20 >>=20 >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more >> difficult to tell which is which. >>=20 >> Regards, >> Rui >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 19:25 >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- >> Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >>=20 >> Hi Erminio: >>=20 >> >>> Several service providers regarded this draft as not meeting their >>> transport networks' needs. >>=20 >> E> This is a true statement: the solution in this draft is useless for >> many MPLS- TP deployments. >>=20 >> The two statements do not necessarily follow. >>=20 >> What we established during discussions at the SG15 plenary in February >> was that the issue some service providers had was that the IETF BFD >> solution exceeded their requirements in that there was additional >> functionality they did not see a need for, and that they considered any >> additional functionality parasitic. >>=20 >> However this is a consequence of adapting an existing technology to a >> new application. I do not see any way around that. And the entire joint >> project was based on the premise of engineering re-use not greenfield >> design. That is what it said on the tin up front, and IMO why when the >> IETF started down this path packet transport transitioned from being a >> minority sport to mainstream, so it is a bit late to cry foul.... >>=20 >> My 2 cents >> Dave >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 18:36 >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >>=20 >> Hi Erminio: >>=20 >> Two of the three document editors were present at SG15 plenary in >> February where the comments originated. The revised meeting schedule >> resulted in a day spent going through the document with the editors. >> IMO there were lots of discussion and legitimate issues with the >> document identified and corrected so it was a useful session. The >> liaison of same was in many ways *after the fact*. >>=20 >> Cheers >> Dave >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:34 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: R: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> The way this draft has been developed is a bit strange. >>=20 >> The poll for its adoption as a WG document was halted by the MPLS WG >> chair >> because "it is not possible to judge consensus": >>=20 >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html >>=20 >> The lack of consensus was motivated by serious technical concerns >> raised by >> several transport experts during the poll. >>=20 >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG >> document: >>=20 >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html >>=20 >> After several WG revisions and WG LCs, the technical issues have not >> been >> resolved. >>=20 >>> Several service providers regarded this draft as not meeting their >> transport >> networks' needs. >>=20 >> This is a true statement: the solution in this draft is useless for >> many MPLS- >> TP deployments. >>=20 >>=20 >> -----Original Message----- >> From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:26 >> To: loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: R: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >>> Version -04 of the document was published June 28th. >>>=20 >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >>> June 29th. >>>=20 >>=20 >> So when the WG LC to confirm the LC comment resolution has been >> launched? >>=20 >> The proto write-up says: >>=20 >> It has also passed a working roup call to verify that LC >> comments >> were correctly with minor comments. >>=20 >> It also says: >>=20 >> The comments has been >> carefully discussed between the authors and people making >> the >> comments and >> has been resolved. >>=20 >> But it seems that some comments have not been discussed with the >> authors of >> the comments. When ITU-T Q10/15 has been involved in discussing its >> comments? >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: quarta-feira, 6 de Julho de 2011 16:44 >> To: Rui Costa >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> All, >>=20 >> Since someone has commented about the process used for resolving >> questions on >> draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. >>=20 >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >> process is: >>=20 >> On February 3rd 2011 the working group last call was issued >> on version -03 >>=20 >> This was copied to the the Ad Hoc Team List >> and liaised to SG15 also on February 3rd >>=20 >> This working group last call ended om Feb 28 >>=20 >>=20 >> On Feb 28 we also received a liaison with comments from SG15 >>=20 >>=20 >> The authors compiled a list of all comments received as part the MPLS >> working group last call; these comments - and the intended resolution >> - >> is included in the meeting minutes from the Prague meeting: >>=20 >>=20 >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf >>=20 >>=20 >> During the IETF meeting in Prague, we agreed with the BFD working >> group to do a separate working group last callfor the BFD working >> group >>=20 >> The (BFD) working group last call was started on March 30th and ran >> for 13 days. The last call ended on April 11th. >>=20 >> The authors have since worked hard to resolve comments, some >> issue has been brought to the working group mailing list for >> resolution. >>=20 >> Version -04 of the document was published June 28th. >>=20 >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >> June 29th. >>=20 >> The AD review resulted in a "New ID needed" due to mostly editorial >> comments. Version -05 was published on June 29 and the IETF last call >> started as soon as the new ID was avaialbe. >>=20 >> The current list of Last Call Comments resoltion is also avaiable at: >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >>=20 >> The list of issues that the authors kept very carefully, shows >> without >> doubt >> that no comments been ignored. >>=20 >> Loa >> mpls wg document shepherd >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 14:58 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> Hi Rui: >>=20 >> The comments were not ignored, the resolution of the Q10 comments as >> well as those collected from the MPLS WG was presented at the last >> IETF. My spreadsheet from which that report was generated and has been >> augmented to include the BFD WG comments is available at >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >>=20 >> So you know... >> Dave >>=20 >>=20 >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of >> Rui Costa >> Sent: segunda-feira, 4 de Julho de 2011 23:03 >> To: ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >> IMHO and for the record: >>=20 >> ITU-T comments regarding this draft haven't been discussed with ITU-T >> but were simply ignored. No LS describing these comments' resolution >> was sent. >>=20 >> Several service providers regarded this draft as not meeting their >> transport networks' needs. >>=20 >> [The v03 draft was published in Feb and went to WG LC. >> The v04 draft addressing WG LC comments was published on the 28th June >> (same date as the proto write-up). >> When was the WG LC launched, to verify LC comments resolution?] >>=20 >> Regards, >> Rui >>=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >>=20 >>=20 >> The IESG has received a request from the Multiprotocol Label Switching >> WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-07-14. 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. >>=20 >> Abstract >>=20 >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >>=20 >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >>=20 >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Fri Jul 8 09:13:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F58E21F8B92; Fri, 8 Jul 2011 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPWSKA0CTMIr; Fri, 8 Jul 2011 09:13:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 58B3F21F8B90; Fri, 8 Jul 2011 09:13:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p68GDMRc002946; Fri, 8 Jul 2011 11:13:25 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 8 Jul 2011 12:13:21 -0400 From: David Allan I To: Rui Costa , Stewart Bryant Date: Fri, 8 Jul 2011 12:13:18 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAApIjzAA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD522135449A@EUSAACMS0703.eamcs.ericsson.se> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , IETF-Announce , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:13:28 -0000 Rui: You wrote: >Reading something, keeping it on record, without effect in the draft and "= ignoring comments" have IMHO similar outcomes. As author of the draft you a= re free to do it. These standards have a great impact >in our work, so i'm also free to write what i did. Numerous comments did have effect on the draft and those that didn't were e= ither simply not actionable, were rhetorical or not constructive, and a few= had to be balanced against comments coming from the MPLS & BFD WGs. I woul= d translate "ingored" or "without effect" to "did not get one'e way". In th= e standards process it happens. Meanwhile as an editor of the document, I'll take the liberty of responding= to some of the points you raise... >My technical concerns regarding this draft were expressed... >...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe= ); >...in operators' meetings' that took place during ITU-T's Feb/2011 plenary= meeting; I and the WG don't really have access to private grumblings. >...in a comparison session that took place during that same ITU-T meeting. Lots of other opinions were expressed as well, and they did not all agree w= ith you. >Some: >CC/CV >I don't understand the need for 2 types of packets: a single type allows C= C; mismatching identifiers in the same CC packets allow CV. >Besides adding complexity, we whether always activate both or potentiate u= ndetected mismerges. OK, lets walk through this. We want CV all the time so that any misconectivity can be detected, but on = the list it was expressed that the group did not want the overhead of proce= ssing the source MEP TLV in every packet in order to achieve this. We could= carry it in every packet and have the receiver simply ignore most of them,= but then that would make the defect entry criteria compeltely random and t= he exit criteria unreliable as well, not really a good design. Hence they a= re separated using different ACH code points and the receiver is obliged to= process every source MEP TLV it receives. I hope this is clear. >(BTW: can't understand how we propose one ACH codepoint to CC, another for= CV, [counting other drafts, another for frame loss ...] but don't consider= assigning 1 single ACH protocol identifier codepoint >as requested by ITU-= T) Because that puts you into two protocol ID demultiplexing steps per OAM PDU= recevied to determine the intended function. Hence COSTS MORE. That is pre= tty basic... > Uni P2P / P2MP > I can't see how BFD will support unidir and hence P2MP other than... > ...eliminating the session "state variable" (down, init, up), aiming just= the state variables we really need, bringing us to something similar to 17= 31, eventually with other bits on the wire or... > ...using IP to create the reverse way, which we cannot assume per require= ments; > Will we create a complete different tool for that? > (BFD's B=3D"bidirectional") I would not go so far as to say "similar to 1731", there is actually a lot = of difference under the hood. As for uni-directional BFD, that is a BFD WG = problem at the moment. > Provisioning list > This is an MPLS profile/subset (and i heard) achievable through a particu= lar configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that = profile/configuration. However, i keep seeing > references f.i. to IP encapsulations unexpected under TP's OAM. > I don't thus understand what the aim is: do we expect this in TP, are we = talking about MPLS in general?... The TP profile is never quite delimited. > Does chapter 4 contain ALL the configurable parameters list agreed to pro= vide in the comparison session? It should. As for encapsulations, unless TP is in a complete island not con= nected to anything (which as a network is rather useless) it will be expect= ed to interoperate with the rest of the MPLS architecture, and the stated i= ntention of tool development was that what resulted was applicable to the b= roader MPLS architecture. Which means backwards compatiblity and procedures= for interoperation. > Backwards compatibility > This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a= better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployme= nt plus coherence with SDH, OTN, as defended by ITU-T. > For reasons like the above, however, MPLS-TP BFD won't be backwards compa= tible with previous BFD (even considering just CC/CV). They don't even shar= e the same codepoint. The issue is not code point, which is the trivial part. It is reuse of the = majority of the implementation. Again, pretty basic. >Simplicity >Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler= : in each flow, a standard defined nr of constant heartbeat signals (with s= tandard constant or provisioned period - no >auto/negotiated -) means OK. A standard defined number of misses means los= t Rx connection. An RDI, the only articulation between Rx and Tx flows, mea= ningful in bidirectional applications, allows each >pear to identify Tx problems. >This OAM simplicity is the key for reliable fail finger pointing, performa= nce reports and protection. Also to allow scaling, more implementation oppo= rtunities/manufacturers, which is valuable for >operators. Well IMO there was not a lot of interest in T-MPLS until the IETF was going= to re-define it and make it compatible with IP/MPLS. So there was an indus= try wide "design intent" implied here. > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more dif= ficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the en= tire MPLS protocol suite. Hope this helps D -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: >Several service providers regarded this draft as not meeting their >transport networks' needs. E> This is a true statement: the solution in this draft is useless for many= MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was = that the issue some service providers had was that the IETF BFD solution ex= ceeded their requirements in that there was additional functionality they d= id not see a need for, and that they considered any additional functionalit= y parasitic. However this is a consequence of adapting an existing technology to a new a= pplication. I do not see any way around that. And the entire joint project = was based on the premise of engineering re-use not greenfield design. That = is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mai= nstream, so it is a bit late to cry foul.... My 2 cents Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February = where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair = because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by= several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been r= esolved. >Several service providers regarded this draft as not meeting their >transport networks' needs. This is a true statement: the solution in this draft is useless for many MP= LS- TP deployments. -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC commen= ts were correctly with minor comments. It also says: The comments has been carefully discussed between the authors and people making the c= omments and has been resolved. But it seems that some comments have not been discussed with the authors of= the comments. When ITU-T Q10/15 has been involved in discussing its commen= ts? -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: quarta-feira, 6 de Julho de 2011 16:44 To: Rui Costa Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without doubt that no comments been ignored. Loa mpls wg document shepherd -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 14:58 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well a= s those collected from the MPLS WG was presented at the last IETF. My sprea= dsheet from which that report was generated and has been augmented to inclu= de the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last= -Call-Comments.xls So you know... Dave -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui= Costa Sent: segunda-feira, 4 de Julho de 2011 23:03 To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transpor= t networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From neil.2.harrison@bt.com Fri Jul 8 09:13:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8721F8B9C; Fri, 8 Jul 2011 09:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MlsPAWD8Iai; Fri, 8 Jul 2011 09:13:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7F721F8B9B; Fri, 8 Jul 2011 09:13:53 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 17:13:52 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.186]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 8 Jul 2011 17:13:52 +0100 From: To: Date: Fri, 8 Jul 2011 17:13:36 +0100 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g2/gPYlO1BBvSs613Cw7wIf+bwABd9Xg Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405A75577E@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:13:57 -0000 Thanks Tom...these are general observations which I think are valid and res= pond to Rui's point about the need for simplicity....and they are as much d= irected to folks pushing overblown OAM in ITU as folks in IETF. You may of= course disagree with them. I recall someone once saying MPLS did not need= DP OAM at all.... regards, Neil > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 08 July 2011 16:27 > To: Harrison,N,Neil,DKQ7 R > Cc: RCosta@ptinovacao.pt; david.i.allan@ericsson.com; > stbryant@cisco.com; mpls@ietf.org; ietf@ietf.org; ietf- > announce@ietf.org > Subject: Re: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > On Jul 8, 2011, at 3:15 AM, wrote: > > > Got to say I agree with Rui on much of what he says here. And I > absolutely resonate with his point on the need for simplicity. The > reason OAM needs to be as simple as possible is because it must be > super reliable....we do not want to consciously build in weaknesses, > esp unnecessary ones.... this also implies minimal config. We could > all do better on this. For example: > > > > - Rui is dead right a CC function is fairly useless, we only > need a CV function...the ATM OAM in I.610 suffers from this problem > (and few others like AIS and the assumed use of request/response MLT to > diagnose leaking/mismerging traffic...request/response OAM won't work > with unidirectional defects). > > While you are entitled to your opinion, I personally think there > are enough requirements elsewhere to have both CC and CV functions. > But we digress. Are you actually asking that the CC functionality be > removed from the draft or just making a general comment? > > > - all packet layer networks should not have an AIS OAM > message....very obvious for the cl-ps mode of course. The co-ps mode > is also not like the co-cs mode. One has to consciously manufacture > AIS messages and target them to specific clients in the co-ps > mode....who may have taken action in their own layer network and 'moved > elsewhere' anyway, ie a total waste of time now. AIS is actually > unnecessary wrt providing information anyway, it simply represents an > in-built weakness of just something else to go wrong which itself will > create problems. > > What does that comment have to do with the actual draft in > question? > > > - creating preconfigured TCM sublayers is just asking for > trouble IMO. It is far smarter to simply create a single end-end OAM > CV (and when required PM) flow and tap this off at intermediate nodes > on the *rare* occasions one wants to do. > > Again, what does this have to do with the actual draft in > question? > > --tom > > > > > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're not the intended > > recipient, note that disclosing, copying, distributing or using this > information > > is prohibited. If you've received this email in error, please let me > know immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> Rui Costa > >> Sent: 08 July 2011 01:15 > >> To: David Allan I; Stewart Bryant > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> David, > >> > >> Reading something, keeping it on record, without effect in the draft > >> and "ignoring comments" have IMHO similar outcomes. As author of the > >> draft you are free to do it. These standards have a great impact in > our > >> work, so i'm also free to write what i did. > >> > >> > >> > >> > >> Stewart, > >> > >> My technical concerns regarding this draft were expressed... > >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > >> believe); > >> ...in operators' meetings' that took place during ITU-T's Feb/2011 > >> plenary meeting; > >> ...in a comparison session that took place during that same ITU-T > >> meeting. > >> Some: > >> > >> CC/CV > >> I don't understand the need for 2 types of packets: a single type > >> allows CC; mismatching identifiers in the same CC packets allow CV. > >> Besides adding complexity, we whether always activate both or > >> potentiate undetected mismerges. > >> (BTW: can't understand how we propose one ACH codepoint to CC, > another > >> for CV, [counting other drafts, another for frame loss ...] but > don't > >> consider assigning 1 single ACH protocol identifier codepoint as > >> requested by ITU-T) > >> > >> Uni P2P / P2MP > >> I can't see how BFD will support unidir and hence P2MP other than... > >> > >> ...eliminating the session "state variable" (down, init, up), aiming > >> just the state variables we really need, bringing us to something > >> similar to 1731, eventually with other bits on the wire or... > >> ...using IP to create the reverse way, which we cannot assume per > >> requirements; > >> Will we create a complete different tool for that? > >> (BFD's B=3D"bidirectional") > >> > >> Provisioning list > >> This is an MPLS profile/subset (and i heard) achievable through a > >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to > >> focus on that profile/configuration. However, i keep seeing > references > >> f.i. to IP encapsulations unexpected under TP's OAM. > >> I don't thus understand what the aim is: do we expect this in TP, > are > >> we talking about MPLS in general?... The TP profile is never quite > >> delimited. > >> Does chapter 4 contain ALL the configurable parameters list agreed > to > >> provide in the comparison session? > >> > >> Backwards compatibility > >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's > not > >> a better argument than grounding MPLS-TP OAM on 1731 due to its ETH > >> deployment plus coherence with SDH, OTN, as defended by ITU-T. > >> For reasons like the above, however, MPLS-TP BFD won't be backwards > >> compatible with previous BFD (even considering just CC/CV). They > don't > >> even share the same codepoint. > >> > >> Simplicity > >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > >> simpler: in each flow, a standard defined nr of constant heartbeat > >> signals (with standard constant or provisioned period - no > >> auto/negotiated -) means OK. A standard defined number of misses > means > >> lost Rx connection. An RDI, the only articulation between Rx and Tx > >> flows, meaningful in bidirectional applications, allows each pear to > >> identify Tx problems. > >> This OAM simplicity is the key for reliable fail finger pointing, > >> performance reports and protection. Also to allow scaling, more > >> implementation opportunities/manufacturers, which is valuable for > >> operators. > >> > >> > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > more > >> difficult to tell which is which. > >> > >> Regards, > >> Rui > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 19:25 > >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > >> Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] R: Re: Last Call: >> 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Hi Erminio: > >> > >> > >>> Several service providers regarded this draft as not meeting their > >>> transport networks' needs. > >> > >> E> This is a true statement: the solution in this draft is useless > for > >> many MPLS- TP deployments. > >> > >> The two statements do not necessarily follow. > >> > >> What we established during discussions at the SG15 plenary in > February > >> was that the issue some service providers had was that the IETF BFD > >> solution exceeded their requirements in that there was additional > >> functionality they did not see a need for, and that they considered > any > >> additional functionality parasitic. > >> > >> However this is a consequence of adapting an existing technology to > a > >> new application. I do not see any way around that. And the entire > joint > >> project was based on the premise of engineering re-use not > greenfield > >> design. That is what it said on the tin up front, and IMO why when > the > >> IETF started down this path packet transport transitioned from being > a > >> minority sport to mainstream, so it is a bit late to cry foul.... > >> > >> My 2 cents > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 18:36 > >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: RE: [mpls] R: Re: Last Call: >> 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Hi Erminio: > >> > >> Two of the three document editors were present at SG15 plenary in > >> February where the comments originated. The revised meeting schedule > >> resulted in a day spent going through the document with the editors. > >> IMO there were lots of discussion and legitimate issues with the > >> document identified and corrected so it was a useful session. The > >> liaison of same was in many ways *after the fact*. > >> > >> Cheers > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:34 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: R: Re: [mpls] Last Call: 05.txt> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> The way this draft has been developed is a bit strange. > >> > >> The poll for its adoption as a WG document was halted by the MPLS WG > >> chair > >> because "it is not possible to judge consensus": > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > >> > >> The lack of consensus was motivated by serious technical concerns > >> raised by > >> several transport experts during the poll. > >> > >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG > >> document: > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > >> > >> After several WG revisions and WG LCs, the technical issues have not > >> been > >> resolved. > >> > >>> Several service providers regarded this draft as not meeting their > >> transport > >> networks' needs. > >> > >> This is a true statement: the solution in this draft is useless for > >> many MPLS- > >> TP deployments. > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:26 > >> To: loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: R: Re: [mpls] Last Call: 05.txt> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >>> Version -04 of the document was published June 28th. > >>> > >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >>> June 29th. > >>> > >> > >> So when the WG LC to confirm the LC comment resolution has been > >> launched? > >> > >> The proto write-up says: > >> > >> It has also passed a working roup call to verify that LC > >> comments > >> were correctly with minor comments. > >> > >> It also says: > >> > >> The comments has been > >> carefully discussed between the authors and people making > >> the > >> comments and > >> has been resolved. > >> > >> But it seems that some comments have not been discussed with the > >> authors of > >> the comments. When ITU-T Q10/15 has been involved in discussing its > >> comments? > >> > >> > >> > >> > >> -----Original Message----- > >> From: Loa Andersson [mailto:loa@pi.nu] > >> Sent: quarta-feira, 6 de Julho de 2011 16:44 > >> To: Rui Costa > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> All, > >> > >> Since someone has commented about the process used for resolving > >> questions on > >> draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > >> > >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > >> process is: > >> > >> On February 3rd 2011 the working group last call was issued > >> on version -03 > >> > >> This was copied to the the Ad Hoc Team List > >> and liaised to SG15 also on February 3rd > >> > >> This working group last call ended om Feb 28 > >> > >> > >> On Feb 28 we also received a liaison with comments from SG15 > >> > >> > >> The authors compiled a list of all comments received as part the > MPLS > >> working group last call; these comments - and the intended > resolution > >> - > >> is included in the meeting minutes from the Prague meeting: > >> > >> > >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > >> > >> > >> During the IETF meeting in Prague, we agreed with the BFD working > >> group to do a separate working group last callfor the BFD working > >> group > >> > >> The (BFD) working group last call was started on March 30th and ran > >> for 13 days. The last call ended on April 11th. > >> > >> The authors have since worked hard to resolve comments, some > >> issue has been brought to the working group mailing list for > >> resolution. > >> > >> Version -04 of the document was published June 28th. > >> > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >> June 29th. > >> > >> The AD review resulted in a "New ID needed" due to mostly editorial > >> comments. Version -05 was published on June 29 and the IETF last > call > >> started as soon as the new ID was avaialbe. > >> > >> The current list of Last Call Comments resoltion is also avaiable > at: > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> The list of issues that the authors kept very carefully, shows > >> without > >> doubt > >> that no comments been ignored. > >> > >> Loa > >> mpls wg document shepherd > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 14:58 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> Hi Rui: > >> > >> The comments were not ignored, the resolution of the Q10 comments as > >> well as those collected from the MPLS WG was presented at the last > >> IETF. My spreadsheet from which that report was generated and has > been > >> augmented to include the BFD WG comments is available at > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> So you know... > >> Dave > >> > >> > >> -----Original Message----- > >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > Of > >> Rui Costa > >> Sent: segunda-feira, 4 de Julho de 2011 23:03 > >> To: ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> IMHO and for the record: > >> > >> ITU-T comments regarding this draft haven't been discussed with ITU- > T > >> but were simply ignored. No LS describing these comments' resolution > >> was sent. > >> > >> Several service providers regarded this draft as not meeting their > >> transport networks' needs. > >> > >> [The v03 draft was published in Feb and went to WG LC. > >> The v04 draft addressing WG LC comments was published on the 28th > June > >> (same date as the proto write-up). > >> When was the WG LC launched, to verify LC comments resolution?] > >> > >> Regards, > >> Rui > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> The IESG > >> Sent: quinta-feira, 30 de Junho de 2011 14:47 > >> To: IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> > >> The IESG has received a request from the Multiprotocol Label > Switching > >> WG > >> (mpls) to consider the following document: > >> - 'Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile' > >> 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 2011-07-14. 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 > >> > >> Continuity Check, Proactive Connectivity Verification and Remote > >> Defect Indication functionalities are required for MPLS-TP OAM. > >> > >> Continuity Check monitors the integrity of the continuity of the > >> label switched path for any loss of continuity defect. > Connectivity > >> verification monitors the integrity of the routing of the label > >> switched path between sink and source for any connectivity issues. > >> Remote defect indication enables an End Point to report, to its > >> associated End Point, a fault or defect condition that it detects > on > >> a pseudo wire, label switched path or Section. > >> > >> This document specifies methods for proactive continuity check, > >> continuity verification, and remote defect indication for MPLS-TP > >> label switched paths, pseudo wires and Sections using > Bidirectional > >> Forwarding Detection. > >> > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From david.i.allan@ericsson.com Fri Jul 8 09:30:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F8421F8BA8; Fri, 8 Jul 2011 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY4lJmmz2VqF; Fri, 8 Jul 2011 09:30:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C411F21F8BA6; Fri, 8 Jul 2011 09:30:14 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p68GU94S006108; Fri, 8 Jul 2011 11:30:11 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 8 Jul 2011 12:30:08 -0400 From: David Allan I To: Thomas Nadeau , "neil.2.harrison@bt.com" Date: Fri, 8 Jul 2011 12:30:07 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g3d5g1+ZEhf1RAmo9qGC9yjrgAAB+HhQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD52213544C9@EUSAACMS0703.eamcs.ericsson.se> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , "ietf-announce@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:30:16 -0000 I think there is some confusion here.... The only CC in isolation in the draft is the option to use RFC 5885. Which = then is a network design issue. Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU th= at requires CV processing so there are CC and CV PDUs interleaved. Mis-conn= ectivity detection is network wide and fairly authoritative (unless we are = discussing a mode of failure in which only "some" packets leak, which means= even an always on CV may not be so unlucky as to leak and be detected). So I think we are in agreement on that front... Dave -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Friday, July 08, 2011 8:27 AM To: neil.2.harrison@bt.com Cc: RCosta@ptinovacao.pt; David Allan I; stbryant@cisco.com; mpls@ietf.org;= ietf@ietf.org; ietf-announce@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard On Jul 8, 2011, at 3:15 AM, wrote: > Got to say I agree with Rui on much of what he says here. And I absolute= ly resonate with his point on the need for simplicity. The reason OAM need= s to be as simple as possible is because it must be super reliable....we do= not want to consciously build in weaknesses, esp unnecessary ones.... this= also implies minimal config. We could all do better on this. For example= : > > - Rui is dead right a CC function is fairly useless, we only need a= CV function...the ATM OAM in I.610 suffers from this problem (and few othe= rs like AIS and the assumed use of request/response MLT to diagnose leaking= /mismerging traffic...request/response OAM won't work with unidirectional d= efects). While you are entitled to your opinion, I personally think there ar= e enough requirements elsewhere to have both CC and CV functions. But we d= igress. Are you actually asking that the CC functionality be removed from t= he draft or just making a general comment? > - all packet layer networks should not have an AIS OAM message....v= ery obvious for the cl-ps mode of course. The co-ps mode is also not like = the co-cs mode. One has to consciously manufacture AIS messages and target= them to specific clients in the co-ps mode....who may have taken action in= their own layer network and 'moved elsewhere' anyway, ie a total waste of = time now. AIS is actually unnecessary wrt providing information anyway, it= simply represents an in-built weakness of just something else to go wrong = which itself will create problems. What does that comment have to do with the actual draft in question= ? > - creating preconfigured TCM sublayers is just asking for trouble I= MO. It is far smarter to simply create a single end-end OAM CV (and when r= equired PM) flow and tap this off at intermediate nodes on the *rare* occas= ions one wants to do. Again, what does this have to do with the actual draft in question? --tom > > regards, Neil > > This email contains BT information, which may be privileged or confidenti= al. > It's meant only for the individual(s) or entity named above. If you're > not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've > received this email in error, please let me know immediately on the email= address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > > > > > > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Rui Costa >> Sent: 08 July 2011 01:15 >> To: David Allan I; Stewart Bryant >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> David, >> >> Reading something, keeping it on record, without effect in the draft >> and "ignoring comments" have IMHO similar outcomes. As author of the >> draft you are free to do it. These standards have a great impact in >> our work, so i'm also free to write what i did. >> >> >> >> >> Stewart, >> >> My technical concerns regarding this draft were expressed... >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i >> believe); ...in operators' meetings' that took place during ITU-T's >> Feb/2011 plenary meeting; ...in a comparison session that took place >> during that same ITU-T meeting. >> Some: >> >> CC/CV >> I don't understand the need for 2 types of packets: a single type >> allows CC; mismatching identifiers in the same CC packets allow CV. >> Besides adding complexity, we whether always activate both or >> potentiate undetected mismerges. >> (BTW: can't understand how we propose one ACH codepoint to CC, >> another for CV, [counting other drafts, another for frame loss ...] >> but don't consider assigning 1 single ACH protocol identifier >> codepoint as requested by ITU-T) >> >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other than... >> >> ...eliminating the session "state variable" (down, init, up), aiming >> just the state variables we really need, bringing us to something >> similar to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume per >> requirements; Will we create a complete different tool for that? >> (BFD's B=3D"bidirectional") >> >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through a >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to >> focus on that profile/configuration. However, i keep seeing >> references f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP, are >> we talking about MPLS in general?... The TP profile is never quite >> delimited. >> Does chapter 4 contain ALL the configurable parameters list agreed to >> provide in the comparison session? >> >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's >> not a better argument than grounding MPLS-TP OAM on 1731 due to its >> ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards >> compatible with previous BFD (even considering just CC/CV). They >> don't even share the same codepoint. >> >> Simplicity >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is >> simpler: in each flow, a standard defined nr of constant heartbeat >> signals (with standard constant or provisioned period - no >> auto/negotiated -) means OK. A standard defined number of misses >> means lost Rx connection. An RDI, the only articulation between Rx >> and Tx flows, meaningful in bidirectional applications, allows each >> pear to identify Tx problems. >> This OAM simplicity is the key for reliable fail finger pointing, >> performance reports and protection. Also to allow scaling, more >> implementation opportunities/manufacturers, which is valuable for >> operators. >> >> >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more >> difficult to tell which is which. >> >> Regards, >> Rui >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 19:25 >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- >> Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> Hi Erminio: >> >> >>> Several service providers regarded this draft as not meeting their >>> transport networks' needs. >> >> E> This is a true statement: the solution in this draft is useless >> E> for >> many MPLS- TP deployments. >> >> The two statements do not necessarily follow. >> >> What we established during discussions at the SG15 plenary in >> February was that the issue some service providers had was that the >> IETF BFD solution exceeded their requirements in that there was >> additional functionality they did not see a need for, and that they >> considered any additional functionality parasitic. >> >> However this is a consequence of adapting an existing technology to a >> new application. I do not see any way around that. And the entire >> joint project was based on the premise of engineering re-use not >> greenfield design. That is what it said on the tin up front, and IMO >> why when the IETF started down this path packet transport >> transitioned from being a minority sport to mainstream, so it is a bit l= ate to cry foul.... >> >> My 2 cents >> Dave >> >> >> >> >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 18:36 >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: RE: [mpls] R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> Hi Erminio: >> >> Two of the three document editors were present at SG15 plenary in >> February where the comments originated. The revised meeting schedule >> resulted in a day spent going through the document with the editors. >> IMO there were lots of discussion and legitimate issues with the >> document identified and corrected so it was a useful session. The >> liaison of same was in many ways *after the fact*. >> >> Cheers >> Dave >> >> >> >> >> -----Original Message----- >> From: erminio.ottone_69@libero.it >> [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:34 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: R: Re: [mpls] Last Call: >> >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> The way this draft has been developed is a bit strange. >> >> The poll for its adoption as a WG document was halted by the MPLS WG >> chair because "it is not possible to judge consensus": >> >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html >> >> The lack of consensus was motivated by serious technical concerns >> raised by several transport experts during the poll. >> >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG >> document: >> >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html >> >> After several WG revisions and WG LCs, the technical issues have not >> been resolved. >> >>> Several service providers regarded this draft as not meeting their >> transport >> networks' needs. >> >> This is a true statement: the solution in this draft is useless for >> many MPLS- TP deployments. >> >> >> -----Original Message----- >> From: erminio.ottone_69@libero.it >> [mailto:erminio.ottone_69@libero.it] >> Sent: quarta-feira, 6 de Julho de 2011 18:26 >> To: loa@pi.nu; Rui Costa >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> Subject: R: Re: [mpls] Last Call: >> >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >>> Version -04 of the document was published June 28th. >>> >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >>> June 29th. >>> >> >> So when the WG LC to confirm the LC comment resolution has been >> launched? >> >> The proto write-up says: >> >> It has also passed a working roup call to verify that LC >> comments were correctly with minor comments. >> >> It also says: >> >> The comments has been >> carefully discussed between the authors and people making >> the comments and >> has been resolved. >> >> But it seems that some comments have not been discussed with the >> authors of the comments. When ITU-T Q10/15 has been involved in >> discussing its comments? >> >> >> >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: quarta-feira, 6 de Julho de 2011 16:44 >> To: Rui Costa >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> Subject: Re: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> All, >> >> Since someone has commented about the process used for resolving >> questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details >> below. >> >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >> process is: >> >> On February 3rd 2011 the working group last call was issued on >> version -03 >> >> This was copied to the the Ad Hoc Team List >> and liaised to SG15 also on February 3rd >> >> This working group last call ended om Feb 28 >> >> >> On Feb 28 we also received a liaison with comments from SG15 >> >> >> The authors compiled a list of all comments received as part the >> MPLS working group last call; these comments - and the intended >> resolution >> - >> is included in the meeting minutes from the Prague meeting: >> >> >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf >> >> >> During the IETF meeting in Prague, we agreed with the BFD working >> group to do a separate working group last callfor the BFD working >> group >> >> The (BFD) working group last call was started on March 30th and ran >> for 13 days. The last call ended on April 11th. >> >> The authors have since worked hard to resolve comments, some issue >> has been brought to the working group mailing list for resolution. >> >> Version -04 of the document was published June 28th. >> >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >> June 29th. >> >> The AD review resulted in a "New ID needed" due to mostly editorial >> comments. Version -05 was published on June 29 and the IETF last call >> started as soon as the new ID was avaialbe. >> >> The current list of Last Call Comments resoltion is also avaiable at: >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >> >> The list of issues that the authors kept very carefully, shows >> without doubt that no comments been ignored. >> >> Loa >> mpls wg document shepherd >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Allan I [mailto:david.i.allan@ericsson.com] >> Sent: quarta-feira, 6 de Julho de 2011 14:58 >> To: Rui Costa; ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> Hi Rui: >> >> The comments were not ignored, the resolution of the Q10 comments as >> well as those collected from the MPLS WG was presented at the last >> IETF. My spreadsheet from which that report was generated and has >> been augmented to include the BFD WG comments is available at >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >> >> So you know... >> Dave >> >> >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >> Of Rui Costa >> Sent: segunda-feira, 4 de Julho de 2011 23:03 >> To: ietf@ietf.org; IETF-Announce >> Cc: mpls@ietf.org >> Subject: RE: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> IMHO and for the record: >> >> ITU-T comments regarding this draft haven't been discussed with ITU-T >> but were simply ignored. No LS describing these comments' resolution >> was sent. >> >> Several service providers regarded this draft as not meeting their >> transport networks' needs. >> >> [The v03 draft was published in Feb and went to WG LC. >> The v04 draft addressing WG LC comments was published on the 28th >> June (same date as the proto write-up). >> When was the WG LC launched, to verify LC comments resolution?] >> >> Regards, >> Rui >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label >> Switching WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 2011-07-14. 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 >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From neil.2.harrison@bt.com Fri Jul 8 09:39:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B00E21F8B61; Fri, 8 Jul 2011 09:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg367DnS1a1z; Fri, 8 Jul 2011 09:39:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5536121F8B5F; Fri, 8 Jul 2011 09:39:40 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 17:39:39 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.186]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 8 Jul 2011 17:39:39 +0100 From: To: , Date: Fri, 8 Jul 2011 17:39:32 +0100 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g3d5g1+ZEhf1RAmo9qGC9yjrgAAB+HhQAABF93A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405A7557A0@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> <60C093A41B5E45409A19D42CF7786DFD52213544C9@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52213544C9@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, ietf-announce@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:39:42 -0000 Thanks Dave. If we don't have this (ie CV function on all connections/LSPs= ) then there is potential security risk wrt leaking traffic. Note that bes= ides trad nested sublayered LSPs in the same layer network this also applie= s to nested LSPs belonging to different MPLS-TP layer networks (may be same= or different party ownership). This point about the OAM CV function also = ought to be captured in any security drafts. regards, Neil > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: 08 July 2011 17:30 > To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R > Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; > ietf@ietf.org; ietf-announce@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > I think there is some confusion here.... > > The only CC in isolation in the draft is the option to use RFC 5885. > Which then is a network design issue. > > Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY > PDU that requires CV processing so there are CC and CV PDUs > interleaved. Mis-connectivity detection is network wide and fairly > authoritative (unless we are discussing a mode of failure in which only > "some" packets leak, which means even an always on CV may not be so > unlucky as to leak and be detected). > > So I think we are in agreement on that front... > Dave > > > > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Friday, July 08, 2011 8:27 AM > To: neil.2.harrison@bt.com > Cc: RCosta@ptinovacao.pt; David Allan I; stbryant@cisco.com; > mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > Subject: Re: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > On Jul 8, 2011, at 3:15 AM, wrote: > > > Got to say I agree with Rui on much of what he says here. And I > absolutely resonate with his point on the need for simplicity. The > reason OAM needs to be as simple as possible is because it must be > super reliable....we do not want to consciously build in weaknesses, > esp unnecessary ones.... this also implies minimal config. We could > all do better on this. For example: > > > > - Rui is dead right a CC function is fairly useless, we only > need a CV function...the ATM OAM in I.610 suffers from this problem > (and few others like AIS and the assumed use of request/response MLT to > diagnose leaking/mismerging traffic...request/response OAM won't work > with unidirectional defects). > > While you are entitled to your opinion, I personally think > there are enough requirements elsewhere to have both CC and CV > functions. But we digress. Are you actually asking that the CC > functionality be removed from the draft or just making a general > comment? > > > - all packet layer networks should not have an AIS OAM > message....very obvious for the cl-ps mode of course. The co-ps mode > is also not like the co-cs mode. One has to consciously manufacture > AIS messages and target them to specific clients in the co-ps > mode....who may have taken action in their own layer network and 'moved > elsewhere' anyway, ie a total waste of time now. AIS is actually > unnecessary wrt providing information anyway, it simply represents an > in-built weakness of just something else to go wrong which itself will > create problems. > > What does that comment have to do with the actual draft in > question? > > > - creating preconfigured TCM sublayers is just asking for > trouble IMO. It is far smarter to simply create a single end-end OAM > CV (and when required PM) flow and tap this off at intermediate nodes > on the *rare* occasions one wants to do. > > Again, what does this have to do with the actual draft in > question? > > --tom > > > > > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're > > not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > > England no: 1800000 > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of Rui Costa > >> Sent: 08 July 2011 01:15 > >> To: David Allan I; Stewart Bryant > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> David, > >> > >> Reading something, keeping it on record, without effect in the draft > >> and "ignoring comments" have IMHO similar outcomes. As author of the > >> draft you are free to do it. These standards have a great impact in > >> our work, so i'm also free to write what i did. > >> > >> > >> > >> > >> Stewart, > >> > >> My technical concerns regarding this draft were expressed... > >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > >> believe); ...in operators' meetings' that took place during ITU-T's > >> Feb/2011 plenary meeting; ...in a comparison session that took place > >> during that same ITU-T meeting. > >> Some: > >> > >> CC/CV > >> I don't understand the need for 2 types of packets: a single type > >> allows CC; mismatching identifiers in the same CC packets allow CV. > >> Besides adding complexity, we whether always activate both or > >> potentiate undetected mismerges. > >> (BTW: can't understand how we propose one ACH codepoint to CC, > >> another for CV, [counting other drafts, another for frame loss ...] > >> but don't consider assigning 1 single ACH protocol identifier > >> codepoint as requested by ITU-T) > >> > >> Uni P2P / P2MP > >> I can't see how BFD will support unidir and hence P2MP other than... > >> > >> ...eliminating the session "state variable" (down, init, up), aiming > >> just the state variables we really need, bringing us to something > >> similar to 1731, eventually with other bits on the wire or... > >> ...using IP to create the reverse way, which we cannot assume per > >> requirements; Will we create a complete different tool for that? > >> (BFD's B=3D"bidirectional") > >> > >> Provisioning list > >> This is an MPLS profile/subset (and i heard) achievable through a > >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to > >> focus on that profile/configuration. However, i keep seeing > >> references f.i. to IP encapsulations unexpected under TP's OAM. > >> I don't thus understand what the aim is: do we expect this in TP, > are > >> we talking about MPLS in general?... The TP profile is never quite > >> delimited. > >> Does chapter 4 contain ALL the configurable parameters list agreed > to > >> provide in the comparison session? > >> > >> Backwards compatibility > >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's > >> not a better argument than grounding MPLS-TP OAM on 1731 due to its > >> ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. > >> For reasons like the above, however, MPLS-TP BFD won't be backwards > >> compatible with previous BFD (even considering just CC/CV). They > >> don't even share the same codepoint. > >> > >> Simplicity > >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > >> simpler: in each flow, a standard defined nr of constant heartbeat > >> signals (with standard constant or provisioned period - no > >> auto/negotiated -) means OK. A standard defined number of misses > >> means lost Rx connection. An RDI, the only articulation between Rx > >> and Tx flows, meaningful in bidirectional applications, allows each > >> pear to identify Tx problems. > >> This OAM simplicity is the key for reliable fail finger pointing, > >> performance reports and protection. Also to allow scaling, more > >> implementation opportunities/manufacturers, which is valuable for > >> operators. > >> > >> > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > more > >> difficult to tell which is which. > >> > >> Regards, > >> Rui > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 19:25 > >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > >> Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] R: Re: Last Call: >> 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Hi Erminio: > >> > >> > >>> Several service providers regarded this draft as not meeting their > >>> transport networks' needs. > >> > >> E> This is a true statement: the solution in this draft is useless > >> E> for > >> many MPLS- TP deployments. > >> > >> The two statements do not necessarily follow. > >> > >> What we established during discussions at the SG15 plenary in > >> February was that the issue some service providers had was that the > >> IETF BFD solution exceeded their requirements in that there was > >> additional functionality they did not see a need for, and that they > >> considered any additional functionality parasitic. > >> > >> However this is a consequence of adapting an existing technology to > a > >> new application. I do not see any way around that. And the entire > >> joint project was based on the premise of engineering re-use not > >> greenfield design. That is what it said on the tin up front, and IMO > >> why when the IETF started down this path packet transport > >> transitioned from being a minority sport to mainstream, so it is a > bit late to cry foul.... > >> > >> My 2 cents > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 18:36 > >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: RE: [mpls] R: Re: Last Call: >> 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Hi Erminio: > >> > >> Two of the three document editors were present at SG15 plenary in > >> February where the comments originated. The revised meeting schedule > >> resulted in a day spent going through the document with the editors. > >> IMO there were lots of discussion and legitimate issues with the > >> document identified and corrected so it was a useful session. The > >> liaison of same was in many ways *after the fact*. > >> > >> Cheers > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > >> [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:34 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: R: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> The way this draft has been developed is a bit strange. > >> > >> The poll for its adoption as a WG document was halted by the MPLS WG > >> chair because "it is not possible to judge consensus": > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > >> > >> The lack of consensus was motivated by serious technical concerns > >> raised by several transport experts during the poll. > >> > >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG > >> document: > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > >> > >> After several WG revisions and WG LCs, the technical issues have not > >> been resolved. > >> > >>> Several service providers regarded this draft as not meeting their > >> transport > >> networks' needs. > >> > >> This is a true statement: the solution in this draft is useless for > >> many MPLS- TP deployments. > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > >> [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:26 > >> To: loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: R: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >>> Version -04 of the document was published June 28th. > >>> > >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >>> June 29th. > >>> > >> > >> So when the WG LC to confirm the LC comment resolution has been > >> launched? > >> > >> The proto write-up says: > >> > >> It has also passed a working roup call to verify that LC > >> comments were correctly with minor comments. > >> > >> It also says: > >> > >> The comments has been > >> carefully discussed between the authors and people making > >> the comments and > >> has been resolved. > >> > >> But it seems that some comments have not been discussed with the > >> authors of the comments. When ITU-T Q10/15 has been involved in > >> discussing its comments? > >> > >> > >> > >> > >> -----Original Message----- > >> From: Loa Andersson [mailto:loa@pi.nu] > >> Sent: quarta-feira, 6 de Julho de 2011 16:44 > >> To: Rui Costa > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> All, > >> > >> Since someone has commented about the process used for resolving > >> questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some > details > >> below. > >> > >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > >> process is: > >> > >> On February 3rd 2011 the working group last call was issued on > >> version -03 > >> > >> This was copied to the the Ad Hoc Team List > >> and liaised to SG15 also on February 3rd > >> > >> This working group last call ended om Feb 28 > >> > >> > >> On Feb 28 we also received a liaison with comments from SG15 > >> > >> > >> The authors compiled a list of all comments received as part the > >> MPLS working group last call; these comments - and the intended > >> resolution > >> - > >> is included in the meeting minutes from the Prague meeting: > >> > >> > >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > >> > >> > >> During the IETF meeting in Prague, we agreed with the BFD working > >> group to do a separate working group last callfor the BFD working > >> group > >> > >> The (BFD) working group last call was started on March 30th and ran > >> for 13 days. The last call ended on April 11th. > >> > >> The authors have since worked hard to resolve comments, some issue > >> has been brought to the working group mailing list for resolution. > >> > >> Version -04 of the document was published June 28th. > >> > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >> June 29th. > >> > >> The AD review resulted in a "New ID needed" due to mostly editorial > >> comments. Version -05 was published on June 29 and the IETF last > call > >> started as soon as the new ID was avaialbe. > >> > >> The current list of Last Call Comments resoltion is also avaiable > at: > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> The list of issues that the authors kept very carefully, shows > >> without doubt that no comments been ignored. > >> > >> Loa > >> mpls wg document shepherd > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 14:58 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> Hi Rui: > >> > >> The comments were not ignored, the resolution of the Q10 comments as > >> well as those collected from the MPLS WG was presented at the last > >> IETF. My spreadsheet from which that report was generated and has > >> been augmented to include the BFD WG comments is available at > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> So you know... > >> Dave > >> > >> > >> -----Original Message----- > >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > >> Of Rui Costa > >> Sent: segunda-feira, 4 de Julho de 2011 23:03 > >> To: ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> IMHO and for the record: > >> > >> ITU-T comments regarding this draft haven't been discussed with ITU- > T > >> but were simply ignored. No LS describing these comments' resolution > >> was sent. > >> > >> Several service providers regarded this draft as not meeting their > >> transport networks' needs. > >> > >> [The v03 draft was published in Feb and went to WG LC. > >> The v04 draft addressing WG LC comments was published on the 28th > >> June (same date as the proto write-up). > >> When was the WG LC launched, to verify LC comments resolution?] > >> > >> Regards, > >> Rui > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of The IESG > >> Sent: quinta-feira, 30 de Junho de 2011 14:47 > >> To: IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> > >> The IESG has received a request from the Multiprotocol Label > >> Switching WG > >> (mpls) to consider the following document: > >> - 'Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile' > >> 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 2011-07-14. 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 > >> > >> Continuity Check, Proactive Connectivity Verification and Remote > >> Defect Indication functionalities are required for MPLS-TP OAM. > >> > >> Continuity Check monitors the integrity of the continuity of the > >> label switched path for any loss of continuity defect. > Connectivity > >> verification monitors the integrity of the routing of the label > >> switched path between sink and source for any connectivity issues. > >> Remote defect indication enables an End Point to report, to its > >> associated End Point, a fault or defect condition that it detects > on > >> a pseudo wire, label switched path or Section. > >> > >> This document specifies methods for proactive continuity check, > >> continuity verification, and remote defect indication for MPLS-TP > >> label switched paths, pseudo wires and Sections using > Bidirectional > >> Forwarding Detection. > >> > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From david.i.allan@ericsson.com Fri Jul 8 09:42:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E390021F8A49; Fri, 8 Jul 2011 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0O6w90nWFBo; Fri, 8 Jul 2011 09:42:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2514821F8B23; Fri, 8 Jul 2011 09:42:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p68Gg5Dp008246; Fri, 8 Jul 2011 11:42:22 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 8 Jul 2011 12:42:02 -0400 From: David Allan I To: "neil.2.harrison@bt.com" , "tnadeau@lucidvision.com" Date: Fri, 8 Jul 2011 12:42:01 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g3d5g1+ZEhf1RAmo9qGC9yjrgAAB+HhQAABF93AAAFWVAA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD52213544E5@EUSAACMS0703.eamcs.ericsson.se> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> <60C093A41B5E45409A19D42CF7786DFD52213544C9@EUSAACMS0703.eamcs.ericsson.se> <6D3D47CB84BDE349BC23BF1C94E316E4405A7557A0@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405A7557A0@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , "ietf-announce@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:42:30 -0000 Hi Neil: As a result of Adrians AD review, some text to that effect was added to the= Security Considerations section. Have a good weekend Dave -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Friday, July 08, 2011 9:40 AM To: David Allan I; tnadeau@lucidvision.com Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; ietf@ietf.org;= ietf-announce@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Thanks Dave. If we don't have this (ie CV function on all connections/LSPs= ) then there is potential security risk wrt leaking traffic. Note that bes= ides trad nested sublayered LSPs in the same layer network this also applie= s to nested LSPs belonging to different MPLS-TP layer networks (may be same= or different party ownership). This point about the OAM CV function also = ought to be captured in any security drafts. regards, Neil > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: 08 July 2011 17:30 > To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R > Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; > ietf@ietf.org; ietf-announce@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > I think there is some confusion here.... > > The only CC in isolation in the draft is the option to use RFC 5885. > Which then is a network design issue. > > Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY > PDU that requires CV processing so there are CC and CV PDUs > interleaved. Mis-connectivity detection is network wide and fairly > authoritative (unless we are discussing a mode of failure in which > only "some" packets leak, which means even an always on CV may not be > so unlucky as to leak and be detected). > > So I think we are in agreement on that front... > Dave > > > > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Friday, July 08, 2011 8:27 AM > To: neil.2.harrison@bt.com > Cc: RCosta@ptinovacao.pt; David Allan I; stbryant@cisco.com; > mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > Subject: Re: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > On Jul 8, 2011, at 3:15 AM, wrote: > > > Got to say I agree with Rui on much of what he says here. And I > absolutely resonate with his point on the need for simplicity. The > reason OAM needs to be as simple as possible is because it must be > super reliable....we do not want to consciously build in weaknesses, > esp unnecessary ones.... this also implies minimal config. We could > all do better on this. For example: > > > > - Rui is dead right a CC function is fairly useless, we only > need a CV function...the ATM OAM in I.610 suffers from this problem > (and few others like AIS and the assumed use of request/response MLT > to diagnose leaking/mismerging traffic...request/response OAM won't > work with unidirectional defects). > > While you are entitled to your opinion, I personally think > there are enough requirements elsewhere to have both CC and CV > functions. But we digress. Are you actually asking that the CC > functionality be removed from the draft or just making a general > comment? > > > - all packet layer networks should not have an AIS OAM > message....very obvious for the cl-ps mode of course. The co-ps mode > is also not like the co-cs mode. One has to consciously manufacture > AIS messages and target them to specific clients in the co-ps > mode....who may have taken action in their own layer network and > 'moved elsewhere' anyway, ie a total waste of time now. AIS is > actually unnecessary wrt providing information anyway, it simply > represents an in-built weakness of just something else to go wrong > which itself will create problems. > > What does that comment have to do with the actual draft in > question? > > > - creating preconfigured TCM sublayers is just asking for > trouble IMO. It is far smarter to simply create a single end-end OAM > CV (and when required PM) flow and tap this off at intermediate nodes > on the *rare* occasions one wants to do. > > Again, what does this have to do with the actual draft in > question? > > --tom > > > > > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're > > not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > > England no: 1800000 > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf Of Rui Costa > >> Sent: 08 July 2011 01:15 > >> To: David Allan I; Stewart Bryant > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> David, > >> > >> Reading something, keeping it on record, without effect in the > >> draft and "ignoring comments" have IMHO similar outcomes. As author > >> of the draft you are free to do it. These standards have a great > >> impact in our work, so i'm also free to write what i did. > >> > >> > >> > >> > >> Stewart, > >> > >> My technical concerns regarding this draft were expressed... > >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > >> believe); ...in operators' meetings' that took place during ITU-T's > >> Feb/2011 plenary meeting; ...in a comparison session that took > >> place during that same ITU-T meeting. > >> Some: > >> > >> CC/CV > >> I don't understand the need for 2 types of packets: a single type > >> allows CC; mismatching identifiers in the same CC packets allow CV. > >> Besides adding complexity, we whether always activate both or > >> potentiate undetected mismerges. > >> (BTW: can't understand how we propose one ACH codepoint to CC, > >> another for CV, [counting other drafts, another for frame loss ...] > >> but don't consider assigning 1 single ACH protocol identifier > >> codepoint as requested by ITU-T) > >> > >> Uni P2P / P2MP > >> I can't see how BFD will support unidir and hence P2MP other than... > >> > >> ...eliminating the session "state variable" (down, init, up), > >> aiming just the state variables we really need, bringing us to > >> something similar to 1731, eventually with other bits on the wire or..= . > >> ...using IP to create the reverse way, which we cannot assume per > >> requirements; Will we create a complete different tool for that? > >> (BFD's B=3D"bidirectional") > >> > >> Provisioning list > >> This is an MPLS profile/subset (and i heard) achievable through a > >> particular configuration. So, i expect each draft-ietf-mpls-TP-* to > >> focus on that profile/configuration. However, i keep seeing > >> references f.i. to IP encapsulations unexpected under TP's OAM. > >> I don't thus understand what the aim is: do we expect this in TP, > are > >> we talking about MPLS in general?... The TP profile is never quite > >> delimited. > >> Does chapter 4 contain ALL the configurable parameters list agreed > to > >> provide in the comparison session? > >> > >> Backwards compatibility > >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's > >> not a better argument than grounding MPLS-TP OAM on 1731 due to its > >> ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. > >> For reasons like the above, however, MPLS-TP BFD won't be backwards > >> compatible with previous BFD (even considering just CC/CV). They > >> don't even share the same codepoint. > >> > >> Simplicity > >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > >> simpler: in each flow, a standard defined nr of constant heartbeat > >> signals (with standard constant or provisioned period - no > >> auto/negotiated -) means OK. A standard defined number of misses > >> means lost Rx connection. An RDI, the only articulation between Rx > >> and Tx flows, meaningful in bidirectional applications, allows each > >> pear to identify Tx problems. > >> This OAM simplicity is the key for reliable fail finger pointing, > >> performance reports and protection. Also to allow scaling, more > >> implementation opportunities/manufacturers, which is valuable for > >> operators. > >> > >> > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > more > >> difficult to tell which is which. > >> > >> Regards, > >> Rui > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 19:25 > >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > >> Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] R: Re: Last Call: > >> (Proactive Connectivity > >> Verification, Continuity Check and Remote Defect indication for > >> MPLS Transport Profile) to Proposed Standard > >> > >> Hi Erminio: > >> > >> > >>> Several service providers regarded this draft as not meeting their > >>> transport networks' needs. > >> > >> E> This is a true statement: the solution in this draft is useless > >> E> for > >> many MPLS- TP deployments. > >> > >> The two statements do not necessarily follow. > >> > >> What we established during discussions at the SG15 plenary in > >> February was that the issue some service providers had was that the > >> IETF BFD solution exceeded their requirements in that there was > >> additional functionality they did not see a need for, and that they > >> considered any additional functionality parasitic. > >> > >> However this is a consequence of adapting an existing technology to > a > >> new application. I do not see any way around that. And the entire > >> joint project was based on the premise of engineering re-use not > >> greenfield design. That is what it said on the tin up front, and > >> IMO why when the IETF started down this path packet transport > >> transitioned from being a minority sport to mainstream, so it is a > bit late to cry foul.... > >> > >> My 2 cents > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 18:36 > >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: RE: [mpls] R: Re: Last Call: > >> (Proactive Connectivity > >> Verification, Continuity Check and Remote Defect indication for > >> MPLS Transport Profile) to Proposed Standard > >> > >> Hi Erminio: > >> > >> Two of the three document editors were present at SG15 plenary in > >> February where the comments originated. The revised meeting > >> schedule resulted in a day spent going through the document with the e= ditors. > >> IMO there were lots of discussion and legitimate issues with the > >> document identified and corrected so it was a useful session. The > >> liaison of same was in many ways *after the fact*. > >> > >> Cheers > >> Dave > >> > >> > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > >> [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:34 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: R: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> The way this draft has been developed is a bit strange. > >> > >> The poll for its adoption as a WG document was halted by the MPLS > >> WG chair because "it is not possible to judge consensus": > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > >> > >> The lack of consensus was motivated by serious technical concerns > >> raised by several transport experts during the poll. > >> > >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG > >> document: > >> > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > >> > >> After several WG revisions and WG LCs, the technical issues have > >> not been resolved. > >> > >>> Several service providers regarded this draft as not meeting their > >> transport > >> networks' needs. > >> > >> This is a true statement: the solution in this draft is useless for > >> many MPLS- TP deployments. > >> > >> > >> -----Original Message----- > >> From: erminio.ottone_69@libero.it > >> [mailto:erminio.ottone_69@libero.it] > >> Sent: quarta-feira, 6 de Julho de 2011 18:26 > >> To: loa@pi.nu; Rui Costa > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> Subject: R: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >>> Version -04 of the document was published June 28th. > >>> > >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >>> June 29th. > >>> > >> > >> So when the WG LC to confirm the LC comment resolution has been > >> launched? > >> > >> The proto write-up says: > >> > >> It has also passed a working roup call to verify that LC > >> comments were correctly with minor comments. > >> > >> It also says: > >> > >> The comments has been > >> carefully discussed between the authors and people > >> making the comments and > >> has been resolved. > >> > >> But it seems that some comments have not been discussed with the > >> authors of the comments. When ITU-T Q10/15 has been involved in > >> discussing its comments? > >> > >> > >> > >> > >> -----Original Message----- > >> From: Loa Andersson [mailto:loa@pi.nu] > >> Sent: quarta-feira, 6 de Julho de 2011 16:44 > >> To: Rui Costa > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> Subject: Re: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> All, > >> > >> Since someone has commented about the process used for resolving > >> questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some > details > >> below. > >> > >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > >> process is: > >> > >> On February 3rd 2011 the working group last call was issued on > >> version -03 > >> > >> This was copied to the the Ad Hoc Team List > >> and liaised to SG15 also on February 3rd > >> > >> This working group last call ended om Feb 28 > >> > >> > >> On Feb 28 we also received a liaison with comments from SG15 > >> > >> > >> The authors compiled a list of all comments received as part the > >> MPLS working group last call; these comments - and the intended > >> resolution > >> - > >> is included in the meeting minutes from the Prague meeting: > >> > >> > >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > >> > >> > >> During the IETF meeting in Prague, we agreed with the BFD working > >> group to do a separate working group last callfor the BFD working > >> group > >> > >> The (BFD) working group last call was started on March 30th and ran > >> for 13 days. The last call ended on April 11th. > >> > >> The authors have since worked hard to resolve comments, some > >> issue has been brought to the working group mailing list for resoluti= on. > >> > >> Version -04 of the document was published June 28th. > >> > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > >> June 29th. > >> > >> The AD review resulted in a "New ID needed" due to mostly > >> editorial comments. Version -05 was published on June 29 and the > >> IETF last > call > >> started as soon as the new ID was avaialbe. > >> > >> The current list of Last Call Comments resoltion is also avaiable > at: > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> The list of issues that the authors kept very carefully, shows > >> without doubt that no comments been ignored. > >> > >> Loa > >> mpls wg document shepherd > >> > >> > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > >> Sent: quarta-feira, 6 de Julho de 2011 14:58 > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> Hi Rui: > >> > >> The comments were not ignored, the resolution of the Q10 comments > >> as well as those collected from the MPLS WG was presented at the > >> last IETF. My spreadsheet from which that report was generated and > >> has been augmented to include the BFD WG comments is available at > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > >> > >> So you know... > >> Dave > >> > >> > >> -----Original Message----- > >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > >> Behalf Of Rui Costa > >> Sent: segunda-feira, 4 de Julho de 2011 23:03 > >> To: ietf@ietf.org; IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: RE: [mpls] Last Call: > >> > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> IMHO and for the record: > >> > >> ITU-T comments regarding this draft haven't been discussed with > >> ITU- > T > >> but were simply ignored. No LS describing these comments' > >> resolution was sent. > >> > >> Several service providers regarded this draft as not meeting their > >> transport networks' needs. > >> > >> [The v03 draft was published in Feb and went to WG LC. > >> The v04 draft addressing WG LC comments was published on the 28th > >> June (same date as the proto write-up). > >> When was the WG LC launched, to verify LC comments resolution?] > >> > >> Regards, > >> Rui > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf Of The IESG > >> Sent: quinta-feira, 30 de Junho de 2011 14:47 > >> To: IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: [mpls] Last Call: > >> (Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile) to Proposed Standard > >> > >> > >> The IESG has received a request from the Multiprotocol Label > >> Switching WG > >> (mpls) to consider the following document: > >> - 'Proactive Connectivity Verification, Continuity Check and Remote > >> Defect indication for MPLS Transport Profile' > >> 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 2011-07-14. 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 > >> > >> Continuity Check, Proactive Connectivity Verification and Remote > >> Defect Indication functionalities are required for MPLS-TP OAM. > >> > >> Continuity Check monitors the integrity of the continuity of the > >> label switched path for any loss of continuity defect. > Connectivity > >> verification monitors the integrity of the routing of the label > >> switched path between sink and source for any connectivity issues. > >> Remote defect indication enables an End Point to report, to its > >> associated End Point, a fault or defect condition that it detects > on > >> a pseudo wire, label switched path or Section. > >> > >> This document specifies methods for proactive continuity check, > >> continuity verification, and remote defect indication for MPLS-TP > >> label switched paths, pseudo wires and Sections using > Bidirectional > >> Forwarding Detection. > >> > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From neil.2.harrison@bt.com Fri Jul 8 09:44:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59A221F8BCC; Fri, 8 Jul 2011 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kStQifBiFiH; Fri, 8 Jul 2011 09:44:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2D75221F8BC8; Fri, 8 Jul 2011 09:44:01 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 8 Jul 2011 17:44:00 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.186]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 8 Jul 2011 17:44:00 +0100 From: To: , Date: Fri, 8 Jul 2011 17:43:56 +0100 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw9g3d5g1+ZEhf1RAmo9qGC9yjrgAAB+HhQAABF93AAAFWVAAAAE9vA Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405A7557A8@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <6D3D47CB84BDE349BC23BF1C94E316E4405A7550DE@EMV62-UKRD.domain1.systemhost.net> <60C093A41B5E45409A19D42CF7786DFD52213544C9@EUSAACMS0703.eamcs.ericsson.se> <6D3D47CB84BDE349BC23BF1C94E316E4405A7557A0@EMV62-UKRD.domain1.systemhost.net> <60C093A41B5E45409A19D42CF7786DFD52213544E5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52213544E5@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, ietf@ietf.org, ietf-announce@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:44:03 -0000 Excellent...well done Adrian! Thanks Dave for the info. Have a nice one y= ourself.... regards, Neil > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: 08 July 2011 17:42 > To: Harrison,N,Neil,DKQ7 R; tnadeau@lucidvision.com > Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; > ietf@ietf.org; ietf-announce@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Hi Neil: > > As a result of Adrians AD review, some text to that effect was added to > the Security Considerations section. > > Have a good weekend > Dave > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, July 08, 2011 9:40 AM > To: David Allan I; tnadeau@lucidvision.com > Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; > ietf@ietf.org; ietf-announce@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > Thanks Dave. If we don't have this (ie CV function on all > connections/LSPs) then there is potential security risk wrt leaking > traffic. Note that besides trad nested sublayered LSPs in the same > layer network this also applies to nested LSPs belonging to different > MPLS-TP layer networks (may be same or different party ownership). > This point about the OAM CV function also ought to be captured in any > security drafts. > > regards, Neil > > > -----Original Message----- > > From: David Allan I [mailto:david.i.allan@ericsson.com] > > Sent: 08 July 2011 17:30 > > To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R > > Cc: RCosta@ptinovacao.pt; stbryant@cisco.com; mpls@ietf.org; > > ietf@ietf.org; ietf-announce@ietf.org > > Subject: RE: [mpls] Last Call: > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > I think there is some confusion here.... > > > > The only CC in isolation in the draft is the option to use RFC 5885. > > Which then is a network design issue. > > > > Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY > > PDU that requires CV processing so there are CC and CV PDUs > > interleaved. Mis-connectivity detection is network wide and fairly > > authoritative (unless we are discussing a mode of failure in which > > only "some" packets leak, which means even an always on CV may not be > > so unlucky as to leak and be detected). > > > > So I think we are in agreement on that front... > > Dave > > > > > > > > -----Original Message----- > > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: Friday, July 08, 2011 8:27 AM > > To: neil.2.harrison@bt.com > > Cc: RCosta@ptinovacao.pt; David Allan I; stbryant@cisco.com; > > mpls@ietf.org; ietf@ietf.org; ietf-announce@ietf.org > > Subject: Re: [mpls] Last Call: > > (Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile) to Proposed Standard > > > > > > On Jul 8, 2011, at 3:15 AM, wrote: > > > > > Got to say I agree with Rui on much of what he says here. And I > > absolutely resonate with his point on the need for simplicity. The > > reason OAM needs to be as simple as possible is because it must be > > super reliable....we do not want to consciously build in weaknesses, > > esp unnecessary ones.... this also implies minimal config. We could > > all do better on this. For example: > > > > > > - Rui is dead right a CC function is fairly useless, we only > > need a CV function...the ATM OAM in I.610 suffers from this problem > > (and few others like AIS and the assumed use of request/response MLT > > to diagnose leaking/mismerging traffic...request/response OAM won't > > work with unidirectional defects). > > > > While you are entitled to your opinion, I personally think > > there are enough requirements elsewhere to have both CC and CV > > functions. But we digress. Are you actually asking that the CC > > functionality be removed from the draft or just making a general > > comment? > > > > > - all packet layer networks should not have an AIS OAM > > message....very obvious for the cl-ps mode of course. The co-ps mode > > is also not like the co-cs mode. One has to consciously manufacture > > AIS messages and target them to specific clients in the co-ps > > mode....who may have taken action in their own layer network and > > 'moved elsewhere' anyway, ie a total waste of time now. AIS is > > actually unnecessary wrt providing information anyway, it simply > > represents an in-built weakness of just something else to go wrong > > which itself will create problems. > > > > What does that comment have to do with the actual draft in > > question? > > > > > - creating preconfigured TCM sublayers is just asking for > > trouble IMO. It is far smarter to simply create a single end-end OAM > > CV (and when required PM) flow and tap this off at intermediate nodes > > on the *rare* occasions one wants to do. > > > > Again, what does this have to do with the actual draft in > > question? > > > > --tom > > > > > > > > > > > > > > regards, Neil > > > > > > This email contains BT information, which may be privileged or > > confidential. > > > It's meant only for the individual(s) or entity named above. If > > you're > > > not the intended recipient, note that disclosing, copying, > > > distributing or using this information is prohibited. If you've > > > received this email in error, please let me know immediately on the > > email address above. Thank you. > > > We monitor our email system, and may record your emails. > > > British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > > > England no: 1800000 > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf Of Rui Costa > > >> Sent: 08 July 2011 01:15 > > >> To: David Allan I; Stewart Bryant > > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > >> Subject: Re: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> David, > > >> > > >> Reading something, keeping it on record, without effect in the > > >> draft and "ignoring comments" have IMHO similar outcomes. As > author > > >> of the draft you are free to do it. These standards have a great > > >> impact in our work, so i'm also free to write what i did. > > >> > > >> > > >> > > >> > > >> Stewart, > > >> > > >> My technical concerns regarding this draft were expressed... > > >> ...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i > > >> believe); ...in operators' meetings' that took place during ITU- > T's > > >> Feb/2011 plenary meeting; ...in a comparison session that took > > >> place during that same ITU-T meeting. > > >> Some: > > >> > > >> CC/CV > > >> I don't understand the need for 2 types of packets: a single type > > >> allows CC; mismatching identifiers in the same CC packets allow > CV. > > >> Besides adding complexity, we whether always activate both or > > >> potentiate undetected mismerges. > > >> (BTW: can't understand how we propose one ACH codepoint to CC, > > >> another for CV, [counting other drafts, another for frame loss > ...] > > >> but don't consider assigning 1 single ACH protocol identifier > > >> codepoint as requested by ITU-T) > > >> > > >> Uni P2P / P2MP > > >> I can't see how BFD will support unidir and hence P2MP other > than... > > >> > > >> ...eliminating the session "state variable" (down, init, up), > > >> aiming just the state variables we really need, bringing us to > > >> something similar to 1731, eventually with other bits on the wire > or... > > >> ...using IP to create the reverse way, which we cannot assume per > > >> requirements; Will we create a complete different tool for that? > > >> (BFD's B=3D"bidirectional") > > >> > > >> Provisioning list > > >> This is an MPLS profile/subset (and i heard) achievable through a > > >> particular configuration. So, i expect each draft-ietf-mpls-TP-* > to > > >> focus on that profile/configuration. However, i keep seeing > > >> references f.i. to IP encapsulations unexpected under TP's OAM. > > >> I don't thus understand what the aim is: do we expect this in TP, > > are > > >> we talking about MPLS in general?... The TP profile is never quite > > >> delimited. > > >> Does chapter 4 contain ALL the configurable parameters list agreed > > to > > >> provide in the comparison session? > > >> > > >> Backwards compatibility > > >> This was the main argument risen to ground MPLS-TP OAM on BFD. > It's > > >> not a better argument than grounding MPLS-TP OAM on 1731 due to > its > > >> ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. > > >> For reasons like the above, however, MPLS-TP BFD won't be > backwards > > >> compatible with previous BFD (even considering just CC/CV). They > > >> don't even share the same codepoint. > > >> > > >> Simplicity > > >> Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is > > >> simpler: in each flow, a standard defined nr of constant heartbeat > > >> signals (with standard constant or provisioned period - no > > >> auto/negotiated -) means OK. A standard defined number of misses > > >> means lost Rx connection. An RDI, the only articulation between Rx > > >> and Tx flows, meaningful in bidirectional applications, allows > each > > >> pear to identify Tx problems. > > >> This OAM simplicity is the key for reliable fail finger pointing, > > >> performance reports and protection. Also to allow scaling, more > > >> implementation opportunities/manufacturers, which is valuable for > > >> operators. > > >> > > >> > > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and > > more > > >> difficult to tell which is which. > > >> > > >> Regards, > > >> Rui > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > > >> Sent: quarta-feira, 6 de Julho de 2011 19:25 > > >> To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF- > > >> Announce > > >> Cc: mpls@ietf.org > > >> Subject: RE: [mpls] R: Re: Last Call: > > >> (Proactive Connectivity > > >> Verification, Continuity Check and Remote Defect indication for > > >> MPLS Transport Profile) to Proposed Standard > > >> > > >> Hi Erminio: > > >> > > >> > > >>> Several service providers regarded this draft as not meeting > their > > >>> transport networks' needs. > > >> > > >> E> This is a true statement: the solution in this draft is useless > > >> E> for > > >> many MPLS- TP deployments. > > >> > > >> The two statements do not necessarily follow. > > >> > > >> What we established during discussions at the SG15 plenary in > > >> February was that the issue some service providers had was that > the > > >> IETF BFD solution exceeded their requirements in that there was > > >> additional functionality they did not see a need for, and that > they > > >> considered any additional functionality parasitic. > > >> > > >> However this is a consequence of adapting an existing technology > to > > a > > >> new application. I do not see any way around that. And the entire > > >> joint project was based on the premise of engineering re-use not > > >> greenfield design. That is what it said on the tin up front, and > > >> IMO why when the IETF started down this path packet transport > > >> transitioned from being a minority sport to mainstream, so it is a > > bit late to cry foul.... > > >> > > >> My 2 cents > > >> Dave > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > > >> Sent: quarta-feira, 6 de Julho de 2011 18:36 > > >> To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > >> Subject: RE: [mpls] R: Re: Last Call: > > >> (Proactive Connectivity > > >> Verification, Continuity Check and Remote Defect indication for > > >> MPLS Transport Profile) to Proposed Standard > > >> > > >> Hi Erminio: > > >> > > >> Two of the three document editors were present at SG15 plenary in > > >> February where the comments originated. The revised meeting > > >> schedule resulted in a day spent going through the document with > the editors. > > >> IMO there were lots of discussion and legitimate issues with the > > >> document identified and corrected so it was a useful session. The > > >> liaison of same was in many ways *after the fact*. > > >> > > >> Cheers > > >> Dave > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: erminio.ottone_69@libero.it > > >> [mailto:erminio.ottone_69@libero.it] > > >> Sent: quarta-feira, 6 de Julho de 2011 18:34 > > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > > >> Cc: mpls@ietf.org > > >> Subject: R: Re: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> The way this draft has been developed is a bit strange. > > >> > > >> The poll for its adoption as a WG document was halted by the MPLS > > >> WG chair because "it is not possible to judge consensus": > > >> > > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > > >> > > >> The lack of consensus was motivated by serious technical concerns > > >> raised by several transport experts during the poll. > > >> > > >> Nevertheless the MPLS WG chair decided to adopt the draft as a WG > > >> document: > > >> > > >> http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > > >> > > >> After several WG revisions and WG LCs, the technical issues have > > >> not been resolved. > > >> > > >>> Several service providers regarded this draft as not meeting > their > > >> transport > > >> networks' needs. > > >> > > >> This is a true statement: the solution in this draft is useless > for > > >> many MPLS- TP deployments. > > >> > > >> > > >> -----Original Message----- > > >> From: erminio.ottone_69@libero.it > > >> [mailto:erminio.ottone_69@libero.it] > > >> Sent: quarta-feira, 6 de Julho de 2011 18:26 > > >> To: loa@pi.nu; Rui Costa > > >> Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > >> Subject: R: Re: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >>> Version -04 of the document was published June 28th. > > >>> > > >>> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > >>> June 29th. > > >>> > > >> > > >> So when the WG LC to confirm the LC comment resolution has been > > >> launched? > > >> > > >> The proto write-up says: > > >> > > >> It has also passed a working roup call to verify that > LC > > >> comments were correctly with minor comments. > > >> > > >> It also says: > > >> > > >> The comments has been > > >> carefully discussed between the authors and people > > >> making the comments and > > >> has been resolved. > > >> > > >> But it seems that some comments have not been discussed with the > > >> authors of the comments. When ITU-T Q10/15 has been involved in > > >> discussing its comments? > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Loa Andersson [mailto:loa@pi.nu] > > >> Sent: quarta-feira, 6 de Julho de 2011 16:44 > > >> To: Rui Costa > > >> Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > >> Subject: Re: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> All, > > >> > > >> Since someone has commented about the process used for resolving > > >> questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some > > details > > >> below. > > >> > > >> The history of draft-ietf-mpls-tp-cc-cv-rdi working group review > > >> process is: > > >> > > >> On February 3rd 2011 the working group last call was issued on > > >> version -03 > > >> > > >> This was copied to the the Ad Hoc Team List > > >> and liaised to SG15 also on February 3rd > > >> > > >> This working group last call ended om Feb 28 > > >> > > >> > > >> On Feb 28 we also received a liaison with comments from SG15 > > >> > > >> > > >> The authors compiled a list of all comments received as part the > > >> MPLS working group last call; these comments - and the intended > > >> resolution > > >> - > > >> is included in the meeting minutes from the Prague meeting: > > >> > > >> > > >> http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > >> > > >> > > >> During the IETF meeting in Prague, we agreed with the BFD working > > >> group to do a separate working group last callfor the BFD working > > >> group > > >> > > >> The (BFD) working group last call was started on March 30th and > ran > > >> for 13 days. The last call ended on April 11th. > > >> > > >> The authors have since worked hard to resolve comments, some > > >> issue has been brought to the working group mailing list for > resolution. > > >> > > >> Version -04 of the document was published June 28th. > > >> > > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > >> June 29th. > > >> > > >> The AD review resulted in a "New ID needed" due to mostly > > >> editorial comments. Version -05 was published on June 29 and the > > >> IETF last > > call > > >> started as soon as the new ID was avaialbe. > > >> > > >> The current list of Last Call Comments resoltion is also avaiable > > at: > > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > >> > > >> The list of issues that the authors kept very carefully, shows > > >> without doubt that no comments been ignored. > > >> > > >> Loa > > >> mpls wg document shepherd > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: David Allan I [mailto:david.i.allan@ericsson.com] > > >> Sent: quarta-feira, 6 de Julho de 2011 14:58 > > >> To: Rui Costa; ietf@ietf.org; IETF-Announce > > >> Cc: mpls@ietf.org > > >> Subject: RE: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> Hi Rui: > > >> > > >> The comments were not ignored, the resolution of the Q10 comments > > >> as well as those collected from the MPLS WG was presented at the > > >> last IETF. My spreadsheet from which that report was generated and > > >> has been augmented to include the BFD WG comments is available at > > >> http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > >> > > >> So you know... > > >> Dave > > >> > > >> > > >> -----Original Message----- > > >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > > >> Behalf Of Rui Costa > > >> Sent: segunda-feira, 4 de Julho de 2011 23:03 > > >> To: ietf@ietf.org; IETF-Announce > > >> Cc: mpls@ietf.org > > >> Subject: RE: [mpls] Last Call: > > >> > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> IMHO and for the record: > > >> > > >> ITU-T comments regarding this draft haven't been discussed with > > >> ITU- > > T > > >> but were simply ignored. No LS describing these comments' > > >> resolution was sent. > > >> > > >> Several service providers regarded this draft as not meeting their > > >> transport networks' needs. > > >> > > >> [The v03 draft was published in Feb and went to WG LC. > > >> The v04 draft addressing WG LC comments was published on the 28th > > >> June (same date as the proto write-up). > > >> When was the WG LC launched, to verify LC comments resolution?] > > >> > > >> Regards, > > >> Rui > > >> > > >> > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf Of The IESG > > >> Sent: quinta-feira, 30 de Junho de 2011 14:47 > > >> To: IETF-Announce > > >> Cc: mpls@ietf.org > > >> Subject: [mpls] Last Call: > > >> (Proactive Connectivity Verification, Continuity Check and Remote > > >> Defect indication for MPLS Transport Profile) to Proposed Standard > > >> > > >> > > >> The IESG has received a request from the Multiprotocol Label > > >> Switching WG > > >> (mpls) to consider the following document: > > >> - 'Proactive Connectivity Verification, Continuity Check and > Remote > > >> Defect indication for MPLS Transport Profile' > > >> 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 2011-07-14. 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 > > >> > > >> Continuity Check, Proactive Connectivity Verification and Remote > > >> Defect Indication functionalities are required for MPLS-TP OAM. > > >> > > >> Continuity Check monitors the integrity of the continuity of the > > >> label switched path for any loss of continuity defect. > > Connectivity > > >> verification monitors the integrity of the routing of the label > > >> switched path between sink and source for any connectivity > issues. > > >> Remote defect indication enables an End Point to report, to its > > >> associated End Point, a fault or defect condition that it > detects > > on > > >> a pseudo wire, label switched path or Section. > > >> > > >> This document specifies methods for proactive continuity check, > > >> continuity verification, and remote defect indication for MPLS- > TP > > >> label switched paths, pseudo wires and Sections using > > Bidirectional > > >> Forwarding Detection. > > >> > > >> > > >> The file can be obtained via > > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >> > > >> IESG discussion can be tracked via > > >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >> > > >> > > >> No IPR declarations have been submitted directly on this I-D. > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > >> > > >> > > >> _______________________________________________ > > >> Ietf mailing list > > >> Ietf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ietf > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > From swallow@cisco.com Fri Jul 8 12:47:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80C821F8B6B for ; Fri, 8 Jul 2011 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-2.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eIMbJHkZs6N for ; Fri, 8 Jul 2011 12:47:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3421F8B70 for ; Fri, 8 Jul 2011 12:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=15940; q=dns/txt; s=iport; t=1310154460; x=1311364060; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=Tz29VWNIcVj2hbDAMiRBTns/XOX9jalL6xWhTF34IwA=; b=K/WU1jgaJ1L/iMl8PyRPUFpWHvkDg93aK/Bvk7OyVHrfhWN5HB1RoEIO +s8Fvi+69YlPiem7ilSAj0Gxrt95k+/5f30k3GS9j5Df45kzcZNVb6FNx 4ZodI2icJhGL6CRUR21j21tnkLCu2gy74Gi33UDlDv0AVTSwcwyRCFyru E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAGZeF06tJV2b/2dsb2JhbABUglGVSY5TZHeIe6MInVkChjYEhx2JJYIKhQaLWg X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208,217";a="1168139" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2011 19:47:39 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68Jldto014371; Fri, 8 Jul 2011 19:47:39 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 14:47:39 -0500 Received: from 10.86.244.217 ([10.86.244.217]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jul 2011 19:47:38 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 08 Jul 2011 15:47:37 -0400 From: George Swallow To: Alexander Vainshtein , Loa Andersson Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3392984857_161861404" X-OriginalArrivalTime: 08 Jul 2011 19:47:39.0167 (UTC) FILETIME=[E4A3BAF0:01CC3DA7] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 19:47:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392984857_161861404 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sasha - On 3/1/11 7:36 AM, "Alexander Vainshtein" wrote: > Loa, and all, > I have two LC comments on the draft. in question. They both refer to issu= es > I've raised in private discussions with George and Matthew and which, to = the > best of my understanding, have not been resolved in the -03 version. >=20 > My first issue deals with potential dangers of sending fault OAM messages= in > conjunction with certain protection mechanisms. >=20 > The example I've presented to George and Matthew deals with the situatio= n > when the LSP in question employs Facility FRR for node protection. >=20 > The topology is shown below: >=20 >=20 > |------| |-----| |-----| |-----| |-----| > | A |<--->| B |<--->| C |<--->| D |<--->| E | > |------| |-----| |-----| |-----| |-----| > \ / > \ / > \ / > \ / > \ / > \ / > \ |------| / > \| C' |/ > |------| >=20 > The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs i= n the > rest of the nodes. > If the link BC is broken, the link-level MEP at C detects that and initia= tes > (I'll skip the details) insertion of AIS (with LDI flag set after some > stabilization) into the LSP. These AIS/LDI packets will be captured by th= e LSP > MEP in D. >=20 I believe you mean E here. >=20 > Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this= LSP, > starting at B and terminated at D, D would be the merge point. Note that = C > would not be aware of this action, and D would not aware of AIS insertion > undertaken by C. > As a consequence, E would receive both AIS/LDI generated by C and valid > traffic coming thru bypass. >=20 The current draft is limited to the operation of PWs, bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is the current scope of MPLS-TP. The draft states that action based on the receipt of an LDI flag is optional. In this situation you would clearly want to ignore the flag. The only other affect is to suppress alarms. But as there is no alarm to suppress, that will have no effect. >=20 > This is definitely not healthy, and the draft does not define any ways to > avoid that. >=20 If you would like to begin a draft on applying AIS to other types of LSPs, that would be much appreciated. >=20 > The text in the draft that deals with protection seems to refer to link > protection rather than to LSP protection. >=20 I agree that that is not clear. I=B9ve updated section 2 para 3 with, =B3When a server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP fails,....=B2 >=20 > IMHO the same problem would appear in the case of segment protection if a= link > in the middle of a segment is broken, so this issue is not limited just t= o > FRR. >=20 > My second issue deals with association between links and LSPs that pass t= hru > these links. Ability to insert Fault OAM messages into all the LSPs cross= ing a > certain link may be compromised IMHO in the case LSPs that use labels fro= m the > per-platform space. It is not clear from the draft how the LSR that has > detected a link failure could decide whether Fault OAM messages should be > inserted in a transit LSP (which it perceives as an ILM table entry) or n= ot - > because the actual LSP could be running thru a different link. The proble= m > would presumably disappear if per-interface label space were used; but RF= C > 5960 does not restrict MPLS-TP from using per-platform label space. >=20 The issue is not per platform labels per se, but to the binding of PWs and LSPs to specific links (which includes hierarchical LSPs). I=B9ve updated section 2 para 3 with =B3Fault OAM messages are generated by intermediate nodes where a bidir-LSP is switched and bound to specific server layers based upon static configuration or signaling. ...George=20 >=20 > I apologize for sending these comments so late in the LC. >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behal= f Of > Loa Andersson > Sent: Thursday, February 03, 2011 1:37 PM > To: mpls-tp@ietf.org; mpls@ietf.org > Cc: ahmpls-tp@lists.itu.int > Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 >=20 > Working Group, >=20 > this is to start a four week working group last call > on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs >=20 > -- >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 --B_3392984857_161861404 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:

<= SPAN STYLE=3D'font-size:10pt'>Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situa= tion when the LSP in question employs Facility FRR for node protection.

The topology is shown below:


|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
|  A   |<--->|  B  |<--->|  C &nb= sp;|<--->|  D  |<--->|  E  |
|------|     |-----|     |-----| &n= bsp;   |-----|     |-----|
            &nb= sp;   \          = ;            /             &nb= sp;    \         = ;           /
            &nb= sp;     \        = ;          /
            &nb= sp;      \       = ;         /
            &nb= sp;       \      = ;        /
            &nb= sp;        \     = ;       /
            &nb= sp;         \ |------| /
            &nb= sp;          \|  &nbs= p;C' |/
            &nb= sp;           |------= |

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D &= nbsp;and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiate= s (I'll skip the details) insertion of AIS (with LDI flag set after some sta= bilization) into the LSP. These AIS/LDI packets will be captured by the LSP = MEP in D.

= I believe you mean E here= .

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for = this LSP, starting at B and terminated at D, D would be the merge point. Not= e that C would not be aware of this action, and D would not aware of AIS ins= ertion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid tra= ffic coming thru bypass.

= The current draft is limi= ted to the operation of PWs, bi-directional LSPs and sections and LSP 1:1 an= d 1+1 protection as that is the current scope of MPLS-TP.  The draft &n= bsp;states that action based on the receipt of an LDI flag is optional. &nbs= p;In this situation you would clearly want to ignore the flag.  The onl= y other affect is to suppress alarms.  But as there is no alarm to supp= ress, that will have no effect.

This is definitely not healthy, and the draft does not define any ways to a= void that.

= If you would like to begi= n a draft on applying AIS to other types of LSPs, that would be much appreci= ated.

The text in the draft that deals with protection seems to refer to link pro= tection rather than to LSP protection.

= I agree that that is not= clear.  I’ve updated section 2 para 3 with, “When a server= layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP fails,....&= #8221;

IMHO the same problem would appear in the case of segment protection if a l= ink in the middle of a segment is broken, so this issue is not limited just = to FRR.

My second issue deals with association between links and LSPs that pass thr= u these links. Ability to insert Fault OAM messages into all the LSPs crossi= ng a certain link may be compromised IMHO in the case LSPs that use labels f= rom the per-platform space. It is not clear from the draft how the LSR that = has detected a link failure could decide whether Fault OAM messages should b= e inserted in a transit LSP (which it perceives as an ILM table entry) or no= t - because the actual LSP could be running thru a different link. The probl= em would presumably disappear if per-interface label space were used; but RF= C 5960 does not restrict MPLS-TP from using per-platform label space.

= The issue is not per plat= form labels per se, but to the binding of PWs and LSPs to specific links (wh= ich includes hierarchical LSPs).  I’ve updated section 2 para 3 w= ith “Fault OAM messages are generated by intermediate nodes where a bi= dir-LSP is switched and bound to specific server layers based upon static co= nfiguration or signaling.

...George

I apologize for sending these comments so late in the LC.

Regards,
     Sasha

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] O= n Behalf Of Loa Andersson
Sent: Thursday, February 03, 2011 1:37 PM
To: mpls-tp@ietf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

this is to start a four week working group last call
on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).

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

This working group last call ends on February 28, 2011.



Loa, George and Ross

MPLS wg co-chairs

--

Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.co= m
Sr Strategy and Standards Manager        = ;    loa@pi.nu
Ericsson Inc           &n= bsp;            =   phone: +46 10 717 52 13
            &nb= sp;            &= nbsp;            = ;        +46 767 72 92 13



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

--B_3392984857_161861404-- From internet-drafts@ietf.org Mon Jul 11 02:42:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF35021F855D; Mon, 11 Jul 2011 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3wE-GFw3s43; Mon, 11 Jul 2011 02:42:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6E21F858A; Mon, 11 Jul 2011 02:42:15 -0700 (PDT) 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.55 Message-ID: <20110711094215.20129.14075.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 02:42:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:42:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen So Ning Filename : draft-ietf-mpls-return-path-specified-lsp-ping-03.txt Pages : 22 Date : 2011-07-11 This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for= the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-l= sp-ping-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-mpls-return-path-specified-ls= p-ping-03.txt From internet-drafts@ietf.org Mon Jul 11 10:20:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA1E11E8124; Mon, 11 Jul 2011 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVH7xoNh61f5; Mon, 11 Jul 2011 10:20:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD211E8121; Mon, 11 Jul 2011 10:20:28 -0700 (PDT) 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.55 Message-ID: <20110711172028.4572.63103.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 10:20:28 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 17:20:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Configuration of Pro-Active Operations, Administration, = and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP= Ping Author(s) : Elisa Bellagamba Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02.txt Pages : 21 Date : 2011-07-11 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP Ping protocol This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-02.txt From swallow@cisco.com Mon Jul 11 13:49:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F8711E80F4 for ; Mon, 11 Jul 2011 13:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.017 X-Spam-Level: X-Spam-Status: No, score=-104.017 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRaCCVLlRH6N for ; Mon, 11 Jul 2011 13:49:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E2A0811E80D1 for ; Mon, 11 Jul 2011 13:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=4391; q=dns/txt; s=iport; t=1310417350; x=1311626950; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=6kbmPmf1LZa9sK7KB54grIYxC24lV+qdobt0glu8eVg=; b=Rsv1jXmkB/wuw4CEAE8bDv5xtxT/Q2HfLxrtJJBto5szto7lKJ9Ntrtv h5cnwHZVneo+aNSNagaNghxONMlOFAFC1IUzpwPlexpllKK6N7F4cQF+f ObAG4SeVfNZREJVL7K7E7U42yRFRWIzZ1jizEcU2b07uExUreunAJUMBx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP9gG06tJV2Y/2dsb2JhbABTpyN3iHqiDZ4UAoY4BJJWhQeLXA X-IronPort-AV: E=Sophos;i="4.65,517,1304294400"; d="scan'208";a="1861763" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2011 20:49:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6BKn9Fo026971; Mon, 11 Jul 2011 20:49:09 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 15:49:09 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jul 2011 20:49:09 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 11 Jul 2011 16:49:06 -0400 From: George Swallow To: Yuji Tochio , "mpls@ietf.org" Message-ID: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcxAC/ln2LzA/rr6S0uftRMSJ/FBww== In-Reply-To: <4D6B8010.6000002@jp.fujitsu.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jul 2011 20:49:09.0264 (UTC) FILETIME=[FB591900:01CC400B] Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:49:11 -0000 Yugi - Thanks for the comments. See inline On 2/28/11 5:59 AM, "Yuji Tochio" wrote: > Hi, > > Some comments > > * Section 2.1 (, 2.1.1) > There are some use of fatal. Please clarify what fatal means. > And it is better to have the definition of this both for AIS > and for LDI fault is defined in the document - changed all occurrances of fatal to fault > * Section 2.1.1 > Use of protection seems to relate to the usage for LDI, differentiated > from AIS. > And "The setting of the LDI flag can be predetermined based > on the protection state If the Server Layer is protected...."means > that there is server layer protection scheme and this prederminnes > the usage of LDI. > This server layer protection scheme should be more clarified. > Is the server layer supposed to have 1:1? > How about 1+1? Either form of protection is fine. But, I don't think this needs to be called out in the draft. > And active MEP should be active Server MEP Fixed. > This had been already pointed out in general by > http://www.ietf.org/mail-archive/web/mpls-tp/current/msg02793.html > (last part in that mail) > > * Section 4 > Please clarify the reception behavior when > - Msg type= reserved added message type = reserved as a condition for dropping > - Msg type = LCK & L-flag set > (should be ignored and this should be described in 5.3) updated description of L-flag with "The L-flag only has significance in the AIS message. For the LKR message the L-flag MUST be set to zero and ignored on receipt." > * Section 5.1 > Following sentence is unclear > "The message MUST be refreshed two more times at an interval > of one second." > I guess this implies that messages should be more than specified > at first second. Is this right? Does this apply to refresh timer is 1? updated beginning of sentence, "Assuming the condition persists, the message MUST be retransmitted" > And in early review from ITU-T, it is proposed to remove the refresh timer > but it still remains. It is better to have the clear reason why it is needed. Y.1731 allows for 1 sec or 1 minute refreshed. The point is that the messaging can be expensive on some existing platforms. > Section 5.3 > It says: > A message is considered a refresh if the message type and IF_ID match > an existing condition and the R-Flag is set to zero. > > How about this case? > A-->B-->C-->D > D is receiving AIS or LDI with IF_ID = B. But another failure at C > happens D starts to receive LDI with IF_ID = C. > In this case, does D have to have two timers for B and C This is an implementation issue. If an operator has configured nodes with varying refresh timers, then to be completely safe about alarm suppression I would say the answer is yes. But if the fault at C persists you will not see the AISes from B and that could time-out anyway. So you could have the same issue with a gap in alarm suppression. Note that this issue also exists in Y.1731 as well. > ...And it is confused that is "refresh(ed)" > It seems that following cases are used in common, but different places > - the receiver, MEP that refresh timer is in for reception process > - the transmitter (as fault detection by refresh timer) > - the transmitter (as message generation makes format refresh by over-written) Rewrote much of this section. Hope you like the new text better. ...George > Regards, > Yuji > > (2011/02/03 20:36), Loa Andersson wrote: >> Working Group, >> >> this is to start a four week working group last call >> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). >> >> Please send comments to the mpls-tp@ietf.org mailing list. >> >> This working group last call ends on February 28, 2011. >> >> >> >> Loa, George and Ross >> >> MPLS wg co-chairs >> >> -- >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From internet-drafts@ietf.org Mon Jul 11 15:08:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5A511E82F2; Mon, 11 Jul 2011 15:08:36 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2Q52KavxCbO; Mon, 11 Jul 2011 15:08:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78811E82EB; Mon, 11 Jul 2011 15:08:35 -0700 (PDT) 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.55 Message-ID: <20110711220835.20262.42580.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:08:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:08:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Fault Management OAM Author(s) : George Swallow Annamaria Fulignoli Martin Vigoureux Sami Boutros David Ward Filename : draft-ietf-mpls-tp-fault-05.txt Pages : 15 Date : 2011-07-11 This draft specifies OAM messages to indicate service disruptive conditions for MPLS based Transport Network Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-05.txt From Rolf.Winter@neclab.eu Tue Jul 12 00:14:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7484321F8BE6 for ; Tue, 12 Jul 2011 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qSd+sJs2tEe for ; Tue, 12 Jul 2011 00:14:46 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BD71921F8BD9 for ; Tue, 12 Jul 2011 00:14:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C0C2228000301 for ; Tue, 12 Jul 2011 09:14:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFN6JTxc8uAu for ; Tue, 12 Jul 2011 09:14:42 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A411628000174 for ; Tue, 12 Jul 2011 09:14:37 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 09:14:37 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: new I-D on MPLS-TP IDs following ITU-T conventions Thread-Index: AcxAY1r5QTUF06iaQDu5Z59aCRuomA== Date: Tue, 12 Jul 2011 07:14:36 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFC4512@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] new I-D on MPLS-TP IDs following ITU-T conventions X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:14:47 -0000 Hi, we have submitted a draft (http://tools.ietf.org/html/draft-win-mpls-tp-itu= -t-identifiers-01) that basically contains the former content (different wo= rds, roughly same meaning) of the MPLS-TP identifiers draft that describes = the ITU-T-based IDs and which fixes the issues that the list discussed prev= iously. It is not done yet but a good basis we believe to be taken on board= as a WG item. Feedback very much appreciated. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Tue Jul 12 00:28:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89AD21F9029 for ; Tue, 12 Jul 2011 00:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VMdS4RkykyT for ; Tue, 12 Jul 2011 00:28:25 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1E65121F9027 for ; Tue, 12 Jul 2011 00:28:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7195B28000305 for ; Tue, 12 Jul 2011 09:28:19 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie93gWtCe9aX for ; Tue, 12 Jul 2011 09:28:19 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5622528000174 for ; Tue, 12 Jul 2011 09:28:14 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 09:28:14 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: new version of the per-interface MIP draft Thread-Index: AcxAZUHe1PZf+IEdRiimifl0q6Q95Q== Date: Tue, 12 Jul 2011 07:28:13 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFC4580@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] new version of the per-interface MIP draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:28:25 -0000 Hi WG, we have submitted a new version of the per-interface MIP draft (http://tool= s.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04). In this new version t= hings have changed significantly based on your valuable feedback. We would = very much appreciate more feedback on this new version of the document. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From binnyjeshan@gmail.com Tue Jul 12 00:45:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B76521F90D2 for ; Tue, 12 Jul 2011 00:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy4vhSP5yAnk for ; Tue, 12 Jul 2011 00:45:47 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74CA021F90D5 for ; Tue, 12 Jul 2011 00:45:47 -0700 (PDT) Received: by ewy19 with SMTP id 19so1890360ewy.31 for ; Tue, 12 Jul 2011 00:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0KIcoKV0tNt7VgWP0oARJdYt6maCNFGWAJgiFU3zACI=; b=UVW5AvZ45M9OsNDr1WzefEkx/+Kv8SJdD3Lf6VHDuSb7GHtiZFgl0zdV7OgHv0umQ6 jabaLx0vWUvCy7YxE8n3nK75mihTDPji4YYgsgQN7bWznWnSSWg6jAUh7QtRhHzY1AXP dOvBVVo4lb6wZgJ0pjsiZTy5+5hduCceJ2tO4= MIME-Version: 1.0 Received: by 10.14.94.201 with SMTP id n49mr1633652eef.12.1310456746138; Tue, 12 Jul 2011 00:45:46 -0700 (PDT) Received: by 10.14.119.1 with HTTP; Tue, 12 Jul 2011 00:45:46 -0700 (PDT) Date: Tue, 12 Jul 2011 13:15:46 +0530 Message-ID: From: binny jeshan To: mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec52155a5d8dc1804a7da7c6c Cc: MPLS-TP ad hoc team , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" , Ross Callon Subject: [mpls] Need clarification on draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:45:48 -0000 --bcaec52155a5d8dc1804a7da7c6c Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, In the new draft version 05, in section 2.3.2 (Static Pseudowire Sub-TLV), AGI is not made up in a TLV format (when comparing RFC 4446 section 3.4; RFC 4447 Section 5.3.2). I had raised this question during the review, but i am not understanding the reason behind why this is still not built in as a TLV, but 'always' a 2 word format (a normal 7byte+1pad L2VPN ID). Kindly clarify Thanks for the time, Binny. On 17 June 2011 11:34, binny jeshan wrote: > Hello, > > In this new draft version section 2.3.2., where the AGI field is newly > added, my question is - shouldn't the AGI Type and Length also be included > in the FEC TLV structure? > > Also, wouldn't it be clear if the usage of EXP bits in (PHB consideration) > is also explicitly defined somewhere around the responder procedures? > > Thanks, > Binny. > > > On 17 June 2011 01:30, Loa Andersson wrote: > >> Working Group. >> >> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID >> after wg last call and published version -04 of the document. >> >> A document detailing how the comments have been addressed will be >> found at: >> http://www.pi.nu/~loa/comments-on-03.xls >> >> This is to start a working group call to verify that all comments >> been adequately addressed. Please send your comments to the >> mpls working group mailing list before June 24th. >> >> Loa >> on behalf of the MPLS wg co-chairs >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --bcaec52155a5d8dc1804a7da7c6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,

In the new draft version 05, in section 2.3.2 (Static = Pseudowire Sub-TLV), AGI is not made up in a TLV format (when comparing RFC= 4446 section 3.4; RFC 4447 Section 5.3.2).

I had raised this quest= ion during the review, but i am not understanding the reason behind why thi= s is still not built in as a TLV, but 'always' a 2 word format (a n= ormal 7byte+1pad L2VPN ID).

Kindly clarify

Thanks for the time,
Binny.

On 17 June 2011 11:34, binny jeshan <= binnyjeshan@gmail.com> wrote:
Hello,

In this new draft version sec= tion 2.3.2., where the AGI field is newly added, my question is - shouldn&#= 39;t the AGI Type and Length also be included in the FEC TLV structure?

Also, wouldn't it be clear if the usage of EXP bits in (PHB conside= ration) is also explicitly defined somewhere around the responder procedure= s?

Thanks,
Binny.


On 17 June 2011 01:30, Loa An= dersson <loa@pi.nu> wrote:
Working Group.

the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
after wg last call and published version -04 of the document.

A document detailing how the comments have been addressed will be
found at:
ht= tp://www.pi.nu/~loa/comments-on-03.xls

This is to start a working group call to verify that all comments
been adequately addressed. Please send your comments to the
mpls working group mailing list before June 24th.

Loa
on behalf of the MPLS wg co-chairs

--


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


--bcaec52155a5d8dc1804a7da7c6c-- From c-sai@bx.jp.nec.com Tue Jul 12 02:20:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BDA21F911B for ; Tue, 12 Jul 2011 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYrq7UqNH7pm for ; Tue, 12 Jul 2011 02:20:16 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 294E421F910C for ; Tue, 12 Jul 2011 02:20:15 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6C9KCik007323; Tue, 12 Jul 2011 18:20:13 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6C9KCj25738; Tue, 12 Jul 2011 18:20:12 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6C9JtOC017088; Tue, 12 Jul 2011 18:20:11 +0900 (JST) Received: from monta.jp.nec.com ([10.26.220.14] [10.26.220.14]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-47772; Tue, 12 Jul 2011 18:19:48 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTP; Tue, 12 Jul 2011 18:19:47 +0900 From: "Zhenlong Cui" To: , References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> Date: Tue, 12 Jul 2011 18:19:47 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> thread-index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZCAF28eAA== Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 09:20:17 -0000 Dear Authors, Two questions regarding the idenfifiers TLV and DSMAP TLV. Question 1: > > > Which return code to send when identifiers are wrong (Malformed echo > > > request received?) or drop the packet. > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > EG > screaming into the night. What does one do when one gets > > > EG > something either not recognizably intended for one, or not > > > EG > from a source that one recognizes? From a security point > > > EG > of view, we cannot require an implementation to reply to > > > EG > the requester in this case (this is an attack vector for > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One or more of the TLVs was not understood)? Can this way two answers be generated? Question 2: In section 2.1.1, Is below("ingress port") correct? Egress IF_Num identifies the ingress port on the target node. A value of 0 indicates that the port is not part of the identifier. Best, zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > Sent: Monday, June 27, 2011 8:04 PM > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > > Types are defined below; Length is the length of the Value field in > octets. The Value field depends on the Type; it is zero padded to > align to a 4-octet boundary. > > That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is determined > by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your argument > why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information is > encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure of > each TLV to extract the value instead of applying the simple rule above. > > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Montag, 27. Juni 2011 12:42 > > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > cv@tools.ietf.org > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > > > IMO, that would be a problem with RFC 4379. Perhaps there is > > an errata? > > > > TLVs are meant to follow each other, where the beginning of the > > next TLV is determined by the length of the current TLV - hence > > it is not correct to specify any content as having any value at > > all if it is beyond the end of the TLV. > > > > -----Original Message----- > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > Sent: Monday, June 27, 2011 5:06 AM > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > cv@tools.ietf.org > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > Importance: High > > > > Hi Eric, > > > > just one more to follow up. You say: > > > > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > EG > even if the last two octets "Must be Zero"). The length of > > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > EG > longer by the addition of the 2-word AGI. Nice catch! > > > > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > included in the length of the sub-TLVs. Why are they included here? > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > EG > Apparently. > > > > > > Which return code to send when identifiers are wrong (Malformed echo > > > request received?) or drop the packet. > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > EG > screaming into the night. What does one do when one gets > > > EG > something either not recognizably intended for one, or not > > > EG > from a source that one recognizes? From a security point > > > EG > of view, we cannot require an implementation to reply to > > > EG > the requester in this case (this is an attack vector for > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > > Using the per-interface model and say the DSMAP TLV did not match the > > > ingress IF identifier, then should this request frame be dropped? > > > Should we reply to the requestor? Can this way two answers be > > > generated? > > > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > > > EG > Thanks. > > > > > > > > > Best, > > > > > > > > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > Of > > > > Loa Andersson > > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > > Ross > > > > Callon; George Swallow; MPLS-TP ad hoc team > > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > > > > > > > Working Group. > > > > > > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > > > after wg last call and published version -04 of the document. > > > > > > > > A document detailing how the comments have been addressed will be > > > > found at: > > > > http://www.pi.nu/~loa/comments-on-03.xls > > > > > > > > This is to start a working group call to verify that all comments > > > > been adequately addressed. Please send your comments to the > > > > mpls working group mailing list before June 24th. > > > > > > > > Loa > > > > on behalf of the MPLS wg co-chairs > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From maciek@juniper.net Tue Jul 12 06:21:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B921F8C31 for ; Tue, 12 Jul 2011 06:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeiUVr73Be4M for ; Tue, 12 Jul 2011 06:21:17 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 728A721F8C50 for ; Tue, 12 Jul 2011 06:21:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKThxKQL8rTFNWS7u4Nd6WnNvo9KAIeoAy@postini.com; Tue, 12 Jul 2011 06:21:16 PDT Received: from jwhyte-sslvpn-nc.jnpr.net (172.26.205.41) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 06:16:23 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Maciek Konstantynowicz In-Reply-To: <23532.1309359379@erosen-linux> Date: Tue, 12 Jul 2011 14:16:19 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> References: <23532.1309359379@erosen-linux> To: X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org Subject: Re: [mpls] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 13:21:17 -0000 Eric, Regarding your question about handling unreachable FEC becoming = reachable again:- We wrote a separate draft with a detailed description of LDP DoD = behaviours in the context of Seamless MPLS http://tools.ietf.org/html/draft-beckhaus-ldp-dod-00 In this draft, #section-4.4.3 describes the behaviour in case specific = requested FEC is unreachable: 4.4.3. Label Request Retry Procedure If AN or AGN receives a "No route" Notification in response to its label request message, it should retry with exponential backoff algorithm similar to the backoff algoritm mentioned in the LDP session negotiation section 4.3. ... AN should follow the exponential backoff algorithm as specified in the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays grow to a maximum delay of 2 minutes. Maciek On 29 Jun 2011, at 15:56, Eric Rosen wrote: >=20 >> For a more long term approach we are in favour of a change to RFC5036 = by >> defining a new TLV which denotes the DU/DoD mode per FEC type. >=20 > Does that mean you expect every FEC type to be able to work in both = modes? > If you only anticipate needing DoD for address prefix FECs, a more > conservative solution might be to just clarify that the negotiated = session > mode applies only to address prefix FECs. >=20 > While on the topic, I do have a question about the use of DoD for = address > prefix FECs. >=20 > =46rom draft-leymann-mpls-seamless-mpls-03: >=20 > the AN will use LDP DoD to only request the label bindings > for the FECs corresponding to the loopback addresses of those egress > nodes to which it has services configured. >=20 > Suppose one of the configured egress nodes is down or otherwise = unreachable > at the time the AN asks for a label binding. How does the AN get the = label > binding when the egress node becomes reachable? Is the AN expected to = ask > periodically for the binding? Is the periodic interval expected to be > configurable? The draft should say something about this. >=20 > I don't think RFC 5036 requires the AGN to remember what the AN has = asked > for, so that it can reply when and if the egress becomes reachable. >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Tue Jul 12 07:41:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18C21F8C69 for ; Tue, 12 Jul 2011 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyY4Q6tLm1sc for ; Tue, 12 Jul 2011 07:41:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF421F8C52 for ; Tue, 12 Jul 2011 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=2140; q=dns/txt; s=iport; t=1310481700; x=1311691300; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=tr2W18rZeJ5n+Wo+6itaCv6A2JAJS08xgtT/k4A+06E=; b=NbD0Qh3QTgr26xF6RPpKpQGDk6lei7AfQ1Yall8pAkGrOR6BehmgzDCZ k8UQqTUIKVlINwGK8poSO7Kon/k9eSypT4qG8dOy6Z6jqdUjXqTpfy0uC 7E7Z2qp5zaUKtff4NUiAiV/gkrMF2lTKQohp6CjHk8zGlk3xi/LlSBLNS g=; X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="2153053" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 14:41:39 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6CEfddv011828; Tue, 12 Jul 2011 14:41:39 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p6CEfbod014369; Tue, 12 Jul 2011 10:41:37 -0400 To: Maciek Konstantynowicz In-reply-to: Your message of Tue, 12 Jul 2011 14:16:19 +0100. <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> Date: Tue, 12 Jul 2011 10:41:37 -0400 Message-ID: <14368.1310481697@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [mpls] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:41:40 -0000 > 4.4.3. Label Request Retry Procedure > If AN or AGN receives a "No route" Notification in response to its > label request message, it should retry with exponential backoff > algorithm similar to the backoff algoritm mentioned in the LDP > session negotiation section 4.3. If AN1 has a label for AN2, and AN2 goes down, this means that AN1 may not get a new label for AN2 until two minutes after AN1 comes back up. Is that considered acceptable? A different approach would be for AN1 to provide the AGN with a list of prefixes for which it needs a label, and then to use the DU procedures, applied to those specified prefixes only. That would meet the goal of keeping unnecessary labels out of AN1, while maintaining the faster responsiveness of the DU procedures. I understand that you don't want to configure the AGN with the set of prefixes for which the AN needs labels, but the AN could pass this information dynamically in an "outbound label filter". Was this approach considered? > ... > AN should follow the exponential backoff algorithm as specified in > the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays > grow to a maximum delay of 2 minutes. I'm not sure I understand the reference to "exponential backoff algorithm as specified in RFC5036". Let me ask a couple of other questions about draft-beckhaus-ldp-dod. Section 4.1: "For the LDP DoD Advertisement mode on AN an ordered label distribution mode and conservative label retention mode MUST be supported." The ordered/independent distinction only applies when you need to send a label that is bound to a prefix for which you are not the LSP egress. Does this even apply to an AN? Why do the ANs need to support conservative label retention mode? If an AN is homed to a pair of AGNs, what's wrong with it requesting a label from each one? "The DoD mode is explicitly mentioned in the description of the conservative mode in RFC5036" That's because conservative mode doesn't make much sense unless you are also using DoD mode. The converse is not necessarily true. From rcallon@juniper.net Tue Jul 12 08:34:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34BB21F8F0B for ; Tue, 12 Jul 2011 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGTmzI5yYBfQ for ; Tue, 12 Jul 2011 08:34:11 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC621F8E8A for ; Tue, 12 Jul 2011 08:34:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKThxpZ8bpxR2r/pfaNGGSjPjWtsXXmKNF@postini.com; Tue, 12 Jul 2011 08:34:10 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 08:31:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 12 Jul 2011 11:31:48 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 12 Jul 2011 11:31:46 -0400 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C29F817E0BEMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 15:34:12 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C29F817E0BEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_DF7F294AF4153D498141CBEFADB17704C29F817E0BEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please <= /div>
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document <= /div>
please respond to this poll with "no/do not support" and at = the same time
give the technical reasons why you are not supporting the document.
 
If you have technical comments or in any other way want to discuss the=
document, please send these comments to the mpls working group mailing=
list, but with another subject than what is on this mail. Please inclu= de the
string “draft-win-mpls-tp-itu-t-identifiers” in the subjec= t line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday be= fore the
IETF. Also note that the length of the poll has  been shortened b= y two days
so that the poll can be completed prior to our first WG meeting in Que= bec City. 
 
Ross
 
 --_000_DF7F294AF4153D498141CBEFADB17704C29F817E0BEMBX01WFjnprn_-- From hongk@cisco.com Tue Jul 12 09:01:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C839F21F8F31 for ; Tue, 12 Jul 2011 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrMhwr1UcXgq for ; Tue, 12 Jul 2011 09:01:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 856B721F8F1F for ; Tue, 12 Jul 2011 09:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=12812; q=dns/txt; s=iport; t=1310486485; x=1311696085; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=H3mwOQfWhLaNfHOiox5O1ooaSasP/nlHnkzHd8egGn4=; b=FR1/4NQnW6SEYWwok3OLZaiL06da/9vkwq/3JD5EiNI7KM1REzupPR2/ xzwr2mtxx7Umit/VbK+h8zlj9huwBWrwbvaIcmRu7WQCm3cJ74NXxPQYQ lQ9qdYhCukCTBseAzwyKfLOVd9gB/2luvwAVYhXT595PbA0FZo4VLt4j5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAOtuHE6tJXG//2dsb2JhbABTglOVIY88d60Anh6FW18Eh1GQE4th X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208,217";a="2193275" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jul 2011 16:01:25 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6CG1O6U023897; Tue, 12 Jul 2011 16:01:24 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 11:01:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC40AC.F355D93C" Date: Tue, 12 Jul 2011 11:01:21 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC047E7FF8@XMB-RCD-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 thread-index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAAqtTg References: From: "Kyung-Yeop Hong (hongk)" To: "Ross Callon" , X-OriginalArrivalTime: 12 Jul 2011 16:01:24.0497 (UTC) FILETIME=[F3287810:01CC40AC] Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:01:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC40AC.F355D93C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No / Do not support. =20 Section 5 proposes a 13 characters long MEG ID format: ICC (1-6 characters) plus "/" (1 character) plus CC (2 characters) plus UMC (4-9 characters). =20 The UMC is limited to 4 characters if 6 characters are used for the ICC. The UMC is a unique operators' code and defined by their name plan which can be based on their geographical area and transmission detail information. In other Recommendations (e.g. G.709) defining ICC-based format, minimum 6 or 7 characters are allocated for unique operators' code. =20 In order to allow operators for future growth of their networks and to maintain their name plan consistent with other Recommendations and existing deployments, the UMC must not be limited to 4 characters. =20 KY =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, July 12, 2011 11:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same time=20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include the=20 string "draft-win-mpls-tp-itu-t-identifiers" in the subject line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before the=20 IETF. Also note that the length of the poll has been shortened by two days=20 so that the poll can be completed prior to our first WG meeting in Quebec City. =20 =20 Ross =20 ------_=_NextPart_001_01CC40AC.F355D93C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No / Do not support.

 

Section 5 proposes a 13 characters long MEG ID = format:

ICC (1-6 characters) plus "/" (1 character) = plus CC (2 characters) plus UMC (4-9 characters).

 

The UMC is limited to 4 characters if 6 characters are = used for the ICC. The UMC is a unique operators' code and defined by their name = plan which can be based on their geographical area and transmission detail information. In other Recommendations (e.g. G.709) defining ICC-based = format, minimum 6 or 7 characters are allocated for unique operators' = code.

 

In order to allow operators for future growth of their = networks and to maintain their name plan consistent with other Recommendations = and existing deployments, the UMC must not be limited to 4 = characters.

 

KY

 

 

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: Tuesday, July 12, 2011 11:32 AM
To: mpls@ietf.org
Cc: Ross Callon; = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

 

Working Group,

 =

this is to start a 12 day poll on making

 =

draft-win-m= pls-tp-itu-t-identifiers-01

 =

an mpls working group document.

 =

If you support the document becoming a working group document please =

respond to this poll with "yes/support"

 =

If you do not support the document becoming a working group document =

please respond to this poll with "no/do not support" and at the same = time

give the technical reasons why you are not supporting the = document.

 =

If you have technical comments or in any other way want to discuss the =

document, please send these comments to the mpls working group mailing =

list, but with another subject than what is on this mail. Please include the =

string “draft-win-mpls-tp-itu-t-identifiers” in the subject line. =

 =

The poll ends 2011-07-24.  Please note that this is the Sunday before = the

IETF. Also note that the length of the poll has  been shortened by two = days

so that the poll can be completed prior to our first WG meeting in Quebec City. 

 =

Ross

 =

------_=_NextPart_001_01CC40AC.F355D93C-- From stbryant@cisco.com Tue Jul 12 10:21:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886CA21F8B6F for ; Tue, 12 Jul 2011 10:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ-MuoEOzSIe for ; Tue, 12 Jul 2011 10:21:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 35A4621F8B48 for ; Tue, 12 Jul 2011 10:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1137; q=dns/txt; s=iport; t=1310491297; x=1311700897; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=tk9wCF26fvEKMXY7jJ6aCfeIP+DeyNzanAdMWHVRq2A=; b=gUX8eRSKzLA59MieLkEa6OADU/7ey5ygm1FtT6/0j2nh4e3VYPKOcBJO 608W2Q1BJS/9P9T8sM2xtDFP2TWzX2dei1Z3S35oh4Vq2lP2cBpTpGEac ejzd92u0gVYRuc5fgU4h7FWrjha+ZtuMfpJ23oHsq+9hFU0SNQx5xy8eP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGALuBHE6Q/khM/2dsb2JhbABTmDiOeXescYMVDwGaboY6BJJckEw X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="101670223" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2011 17:21:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6CHLVtS032207 for ; Tue, 12 Jul 2011 17:21:36 GMT Received: from dhcp-gpk02-vlan300-64-103-65-77.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6CHLTlw019918; Tue, 12 Jul 2011 18:21:31 +0100 (BST) Message-ID: <4E1C82E8.8050005@cisco.com> Date: Tue, 12 Jul 2011 18:22:48 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:21:41 -0000 I am not going to express an opinion either way on the adoption of this document as WG draft. That is for the working group to decide. I do however have a few questions that I would like to ask the authors. The proposal seems to be to constrain the total identifier length to 13bytes. Why is this necessary? The format chosen is ICC::Country_Code, using a "/" char as a separator. Why is that better than going from most unique to least unique, particularly since the CC is a fixed format. So why did you not adopt the format CC::ICC? You then say that 16 bits of further MEG discriminator is sufficient. How do we know that this is indeed sufficient? Why have you not provided at least a 32 bit integer for this purpose in order to make sure we have sufficient identifier space with the ability to partition (subnet) allocations? I note that the equivalent function in Y.1731 provides about 36 bits of identifier space (7 octets of 36 states/octet), so compressing this by a factor of 10^6 would seem to require some explanation to the working group so as to verify the decision. - Stewart From Rolf.Winter@neclab.eu Tue Jul 12 11:12:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1521F8D4C for ; Tue, 12 Jul 2011 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aacWWAXdlYm for ; Tue, 12 Jul 2011 11:12:35 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1B321F8D28 for ; Tue, 12 Jul 2011 11:12:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id ECC4928000305; Tue, 12 Jul 2011 20:12:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Wc90Wxq-bj; Tue, 12 Jul 2011 20:12:33 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C550028000301; Tue, 12 Jul 2011 20:12:03 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 20:12:03 +0200 From: Rolf Winter To: Ross Callon Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAFmO+4 Date: Tue, 12 Jul 2011 18:12:02 +0000 Message-ID: <432C511F-AD32-4C0E-B643-08B93C3A9E68@office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_432C511FAD324C0EB64308B93C3A9E68officehd_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , Ross Callon Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:12:36 -0000 --_000_432C511FAD324C0EB64308B93C3A9E68officehd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/Support. I don't think that every detail of the document is done yet an= d surely needs discussion. However the subject of the draft has been part o= f a wg draft already and I think the wg should take ownership of the docume= nt. On 12.07.2011, at 17:34, "Ross Callon" > wrote: Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string =93draft-win-mpls-tp-itu-t-identifiers=94 in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_432C511FAD324C0EB64308B93C3A9E68officehd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes/Support. I don't think that every detail of the document is done y= et and surely needs discussion. However the subject of the draft has been p= art of a wg draft already and I think the wg should take ownership of the d= ocument.



On 12.07.2011, at 17:34, "Ross Callon" <rcallon@juniper.net> wrote:

Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please <= /div>
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document <= /div>
please respond to this poll with "no/do not support" and at = the same time
give the technical reasons why you are not supporting the document.
 
If you have technical comments or in any other way want to discuss the=
document, please send these comments to the mpls working group mailing=
list, but with another subject than what is on this mail. Please inclu= de the
string =93draft-win-mpls-tp-itu-t-identifiers=94 in the subject line. =
 
The poll ends 2011-07-24.  Please note that this is the Sunday be= fore the
IETF. Also note that the length of the poll has  been shortened b= y two days
so that the poll can be completed prior to our first WG meeting in Que= bec City. 
 
Ross
 
--_000_432C511FAD324C0EB64308B93C3A9E68officehd_-- From jdrake@juniper.net Tue Jul 12 11:52:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3B021F8E77 for ; Tue, 12 Jul 2011 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asgprkN2TTQa for ; Tue, 12 Jul 2011 11:52:28 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D471321F8E6A for ; Tue, 12 Jul 2011 11:52:24 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKThyX6PSTw3jJOmungifHAhiFPv43wr1c@postini.com; Tue, 12 Jul 2011 11:52:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 12 Jul 2011 11:50:04 -0700 From: John E Drake To: Ross Callon , "mpls@ietf.org" Date: Tue, 12 Jul 2011 11:50:03 -0700 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaA Message-ID: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0A91E82B2EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:52:29 -0000 --_000_5E893DB832F57341992548CDBB333163A0A91E82B2EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross, Isn't it a bit premature to be asking to make this a working group document= ? Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_5E893DB832F57341992548CDBB333163A0A91E82B2EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ross,

 

<= p class=3DMsoNormal>Isn’t it a bit premature to be asking to m= ake this a working group document?

 

Thanks,

 

=

John

=  

Sent fr= om my iPhone

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callo= n
Sent: Tuesday, July 12, 2011 8:32 AM
To: mpls@ietf.or= g
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf= .org
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-= 01

 <= /p>

Working Group,

 

this is to sta= rt a 12 day poll on making

&n= bsp;

draft-win-mpls-tp-itu-t-= identifiers-01

 

an mpls working group document.=

 

If you support the document becoming a working group do= cument please

respond to thi= s poll with "yes/support"

 

If you do not s= upport the document becoming a working group document

please respond to this poll with "no/do not = support" and at the same time

give the technical reasons why you are not supporting the document.<= o:p>

 

<= /div>

If you have technical comments or in any other way = want to discuss the

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>document= , please send these comments to the mpls working group mailing <= /span>

list, but with another subject than what= is on this mail. Please include the

string “draft-win-mpls-tp-itu-t-identifiers” in the su= bject line.

 

The poll ends 2011-07-24.  Please= note that this is the Sunday before the

<= p class=3DMsoNormal>IETF. Also note that the length of the poll has  been sho= rtened by two days

so that t= he poll can be completed prior to our first WG meeting in Quebec City. = ;

 

Ross

 

= --_000_5E893DB832F57341992548CDBB333163A0A91E82B2EMBX01HQjnprn_-- From kishoret@juniper.net Tue Jul 12 11:57:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851E021F8D48 for ; Tue, 12 Jul 2011 11:57:28 -0700 (PDT) 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.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBu8qyjYky7E for ; Tue, 12 Jul 2011 11:57:28 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5107B21F8CAA for ; Tue, 12 Jul 2011 11:57:27 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKThyZEk5OrhzXT0Qkep2/foDKOv7Wydik@postini.com; Tue, 12 Jul 2011 11:57:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 11:55:50 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 12 Jul 2011 14:55:48 -0400 From: Kishore Tiruveedhula To: "erosen@cisco.com" , Maciek Konstantynowicz Date: Tue, 12 Jul 2011 14:55:46 -0400 Thread-Topic: [mpls] LDP DoD and PW Signalling ... Thread-Index: AcxAodDMAEz5P/cBRaiiQNqV4HGnKgAC9Pqw Message-ID: References: Your message of Tue, 12 Jul 2011 14:16:19 +0100. <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> <14368.1310481697@erosen-linux> In-Reply-To: <14368.1310481697@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:57:28 -0000 Eric, Please see below inline .. >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Tuesday, July 12, 2011 10:42 AM >To: Maciek Konstantynowicz >Cc: erosen@cisco.com; Nicolai Leymann; mpls@ietf.org; Thomas Beckhaus; >Kishore Tiruveedhula; Bruno Decraene >Subject: Re: [mpls] LDP DoD and PW Signalling ... > > >> 4.4.3. Label Request Retry Procedure > >> If AN or AGN receives a "No route" Notification in response to its >> label request message, it should retry with exponential backoff >> algorithm similar to the backoff algoritm mentioned in the LDP >> session negotiation section 4.3. > >If AN1 has a label for AN2, and AN2 goes down, this means that AN1 may >not >get a new label for AN2 until two minutes after AN1 comes back up. Is >that >considered acceptable? > >A different approach would be for AN1 to provide the AGN with a list of >prefixes for which it needs a label, and then to use the DU procedures, >applied to those specified prefixes only. That would meet the goal of >keeping unnecessary labels out of AN1, while maintaining the faster >responsiveness of the DU procedures. I understand that you don't want >to >configure the AGN with the set of prefixes for which the AN needs >labels, >but the AN could pass this information dynamically in an "outbound label >filter". > >Was this approach considered? [Kishore] This is kind of mixing both DU and DOD procedures and need to pro= pose the distribution modes (DU, DOD and both) per fec independent of sessi= on distribution mode and requires protocol changes.=20 > >> ... >> AN should follow the exponential backoff algorithm as specified in >> the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays >> grow to a maximum delay of 2 minutes. > >I'm not sure I understand the reference to "exponential backoff >algorithm as >specified in RFC5036". > [Kishore] Below is from section 2.5.3 in RFC 5036. This is the one referrin= g in the above sentence and will add this reference section number in next = revision.=20 The session establishment setup attempt following a NAK'd Initialization message MUST be delayed no less than 15 seconds, and subsequent delays MUST grow to a maximum delay of no less than 2 minutes. The specific session establishment action that must be delayed is the attempt to open the session transport connection by the LSR playing the active role. >Let me ask a couple of other questions about draft-beckhaus-ldp-dod. > >Section 4.1: > > "For the LDP DoD Advertisement mode on AN an ordered label > distribution mode and conservative label retention mode MUST be > supported." > >The ordered/independent distinction only applies when you need to send a >label that is bound to a prefix for which you are not the LSP egress. >Does >this even apply to an AN? [Kishore] I think the ordered/independent applies to AGN, probably not for = the egress case. I agree. Section 3.5.7.1.2. in RFC5036 says: > >Why do the ANs need to support conservative label retention mode? If an >AN >is homed to a pair of AGNs, what's wrong with it requesting a label from >each one? > > "The DoD mode is explicitly mentioned in the description of the > conservative mode in RFC5036" > >That's because conservative mode doesn't make much sense unless you are >also >using DoD mode. The converse is not necessarily true. [Kishore] I think the conservative mode doesn't restrict sending label requ= ests to multiple peers in case of ECMP. The conservative description in RFC 5036 says: "If operating in Downstream on Demand mode, an LSR will request label mappings only from the next hop LSR according to routing." Thanks, Kishore From Manuel.Paul@telekom.de Tue Jul 12 12:50:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4C89E800A for ; Tue, 12 Jul 2011 12:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cuYdHxZnKdE for ; Tue, 12 Jul 2011 12:50:16 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8EECF21F8C8B for ; Tue, 12 Jul 2011 12:50:14 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jul 2011 21:49:44 +0200 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.3]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Tue, 12 Jul 2011 21:49:39 +0200 From: To: , Date: Tue, 12 Jul 2011 21:49:39 +0200 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAH5gaw Message-ID: <9435EDACD941174099E143BCA2BCD615F7A2457369@HE101452.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9435EDACD941174099E143BCA2BCD615F7A2457369HE101452emea1_" MIME-Version: 1.0 Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:50:17 -0000 --_000_9435EDACD941174099E143BCA2BCD615F7A2457369HE101452emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQuDQoNClRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIHJpZ2h0IGJhc2lzIHRv IG1vdmUgZm9yd2FyZC4NCkZ1cnRoZXJtb3JlLCBpdCBwcm92aWRlcyBjb250ZW50IGZvciBhbiBp bXBvcnRhbnQgbWF0dGVyIChhcyBwYXJ0IG9mIHRoZSBNUExTLVRQIHJlcXVpcmVtZW50cykgdGhh dCBoYXMgYWxyZWFkeSBiZWVuIGFkb3B0ZWQgYnkgdGhlIFdHLg0KDQoNClRoYW5rcywNCg0KTWFu dWVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS b3NzIENhbGxvbg0KU2VudDogVHVlc2RheSwgSnVseSAxMiwgMjAxMSA1OjMyIFBNDQpUbzogbXBs c0BpZXRmLm9yZw0KQ2M6IFJvc3MgQ2FsbG9uOyBkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVu dGlmaWVyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIFBvbGwgb24gZHJhZnQtd2lu LW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDENCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBp cyB0byBzdGFydCBhIDEyIGRheSBwb2xsIG9uIG1ha2luZw0KDQpkcmFmdC13aW4tbXBscy10cC1p dHUtdC1pZGVudGlmaWVycy0wMQ0KDQphbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoN CklmIHlvdSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQgcGxlYXNlDQpyZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJ5ZXMvc3VwcG9ydCINCg0K SWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQNCnBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJuby9kbyBub3Qg c3VwcG9ydCIgYW5kIGF0IHRoZSBzYW1lIHRpbWUNCmdpdmUgdGhlIHRlY2huaWNhbCByZWFzb25z IHdoeSB5b3UgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC4NCg0KSWYgeW91IGhhdmUg dGVjaG5pY2FsIGNvbW1lbnRzIG9yIGluIGFueSBvdGhlciB3YXkgd2FudCB0byBkaXNjdXNzIHRo ZQ0KZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtp bmcgZ3JvdXAgbWFpbGluZw0KbGlzdCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0IHRoYW4gd2hh dCBpcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIHRoZQ0Kc3RyaW5nIOKAnGRyYWZ0LXdp bi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJz4oCdIGluIHRoZSBzdWJqZWN0IGxpbmUuDQoNClRo ZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4gIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyB0aGUgU3Vu ZGF5IGJlZm9yZSB0aGUNCklFVEYuIEFsc28gbm90ZSB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIHBv bGwgaGFzICBiZWVuIHNob3J0ZW5lZCBieSB0d28gZGF5cw0Kc28gdGhhdCB0aGUgcG9sbCBjYW4g YmUgY29tcGxldGVkIHByaW9yIHRvIG91ciBmaXJzdCBXRyBtZWV0aW5nIGluIFF1ZWJlYyBDaXR5 Lg0KDQpSb3NzDQoNCg== --_000_9435EDACD941174099E143BCA2BCD615F7A2457369HE101452emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5lcmF0 b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2 IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6 IzYwNjQyMDsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRpdi5l bWFpbHF1b3RlDQoJe21zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJYm9y ZGVyOm5vbmU7DQoJcGFkZGluZzowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjp3 aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNw dCA4NDEuOXB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tIGNvbnZlcnRl ZCBmcm9tIHJ0ZiAtLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1ERSBsaW5rPWJsdWUgdmxpbms9 IiM2MDY0MjAiPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpBcmlhbCc+WWVzL3N1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg ZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWwnPlRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIHJpZ2h0IGJhc2lzIHRv IG1vdmUgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5GdXJ0aGVybW9yZSwgaXQgcHJv dmlkZXMgY29udGVudCBmb3IgYW4gaW1wb3J0YW50IG1hdHRlcg0KKGFzIHBhcnQgb2YgdGhlIE1Q TFMtVFAgcmVxdWlyZW1lbnRzKSB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gYWRvcHRlZCBieSB0aGUg V0cuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPGRpdj4NCg0KPHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0Jz48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2snPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQnPjxmb250IHNpemU9MiBjb2xvcj1ibGFjaw0KZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayc+ TWFudWVsPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpBcmlhbCc+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFs Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5 bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIx MDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9s ZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTINCmZhY2U9VGFob21hPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+IG1wbHMtYm91bmNl c0BpZXRmLm9yZw0KW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxl PSdmb250LXdlaWdodDpib2xkJz5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5Sb3NzDQpDYWxsb248 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBU dWVzZGF5LCBKdWx5IDEyLCAyMDExIDU6MzINClBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQt d2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IG1wbHNAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBz dHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gUm9zcyBDYWxsb247DQpkcmFm dC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc0B0b29scy5pZXRmLm9yZzxicj4NCjxiPjxz cGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFttcGxzXSBQ b2xsIG9uDQpkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVycy0wMTwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEy LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz5Xb3JraW5nIEdyb3VwLDxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OkNhbGlicmknPnRoaXMgaXMgdG8gc3RhcnQgYSAxMiBkYXkgcG9sbCBvbiBtYWtpbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpDYWxpYnJpJz5kcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVycy0w MTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OkNhbGlicmknPmFuIG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudC48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseTpDYWxpYnJpJz5JZiB5b3Ugc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3 b3JraW5nIGdyb3VwDQpkb2N1bWVudCBwbGVhc2UgPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg ZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6 Q2FsaWJyaSc+cmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAmcXVvdDt5ZXMvc3VwcG9ydCZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OkNhbGlicmknPklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQg YmVjb21pbmcgYSB3b3JraW5nDQpncm91cCBkb2N1bWVudCA8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseTpDYWxpYnJpJz5wbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAmcXVvdDtuby9k byBub3QNCnN1cHBvcnQmcXVvdDsgYW5kIGF0IHRoZSBzYW1lIHRpbWUgPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6Q2FsaWJyaSc+Z2l2ZSB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgd2h5IHlvdSBh cmUgbm90IHN1cHBvcnRpbmcgdGhlDQpkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpDYWxpYnJpJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz5JZiB5 b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55IG90aGVyIHdheSB3YW50IHRvDQpk aXNjdXNzIHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz5kb2N1bWVudCwg cGxlYXNlIHNlbmQgdGhlc2UgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZw0KZ3JvdXAgbWFp bGluZyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz5saXN0LCBidXQgd2l0aCBh bm90aGVyIHN1YmplY3QgdGhhbiB3aGF0IGlzIG9uIHRoaXMgbWFpbC4NClBsZWFzZSBpbmNsdWRl IHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpJz5zdHJpbmcg4oCcZHJhZnQt d2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnPigJ0gaW4gdGhlDQpzdWJqZWN0IGxpbmUuIDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmknPlRoZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4mbmJzcDsgUGxlYXNl IG5vdGUgdGhhdCB0aGlzIGlzDQp0aGUgU3VuZGF5IGJlZm9yZSB0aGUgPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6Q2FsaWJyaSc+SUVURi4gQWxzbyBub3RlIHRoYXQgdGhlIGxlbmd0aCBvZiB0 aGUgcG9sbCBoYXMmbmJzcDsgYmVlbg0Kc2hvcnRlbmVkIGJ5IHR3byBkYXlzIDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPnNvIHRoYXQgdGhlIHBvbGwgY2FuIGJlIGNvbXBsZXRl ZCBwcmlvciB0byBvdXIgZmlyc3QgV0cNCm1lZXRpbmcgaW4gUXVlYmVjIENpdHkuJm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkNhbGlicmknPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmknPlJvc3M8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUNh bGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJp Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_9435EDACD941174099E143BCA2BCD615F7A2457369HE101452emea1_-- From erosen@cisco.com Tue Jul 12 13:04:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4921F8B42 for ; Tue, 12 Jul 2011 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCwnVIs9mZJb for ; Tue, 12 Jul 2011 13:04:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 941BF21F8B3C for ; Tue, 12 Jul 2011 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1234; q=dns/txt; s=iport; t=1310501049; x=1311710649; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=kVSghFQQLauSGzH0szU7R7lJrDGYSjBEcbW/rT9GLrI=; b=Ebkm1HXRCz+YyAQVCxcF1Ba0L7btr3SDBIxeqeaYTVki58XReSNCywTj N/DmoniwCXRS5JHOILOYELQdRjKXpFMcjMrkCjkZGtPPQMkoTk+eLfXJx PIZaUJ5q7VHSNrOlJzAUjyhoAO3GleI+XfNG1alejRJHcsafglXTa21xB U=; X-IronPort-AV: E=Sophos;i="4.65,522,1304294400"; d="scan'208";a="2280246" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 20:04:09 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6CK48BT008703; Tue, 12 Jul 2011 20:04:08 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p6CK47iX018805; Tue, 12 Jul 2011 16:04:07 -0400 To: Kishore Tiruveedhula In-reply-to: Your message of Tue, 12 Jul 2011 14:55:46 -0400. Date: Tue, 12 Jul 2011 16:04:07 -0400 Message-ID: <18804.1310501047@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" Subject: Re: [mpls] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 20:04:10 -0000 > This is kind of mixing both DU and DOD procedures and need to propose the > distribution modes (DU, DOD and both) per fec independent of session > distribution mode and requires protocol changes. It does require a protocol extension to enable the AN to send its list of "interesting prefixes" to the AGN. Once that's done, it would really be DU mode. A couple of relevant drafts would be: draft-raza-mpls-ldp-applicability-label-adv-01.txt draft-raza-mpls-ldp-olf-00.txt I think it's worth considering protocol extensions, as the DoD procedures were really intended for a different application and may not be the best fit for the requirements. > I think the conservative mode doesn't restrict sending label requests to > multiple peers in case of ECMP. I wasn't thinking of the ECMP case, but of a case where the AN is using only one route at a time. Even if it is using only one route at a time, it may want to be prepared to switch to the other route quickly if circumstances change. So if the AN is using DoD mode, it may still make sense to use liberal label retention mode. The number of extra labels for it to maintain would not be large, and the latency to change paths is lowered. From huubatwork@gmail.com Tue Jul 12 13:53:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D485C9E8034 for ; Tue, 12 Jul 2011 13:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72C0e7QTzA2I for ; Tue, 12 Jul 2011 13:53:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE699E8033 for ; Tue, 12 Jul 2011 13:53:24 -0700 (PDT) Received: by ewy19 with SMTP id 19so2176418ewy.31 for ; Tue, 12 Jul 2011 13:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MsNuGUeeHiSIBND4qx300pOLCQWYuTp09coRQSQYUag=; b=m8EzLp/LCV/uszlBebWQltp3sKZmHAkslekiBcYc4kUHDsxMwSBkj2i5WR2s9j2ADT zBFbwjc8u7pShC7+f4xGRenc88dlDwqdGKIPNLsO/q52EwRNqwZjbYfrRRAC2oDwRUiC sBFWXGfseM+f0Gu6ShbXtorYmOHy1SkUjH5CM= Received: by 10.213.103.69 with SMTP id j5mr138168ebo.147.1310504002431; Tue, 12 Jul 2011 13:53:22 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id z14sm1657229eef.47.2011.07.12.13.53.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 13:53:21 -0700 (PDT) Message-ID: <4E1CB43E.1080005@gmail.com> Date: Tue, 12 Jul 2011 22:53:18 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Ross Callon References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 20:53:25 -0000 "yes/support" this document provides a method to uniquely provide an Operator ID and how this can be used in a MEG-ID. Regards, Huub. On 12-07-11 17:31, Ross Callon wrote: > Working Group, > this is to start a 12 day poll on making > draft-win-mpls-tp-itu-t-identifiers-01 > an mpls working group document. > If you support the document becoming a working group document please > respond to this poll with "yes/support" > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same time > give the technical reasons why you are not supporting the document. > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please include > the > string “draft-win-mpls-tp-itu-t-identifiers” in the subject line. > The poll ends 2011-07-24. Please note that this is the Sunday before the > IETF. Also note that the length of the poll has been shortened by two days > so that the poll can be completed prior to our first WG meeting in > Quebec City. > Ross > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 我爱外点一七三一 From hffellow@hotmail.com Tue Jul 12 14:36:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0D21F8C74 for ; Tue, 12 Jul 2011 14:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.848 X-Spam-Level: *** X-Spam-Status: No, score=3.848 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUC3u-uES5oV for ; Tue, 12 Jul 2011 14:36:29 -0700 (PDT) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by ietfa.amsl.com (Postfix) with ESMTP id 44D1821F8C52 for ; Tue, 12 Jul 2011 14:36:29 -0700 (PDT) Received: from BLU0-SMTP139 ([65.55.111.136]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 14:36:29 -0700 X-Originating-IP: [112.64.191.96] X-Originating-Email: [hffellow@hotmail.com] Message-ID: Received: from [172.26.2.9] ([112.64.191.96]) by BLU0-SMTP139.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 14:36:26 -0700 References: In-Reply-To: MIME-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="Apple-Mail-39--660573275" X-Mailer: iPhone Mail (8C148) From: Huang Feng Date: Wed, 13 Jul 2011 05:36:25 +0800 To: Ross Callon X-OriginalArrivalTime: 12 Jul 2011 21:36:27.0936 (UTC) FILETIME=[C1BDD200:01CC40DB] Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:36:30 -0000 --Apple-Mail-39--660573275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" Yes/support BR hffellow Send from my iPhone =D4=DA 2011-7-12=A3=AC23:31=A3=ACRoss Callon =D0=B4=B5= =C0=A3=BA > Working Group, > =20 > this is to start a 12 day poll on making > =20 > draft-win-mpls-tp-itu-t-identifiers-01 > =20 > an mpls working group document. > =20 > If you support the document becoming a working group document please > respond to this poll with "yes/support" > =20 > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same time > give the technical reasons why you are not supporting the document. > =20 > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please include t= he > string =A1=B0draft-win-mpls-tp-itu-t-identifiers=A1=B1 in the subject line= . > =20 > The poll ends 2011-07-24. Please note that this is the Sunday before the > IETF. Also note that the length of the poll has been shortened by two day= s > so that the poll can be completed prior to our first WG meeting in Quebec C= ity.=20 > =20 > Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-39--660573275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes/support

BR=
hffellow

Send from my iPhone
=E5=9C=A8 2011-7-12=EF=BC=8C23:31=EF=BC=8CRoss Callon <rcallon@juniper.net> =E5=86=99=E9=81=93=EF=BC=9A=

Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document
please respond to this poll with "no/do not support" and at the same ti= me
give the technical reasons why you are not supporting the document.
 
If you have technical comments or in any other way want to discuss the <= /div>
document, please send these comments to the mpls working group mailing <= /div>
list, but with another subject than what is on this mail. Please includ= e the
string =E2=80=9Cdraft-win-mpls-tp-itu-t-identifiers=E2=80=9D in the sub= ject line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday bef= ore the
IETF. Also note that the length of the poll has  been shortened by= two days
so that the poll can be completed prior to our first WG meeting in Queb= ec City. 
 
Ross
 
____________________= ___________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman= /listinfo/mpls
= --Apple-Mail-39--660573275-- From c-sai@bx.jp.nec.com Tue Jul 12 17:13:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E321F8B43 for ; Tue, 12 Jul 2011 17:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN7VnOhwJZwn for ; Tue, 12 Jul 2011 17:13:32 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id CB79021F8B3F for ; Tue, 12 Jul 2011 17:13:30 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6D0DT64006307; Wed, 13 Jul 2011 09:13:29 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6D0DT721856; Wed, 13 Jul 2011 09:13:29 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6D0DTQW026500; Wed, 13 Jul 2011 09:13:29 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-54542; Wed, 13 Jul 2011 09:13:08 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTPA id BT-MMP-9867; Wed, 13 Jul 2011 09:13:07 +0900 From: "Zhenlong Cui" To: "'Ross Callon'" References: Date: Wed, 13 Jul 2011 09:13:07 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gASHPsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:13:34 -0000 Yes/support. Thanks, Zhenlong ________________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon Sent: Wednesday, July 13, 2011 12:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, =A0 this is to start a 12 day poll on making =A0 draft-win-mpls-tp-itu-t-identifiers-01 =A0 an mpls working group document. =A0 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =A0 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same = time=20 give the technical reasons why you are not supporting the document. =A0 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include = the=20 string =93draft-win-mpls-tp-itu-t-identifiers=94 in the subject line.=20 =A0 The poll ends 2011-07-24.=A0 Please note that this is the Sunday before = the=20 IETF. Also note that the length of the poll has=A0 been shortened by two = days=20 so that the poll can be completed prior to our first WG meeting in = Quebec City.=A0=20 =A0 Ross =A0 From Feng.f.Huang@alcatel-sbell.com.cn Tue Jul 12 17:42:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0558021F8BCC for ; Tue, 12 Jul 2011 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.15 X-Spam-Level: *** X-Spam-Status: No, score=3.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuCcBSwuJN-u for ; Tue, 12 Jul 2011 17:42:38 -0700 (PDT) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4CC21F8BC9 for ; Tue, 12 Jul 2011 17:42:37 -0700 (PDT) X-AuditID: ac189297-b7b14ae000003039-12-4e1ce9f9dfae Received: from cnshgsbhs02.ad4.ad.alcatel.com (Unknown_Domain [172.24.146.147]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 41.BB.12345.9F9EC1E4; Wed, 13 Jul 2011 08:42:34 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 08:42:34 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC40F5.C10E5593" Date: Wed, 13 Jul 2011 08:42:32 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gATNCfw References: From: "HUANG Feng F" To: "Ross Callon" , X-OriginalArrivalTime: 13 Jul 2011 00:42:34.0309 (UTC) FILETIME=[C16B1F50:01CC40F5] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:42:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC40F5.C10E5593 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable yes/support B.R. Feng ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon Sent: 2011=C4=EA7=D4=C212=C8=D5 23:32 To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same = time=20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include = the=20 string =A1=B0draft-win-mpls-tp-itu-t-identifiers=A1=B1 in the subject = line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before = the=20 IETF. Also note that the length of the poll has been shortened by two = days=20 so that the poll can be completed prior to our first WG meeting in = Quebec City. =20 =20 Ross =20 ------_=_NextPart_001_01CC40F5.C10E5593 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
yes/support
B.R.
Feng
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Ross = Callon
Sent:=20 2011=C4=EA7=D4=C212=C8=D5 23:32
To: = mpls@ietf.org
Cc: Ross Callon;=20 draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = [mpls]=20 Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document = please
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group = document
please respond to this poll with "no/do not support" and at the = same time=20
give the technical reasons why you are not supporting the = document.
 
If you have technical comments or in any other way want to discuss = the=20
document, please send these comments to the mpls working group = mailing=20
list, but with another subject than what is on this mail. Please = include=20 the
string =A1=B0draft-win-mpls-tp-itu-t-identifiers=A1=B1 in the = subject line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday = before=20 the
IETF. Also note that the length of the poll has  been = shortened by two=20 days
so that the poll can be completed prior to our first WG meeting in = Quebec=20 City. 
 
Ross
 
 ------_=_NextPart_001_01CC40F5.C10E5593-- From liu.guoman@zte.com.cn Tue Jul 12 17:50:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17411E80C7 for ; Tue, 12 Jul 2011 17:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEZQ8p80pZYa for ; Tue, 12 Jul 2011 17:50:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 492B811E807D for ; Tue, 12 Jul 2011 17:50:03 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 13132806486374; Wed, 13 Jul 2011 08:44:20 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 94465.806486374; Wed, 13 Jul 2011 08:49:50 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id p6D0nw8k004297 for ; Wed, 13 Jul 2011 08:49:58 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6D0fuhp096913; Wed, 13 Jul 2011 08:41:56 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201107130049.p6D0nw8k004297@mse01.zte.com.cn> In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Wed, 13 Jul 2011 08:41:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-13 08:41:56, Serialize complete at 2011-07-13 08:41:56 Content-Type: multipart/alternative; boundary="=_alternative 00040066482578CC_=" X-MAIL: mse01.zte.com.cn p6D0nw8k004297 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:50:04 -0000 This is a multipart message in MIME format. --=_alternative 00040066482578CC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eWVzL3N1cHBvcnQNCg0KDQoNCg0KDQoNCg0KUm9zcyBDYWxsb24gPHJjYWxsb25AanVuaXBlci5u ZXQ+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA3LTEyIDIzOjMxDQoN CsrVvP7Iyw0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0KUm9zcyBDYWxs b24gPHJjYWxsb25AanVuaXBlci5uZXQ+LCANCiJkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVu dGlmaWVyc0B0b29scy5pZXRmLm9yZyIgDQo8ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRp ZmllcnNAdG9vbHMuaWV0Zi5vcmc+DQrW98ziDQpbbXBsc10gUG9sbCBvbiBkcmFmdC13aW4tbXBs cy10cC1pdHUtdC1pZGVudGlmaWVycy0wMQ0KDQoNCg0KDQoNCg0KV29ya2luZyBHcm91cCwNCiAN CnRoaXMgaXMgdG8gc3RhcnQgYSAxMiBkYXkgcG9sbCBvbiBtYWtpbmcNCiANCmRyYWZ0LXdpbi1t cGxzLXRwLWl0dS10LWlkZW50aWZpZXJzLTAxDQogDQphbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQuDQogDQpJZiB5b3Ugc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5n IGdyb3VwIGRvY3VtZW50IHBsZWFzZSANCnJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGggInllcy9z dXBwb3J0Ig0KIA0KSWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBh IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgDQpwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0 aCAibm8vZG8gbm90IHN1cHBvcnQiIGFuZCBhdCB0aGUgc2FtZSB0aW1lIA0KZ2l2ZSB0aGUgdGVj aG5pY2FsIHJlYXNvbnMgd2h5IHlvdSBhcmUgbm90IHN1cHBvcnRpbmcgdGhlIGRvY3VtZW50Lg0K IA0KSWYgeW91IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIG9yIGluIGFueSBvdGhlciB3YXkgd2Fu dCB0byBkaXNjdXNzIHRoZSANCmRvY3VtZW50LCBwbGVhc2Ugc2VuZCB0aGVzZSBjb21tZW50cyB0 byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgDQpsaXN0LCBidXQgd2l0aCBhbm90aGVy IHN1YmplY3QgdGhhbiB3aGF0IGlzIG9uIHRoaXMgbWFpbC4gUGxlYXNlIGluY2x1ZGUgDQp0aGUg DQpzdHJpbmcgobBkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc6GxIGluIHRoZSBz dWJqZWN0IGxpbmUuIA0KIA0KVGhlIHBvbGwgZW5kcyAyMDExLTA3LTI0LiAgUGxlYXNlIG5vdGUg dGhhdCB0aGlzIGlzIHRoZSBTdW5kYXkgYmVmb3JlIHRoZSANCklFVEYuIEFsc28gbm90ZSB0aGF0 IHRoZSBsZW5ndGggb2YgdGhlIHBvbGwgaGFzICBiZWVuIHNob3J0ZW5lZCBieSB0d28gDQpkYXlz IA0Kc28gdGhhdCB0aGUgcG9sbCBjYW4gYmUgY29tcGxldGVkIHByaW9yIHRvIG91ciBmaXJzdCBX RyBtZWV0aW5nIGluIFF1ZWJlYyANCkNpdHkuIA0KIA0KUm9zcw0KIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 00040066482578CC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnllcy9zdXBwb3J0PGJyPg0KPC9m b250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5Sb3NzIENhbGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDs8L2I+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy1i b3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTEtMDctMTIgMjM6MzE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJvc3MgQ2FsbG9uICZsdDtyY2FsbG9uQGp1bmlw ZXIubmV0Jmd0OywNCiZxdW90O2RyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzQHRv b2xzLmlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVy c0B0b29scy5pZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlttcGxzXSBQb2xsIG9uIGRy YWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzLTAxPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPldvcmtpbmcg R3JvdXAsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPnRoaXMgaXMgdG8gc3RhcnQgYSAx MiBkYXkgcG9sbCBvbiBtYWtpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ZHJhZnQt d2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+YW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5JZiB5b3Ugc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYQ0Kd29ya2lu ZyBncm91cCBkb2N1bWVudCBwbGVhc2UgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5yZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUg ZG9jdW1lbnQgYmVjb21pbmcNCmEgd29ya2luZyBncm91cCBkb2N1bWVudCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPnBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3 aXRoICZxdW90O25vL2RvDQpub3Qgc3VwcG9ydCZxdW90OyBhbmQgYXQgdGhlIHNhbWUgdGltZSA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPmdpdmUgdGhlIHRlY2huaWNh bCByZWFzb25zIHdoeSB5b3UgYXJlDQpub3Qgc3VwcG9ydGluZyB0aGUgZG9jdW1lbnQuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmIHlvdSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyBv ciBpbiBhbnkNCm90aGVyIHdheSB3YW50IHRvIGRpc2N1c3MgdGhlIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1l bnRzIHRvDQp0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5saXN0LCBidXQgd2l0aCBhbm90aGVyIHN1YmplY3QgdGhh biB3aGF0DQppcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIHRoZSA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPnN0cmluZyChsGRyYWZ0LXdpbi1tcGxzLXRwLWl0 dS10LWlkZW50aWZpZXJzobENCmluIHRoZSBzdWJqZWN0IGxpbmUuIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5UaGUgcG9sbCBlbmRzIDIwMTEtMDctMjQuICZuYnNwO1BsZWFzZQ0Kbm90 ZSB0aGF0IHRoaXMgaXMgdGhlIFN1bmRheSBiZWZvcmUgdGhlIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+SUVURi4gQWxzbyBub3RlIHRoYXQgdGhlIGxlbmd0aCBvZiB0 aGUNCnBvbGwgaGFzICZuYnNwO2JlZW4gc2hvcnRlbmVkIGJ5IHR3byBkYXlzIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+c28gdGhhdCB0aGUgcG9sbCBjYW4gYmUgY29t cGxldGVkIHByaW9yDQp0byBvdXIgZmlyc3QgV0cgbWVldGluZyBpbiBRdWViZWMgQ2l0eS4gJm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJvc3M8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWls aW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZu YnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFp bCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJz cDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDtt YWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJt aXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtv ZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlz Jm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVk Jm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5i c3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5i c3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5 b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZu YnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRv ciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNw O2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0 aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMm bmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJz cDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1T cGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00040066482578CC_=-- From ma.yuxia@zte.com.cn Tue Jul 12 20:02:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1008011E80D3; Tue, 12 Jul 2011 20:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.931 X-Spam-Level: X-Spam-Status: No, score=-90.931 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7iOzYoMEMSx; Tue, 12 Jul 2011 20:02:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E511E80C2; Tue, 12 Jul 2011 20:02:27 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Wed, 13 Jul 2011 11:00:59 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.2478792715; Wed, 13 Jul 2011 11:02:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6D32Jn3066973; Wed, 13 Jul 2011 11:02:19 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Wed, 13 Jul 2011 11:02:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-13 11:02:20, Serialize complete at 2011-07-13 11:02:20 Content-Type: multipart/alternative; boundary="=_alternative 0010C174482578CC_=" X-MAIL: mse02.zte.com.cn p6D32Jn3066973 Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , mpls-bounces@ietf.org Subject: [mpls] =?gb2312?b?tPC4tDogIFBvbGwgb24gZHJhZnQtd2luLW1wbHMtdHAt?= =?gb2312?b?aXR1LXQtaWRlbnRpZmllcnMtMDE=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 03:02:29 -0000 This is a multipart message in MIME format. --=_alternative 0010C174482578CC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL1N1cHBvcnQNCg0KDQoNCg0KDQoNClJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0 PiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wNy0xMiAyMzozMQ0KDQrK 1bz+yMsNCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCrOty80NClJvc3MgQ2FsbG9u IDxyY2FsbG9uQGp1bmlwZXIubmV0PiwgDQoiZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRp ZmllcnNAdG9vbHMuaWV0Zi5vcmciIA0KPGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZp ZXJzQHRvb2xzLmlldGYub3JnPg0K1vfM4g0KW21wbHNdIFBvbGwgb24gZHJhZnQtd2luLW1wbHMt dHAtaXR1LXQtaWRlbnRpZmllcnMtMDENCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQogDQp0 aGlzIGlzIHRvIHN0YXJ0IGEgMTIgZGF5IHBvbGwgb24gbWFraW5nDQogDQpkcmFmdC13aW4tbXBs cy10cC1pdHUtdC1pZGVudGlmaWVycy0wMQ0KIA0KYW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KIA0KSWYgeW91IHN1cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nIGEgd29ya2luZyBn cm91cCBkb2N1bWVudCBwbGVhc2UgDQpyZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJ5ZXMvc3Vw cG9ydCINCiANCklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3 b3JraW5nIGdyb3VwIGRvY3VtZW50IA0KcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGgg Im5vL2RvIG5vdCBzdXBwb3J0IiBhbmQgYXQgdGhlIHNhbWUgdGltZSANCmdpdmUgdGhlIHRlY2hu aWNhbCByZWFzb25zIHdoeSB5b3UgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC4NCiAN CklmIHlvdSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyBvciBpbiBhbnkgb3RoZXIgd2F5IHdhbnQg dG8gZGlzY3VzcyB0aGUgDQpkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlc2UgY29tbWVudHMgdG8g dGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIA0KbGlzdCwgYnV0IHdpdGggYW5vdGhlciBz dWJqZWN0IHRoYW4gd2hhdCBpcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIA0KdGhlIA0K c3RyaW5nIKGwZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnOhsSBpbiB0aGUgc3Vi amVjdCBsaW5lLiANCiANClRoZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4gIFBsZWFzZSBub3RlIHRo YXQgdGhpcyBpcyB0aGUgU3VuZGF5IGJlZm9yZSB0aGUgDQpJRVRGLiBBbHNvIG5vdGUgdGhhdCB0 aGUgbGVuZ3RoIG9mIHRoZSBwb2xsIGhhcyAgYmVlbiBzaG9ydGVuZWQgYnkgdHdvIA0KZGF5cyAN CnNvIHRoYXQgdGhlIHBvbGwgY2FuIGJlIGNvbXBsZXRlZCBwcmlvciB0byBvdXIgZmlyc3QgV0cg bWVldGluZyBpbiBRdWViZWMgDQpDaXR5LiANCiANClJvc3MNCiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg== --=_alternative 0010C174482578CC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zPlllcy9TdXBwb3J0PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlJvc3MgQ2FsbG9u ICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5jZXNAaWV0Zi5vcmc8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0xMiAyMzoz MTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Um9zcyBDYWxsb24gJmx0O3JjYWxsb25AanVuaXBlci5uZXQmZ3Q7LA0KJnF1 b3Q7ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnNAdG9vbHMuaWV0Zi5vcmcmcXVv dDsgJmx0O2RyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzQHRvb2xzLmlldGYub3Jn Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHNdIFBvbGwgb24gZHJhZnQtd2luLW1wbHMtdHAt aXR1LXQtaWRlbnRpZmllcnMtMDE8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+V29ya2luZyBHcm91cCw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+dGhpcyBpcyB0byBzdGFydCBhIDEyIGRheSBwb2xsIG9uIG1h a2luZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5kcmFmdC13aW4tbXBscy10cC1pdHUt dC1pZGVudGlmaWVycy0wMTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5hbiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmIHlv dSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhDQp3b3JraW5nIGdyb3VwIGRvY3VtZW50 IHBsZWFzZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPnJlc3BvbmQg dG8gdGhpcyBwb2xsIHdpdGggJnF1b3Q7eWVzL3N1cHBvcnQmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+SWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWlu Zw0KYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+cGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGggJnF1b3Q7bm8vZG8N Cm5vdCBzdXBwb3J0JnF1b3Q7IGFuZCBhdCB0aGUgc2FtZSB0aW1lIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Z2l2ZSB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgd2h5IHlv dSBhcmUNCm5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+SWYgeW91IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIG9yIGluIGFueQ0Kb3RoZXIg d2F5IHdhbnQgdG8gZGlzY3VzcyB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5kb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlc2UgY29tbWVudHMgdG8NCnRoZSBtcGxz IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPmxpc3QsIGJ1dCB3aXRoIGFub3RoZXIgc3ViamVjdCB0aGFuIHdoYXQNCmlzIG9uIHRo aXMgbWFpbC4gUGxlYXNlIGluY2x1ZGUgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+c3RyaW5nIKGwZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnOh sQ0KaW4gdGhlIHN1YmplY3QgbGluZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRo ZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4gJm5ic3A7UGxlYXNlDQpub3RlIHRoYXQgdGhpcyBpcyB0 aGUgU3VuZGF5IGJlZm9yZSB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5JRVRGLiBBbHNvIG5vdGUgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZQ0KcG9sbCBoYXMgJm5i c3A7YmVlbiBzaG9ydGVuZWQgYnkgdHdvIGRheXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5zbyB0aGF0IHRoZSBwb2xsIGNhbiBiZSBjb21wbGV0ZWQgcHJpb3INCnRv IG91ciBmaXJzdCBXRyBtZWV0aW5nIGluIFF1ZWJlYyBDaXR5LiAmbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Um9zczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1w bHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0010C174482578CC_=-- From swallow@cisco.com Tue Jul 12 21:19:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E2921F8B8E for ; Tue, 12 Jul 2011 21:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=-1.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj3X2jfsu5ZT for ; Tue, 12 Jul 2011 21:18:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EF42121F8B89 for ; Tue, 12 Jul 2011 21:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=1177; q=dns/txt; s=iport; t=1310530736; x=1311740336; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=Re0NxnsEv4PD5GWwAqVPdOvCq5dOyErio/pntV0A2LU=; b=Hy56wvBY2cW1t63DAXsEw3gaIPYrlBMmG0abJZE/91b0RY0yKaxtVhIS fd55Tg6Qxdv55BymnL/fNdtcBb3twmpMrzrfJVXNVavif35V1nJBn6FPQ uUrDhBENPoDPI431rrWIq5MiRrkpuCG9wy500znVB1094wNPc8YQho9Vy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4iAOMbHU6tJXG8/2dsb2JhbABTG4I4lWmGdQschnZpd6wbgSKeFIY6BIJNkBSFCItg X-IronPort-AV: E=Sophos;i="4.65,523,1304294400"; d="scan'208,217";a="2394120" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jul 2011 04:18:55 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6D4It7B030562 for ; Wed, 13 Jul 2011 04:18:55 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 23:18:55 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Jul 2011 04:18:55 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 13 Jul 2011 00:18:52 -0400 From: George Swallow To: Message-ID: Thread-Topic: draft-ietf-mpls-tp-fault-05.txt Thread-Index: AcxAFxnx8kQLt/cjTs66F9mgMDMs3QA/N7K5 In-Reply-To: <20110711220835.20262.42580.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393361134_29201616" X-OriginalArrivalTime: 13 Jul 2011 04:18:55.0228 (UTC) FILETIME=[FAA62BC0:01CC4113] Subject: [mpls] draft-ietf-mpls-tp-fault-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 04:19:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393361134_29201616 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This version addresses the last call comments. The comment resolution can be found at http://www.pi.nu/~loa/Version3_Comment_Resolution.xls ...George --B_3393361134_29201616 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable draft-ietf-mpls-tp-fault-05.txt This ve= rsion addresses the last call comments.

The comment resolution can be found at

http://www.pi.nu/~loa/Version3_Comment_Resolution.xls

...George --B_3393361134_29201616-- From loa@pi.nu Wed Jul 13 00:31:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5AB21F8B3D for ; Wed, 13 Jul 2011 00:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceeIMzrRZ4+E for ; Wed, 13 Jul 2011 00:30:57 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9C21F8B1D for ; Wed, 13 Jul 2011 00:30:57 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0E42B514044; Wed, 13 Jul 2011 09:30:54 +0200 (CEST) Message-ID: <4E1D49AE.9060707@pi.nu> Date: Wed, 13 Jul 2011 09:30:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , MPLS-TP ad hoc team , draft-ietf-mpls-tp-fault@tools.ietf.org Subject: [mpls] verification call on draft-ietf-mpls-tp-fault-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 07:31:01 -0000 Working group, this is to start a one week verification call on http://www.ietf.org/id/draft-ietf-mpls-tp-fault-05.txt The authors has updated the draft after working last call and the intention of the verification call is to verify that all comments has been adequately addressed. A list detailing how the comments been addressed is found at: http://www.pi.nu/~loa/Version3_Comment_Resolution.xls Please send your comments to the working group mailing list (mpls@ietf.org) before eob July 20, 2011. /Loa for the wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From alessandro.dalessandro@telecomitalia.it Wed Jul 13 02:07:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE74221F85F1 for ; Wed, 13 Jul 2011 02:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Som12oKGe2bi for ; Wed, 13 Jul 2011 02:07:02 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2893321F85F0 for ; Wed, 13 Jul 2011 02:07:02 -0700 (PDT) Content-Type: multipart/mixed; boundary="_111c2430-e486-477b-a3aa-d2912b0aabcc_" Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 11:07:00 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Wed, 13 Jul 2011 11:07:00 +0200 From: D'Alessandro Alessandro Gerardo To: John E Drake , "mpls@ietf.org" Date: Wed, 13 Jul 2011 11:06:59 +0200 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaAAB3ekGA= Message-ID: References: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: [mpls] R: Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:07:04 -0000 --_111c2430-e486-477b-a3aa-d2912b0aabcc_ Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61464GRFMBX702RM00_" --_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61464GRFMBX702RM00_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear John, if you mean "do not support", please could you provide a technical reason.= I'm interested in knowing your position. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di John = E Drake Inviato: marted=EC 12 luglio 2011 20:50 A: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Oggetto: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Ross, Isn't it a bit premature to be asking to make this a working group document= ? Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61464GRFMBX702RM00_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear John,=

if you mea= n “do not support”, please could  you provide a technical reason= . I’m interested in knowing your position.

 = ;

Best regar= ds,

Alessandro=

 = ;

--------------= ----------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07<= /span>

 <= /p>

Da: mpls-b= ounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di John E Drake
Inviato: marted=EC 12 luglio 2011 20:50
A: Ross Callon; mpls@ietf.org
Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Oggetto: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

 

Ross,=

 = ;

Isn’= t it a bit premature to be asking to make this a working group document?

 = ;

Thanks,

 = ;

John<= /o:p>

 = ;

Sent from = my iPhone

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Tuesday, July 12, 2011 8:32 AM
To: mpls@ietf.org
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org<= br> Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01<= /o:p>

 

Working Group,

 =

this is to start a 12 da= y poll on making

 =

draft-win-mpls-tp-itu-t-= identifiers-01

 =

an mpls working group do= cument.

 =

If you support the docum= ent becoming a working group document please

respond to this poll wit= h "yes/support"

 =

If you do not support th= e document becoming a working group document

please respond to this p= oll with "no/do not support" and at the same time

give the technical reaso= ns why you are not supporting the document.

 =

If you have technical co= mments or in any other way want to discuss the

document, please send th= ese comments to the mpls working group mailing

list, but with another s= ubject than what is on this mail. Please include the

string “draft-win-= mpls-tp-itu-t-identifiers” in the subject line.

 =

The poll ends 2011-07-24= .  Please note that this is the Sunday before the

IETF. Also note that the= length of the poll has  been shortened by two days

so that the poll can be = completed prior to our first WG meeting in Quebec City. 

 =

Ross

 =

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61464GRFMBX702RM00_-- --_111c2430-e486-477b-a3aa-d2912b0aabcc_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_111c2430-e486-477b-a3aa-d2912b0aabcc_-- From alessandro.dalessandro@telecomitalia.it Wed Jul 13 02:07:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B220821F85F3 for ; Wed, 13 Jul 2011 02:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.232 X-Spam-Level: * X-Spam-Status: No, score=1.232 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7Jf45LShg1o for ; Wed, 13 Jul 2011 02:07:30 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3803721F88D6 for ; Wed, 13 Jul 2011 02:07:29 -0700 (PDT) Content-Type: multipart/mixed; boundary="_39967c60-eb54-4a1a-b2f8-d4caecd8fcb5_" Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 11:07:28 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Wed, 13 Jul 2011 11:07:28 +0200 From: D'Alessandro Alessandro Gerardo To: Ross Callon , "mpls@ietf.org" Date: Wed, 13 Jul 2011 11:07:26 +0200 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAk3H0Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: [mpls] R: Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:07:31 -0000 --_39967c60-eb54-4a1a-b2f8-d4caecd8fcb5_ Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61466GRFMBX702RM00_" --_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61466GRFMBX702RM00_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes support ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Ross = Callon Inviato: marted=EC 12 luglio 2011 17:32 A: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Oggetto: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61466GRFMBX702RM00_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes support

 <= /p>

--------------= ----------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07<= /span>

 <= /p>

Da: mpls-b= ounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Ross Callon
Inviato: marted=EC 12 luglio 2011 17:32
A: mpls@ietf.org
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org<= br> Oggetto: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01<= /o:p>

 

Working Group,

 

this is to start a 12 day poll on makin= g

 

draft-win-mpls-tp-itu-t-identifiers-01<= o:p>

 

an mpls working group document.

 

If you support the document becoming a = working group document please

respond to this poll with "yes/sup= port"

 

If you do not support the document beco= ming a working group document

please respond to this poll with "= no/do not support" and at the same time

give the technical reasons why you are = not supporting the document.

 

If you have technical comments or in an= y other way want to discuss the

document, please send these comments to= the mpls working group mailing

list, but with another subject than wha= t is on this mail. Please include the

string “draft-win-mpls-tp-itu-t-i= dentifiers” in the subject line.

 

The poll ends 2011-07-24.  Please = note that this is the Sunday before the

IETF. Also note that the length of the = poll has  been shortened by two days

so that the poll can be completed prior= to our first WG meeting in Quebec City. 

 

Ross

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A1F769BC58A8B146B2EEA818EAE052A2096BC61466GRFMBX702RM00_-- --_39967c60-eb54-4a1a-b2f8-d4caecd8fcb5_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_39967c60-eb54-4a1a-b2f8-d4caecd8fcb5_-- From neil.2.harrison@bt.com Wed Jul 13 02:31:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB4F21F8B06 for ; Wed, 13 Jul 2011 02:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18lNZ7-R7xGO for ; Wed, 13 Jul 2011 02:31:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8621F8B08 for ; Wed, 13 Jul 2011 02:31:17 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 13 Jul 2011 10:31:10 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 13 Jul 2011 10:31:10 +0100 From: To: Date: Wed, 13 Jul 2011 10:31:01 +0100 Thread-Topic: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAuFFmGaL4sC/wRNCLF0dBmDoMDgAhk72g Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> References: <4E1C82E8.8050005@cisco.com> In-Reply-To: <4E1C82E8.8050005@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: stbryant@cisco.com Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:31:18 -0000 I also have a question on this draft: How do different MPLS-TP layer networks that belong to the same operator ge= t differentiated...noting that these may form nested client/server relation= ships and thus be subject to inter-layer misconnectivity as well as intra-l= ayer misconnectivity? Thanks.....regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: 12 July 2011 18:23 > To: mpls@ietf.org > Subject: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 >=20 >=20 > I am not going to express an opinion either way on the adoption of this > document as WG draft. That is for the working group to decide. >=20 > I do however have a few questions that I would like to ask the authors. >=20 > The proposal seems to be to constrain the total identifier length to > 13bytes. Why is this necessary? >=20 > The format chosen is ICC::Country_Code, using a "/" char as a > separator. > Why is that better than going from most unique to least unique, > particularly since the CC is a fixed format. So why did you not adopt > the format CC::ICC? >=20 > You then say that 16 bits of further MEG discriminator is sufficient. > How do we know that this is indeed sufficient? >=20 > Why have you not provided at least a 32 bit integer for this purpose in > order to make sure we have sufficient identifier space with the ability > to partition (subnet) allocations? >=20 > I note that the equivalent function in Y.1731 provides about 36 bits of > identifier space (7 octets of 36 states/octet), so compressing this by > a > factor of 10^6 would seem to require some explanation to the working > group so as to verify the decision. >=20 > - Stewart >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From alessandro.dalessandro@telecomitalia.it Wed Jul 13 06:07:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0861921F84F5; Wed, 13 Jul 2011 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.069 X-Spam-Level: X-Spam-Status: No, score=-0.069 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxvli4Sf+ick; Wed, 13 Jul 2011 06:06:57 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0021F8564; Wed, 13 Jul 2011 06:02:29 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 15:02:27 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Wed, 13 Jul 2011 15:02:26 +0200 From: D'Alessandro Alessandro Gerardo To: IETF-Announce Date: Wed, 13 Jul 2011 15:02:25 +0200 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw78+yUyZwkPT7YRSyxVgVnNmWPlAFUhpLQ Message-ID: References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B3D5@INOAVREX11.ptin.corpPT.com> <4E1482C8.6020701@pi.nu> In-Reply-To: <4E1482C8.6020701@pi.nu> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: [mpls] R: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:07:01 -0000 Dear all, I regret to say I have the same concerns expressed by Rui and Erminio about= the procedure adopted for this document that has brought so many discussio= ns. Anyway, probably because of the lack of a reasonable time (in my opinio= n) for discussions about the previous document version (-04) I have the fol= lowing comments on this version: 1. it is not clear the BFD's scope Sect. 1: PW, LSP, SPME Sect. 1: LSP Sect 3: LSP Sect 3.1:LSP, PW Sect 3.3: PW, LSP, SPME, Section Sect 3.7: LSP 2. encapsulation Sect 1: supported encapsulation GAL/GACh, VCCV, UDP/IP: can be expr= essed a preference (MUST/MAY) for Transport Profile applications for intero= perability issues? I would avoid single vendor networks coming from too man= y options. 3. diagnostic code 5 Could you clarify what is the BFD state machine behavior receiving/= transmitting a Diagn Code=3D5 4. detection time Sect 3.2: I expect it is that one defined in RFC5884 i.e. detect Mu= lt x greater (bfd.requiredminrxinterval, last received desired min tx inter= val). What "interval" means is not clear 5. session periodicity Sec 3.3 Should be clarified being not defined in RFC5880 6. detection of loss of continuity Sect 3.3 can CV packet sent on the wire replace CC packet (for LOC= purpose on the far end)? 7. CV vs CC packets Sect 3.6 Generally speaking, how should the received CV packet's fi= elds be managed with respect of the BFD state machine/BFD states? (beyond w= hat is specified in such paragraph limited to P/F and Sta). 8. encoding Sect 3.5: could you clarify what " A BFD session will only use one = encoding of the Source ID TLV" means? 9. editorial Source ID TLV, MEP source ID TLV, Source MEP TLV should be aligned 10. terminology Wrt sect 3.6 I would ask a clarification about the terminology wher= e I found a- "A BFD session corresponds to a CC and proactive CV OAM instance= " b- " A BFD session is enabled when the CC and proactive CV function= ality is enabled" c- " When the CC and proactive CV functionality is disabled ..., th= e BFD session transitions to the ADMIN DOWN State and the BFD session ends" In the ADMIN DOWN state I understood I can have BFD control= packet exchange between the end points. Is it consistent with CC/CV functi= onality disabled? 11. code points Code points are not specified in section 3.1 as stated 12. BFD fixed rate Sect 3.7 " This rate is a fixed value common for both directions of= MEG for the lifetime of the MEG". Is this statement implying that MEG must= be destroyed to be able to change the BFD rate? Should not be limited to t= he BFD session lifetime (to be clarified what it means... because moving to= ADMIN DOWN state both ends could not be enough) 13. two BFD modes Sect 3.7 " Two independent BFD sessions are used for independent op= eration". In my opinion, this approach still remain a big limitation in BFD= usage. Is it implementation specific the way the two ends distinguish betw= een the two BFD modes? 14. bfd.RemoteDiscr Sect 3.7 " In coordinated mode, an implementation SHOULD NOT reset = bfd.RemoteDiscr until it is exiting the DOWN state" Is it a deviation from BFD as specified in RFC 5880? If it is, coul= d you clarified the reason for that? 15. bfd.RemoteDiscr Sect 3.7 Could you clarify the reasons behind different treatments = for bfd.RemoteDiscr in coordinated mode and independent mode? 16. overall operation Sect 3.7 "Overall operation is as specified in [4] and augmented fo= r MPLS in[8]" Are you sure that it can be generalized in that way? Should not be = the case to specify more in details what applies and what do not apply? 17. IP-based BFD Sect 3.1 IP-based BFD can carry out CV functionality only if IP SA= is public 18. CV during transient states Sect 3.2 for clarification: at start-up, CC are sent one per second= . CV are sent in addition to CC (so we have two BFD packets per second)? 19. misconnections Sect 3.7.3 sect 3.7.3 states a misconnection bring BFD session to D= OWN whilst it is not clear if sect 3.7.5 state that misconnection do not im= pact on BFD state transition 20. encapsulation modes Sect 4: if I understood well, there are 4 encapusulations and modes= for BFD: UDP/IP/LSP; CC mode in G-ACh; UPD/IP in G-ACh e CC/CV mode in G-A= Ch. Do all of them satisfy transport requirements? I understand they are not interoperable (as well as the two BFD mod= e for the same CC/CV in G-Ach encapsulation). Is it correct? Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Loa A= ndersson Inviato: mercoled=EC 6 luglio 2011 17:44 A: Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Oggetto: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving questions = on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is= : On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS work= ing group last call; these comments - and the intended resolution - is inc= luded in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 = days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without do= ubt that no comments been ignored. Loa mpls wg document shepherd On 2011-07-05 00:02, Rui Costa wrote: > IMHO and for the record: > > ITU-T comments regarding this draft haven't been discussed with ITU-T but= were simply ignored. No LS describing these comments' resolution was sent. > > Several service providers regarded this draft as not meeting their transp= ort networks' needs. > > [The v03 draft was published in Feb and went to WG LC. > The v04 draft addressing WG LC comments was published on the 28th June (s= ame date as the proto write-up). > When was the WG LC launched, to verify LC comments resolution?] > > Regards, > Rui > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of The IESG > Sent: quinta-feira, 30 de Junho de 2011 14:47 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: > (Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching > WG > (mpls) to consider the following document: > - 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From malcolm.betts@zte.com.cn Wed Jul 13 07:44:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CB011E80E0; Wed, 13 Jul 2011 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fafudOx4FqY; Wed, 13 Jul 2011 07:44:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8266511E80B6; Wed, 13 Jul 2011 07:44:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321784411434; Wed, 13 Jul 2011 22:38:22 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 33116.2478792715; Wed, 13 Jul 2011 22:44:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6DEiM4X008780; Wed, 13 Jul 2011 22:44:22 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: References: To: Ross Callon MIME-Version: 1.0 X-KeepSent: 41CDDFB8:012DC6EF-852578CC:0050E7D9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 13 Jul 2011 10:44:05 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-13 22:44:26, Serialize complete at 2011-07-13 22:44:26 Content-Type: multipart/alternative; boundary="=_alternative 0050F6F8852578CC_=" X-MAIL: mse02.zte.com.cn p6DEiM4X008780 Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:44:43 -0000 This is a multipart message in MIME format. --=_alternative 0050F6F8852578CC_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KDQoNClJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PiANClNl bnQgYnk6IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMTIvMDcvMjAxMSAxMTozMSBBTQ0KDQpUbw0K Im1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KY2MNClJvc3MgQ2FsbG9uIDxyY2FsbG9u QGp1bmlwZXIubmV0PiwgDQoiZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnNAdG9v bHMuaWV0Zi5vcmciIA0KPGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzQHRvb2xz LmlldGYub3JnPg0KU3ViamVjdA0KW21wbHNdIFBvbGwgb24gZHJhZnQtd2luLW1wbHMtdHAtaXR1 LXQtaWRlbnRpZmllcnMtMDENCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQogDQp0aGlzIGlz IHRvIHN0YXJ0IGEgMTIgZGF5IHBvbGwgb24gbWFraW5nDQogDQpkcmFmdC13aW4tbXBscy10cC1p dHUtdC1pZGVudGlmaWVycy0wMQ0KIA0KYW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K IA0KSWYgeW91IHN1cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nIGEgd29ya2luZyBncm91cCBk b2N1bWVudCBwbGVhc2UgDQpyZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICJ5ZXMvc3VwcG9ydCIN CiANCklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5n IGdyb3VwIGRvY3VtZW50IA0KcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGggIm5vL2Rv IG5vdCBzdXBwb3J0IiBhbmQgYXQgdGhlIHNhbWUgdGltZSANCmdpdmUgdGhlIHRlY2huaWNhbCBy ZWFzb25zIHdoeSB5b3UgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC4NCiANCklmIHlv dSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyBvciBpbiBhbnkgb3RoZXIgd2F5IHdhbnQgdG8gZGlz Y3VzcyB0aGUgDQpkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlc2UgY29tbWVudHMgdG8gdGhlIG1w bHMgd29ya2luZyBncm91cCBtYWlsaW5nIA0KbGlzdCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0 IHRoYW4gd2hhdCBpcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIA0KdGhlIA0Kc3RyaW5n IOKAnGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJz4oCdIGluIHRoZSBzdWJqZWN0 IGxpbmUuIA0KIA0KVGhlIHBvbGwgZW5kcyAyMDExLTA3LTI0LiAgUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIGlzIHRoZSBTdW5kYXkgYmVmb3JlIHRoZSANCklFVEYuIEFsc28gbm90ZSB0aGF0IHRoZSBs ZW5ndGggb2YgdGhlIHBvbGwgaGFzICBiZWVuIHNob3J0ZW5lZCBieSB0d28gDQpkYXlzIA0Kc28g dGhhdCB0aGUgcG9sbCBjYW4gYmUgY29tcGxldGVkIHByaW9yIHRvIG91ciBmaXJzdCBXRyBtZWV0 aW5nIGluIFF1ZWJlYyANCkNpdHkuIA0KIA0KUm9zcw0KIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 0050F6F8852578CC_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9zdXBwb3J0PC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlJvc3MgQ2FsbG9uICZsdDty Y2FsbG9uQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+U2VudCBieTogbXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEyLzA3LzIwMTEgMTE6MzEgQU08L2ZvbnQ+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDttcGxz QGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJv c3MgQ2FsbG9uICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OywNCiZxdW90O2RyYWZ0LXdpbi1t cGxzLXRwLWl0dS10LWlkZW50aWZpZXJzQHRvb2xzLmlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC13 aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc0B0b29scy5pZXRmLm9yZyZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlttcGxzXSBQb2xsIG9uIGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50 aWZpZXJzLTAxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPldvcmtpbmcgR3JvdXAsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPnRoaXMgaXMgdG8gc3RhcnQgYSAxMiBkYXkgcG9sbCBvbiBtYWtpbmc8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmll cnMtMDE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+YW4gbXBscyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JZiB5b3Ugc3VwcG9ydCB0 aGUgZG9jdW1lbnQgYmVjb21pbmcgYQ0Kd29ya2luZyBncm91cCBkb2N1bWVudCBwbGVhc2UgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5yZXNwb25kIHRvIHRoaXMgcG9s bCB3aXRoICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcNCmEgd29ya2lu ZyBncm91cCBkb2N1bWVudCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PnBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICZxdW90O25vL2RvDQpub3Qgc3VwcG9y dCZxdW90OyBhbmQgYXQgdGhlIHNhbWUgdGltZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPmdpdmUgdGhlIHRlY2huaWNhbCByZWFzb25zIHdoeSB5b3UgYXJlDQpub3Qg c3VwcG9ydGluZyB0aGUgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPklm IHlvdSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyBvciBpbiBhbnkNCm90aGVyIHdheSB3YW50IHRv IGRpc2N1c3MgdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ZG9j dW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1lbnRzIHRvDQp0aGUgbXBscyB3b3JraW5nIGdy b3VwIG1haWxpbmcgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5saXN0 LCBidXQgd2l0aCBhbm90aGVyIHN1YmplY3QgdGhhbiB3aGF0DQppcyBvbiB0aGlzIG1haWwuIFBs ZWFzZSBpbmNsdWRlIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PnN0cmluZyDigJxkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc+KAnQ0KaW4gdGhl IHN1YmplY3QgbGluZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZSBwb2xsIGVu ZHMgMjAxMS0wNy0yNC4gJm5ic3A7UGxlYXNlDQpub3RlIHRoYXQgdGhpcyBpcyB0aGUgU3VuZGF5 IGJlZm9yZSB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JRVRG LiBBbHNvIG5vdGUgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZQ0KcG9sbCBoYXMgJm5ic3A7YmVlbiBz aG9ydGVuZWQgYnkgdHdvIGRheXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5zbyB0aGF0IHRoZSBwb2xsIGNhbiBiZSBjb21wbGV0ZWQgcHJpb3INCnRvIG91ciBmaXJz dCBXRyBtZWV0aW5nIGluIFF1ZWJlYyBDaXR5LiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+Um9zczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5v cmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBsczwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0050F6F8852578CC_=-- From venkatflex@gmail.com Wed Jul 13 07:59:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3680721F870F for ; Wed, 13 Jul 2011 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTKw3VXGzOXl for ; Wed, 13 Jul 2011 07:59:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E921F86EA for ; Wed, 13 Jul 2011 07:58:59 -0700 (PDT) Received: by wwe5 with SMTP id 5so4032403wwe.13 for ; Wed, 13 Jul 2011 07:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=12WTtZ7foksTQaj76XAwzfUZVgOIZj1JF3ysTOXzgaM=; b=I40cD1DGFsCRtqcNG6jU1IZZ72AMS+8IyExdQ3Qxdk5QMEMKjCA98HhD5lGcEbNLg+ 3+mgIFVo7Lx0UD2Dd8Ws/aylXA8kx4cLlaWxuZ9AGAeGGuiUIJRf3Y0M/YseyscGgIE4 DduxABYfDI7jyCH5I3vtKQJ5zB8+3NN6SPVJA= MIME-Version: 1.0 Received: by 10.216.136.202 with SMTP id w52mr5189989wei.68.1310569138010; Wed, 13 Jul 2011 07:58:58 -0700 (PDT) Received: by 10.216.183.19 with HTTP; Wed, 13 Jul 2011 07:58:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jul 2011 10:58:57 -0400 Message-ID: From: venkatesan mahalingam To: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Content-Type: multipart/alternative; boundary=0016e6d55a38ecb8b804a7f4a779 Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:59:03 -0000 --0016e6d55a38ecb8b804a7f4a779 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes/Support Regards, Venkat. > *Ross Callon * > Sent by: mpls-bounces@ietf.org > > 12/07/2011 11:31 AM > To > "mpls@ietf.org" > cc > Ross Callon , " > draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" < > draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org> > Subject > [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 > > > > > Working Group, > > this is to start a 12 day poll on making > > draft-win-mpls-tp-itu-t-identifiers-01 > > an mpls working group document. > > If you support the document becoming a working group document please > respond to this poll with "yes/support" > > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same time > give the technical reasons why you are not supporting the document. > > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please include > the > string =93draft-win-mpls-tp-itu-t-identifiers=94 in the subject line. > > The poll ends 2011-07-24. Please note that this is the Sunday before the > IETF. Also note that the length of the poll has been shortened by two da= ys > > so that the poll can be completed prior to our first WG meeting in Quebec > City. > > Ross > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --0016e6d55a38ecb8b804a7f4a779 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes/Support

Regards,
Venkat.


Ross Callon <r= callon@juniper.net>
Sent by: mpls-bounces@ietf.org

12/07/2011 11:31 AM

To
"mpls@ietf.org" <mpls@ietf.org>
cc
Ross Callon <rcallon@juniper.net>, "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org&q= uot; <draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org>
Subject
[mpls] Poll on draft-win-mpls= -tp-itu-t-identifiers-01





Working Group,
=A0
this is to start a 12 day poll on mak= ing
=A0
draft-win-mpls-tp-itu-t-identifiers-0= 1
=A0
an mpls working group document.
=A0
If you support the document becoming = a working group document please
respond to this poll with "yes/s= upport"
=A0
If you do not support the document be= coming a working group document
please respond to this poll with &quo= t;no/do not support" and at the same time
give the technical reasons why you ar= e not supporting the document.
=A0
If you have technical comments or in = any other way want to discuss the
document, please send these comments = to the mpls working group mailing
list, but with another subject than w= hat is on this mail. Please include the
string =93draft-win-mpls-tp-itu-t-ide= ntifiers=94 in the subject line.
=A0
The poll ends 2011-07-24. =A0Please note that this is the Sunday before the
IETF. Also note that the length of th= e poll has =A0been shortened by two days
so that the poll can be completed pri= or to our first WG meeting in Quebec City. =A0
=A0
Ross
=A0___________________________________= ____________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=


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


--0016e6d55a38ecb8b804a7f4a779-- From nurit.sprecher@nsn.com Wed Jul 13 08:21:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FECF11E8107 for ; Wed, 13 Jul 2011 08:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=3.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg5f7+3kBkho for ; Wed, 13 Jul 2011 08:21:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6568611E8095 for ; Wed, 13 Jul 2011 08:21:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6DFLKkJ024702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jul 2011 17:21:20 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6DFLJSV024355; Wed, 13 Jul 2011 17:21:20 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 17:21:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4170.7C95C413" Date: Wed, 13 Jul 2011 17:21:04 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326404203FD4@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAxvbRw References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Ross Callon" , X-OriginalArrivalTime: 13 Jul 2011 15:21:07.0026 (UTC) FILETIME=[7CA56B20:01CC4170] Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:21:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4170.7C95C413 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am a bit concerned.=20 I think the IETF should support ICC based identifiers as required and agreed.=20 BUT I am concerned from the same technical concerns and question that K.Y. and Stewart raised up. I think the document is immature for adoption.=20 Moreover, I do not think it is the role of the IETF to define the format of global ICC. We need to ask the ITU-T for a reference to a document that defines global ICC to ensure consistent definition with other transport networks.=20 I do not think the IETF should refer to a liaison as a technical specification as is, but as a mean to get a pointer to the appropriate document that we need to refer to.=20 I do not see the benefit in just putting a place holder for an IETF document. Let's first bring the information and then we should progress with the document.=20 Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Ross Callon Sent: Tuesday, July 12, 2011 6:32 PM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same time=20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include the=20 string "draft-win-mpls-tp-itu-t-identifiers" in the subject line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before the=20 IETF. Also note that the length of the poll has been shortened by two days=20 so that the poll can be completed prior to our first WG meeting in Quebec City. =20 =20 Ross =20 ------_=_NextPart_001_01CC4170.7C95C413 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am a bit concerned.

I think the IETF should support ICC based identifiers as required and = agreed.

BUT

I am concerned from the same technical concerns and question that = K.Y. and Stewart raised up. I think the document is immature for = adoption.

Moreover, I do not think it is the role of the IETF to define the = format of global ICC. We need to ask the ITU-T for a reference to a = document that defines global ICC to ensure consistent definition with = other transport networks.

I do not think the IETF should refer to a liaison as a technical = specification as is, but as a mean to get a pointer to the appropriate = document that we need to refer to.

I do not see the benefit in just putting a place holder for an IETF = document. Let's first bring the information and then we should progress = with the document.

Best regards,

Nurit

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Ross Callon
Sent: Tuesday, July 12, 2011 6:32 = PM
To: mpls@ietf.org
Cc: Ross Callon; = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

<= p class=3DMsoNormal> 

Working = Group,

 =

this is to = start a 12 day poll on making

 =

draft-win-m= pls-tp-itu-t-identifiers-01

 =

an mpls = working group document.

 =

If you = support the document becoming a working group document please =

respond to = this poll with = "yes/support"

 =

If you do = not support the document becoming a working group document =

please = respond to this poll with "no/do not support" and at the same = time

give the = technical reasons why you are not supporting the = document.

 =

If you = have technical comments or in any other way want to discuss the =

document, = please send these comments to the mpls working group mailing =

list, but = with another subject than what is on this mail. Please include the =

string = “draft-win-mpls-tp-itu-t-identifiers” in the subject line. =

 =

The poll = ends 2011-07-24.  Please note that this is the Sunday before the =

IETF. Also = note that the length of the poll has  been shortened by two days =

so that = the poll can be completed prior to our first WG meeting in Quebec = City. 

 =

Ross

 =

------_=_NextPart_001_01CC4170.7C95C413-- From curtis@occnc.com Wed Jul 13 10:09:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B86B21F876F for ; Wed, 13 Jul 2011 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7mijOEa17lq for ; Wed, 13 Jul 2011 10:09:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2321F86EA for ; Wed, 13 Jul 2011 10:09:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6DH9Go7092662; Wed, 13 Jul 2011 13:09:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107131709.p6DH9Go7092662@harbor.orleans.occnc.com> To: Ross Callon From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Jul 2011 11:31:46 EDT." Date: Wed, 13 Jul 2011 13:09:16 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 17:09:18 -0000 In message Ross Callon writes: > > Working Group, > > this is to start a 12 day poll on making > > draft-win-mpls-tp-itu-t-identifiers-01 > > an mpls working group document. > > If you support the document becoming a working group document please > respond to this poll with "yes/support" > > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same time > give the technical reasons why you are not supporting the document. > > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please include th= > e > string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. > > The poll ends 2011-07-24. Please note that this is the Sunday before the > IETF. Also note that the length of the poll has been shortened by two days > so that the poll can be completed prior to our first WG meeting in Quebec C= > ity. > > Ross No / Do not support This should be input to draft-ietf-mpls-tp-identifiers-06 which is already a WG document and has matured quite a bit over its six iterations so far. I'm not saying that it should be accepted, but it is input. If anything this is a new 13 byte Global_ID that might be considered as an alternate to the 4-octet AS number (which is essentially what the draft suggests). However the problem is that the ASCII is OK for configuration but the four byte binary is used in the AII type 2 used in PW [RFC5003, RFC4446]. A new AII type is needed if this format is accepted. There is also the issue that the Tunnel_ID and Extended_Tunnel_ID in RFC3209 is 4 bytes or 16 bytes and has in the past been a globally unique identifier that happens to be an IP address. In draft-ietf-mpls-tp-identifiers this is set to the node_ID which happily fits nicely. Any attempt to use ICC/CC would have to update all documents that currently use a four byte or 16 byte identifier which is normally configured with an IPv4 or IPv6 address. Since this is likely to be impractical and breaks backwards compatibility with all MPLS implementations up to now, I dont' support this. Curtis From jdrake@juniper.net Wed Jul 13 10:21:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D0D11E80DD for ; Wed, 13 Jul 2011 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.595 X-Spam-Level: X-Spam-Status: No, score=-4.595 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljRGKdLBug2f for ; Wed, 13 Jul 2011 10:21:20 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4D11E817D for ; Wed, 13 Jul 2011 10:21:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTh3UC4VZpPbaMa+NGQTEJIi1cP1t7Cc8@postini.com; Wed, 13 Jul 2011 10:21:19 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 13 Jul 2011 10:18:45 -0700 From: John E Drake To: D'Alessandro Alessandro Gerardo , "mpls@ietf.org" Date: Wed, 13 Jul 2011 10:18:44 -0700 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaAAB3ekGAAETQeUA== Message-ID: <5E893DB832F57341992548CDBB333163A0A91E8CE9@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 17:21:23 -0000 --_004_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_ Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_" --_000_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alessandro, I was not taking a position. Rather, I was strictly asking a procedural qu= estion. Thanks, John Sent from my iPhone From: D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@teleco= mitalia.it] Sent: Wednesday, July 13, 2011 2:07 AM To: John E Drake; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: R: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Dear John, if you mean "do not support", please could you provide a technical reason.= I'm interested in knowing your position. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di John = E Drake Inviato: marted=EC 12 luglio 2011 20:50 A: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Oggetto: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Ross, Isn't it a bit premature to be asking to make this a working group document= ? Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:image001.gif@01CC4146.3E865950]Rispetta l'ambiente. Non stampare quest= a mail se non =E8 necessario. --_000_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Alessandr= o,

 

I was not taking a position.=A0 Rather, I = was strictly asking a procedural question.

 

Th= anks,

 

John

 

Sent from my iPhone

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@telecomitali= a.it]
Sent: Wednesday, July 13, 2011 2:07 AM
To: John = E Drake; mpls@ietf.org
Cc: draft-win-mpls-tp-itu-t-identifiers@to= ols.ietf.org
Subject: R: Poll on draft-win-mpls-tp-itu-t-identifi= ers-01

 

Dear John,

if you mean “do not suppor= t”, please could  you provide a technical reason. = I’m interested in knowing your position.<= /o:p>

 

Best regards,

Alessandro

 

-----------------------------------------------------= -------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation=
Via Reiss Romoli, 274 - 10148 Torino
phon= e:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 63= 9 07

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

Da: mpls-bounces@ietf.or= g [mailto:mpls-bounces@ietf.org] Per conto di John E Drake
Inv= iato: marted=EC 12 luglio 2011 20:50
A: Ross Callon; mpls@iet= f.org
Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
<= b>Oggetto: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

=  

Ros= s,

=  

Isn’t it a bit premature to be asking to make this a working grou= p document?

 

Thanks,

 

John

 

Sent from my iPhone

 

From= : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of <= /b>Ross Callon
Sent: Tuesday, July 12, 2011 8:32 AM
To:= mpls@ietf.org
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifie= rs@tools.ietf.org
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t= -identifiers-01

 

Working Group,

 

this is to start a 12 day poll on making

 

draft-win-mpls-tp-itu= -t-identifiers-01

 

<= p class=3DMsoNormal>an mpls working group document.

 

If you support the document becomin= g a working group document please =

respond to this poll with "yes/support&qu= ot;

&n= bsp;

I= f you do not support the document becoming a working group document =

please respo= nd to this poll with "no/do not support" and at the same time

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>give the= technical reasons why you are not supporting the document.

 

If you have techni= cal comments or in any other way want to discuss the

document, please send these= comments to the mpls working group mailing

list, but with another subject than = what is on this mail. Please include the =

string “draft-win-mpls-tp-itu-t-i= dentifiers” in the subject line.

 <= /span>

The poll ends 2011-07-24.  Please n= ote that this is the Sunday before the

IETF. Also note that the length of the po= ll has  been shortened by two days <= /span>

so that the poll can be completed prior = to our first WG meeting in Quebec City.  <= /o:p>

 =

Ross<= /o:p>

 =

=

Questo messaggio e= i suoi allegati sono indirizzati esclusivamente alle persone indicate. La = diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di qu= este informazioni sono rigorosamente vietate. Qualora abbiate ricevuto ques= to documento per errore siete cortesemente pregati di darne immediata comun= icazione al mittente e di provvedere alla sua distruzione, Grazie. <= /span>

This e-mail and any attachments is confidential a= nd may contain privileged information intended for the addressee(s) only. D= issemination, copying, printing or use by anybody else is unauthorised. If = you are not the intended recipient, please delete this message and any atta= chments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

 

= --_000_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_-- --_004_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Wed, 13 Jul 2011 10:18:44 GMT"; modification-date="Wed, 13 Jul 2011 10:18:44 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_5E893DB832F57341992548CDBB333163A0A91E8CE9EMBX01HQjnprn_-- From curtis@occnc.com Wed Jul 13 10:43:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94B11E821F for ; Wed, 13 Jul 2011 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqAtsjdss4o0 for ; Wed, 13 Jul 2011 10:43:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48911E81E6 for ; Wed, 13 Jul 2011 10:42:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6DHgMXl093080; Wed, 13 Jul 2011 13:42:22 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> To: neil.2.harrison@bt.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 13 Jul 2011 13:42:22 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, stbryant@cisco.com Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 17:43:08 -0000 In message <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> neil.2.harrison@bt.com writes: > > I also have a question on this draft: > > How do different MPLS-TP layer networks that belong to the same > operator get differentiated...noting that these may form nested > client/server relationships and thus be subject to inter-layer > misconnectivity as well as intra-layer misconnectivity? > > Thanks.....regards, Neil How about the operator allocates from a different IP prefix for each layer and uses a one line policy statement to prevent inter-layer misconnectivity even if misconfiguration were to occur. Oops. Wrong type of identifiers. No identifier aggregation in the ICC/CC name space. :-) IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. At least those could be aggregated (not that I recommend using them). Curtis From erminio.ottone_69@libero.it Wed Jul 13 11:12:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AED21F8BE4 for ; Wed, 13 Jul 2011 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vtsubUQmiOx for ; Wed, 13 Jul 2011 11:12:07 -0700 (PDT) Received: from outrelay03.libero.it (outrelay03.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2170121F8BE1 for ; Wed, 13 Jul 2011 11:12:03 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4E1DDFEF.0103,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay03.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF1D02FE87DF; Wed, 13 Jul 2011 20:11:59 +0200 Message-ID: <32340512.3269151310580719542.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 20:11:59 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_244863_16724237.1310580719542" X-SenderIP: 79.45.147.208 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: [mpls] R: Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 18:12:08 -0000 ------=_Part_244863_16724237.1310580719542 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes/support ----Messaggio originale---- Da: rcallon@juniper.net Data: 12-lug-2011 17.31 A: "mpls@ietf.org" Cc: "Ross Callon", "draft-win-mpls-tp-itu-t-identifier= s@tools.ietf.org" Ogg: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2p= x solid; } -> .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-lef= t: #800000 2px solid; } -> --> Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same time= =20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include th= e=20 string =E2=80=9Cdraft-win-mpls-tp-itu-t-identifiers=E2=80=9D in the subject= line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before the= =20 IETF. Also note that the length of the poll has been shortened by two days= =20 so that the poll can be completed prior to our first WG meeting in Quebec C= ity. =20 =20 Ross =20 ------=_Part_244863_16724237.1310580719542 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable

yes/support

----Messaggio originale----
Da: rcallon@juniper.net
Data:= 12-lug-2011 17.31
A: "mpls@ietf.org"<mpls@ietf.org>
Cc: "Ross = Callon"<rcallon@juniper.net>, "draft-win-mpls-tp-itu-t-identifiers@to= ols.ietf.org"<draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org>
= Ogg: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please <= /DIV>
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document <= /DIV>
please respond to this poll with "no/do not support" and at the same t= ime
give the technical reasons why you are not supporting the document.
 
If you have technical comments or in any other way want to discuss the=
document, please send these comments to the mpls working group mailing=
list, but with another subject than what is on this mail. Please inclu= de the
string =E2=80=9Cdraft-win-mpls-tp-itu-t-identifiers=E2=80=9D in the su= bject line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday be= fore the
IETF. Also note that the length of the poll has  been shortened b= y two days
so that the poll can be completed prior to our first WG meeting in Que= bec City. 
 
Ross
 


------=_Part_244863_16724237.1310580719542-- From erminio.ottone_69@libero.it Wed Jul 13 13:26:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6105F11E80F1; Wed, 13 Jul 2011 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAxwydXa3vjY; Wed, 13 Jul 2011 13:26:40 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8F11E807D; Wed, 13 Jul 2011 13:26:40 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0204.4E1DFF7B.00C8,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF25035F586E; Wed, 13 Jul 2011 22:26:35 +0200 Message-ID: <31453662.3306881310588795478.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:26:35 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "RCosta@ptinovacao.pt" , "ietf@ietf.org" , IETF-Announce MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" Subject: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:26:41 -0000 >However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul.... This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase "decide whether LSP-Ping or BFD can or should be tweaked or not" and slide 46 reckons "many options including non IP BFD is an option encapsulation of Y.1731 PDU" It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 6-lug-2011 20.24 >A: "erminio.ottone_69@libero.it", "RCosta@ptinovacao.pt", "ietf@ietf.org", "IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > > >>Several service providers regarded this draft as not meeting their >>transport networks' needs. > >E> This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. > >The two statements do not necessarily follow. > >What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. > >However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul.... > >My 2 cents >Dave > From erminio.ottone_69@libero.it Wed Jul 13 13:27:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB7611E810F; Wed, 13 Jul 2011 13:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBLbf28wfCN1; Wed, 13 Jul 2011 13:27:59 -0700 (PDT) Received: from outrelay02.libero.it (outrelay02.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF811E8114; Wed, 13 Jul 2011 13:27:58 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4E1DFFC9.010E,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay02.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E09A78E01913BCF; Wed, 13 Jul 2011 22:27:53 +0200 Message-ID: <27773911.3307261310588873729.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:27:53 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "loa@pi.nu" , Rui Costa MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:27:59 -0000 Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 6-lug-2011 19.35 >A: "erminio.ottone_69@libero.it", "loa@pi.nu" , "Rui Costa" >Cc: "mpls@ietf.org", "ietf@ietf.org", "IETF- Announce" >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > >Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. > >Cheers >Dave > From erminio.ottone_69@libero.it Wed Jul 13 13:32:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116F511E80F1; Wed, 13 Jul 2011 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.418 X-Spam-Level: * X-Spam-Status: No, score=1.418 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp9F3f0-IuGe; Wed, 13 Jul 2011 13:32:14 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2B13921F89BA; Wed, 13 Jul 2011 13:32:14 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4E1E00CA.000D,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF25035F7043; Wed, 13 Jul 2011 22:32:09 +0200 Message-ID: <24102355.3308421310589129962.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:32:09 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , , , IETF-Announce MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: mpls@ietf.org Subject: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:32:15 -0000 The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? >----Messaggio originale---- >Da: nurit.sprecher@nsn.com >Data: 7-lug-2011 11.59 >A: , , , "IETF-Announce" >Cc: >Ogg: RE: [mpls] R: Re: LastCall: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard > >Erminio, >I do not think the history is relevant for this specific discussion... >Also I find it inappropriate to give statements with no justifications >behind. >You say: "the solution in this draft is useless for many MPLS-TP >deployments.". in order to seriously consider your comment, you have to >show why it is useless and which requirements are not satisfied. >Otherwise you cannot expect anyone to refer to your point. >Best regards, >Nurit > >P.s. did you mean that the document is useless to available non-standard >deployments, e.g. T-MPLS? > > From erminio.ottone_69@libero.it Wed Jul 13 13:38:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16111E80C3; Wed, 13 Jul 2011 13:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtiAClvlRKKW; Wed, 13 Jul 2011 13:38:49 -0700 (PDT) Received: from outrelay03.libero.it (outrelay03.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id 640D821F8A51; Wed, 13 Jul 2011 13:38:47 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0203.4E1E0251.00E3,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay03.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF1D03011860; Wed, 13 Jul 2011 22:38:41 +0200 Message-ID: <947166.3310311310589521384.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:38:41 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , Rui Costa , Stewart Bryant MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: [mpls] R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:38:53 -0000 >I would not go so far as to say "similar to 1731", there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectional p2p and p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor does resolve the technical issue that have been raised. >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 8-lug-2011 18.13 >A: "Rui Costa", "Stewart Bryant" >Cc: "erminio.ottone_69@libero.it", "mpls@ietf. org", "ietf@ietf.org", "IETF-Announce" >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Rui: > >You wrote: > >>Reading something, keeping it on record, without effect in the draft and "ignoring comments" have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact >>in our work, so i'm also free to write what i did. > >Numerous comments did have effect on the draft and those that didn't were either simply not actionable, were rhetorical or not constructive, and a few had to be balanced against comments coming from the MPLS & BFD WGs. I would translate "ingored" or "without effect" to "did not get one'e way". In the standards process it happens. > >Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... > >>My technical concerns regarding this draft were expressed... >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe); >>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; > >I and the WG don't really have access to private grumblings. > >>...in a comparison session that took place during that same ITU-T meeting. > >Lots of other opinions were expressed as well, and they did not all agree with you. > >>Some: >>CC/CV >>I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. >>Besides adding complexity, we whether always activate both or potentiate undetected mismerges. > >OK, lets walk through this. > >We want CV all the time so that any misconectivity can be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. > >>(BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T) > >Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... > >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other than... >> ...eliminating the session "state variable" (down, init, up), aiming just the state variables we really need, bringing us to something similar to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume per requirements; >> Will we create a complete different tool for that? >> (BFD's B="bidirectional") > >I would not go so far as to say "similar to 1731", there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. > >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through a particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that profile/configuration. However, i keep seeing >> references f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP, are we talking about MPLS in general?... The TP profile is never quite delimited. >> Does chapter 4 contain ALL the configurable parameters list agreed to provide in the comparison session? > >It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation. > >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards compatible with previous BFD (even considering just CC/CV). They don't even share the same codepoint. > >The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. > >>Simplicity >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: in each flow, a standard defined nr of constant heartbeat signals (with standard constant or provisioned period - no >>auto/negotiated -) means OK. A standard defined number of misses means lost Rx connection. An RDI, the only articulation between Rx and Tx flows, meaningful in bidirectional applications, allows each >>pear to identify Tx problems. >>This OAM simplicity is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more implementation opportunities/manufacturers, which is valuable for >>operators. > >Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide "design intent" implied here. > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. > >That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. > >Hope this helps >D > > > > > > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 19:25 >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > > >>Several service providers regarded this draft as not meeting their >>transport networks' needs. > >E> This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. > >The two statements do not necessarily follow. > >What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. > >However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul.... > >My 2 cents >Dave > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 18:36 >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > >Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. > >Cheers >Dave > > > > >-----Original Message----- >From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] >Sent: quarta-feira, 6 de Julho de 2011 18:34 >To: Rui Costa; ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >The way this draft has been developed is a bit strange. > >The poll for its adoption as a WG document was halted by the MPLS WG chair because "it is not possible to judge consensus": > >http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > >The lack of consensus was motivated by serious technical concerns raised by several transport experts during the poll. > >Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: > >http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > >After several WG revisions and WG LCs, the technical issues have not been resolved. > >>Several service providers regarded this draft as not meeting their >>transport >networks' needs. > >This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. > > >-----Original Message----- >From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] >Sent: quarta-feira, 6 de Julho de 2011 18:26 >To: loa@pi.nu; Rui Costa >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >> Version -04 of the document was published June 28th. >> >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent >> June 29th. >> > >So when the WG LC to confirm the LC comment resolution has been launched? > >The proto write-up says: > > It has also passed a working roup call to verify that LC comments were correctly with minor comments. > >It also says: > > The comments has been > carefully discussed between the authors and people making the comments and > has been resolved. > >But it seems that some comments have not been discussed with the authors of the comments. When ITU-T Q10/15 has been involved in discussing its comments? > > > > >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: quarta-feira, 6 de Julho de 2011 16:44 >To: Rui Costa >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >All, > >Since someone has commented about the process used for resolving >questions on >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >process is: > >On February 3rd 2011 the working group last call was issued >on version -03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > >The authors compiled a list of all comments received as part the MPLS >working group last call; these comments - and the intended resolution - >is included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD working > group to do a separate working group last callfor the BFD working > group > >The (BFD) working group last call was started on March 30th and ran >for 13 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some > issue has been brought to the working group mailing list for > resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editorial > comments. Version -05 was published on June 29 and the IETF last call > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiable at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows without >doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > > > > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 14:58 >To: Rui Costa; ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Hi Rui: > >The comments were not ignored, the resolution of the Q10 comments as well as those collected from the MPLS WG was presented at the last IETF. My spreadsheet from which that report was generated and has been augmented to include the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments. xls > >So you know... >Dave > > >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui Costa >Sent: segunda-feira, 4 de Julho de 2011 23:03 >To: ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record: > >ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. > >Several service providers regarded this draft as not meeting their transport networks' needs. > >[The v03 draft was published in Feb and went to WG LC. >The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). >When was the WG LC launched, to verify LC comments resolution?] > >Regards, >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From erminio.ottone_69@libero.it Wed Jul 13 13:47:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE921F8AED; Wed, 13 Jul 2011 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1qca+PdiI8R; Wed, 13 Jul 2011 13:47:37 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2673521F8AEA; Wed, 13 Jul 2011 13:47:37 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4E1E0463.0071,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF25035FB03E; Wed, 13 Jul 2011 22:47:31 +0200 Message-ID: <6036596.3312721310590051192.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:47:31 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , Rui Costa , Stewart Bryant MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: [mpls] R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:47:38 -0000 >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards compatible with previous BFD (even considering just CC/CV). They don't even share the same codepoint. > >The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. > I disagree. From a backward compatibility perspecting the codepoint is very relevant. An existing implementation does not reckon the new encapsulation: the only way to deploy this solution in a backward compatible manner is by upgrading all the IP/MPLS nodes that have been deployed up to so far. I think that the "reuse of the majority of the implementation" is actually the issue. Those implementations do not have the capabilities required to be deployed in a transport network. Developing a non-transport capable standard will not make these boxes transport capable but it would just make the standard useless for a transport environment. >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 8-lug-2011 18.13 >A: "Rui Costa", "Stewart Bryant" >Cc: "erminio.ottone_69@libero.it", "mpls@ietf. org", "ietf@ietf.org", "IETF-Announce" >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Rui: > >You wrote: > >>Reading something, keeping it on record, without effect in the draft and "ignoring comments" have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact >>in our work, so i'm also free to write what i did. > >Numerous comments did have effect on the draft and those that didn't were either simply not actionable, were rhetorical or not constructive, and a few had to be balanced against comments coming from the MPLS & BFD WGs. I would translate "ingored" or "without effect" to "did not get one'e way". In the standards process it happens. > >Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise... > >>My technical concerns regarding this draft were expressed... >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe); >>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; > >I and the WG don't really have access to private grumblings. > >>...in a comparison session that took place during that same ITU-T meeting. > >Lots of other opinions were expressed as well, and they did not all agree with you. > >>Some: >>CC/CV >>I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. >>Besides adding complexity, we whether always activate both or potentiate undetected mismerges. > >OK, lets walk through this. > >We want CV all the time so that any misconectivity can be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. > >>(BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T) > >Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... > >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other than... >> ...eliminating the session "state variable" (down, init, up), aiming just the state variables we really need, bringing us to something similar to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume per requirements; >> Will we create a complete different tool for that? >> (BFD's B="bidirectional") > >I would not go so far as to say "similar to 1731", there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. > >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through a particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that profile/configuration. However, i keep seeing >> references f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP, are we talking about MPLS in general?... The TP profile is never quite delimited. >> Does chapter 4 contain ALL the configurable parameters list agreed to provide in the comparison session? > >It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation. > >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwards compatible with previous BFD (even considering just CC/CV). They don't even share the same codepoint. > >The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. > >>Simplicity >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: in each flow, a standard defined nr of constant heartbeat signals (with standard constant or provisioned period - no >>auto/negotiated -) means OK. A standard defined number of misses means lost Rx connection. An RDI, the only articulation between Rx and Tx flows, meaningful in bidirectional applications, allows each >>pear to identify Tx problems. >>This OAM simplicity is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more implementation opportunities/manufacturers, which is valuable for >>operators. > >Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide "design intent" implied here. > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. > >That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. > >Hope this helps >D > > > > > > From jdrake@juniper.net Wed Jul 13 13:48:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3911E8172; Wed, 13 Jul 2011 13:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KUBDFa6IZ8Q; Wed, 13 Jul 2011 13:48:46 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id AF7FF11E8171; Wed, 13 Jul 2011 13:48:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTh4EpYgppywL+vECy6KA5u1FPSPomo02@postini.com; Wed, 13 Jul 2011 13:48:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 13 Jul 2011 13:46:28 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "david.i.allan@ericsson.com" , "RCosta@ptinovacao.pt" , "ietf@ietf.org" , IETF-Announce Date: Wed, 13 Jul 2011 13:46:27 -0700 Thread-Topic: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxBmzNJGVqWfL2eQJSfSHict657jgAAmysw Message-ID: <5E893DB832F57341992548CDBB333163A0A91E90F6@EMBX01-HQ.jnpr.net> References: <31453662.3306881310588795478.JavaMail.defaultUser@defaultHost> In-Reply-To: <31453662.3306881310588795478.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:48:50 -0000 Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/m= pls-17_files/frame.htm), with Huub's name as an author, details a plan for = MPLS-TP OAM which the MPLS WG has followed to this day. I think the report= is compelling evidence that the claim that a packet transport network is a= n MPLS application that intrinsically requires a different OAM solution is = simply a lame ex post facto attempt to justify the ITU's abrogation of the = agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15= ): "The ITU-T accepts these recommendations and states that any extensions to = MPLS technology will be progressed via the IETF standards process using the= procedures defined in RFC 4929 (Change Process for Multiprotocol Label Swi= tching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Expe= rts from the ITU-T will assist the IETF in the development of RFCs that des= cribe the transport extensions by providing input to and review of the draf= ts as they are progressed via the IETF standards process.. The ITU-T will d= evelop new or revised Recommendations that will allow IETF MPLS-TP to be in= tegrated into the transport network including integration with the existing= equipment, and operations infrastructure. These Recommendations will make= normative references to the base IETF MPLS-TP technology and will be devel= oped with input from and review by experts from the IETF to ensure consiste= ncy with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to co= ntinuing the cooperative development of IETF MPLS to address the needs of t= he transport network. We also believe that this resolution will fulfil the = mutual goal of improve the functionality of the internet and transport netw= orks and guaranteeing complete interoperability and architectural soundness= ." Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: Wednesday, July 13, 2011 1:27 PM > To: david.i.allan@ericsson.com; RCosta@ptinovacao.pt; ietf@ietf.org; > IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] R: RE: R: Re: Last Call: 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard >=20 > >However this is a consequence of adapting an existing technology to a > new > application. I do not see any way around that. And the entire joint > project was > based on the premise of engineering re-use not greenfield design. That > is what > it said on the tin up front, and IMO why when the IETF started down > this path > packet transport transitioned from being a minority sport to > mainstream, so it > is a bit late to cry foul.... >=20 > This is not what the IETF has committed to deliver to ITU-T and in fact > slide > 44 postpones to the OAM design phase "decide whether LSP-Ping or BFD > can or > should be tweaked or not" and slide 46 reckons "many options including > non IP > BFD is an option encapsulation of Y.1731 PDU" >=20 > It seems to me after having read the draft and followed this very long > thread > that tweaking BFD is not the right approach to meet ITU-T requirements > so it > would be worth evaluating the other alternative considered viable by > the JWT > which is encapulating Y.1731 PDUs. >=20 > >----Messaggio originale---- > >Da: david.i.allan@ericsson.com > >Data: 6-lug-2011 20.24 > >A: "erminio.ottone_69@libero.it", > "RCosta@ptinovacao.pt", > "ietf@ietf.org", > "IETF-Announce" > >Cc: "mpls@ietf.org" > >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > indication for MPLS Transport Profile) to Proposed Standard > > > >Hi Erminio: > > > > > >>Several service providers regarded this draft as not meeting their > >>transport networks' needs. > > > >E> This is a true statement: the solution in this draft is useless for > many > MPLS- TP deployments. > > > >The two statements do not necessarily follow. > > > >What we established during discussions at the SG15 plenary in February > was > that the issue some service providers had was that the IETF BFD > solution > exceeded their requirements in that there was additional functionality > they did > not see a need for, and that they considered any additional > functionality > parasitic. > > > >However this is a consequence of adapting an existing technology to a > new > application. I do not see any way around that. And the entire joint > project was > based on the premise of engineering re-use not greenfield design. That > is what > it said on the tin up front, and IMO why when the IETF started down > this path > packet transport transitioned from being a minority sport to > mainstream, so it > is a bit late to cry foul.... > > > >My 2 cents > >Dave > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From erminio.ottone_69@libero.it Wed Jul 13 13:51:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4021F8B00; Wed, 13 Jul 2011 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJUGJ+j1iEQt; Wed, 13 Jul 2011 13:51:42 -0700 (PDT) Received: from outrelay02.libero.it (outrelay02.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5321F876B; Wed, 13 Jul 2011 13:51:34 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4E1E0554.011D,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay02.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E09A78E01919EB2; Wed, 13 Jul 2011 22:51:32 +0200 Message-ID: <3763381.3313701310590292624.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 22:51:32 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , IETF-Announce MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: [mpls] R: R: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:51:46 -0000 It looks like this draft does not define a "single" solution for CC, CV and= RDI=20 function >----Messaggio originale---- >Da: alessandro.dalessandro@telecomitalia.it >Data: 13-lug-2011 15.02 >A: "IETF-Announce" >Cc: "mpls@ietf.org", "ietf@ietf.org" >Ogg: [mpls] R: Last Call:=09<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>=09 (Proactive Connectivity=09Verification, Continuity Check and Remote Defect= =20 indication for=09MPLS=09Transport=09Profile) to Proposed Standard > >Dear all, >I regret to say I have the same concerns expressed by Rui and Erminio abou= t=20 the procedure adopted for this document that has brought so many discussion= s.=20 Anyway, probably because of the lack of a reasonable time (in my opinion) f= or=20 discussions about the previous document version (-04) I have the following= =20 comments on this version: > >1. it is not clear the BFD's scope > Sect. 1: PW, LSP, SPME > Sect. 1: LSP > Sect 3: LSP > Sect 3.1:LSP, PW > Sect 3.3: PW, LSP, SPME, Section > Sect 3.7: LSP > >2. encapsulation > Sect 1: supported encapsulation GAL/GACh, VCCV, UDP/IP: can be=20 expressed a preference (MUST/MAY) for Transport Profile applications for=20 interoperability issues? I would avoid single vendor networks coming from t= oo=20 many options. > >3. diagnostic code 5 > Could you clarify what is the BFD state machine behavior=20 receiving/transmitting a Diagn Code=3D5 > >4. detection time > Sect 3.2: I expect it is that one defined in RFC5884 i.e. detect M= ult=20 x greater (bfd.requiredminrxinterval, last received desired min tx interval= ).=20 What "interval" means is not clear > >5. session periodicity > Sec 3.3 Should be clarified being not defined in RFC5880 > >6. detection of loss of continuity > Sect 3.3 can CV packet sent on the wire replace CC packet (for LO= C=20 purpose on the far end)? > >7. CV vs CC packets > Sect 3.6 Generally speaking, how should the received CV packet's= =20 fields be managed with respect of the BFD state machine/BFD states? (beyond= =20 what is specified in such paragraph limited to P/F and Sta). > >8. encoding > Sect 3.5: could you clarify what " A BFD session will only use one= =20 encoding of the Source ID TLV" means? > >9. editorial > Source ID TLV, MEP source ID TLV, Source MEP TLV should be aligned > >10. terminology > Wrt sect 3.6 I would ask a clarification about the terminology whe= re=20 I found > a- "A BFD session corresponds to a CC and proactive CV OAM instanc= e" > b- " A BFD session is enabled when the CC and proactive CV=20 functionality is enabled" > c- " When the CC and proactive CV functionality is disabled ..., t= he=20 BFD session transitions to the ADMIN DOWN State and the BFD session ends" > In the ADMIN DOWN state I understood I can have BFD contro= l=20 packet exchange between the end points. Is it consistent with CC/CV=20 functionality disabled? >11. code points > Code points are not specified in section 3.1 as stated > >12. BFD fixed rate > Sect 3.7 " This rate is a fixed value common for both directions o= f=20 MEG for the lifetime of the MEG". Is this statement implying that MEG must = be=20 destroyed to be able to change the BFD rate? Should not be limited to the B= FD=20 session lifetime (to be clarified what it means... because moving to ADMIN = DOWN=20 state both ends could not be enough) > >13. two BFD modes > Sect 3.7 " Two independent BFD sessions are used for independent= =20 operation". In my opinion, this approach still remain a big limitation in B= FD=20 usage. > Is it implementation specific the way the two ends distinguish=20 between the two BFD modes? > >14. bfd.RemoteDiscr > Sect 3.7 " In coordinated mode, an implementation SHOULD NOT reset= =20 bfd.RemoteDiscr until it is exiting the DOWN state" > Is it a deviation from BFD as specified in RFC 5880? If it is, cou= ld=20 you clarified the reason for that? > >15. bfd.RemoteDiscr > Sect 3.7 Could you clarify the reasons behind different treatments= =20 for bfd.RemoteDiscr in coordinated mode and independent mode? > >16. overall operation > Sect 3.7 "Overall operation is as specified in [4] and augmented f= or=20 MPLS in[8]" > Are you sure that it can be generalized in that way? Should not be= =20 the case to specify more in details what applies and what do not apply? > >17. IP-based BFD > Sect 3.1 IP-based BFD can carry out CV functionality only if IP S= A=20 is public > >18. CV during transient states > Sect 3.2 for clarification: at start-up, CC are sent one per secon= d.=20 CV are sent in addition to CC (so we have two BFD packets per second)? > >19. misconnections > Sect 3.7.3 sect 3.7.3 states a misconnection bring BFD session to= =20 DOWN whilst it is not clear if sect 3.7.5 state that misconnection do not= =20 impact on BFD state transition > >20. encapsulation modes > Sect 4: if I understood well, there are 4 encapusulations and mode= s=20 for BFD: UDP/IP/LSP; CC mode in G-ACh; UPD/IP in G-ACh e CC/CV mode in G-AC= h. > Do all of them satisfy transport requirements? > I understand they are not interoperable (as well as the two BFD mo= de=20 for the same CC/CV in G-Ach encapsulation). Is it correct? > >Best regards, >Alessandro > >------------------------------------------------------------------ >Telecom Italia >Alessandro D'Alessandro >Transport Innovation >Via Reiss Romoli, 274 - 10148 Torino >phone: +39 011 228 5887 >mobile: +39 335 766 9607 >fax: +39 06 418 639 07 > > >-----Messaggio originale----- >Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Loa= =20 Andersson >Inviato: mercoled=C3=AC 6 luglio 2011 17:44 >A: Rui Costa >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >Oggetto: Re: [mpls] Last Call: =20 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >All, > >Since someone has commented about the process used for resolving questions= on=20 draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process i= s: > >On February 3rd 2011 the working group last call was issued on version -03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > >The authors compiled a list of all comments received as part the MPLS=20 working group last call; these comments - and the intended resolution - is= =20 included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD working > group to do a separate working group last callfor the BFD working > group > >The (BFD) working group last call was started on March 30th and ran for 13= =20 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some > issue has been brought to the working group mailing list for > resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editorial > comments. Version -05 was published on June 29 and the IETF last call > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiable at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows without= =20 doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > >On 2011-07-05 00:02, Rui Costa wrote: >> IMHO and for the record: >> >> ITU-T comments regarding this draft haven't been discussed with ITU-T bu= t=20 were simply ignored. No LS describing these comments' resolution was sent. >> >> Several service providers regarded this draft as not meeting their=20 transport networks' needs. >> >> [The v03 draft was published in Feb and went to WG LC. >> The v04 draft addressing WG LC comments was published on the 28th June= =20 (same date as the proto write-up). >> When was the WG LC launched, to verify LC comments resolution?] >> >> Regards, >> Rui >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of The IESG >> Sent: quinta-feira, 30 de Junho de 2011 14:47 >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: >> (Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile) to Proposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label Switching >> WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 2011-07-14. 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 >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13=20 _______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle=20 persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla=20 conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te=20 ricevuto questo documento per errore siete cortesemente pregati di darne=20 immediata comunicazione al mittente e di provvedere alla sua distruzione,= =20 Grazie. > >This e-mail and any attachments is confidential and may contain privileged= =20 information intended for the addressee(s) only. Dissemination, copying,=20 printing or use by anybody else is unauthorised. If you are not the intende= d=20 recipient, please delete this message and any attachments and advise the se= nder=20 by return e-mail, Thanks. > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed Jul 13 14:04:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7321F8B02; Wed, 13 Jul 2011 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBckENbBuHPG; Wed, 13 Jul 2011 14:04:21 -0700 (PDT) Received: from outrelay03.libero.it (outrelay03.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id 885C821F8B00; Wed, 13 Jul 2011 14:04:20 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020C.4E1E084E.003A,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail23 (172.31.0.48) by outrelay03.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DE4FF1D03017E90; Wed, 13 Jul 2011 23:04:13 +0200 Message-ID: <29155895.3316791310591053994.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 23:04:13 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "david.i.allan@ericsson.com" , "RCosta@ptinovacao.pt" , "ietf@ietf.org" , IETF-Announce MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.163.248 Cc: "mpls@ietf.org" Subject: [mpls] R: RE: R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 21:04:21 -0000 The JWT report is aligned with my statement. The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. >----Messaggio originale---- >Da: jdrake@juniper.net >Data: 13-lug-2011 22.46 >A: "erminio.ottone_69@libero.it", "david.i. allan@ericsson.com", "RCosta@ptinovacao.pt" , "ietf@ietf.org", "IETF-Announce" >Cc: "mpls@ietf.org" >Ogg: RE: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05. txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > >Italo, > >The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): > >"The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... > >The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness." > >Thanks, > >John > >Sent from my iPhone > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: Wednesday, July 13, 2011 1:27 PM >> To: david.i.allan@ericsson.com; RCosta@ptinovacao.pt; ietf@ietf.org; >> IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] R: RE: R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> >However this is a consequence of adapting an existing technology to a >> new >> application. I do not see any way around that. And the entire joint >> project was >> based on the premise of engineering re-use not greenfield design. That >> is what >> it said on the tin up front, and IMO why when the IETF started down >> this path >> packet transport transitioned from being a minority sport to >> mainstream, so it >> is a bit late to cry foul.... >> >> This is not what the IETF has committed to deliver to ITU-T and in fact >> slide >> 44 postpones to the OAM design phase "decide whether LSP-Ping or BFD >> can or >> should be tweaked or not" and slide 46 reckons "many options including >> non IP >> BFD is an option encapsulation of Y.1731 PDU" >> >> It seems to me after having read the draft and followed this very long >> thread >> that tweaking BFD is not the right approach to meet ITU-T requirements >> so it >> would be worth evaluating the other alternative considered viable by >> the JWT >> which is encapulating Y.1731 PDUs. >> >> >----Messaggio originale---- >> >Da: david.i.allan@ericsson.com >> >Data: 6-lug-2011 20.24 >> >A: "erminio.ottone_69@libero.it", >> "RCosta@ptinovacao.pt", >> "ietf@ietf.org", >> "IETF-Announce" >> >Cc: "mpls@ietf.org" >> >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- >> 05.txt> >> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect >> indication for MPLS Transport Profile) to Proposed Standard >> > >> >Hi Erminio: >> > >> > >> >>Several service providers regarded this draft as not meeting their >> >>transport networks' needs. >> > >> >E> This is a true statement: the solution in this draft is useless for >> many >> MPLS- TP deployments. >> > >> >The two statements do not necessarily follow. >> > >> >What we established during discussions at the SG15 plenary in February >> was >> that the issue some service providers had was that the IETF BFD >> solution >> exceeded their requirements in that there was additional functionality >> they did >> not see a need for, and that they considered any additional >> functionality >> parasitic. >> > >> >However this is a consequence of adapting an existing technology to a >> new >> application. I do not see any way around that. And the entire joint >> project was >> based on the premise of engineering re-use not greenfield design. That >> is what >> it said on the tin up front, and IMO why when the IETF started down >> this path >> packet transport transitioned from being a minority sport to >> mainstream, so it >> is a bit late to cry foul.... >> > >> >My 2 cents >> >Dave >> > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From jdrake@juniper.net Wed Jul 13 14:52:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C1C11E81B1; Wed, 13 Jul 2011 14:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP9fkMX8g7NA; Wed, 13 Jul 2011 14:51:59 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 586EE11E81AE; Wed, 13 Jul 2011 14:51:59 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTh4TdDoCtWo0fn3CTPbJiemiZctIoI3v@postini.com; Wed, 13 Jul 2011 14:51:59 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 13 Jul 2011 14:51:01 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "david.i.allan@ericsson.com" , "RCosta@ptinovacao.pt" , "ietf@ietf.org" , IETF-Announce Date: Wed, 13 Jul 2011 14:50:59 -0700 Thread-Topic: RE: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxBoG0OS2ifSLKARaC6iTe+89k3eAABOY5w Message-ID: <5E893DB832F57341992548CDBB333163A0A92C535B@EMBX01-HQ.jnpr.net> References: <29155895.3316791310591053994.JavaMail.defaultUser@defaultHost> In-Reply-To: <29155895.3316791310591053994.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 21:52:00 -0000 SXRhbG8sDQoNCkNvbW1lbnRzIGlubGluZS4NCg0KVGhhbmtzLA0KDQpKb2huDQoNClNlbnQgZnJv bSBteSBpUGhvbmUNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVy bWluaW8ub3R0b25lXzY5QGxpYmVyby5pdCBbbWFpbHRvOmVybWluaW8ub3R0b25lXzY5QGxpYmVy by5pdF0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDEzLCAyMDExIDI6MDQgUE0NCj4gVG86IEpv aG4gRSBEcmFrZTsgZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb207IFJDb3N0YUBwdGlub3ZhY2Fv LnB0Ow0KPiBpZXRmQGlldGYub3JnOyBJRVRGLUFubm91bmNlDQo+IENjOiBtcGxzQGlldGYub3Jn DQo+IFN1YmplY3Q6IFI6IFJFOiBbbXBsc10gUjogUkU6IFI6IFJlOiBMYXN0IENhbGw6IDxkcmFm dC1pZXRmLW1wbHMtdHAtY2MtDQo+IGN2LXJkaS0wNS50eHQ+IChQcm9hY3RpdmUgQ29ubmVjdGl2 aXR5IFZlcmlmaWNhdGlvbiwgQ29udGludWl0eSBDaGVjaw0KPiBhbmQgUmVtb3RlIERlZmVjdCBp bmRpY2F0aW9uIGZvciBNUExTIFRyYW5zcG9ydCBQcm9maWxlKSB0byBQcm9wb3NlZA0KPiBTdGFu ZGFyZA0KPiANCj4gVGhlIEpXVCByZXBvcnQgaXMgYWxpZ25lZCB3aXRoIG15IHN0YXRlbWVudC4N Cg0KSkQ6ICBBcyBTRzE1IG1hbmFnZW1lbnQgaXMgZm9uZCBvZiBwb2ludGluZyBvdXQsIHdoZW4g aXQgc3VpdHMgdGhlbSwgdGhlIEpXVCBvcGVyYXRlZCBvbiBhIHZlcnkgY29tcHJlc3NlZCB0aW1l IHNjYWxlIGFuZCBkaWRuJ3QgZnVsbHkgZXhwbG9yZSBhbGwgb2YgdGhlIHRlY2huaWNhbCBpc3N1 ZXMNCg0KPiANCj4gVGhlIGRlY2lzaW9uIGF0IElFVEY3NSBoYXMgYmVlbiB0YWtlbiBieSB0aGUg TVBMUyBXRyBhZnRlciB0aGUgSldUIGFuZA0KPiBoYXMNCj4gbmV2ZXIgYmVlbiBlbmRvcnNlZCBi eSBJVFUtVCAoSHV1YiBpcyBOT1QgSVRVLVQgYW5kLCBhcyBmYXIgYXMgSQ0KPiB1bmRlcnN0b29k LCBoZQ0KPiBsYXRlciByZW1vdmVkIGhpcyBuYW1lIGJlY2F1c2UgdGhlIG90aGVyIGVkaXRvcnMg b2YgdGhlIE9BTSBBbmFseXNpcw0KPiBkcmFmdCB3ZXJlDQo+IG5vdCBjb25zaWRlcmluZyBoaXMg aW5wdXQgdG8gdGhlIGRvY3VtZW50KS4NCg0KSkQ6ICBJJ20gbm90IHN1cmUgd2hhdCB5b3VyIHBv aW50IGlzDQoNCj4gDQo+IFRoZSBCRkQtYmFzZWQgc29sdXRpb24gYWNjZXB0ZWQgYnkgSUVURjc1 IGZvciBwcm8tYWN0aXZlIENDL0NWL1JESSB3YXMNCj4gY29tcGxldGVseSBkaWZmZXJlbnQgKGFu ZCB0ZWNobmljYWxseSBtdWNoIHN1cGVyaW9yKSB0aGFuIHRoZSBvbmUNCj4gZGVzY3JpYmVkIGJ5 DQo+IHRoaXMgZHJhZnQuDQoNCkpEOiAgT2J2aW91c2x5IHdlIGRpc2FncmVlDQoNCj4gDQo+IEFj Y2VwdGluZyBhIHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlIHJlcXVpcmVtZW50cyBkb2VzIG5vdCBt ZWFuIHNpZ25pbmcNCj4gYSBibGFuaw0KPiBjaGVxdWUgdGhhdCB3aGljaGV2ZXIgY2hhbmdlcyBp cyBkb25lIGlzIGFjY2VwdGFibGUgcmVnYXJsZXNzIHdoZXRoZXINCj4gaXQgbWVldHMNCj4gb3Ig bm90IHRoZSByZXF1aXJlbWVudHMuDQoNCkpEOiAgVGhlIHJlcXVpcmVtZW50cyBhcyBkb2N1bWVu dGVkIGluIFJGQ3MgNTY1NCwgNTg2MCwgYW5kIDU5NTEsIG9yIHRoZSByZXF1aXJlbWVudHMgdGhh dCBzZWVtIHRvIGNoYW5nZSBiYXNlZCB1cG9uIHRoZSBwaGFzZXMgb2YgdGhlIG1vb24/DQogDQo+ IA0KPiA+LS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tDQo+ID5EYTogamRyYWtlQGp1bmlwZXIu bmV0DQo+ID5EYXRhOiAxMy1sdWctMjAxMSAyMi40Ng0KPiA+QTogImVybWluaW8ub3R0b25lXzY5 QGxpYmVyby5pdCI8ZXJtaW5pby5vdHRvbmVfNjlAbGliZXJvLml0PiwNCj4gImRhdmlkLmkuDQo+ IGFsbGFuQGVyaWNzc29uLmNvbSI8ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20+LCAiUkNvc3Rh QHB0aW5vdmFjYW8ucHQiDQo+IDxSQ29zdGFAcHRpbm92YWNhby5wdD4sICJpZXRmQGlldGYub3Jn IjxpZXRmQGlldGYub3JnPiwgIklFVEYtDQo+IEFubm91bmNlIjxpZXRmLQ0KPiBhbm5vdW5jZUBp ZXRmLm9yZz4NCj4gPkNjOiAibXBsc0BpZXRmLm9yZyI8bXBsc0BpZXRmLm9yZz4NCj4gPk9nZzog UkU6IFttcGxzXSBSOiBSRTogUjogUmU6CUxhc3QJQ2FsbDoJJmx0O2RyYWZ0LWlldGYtbXBscy10 cC0NCj4gY2MtY3YtcmRpLTA1Lg0KPiB0eHQmZ3Q7CShQcm9hY3RpdmUJQ29ubmVjdGl2aXR5CVZl cmlmaWNhdGlvbiwJQ29udGludWl0eQ0KPiBDaGVjayBhbmQgUmVtb3RlDQo+IERlZmVjdAlpbmRp Y2F0aW9uCWZvcglNUExTCVRyYW5zcG9ydAlQcm9maWxlKSB0byBQcm9wb3NlZA0KPiBTdGFuZGFy ZA0KPiA+DQo+ID5JdGFsbywNCj4gPg0KPiA+VGhlIGRlc2lnbiB0ZWFtIHJlcG9ydA0KPiAoaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy83NS9zbGlkZXMvbXBscy0NCj4gMTcvbXBscy0x N19maWxlcy9mcmFtZS5odG0pLCB3aXRoIEh1dWIncyBuYW1lIGFzIGFuIGF1dGhvciwgZGV0YWls cyBhDQo+IHBsYW4gZm9yDQo+IE1QTFMtVFAgT0FNIHdoaWNoIHRoZSBNUExTIFdHIGhhcyBmb2xs b3dlZCB0byB0aGlzIGRheS4gIEkgdGhpbmsgdGhlDQo+IHJlcG9ydCBpcw0KPiBjb21wZWxsaW5n IGV2aWRlbmNlIHRoYXQgdGhlIGNsYWltIHRoYXQgYSBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmsg aXMNCj4gYW4gTVBMUw0KPiBhcHBsaWNhdGlvbiB0aGF0IGludHJpbnNpY2FsbHkgcmVxdWlyZXMg YSBkaWZmZXJlbnQgT0FNIHNvbHV0aW9uIGlzDQo+IHNpbXBseSBhDQo+IGxhbWUgZXggcG9zdCBm YWN0byBhdHRlbXB0IHRvIGp1c3RpZnkgdGhlIElUVSdzIGFicm9nYXRpb24gb2YgdGhlDQo+IGFn cmVlbWVudA0KPiB3aXRoIHRoZSBJRVRGIChURDA3IChXUDMvU0cxNSkgZnJvbSBEZWNlbWJlciAy MDA4IHNvdXJjZWQgYnkgU0cxNSk6DQo+ID4NCj4gPiJUaGUgSVRVLVQgYWNjZXB0cyB0aGVzZSBy ZWNvbW1lbmRhdGlvbnMgYW5kIHN0YXRlcyB0aGF0IGFueQ0KPiBleHRlbnNpb25zIHRvDQo+IE1Q TFMgdGVjaG5vbG9neSB3aWxsIGJlIHByb2dyZXNzZWQgdmlhIHRoZSBJRVRGIHN0YW5kYXJkcyBw cm9jZXNzIHVzaW5nDQo+IHRoZQ0KPiBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDIDQ5MjkgKENo YW5nZSBQcm9jZXNzIGZvciBNdWx0aXByb3RvY29sIExhYmVsDQo+IFN3aXRjaGluZyAoTVBMUykg YW5kIEdlbmVyYWxpemVkIE1QTFMgKEdNUExTKSBQcm90b2NvbHMgYW5kDQo+IFByb2NlZHVyZXMp Lg0KPiBFeHBlcnRzIGZyb20gdGhlIElUVS1UIHdpbGwgYXNzaXN0IHRoZSBJRVRGIGluIHRoZSBk ZXZlbG9wbWVudCBvZiBSRkNzDQo+IHRoYXQNCj4gZGVzY3JpYmUgdGhlIHRyYW5zcG9ydCBleHRl bnNpb25zIGJ5IHByb3ZpZGluZyBpbnB1dCB0byBhbmQgcmV2aWV3IG9mDQo+IHRoZQ0KPiBkcmFm dHMgYXMgdGhleSBhcmUgcHJvZ3Jlc3NlZCB2aWEgdGhlIElFVEYgc3RhbmRhcmRzIHByb2Nlc3Mu LiBUaGUgSVRVLQ0KPiBUIHdpbGwNCj4gZGV2ZWxvcCBuZXcgb3IgcmV2aXNlZCBSZWNvbW1lbmRh dGlvbnMgdGhhdCB3aWxsIGFsbG93IElFVEYgTVBMUy1UUCB0bw0KPiBiZQ0KPiBpbnRlZ3JhdGVk IGludG8gdGhlIHRyYW5zcG9ydCBuZXR3b3JrIGluY2x1ZGluZyBpbnRlZ3JhdGlvbiB3aXRoIHRo ZQ0KPiBleGlzdGluZw0KPiBlcXVpcG1lbnQsIGFuZCBvcGVyYXRpb25zIGluZnJhc3RydWN0dXJl LiAgVGhlc2UgUmVjb21tZW5kYXRpb25zIHdpbGwNCj4gbWFrZQ0KPiBub3JtYXRpdmUgcmVmZXJl bmNlcyB0byB0aGUgYmFzZSBJRVRGIE1QTFMtVFAgdGVjaG5vbG9neSBhbmQgd2lsbCBiZQ0KPiBk ZXZlbG9wZWQNCj4gd2l0aCBpbnB1dCBmcm9tIGFuZCByZXZpZXcgYnkgZXhwZXJ0cyBmcm9tIHRo ZSBJRVRGIHRvIGVuc3VyZQ0KPiBjb25zaXN0ZW5jeSB3aXRoDQo+IE1QTFMtVFAuLi4NCj4gPg0K PiA+VGhlIElUVS1UIGhhcyBhY2NlcHRlZCB0aGUgcHJvcG9zYWxzIGZyb20gdGhlIEpXVCBhbmQg d2UgbG9vayBmb3J3YXJkDQo+IHRvDQo+IGNvbnRpbnVpbmcgdGhlIGNvb3BlcmF0aXZlIGRldmVs b3BtZW50IG9mIElFVEYgTVBMUyB0byBhZGRyZXNzIHRoZQ0KPiBuZWVkcyBvZiB0aGUNCj4gdHJh bnNwb3J0IG5ldHdvcmsuIFdlIGFsc28gYmVsaWV2ZSB0aGF0IHRoaXMgcmVzb2x1dGlvbiB3aWxs IGZ1bGZpbCB0aGUNCj4gbXV0dWFsDQo+IGdvYWwgb2YgaW1wcm92ZSB0aGUgZnVuY3Rpb25hbGl0 eSBvZiB0aGUgaW50ZXJuZXQgYW5kIHRyYW5zcG9ydA0KPiBuZXR3b3JrcyBhbmQNCj4gZ3VhcmFu dGVlaW5nIGNvbXBsZXRlIGludGVyb3BlcmFiaWxpdHkgYW5kIGFyY2hpdGVjdHVyYWwgc291bmRu ZXNzLiINCj4gPg0KPiA+VGhhbmtzLA0KPiA+DQo+ID5Kb2huDQo+ID4NCj4gPlNlbnQgZnJvbSBt eSBpUGhvbmUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPiBPZg0KPiA+PiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCj4gPj4gU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDEzLCAyMDExIDE6MjcgUE0NCj4gPj4gVG86IGRhdmlkLmkuYWxs YW5AZXJpY3Nzb24uY29tOyBSQ29zdGFAcHRpbm92YWNhby5wdDsgaWV0ZkBpZXRmLm9yZzsNCj4g Pj4gSUVURi1Bbm5vdW5jZQ0KPiA+PiBDYzogbXBsc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBb bXBsc10gUjogUkU6IFI6IFJlOiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1wbHMtdHAtY2MtY3Yt DQo+IHJkaS0NCj4gPj4gMDUudHh0PiAoUHJvYWN0aXZlIENvbm5lY3Rpdml0eSBWZXJpZmljYXRp b24sIENvbnRpbnVpdHkgQ2hlY2sgYW5kDQo+ID4+IFJlbW90ZSBEZWZlY3QgaW5kaWNhdGlvbiBm b3IgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSkgdG8gUHJvcG9zZWQNCj4gPj4gU3RhbmRhcmQNCj4g Pj4NCj4gPj4gPkhvd2V2ZXIgdGhpcyBpcyBhIGNvbnNlcXVlbmNlIG9mIGFkYXB0aW5nIGFuIGV4 aXN0aW5nIHRlY2hub2xvZ3kgdG8NCj4gYQ0KPiA+PiBuZXcNCj4gPj4gYXBwbGljYXRpb24uIEkg ZG8gbm90IHNlZSBhbnkgd2F5IGFyb3VuZCB0aGF0LiBBbmQgdGhlIGVudGlyZSBqb2ludA0KPiA+ PiBwcm9qZWN0IHdhcw0KPiA+PiBiYXNlZCBvbiB0aGUgcHJlbWlzZSBvZiBlbmdpbmVlcmluZyBy ZS11c2Ugbm90IGdyZWVuZmllbGQgZGVzaWduLg0KPiBUaGF0DQo+ID4+IGlzIHdoYXQNCj4gPj4g aXQgc2FpZCBvbiB0aGUgdGluIHVwIGZyb250LCBhbmQgSU1PIHdoeSB3aGVuIHRoZSBJRVRGIHN0 YXJ0ZWQgZG93bg0KPiA+PiB0aGlzIHBhdGgNCj4gPj4gcGFja2V0IHRyYW5zcG9ydCB0cmFuc2l0 aW9uZWQgZnJvbSBiZWluZyBhIG1pbm9yaXR5IHNwb3J0IHRvDQo+ID4+IG1haW5zdHJlYW0sIHNv IGl0DQo+ID4+IGlzIGEgYml0IGxhdGUgdG8gY3J5IGZvdWwuLi4uDQo+ID4+DQo+ID4+IFRoaXMg aXMgbm90IHdoYXQgdGhlIElFVEYgaGFzIGNvbW1pdHRlZCB0byBkZWxpdmVyIHRvIElUVS1UIGFu ZCBpbg0KPiBmYWN0DQo+ID4+IHNsaWRlDQo+ID4+IDQ0IHBvc3Rwb25lcyB0byB0aGUgT0FNIGRl c2lnbiBwaGFzZSAiZGVjaWRlIHdoZXRoZXIgTFNQLVBpbmcgb3IgQkZEDQo+ID4+IGNhbiBvcg0K PiA+PiBzaG91bGQgYmUgdHdlYWtlZCBvciBub3QiIGFuZCBzbGlkZSA0NiByZWNrb25zICJtYW55 IG9wdGlvbnMNCj4gaW5jbHVkaW5nDQo+ID4+IG5vbiBJUA0KPiA+PiBCRkQgaXMgYW4gb3B0aW9u IGVuY2Fwc3VsYXRpb24gb2YgWS4xNzMxIFBEVSINCj4gPj4NCj4gPj4gSXQgc2VlbXMgdG8gbWUg YWZ0ZXIgaGF2aW5nIHJlYWQgdGhlIGRyYWZ0IGFuZCBmb2xsb3dlZCB0aGlzIHZlcnkNCj4gbG9u Zw0KPiA+PiB0aHJlYWQNCj4gPj4gdGhhdCB0d2Vha2luZyBCRkQgaXMgbm90IHRoZSByaWdodCBh cHByb2FjaCB0byBtZWV0IElUVS1UDQo+IHJlcXVpcmVtZW50cw0KPiA+PiBzbyBpdA0KPiA+PiB3 b3VsZCBiZSB3b3J0aCBldmFsdWF0aW5nIHRoZSBvdGhlciBhbHRlcm5hdGl2ZSBjb25zaWRlcmVk IHZpYWJsZSBieQ0KPiA+PiB0aGUgSldUDQo+ID4+IHdoaWNoIGlzIGVuY2FwdWxhdGluZyBZLjE3 MzEgUERVcy4NCj4gPj4NCj4gPj4gPi0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLQ0KPiA+PiA+ RGE6IGRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tDQo+ID4+ID5EYXRhOiA2LWx1Zy0yMDExIDIw LjI0DQo+ID4+ID5BOiAiZXJtaW5pby5vdHRvbmVfNjlAbGliZXJvLml0Ijxlcm1pbmlvLm90dG9u ZV82OUBsaWJlcm8uaXQ+LA0KPiA+PiAiUkNvc3RhQHB0aW5vdmFjYW8ucHQiPFJDb3N0YUBwdGlu b3ZhY2FvLnB0PiwNCj4gPj4gImlldGZAaWV0Zi5vcmciPGlldGZAaWV0Zi5vcmc+LA0KPiA+PiAi SUVURi1Bbm5vdW5jZSI8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gPj4gPkNjOiAibXBsc0Bp ZXRmLm9yZyI8bXBsc0BpZXRmLm9yZz4NCj4gPj4gPk9nZzogUkU6IFttcGxzXSBSOiBSZTogTGFz dAlDYWxsOgkmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLWNjLWN2LQ0KPiByZGktDQo+ID4+IDA1LnR4 dCZndDsNCj4gPj4gKFByb2FjdGl2ZQlDb25uZWN0aXZpdHkJVmVyaWZpY2F0aW9uLAlDb250aW51 aXR5IENoZWNrDQo+IGFuZA0KPiA+PiBSZW1vdGUgRGVmZWN0DQo+ID4+IGluZGljYXRpb24JZm9y CU1QTFMJVHJhbnNwb3J0CVByb2ZpbGUpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4+ID4NCj4g Pj4gPkhpIEVybWluaW86DQo+ID4+ID4NCj4gPj4gPjxzbmlwcGVkPg0KPiA+PiA+PlNldmVyYWwg c2VydmljZSBwcm92aWRlcnMgcmVnYXJkZWQgdGhpcyBkcmFmdCBhcyBub3QgbWVldGluZyB0aGVp cg0KPiA+PiA+PnRyYW5zcG9ydCBuZXR3b3JrcycgbmVlZHMuDQo+ID4+ID4NCj4gPj4gPkU+IFRo aXMgaXMgYSB0cnVlIHN0YXRlbWVudDogdGhlIHNvbHV0aW9uIGluIHRoaXMgZHJhZnQgaXMgdXNl bGVzcw0KPiBmb3INCj4gPj4gbWFueQ0KPiA+PiBNUExTLSBUUCBkZXBsb3ltZW50cy4NCj4gPj4g Pg0KPiA+PiA+VGhlIHR3byBzdGF0ZW1lbnRzIGRvIG5vdCBuZWNlc3NhcmlseSBmb2xsb3cuDQo+ ID4+ID4NCj4gPj4gPldoYXQgd2UgZXN0YWJsaXNoZWQgZHVyaW5nIGRpc2N1c3Npb25zIGF0IHRo ZSBTRzE1IHBsZW5hcnkgaW4NCj4gRmVicnVhcnkNCj4gPj4gd2FzDQo+ID4+IHRoYXQgdGhlIGlz c3VlIHNvbWUgc2VydmljZSBwcm92aWRlcnMgaGFkIHdhcyB0aGF0IHRoZSBJRVRGIEJGRA0KPiA+ PiBzb2x1dGlvbg0KPiA+PiBleGNlZWRlZCB0aGVpciByZXF1aXJlbWVudHMgaW4gdGhhdCB0aGVy ZSB3YXMgYWRkaXRpb25hbA0KPiBmdW5jdGlvbmFsaXR5DQo+ID4+IHRoZXkgZGlkDQo+ID4+IG5v dCBzZWUgYSBuZWVkIGZvciwgYW5kIHRoYXQgdGhleSBjb25zaWRlcmVkIGFueSBhZGRpdGlvbmFs DQo+ID4+IGZ1bmN0aW9uYWxpdHkNCj4gPj4gcGFyYXNpdGljLg0KPiA+PiA+DQo+ID4+ID5Ib3dl dmVyIHRoaXMgaXMgYSBjb25zZXF1ZW5jZSBvZiBhZGFwdGluZyBhbiBleGlzdGluZyB0ZWNobm9s b2d5IHRvDQo+IGENCj4gPj4gbmV3DQo+ID4+IGFwcGxpY2F0aW9uLiBJIGRvIG5vdCBzZWUgYW55 IHdheSBhcm91bmQgdGhhdC4gQW5kIHRoZSBlbnRpcmUgam9pbnQNCj4gPj4gcHJvamVjdCB3YXMN Cj4gPj4gYmFzZWQgb24gdGhlIHByZW1pc2Ugb2YgZW5naW5lZXJpbmcgcmUtdXNlIG5vdCBncmVl bmZpZWxkIGRlc2lnbi4NCj4gVGhhdA0KPiA+PiBpcyB3aGF0DQo+ID4+IGl0IHNhaWQgb24gdGhl IHRpbiB1cCBmcm9udCwgYW5kIElNTyB3aHkgd2hlbiB0aGUgSUVURiBzdGFydGVkIGRvd24NCj4g Pj4gdGhpcyBwYXRoDQo+ID4+IHBhY2tldCB0cmFuc3BvcnQgdHJhbnNpdGlvbmVkIGZyb20gYmVp bmcgYSBtaW5vcml0eSBzcG9ydCB0bw0KPiA+PiBtYWluc3RyZWFtLCBzbyBpdA0KPiA+PiBpcyBh IGJpdCBsYXRlIHRvIGNyeSBmb3VsLi4uLg0KPiA+PiA+DQo+ID4+ID5NeSAyIGNlbnRzDQo+ID4+ ID5EYXZlDQo+ID4+ID4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4gbXBsc0BpZXRmLm9yZw0K PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPiAN Cg0K From david.i.allan@ericsson.com Wed Jul 13 15:24:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC3811E809A; Wed, 13 Jul 2011 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6KbYltFl5dJ; Wed, 13 Jul 2011 15:24:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 426F711E8082; Wed, 13 Jul 2011 15:24:07 -0700 (PDT) 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 p6DMO3bj022087; Wed, 13 Jul 2011 17:24:06 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 13 Jul 2011 18:24:01 -0400 From: David Allan I To: "erminio.ottone_69@libero.it" , "loa@pi.nu" , Rui Costa Date: Wed, 13 Jul 2011 18:24:00 -0400 Thread-Topic: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxBm16fxXJVoZpkQjint6SX3SKvxAAC06zg Message-ID: <60C093A41B5E45409A19D42CF7786DFD5221437821@EUSAACMS0703.eamcs.ericsson.se> References: <27773911.3307261310588873729.JavaMail.defaultUser@defaultHost> In-Reply-To: <27773911.3307261310588873729.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 22:24:08 -0000 HI Erminio: The comments that were raised during the day long discussion with the edito= rs at the SG15 plenary resulted in those comments appearing in the liasion = IMO in an actionable form and resulted in a constructive outcome. I enjoyed= that level of cooperation. The comments that were punted over the wall with no discussion (depsite req= uests to allocate meeting time to do so) in some cases were sufficiently va= gue as to have no constructive value or not have a recognizable issue to be= addressed. A request to have the commenters identified in the liaison so that comments= that were unclear could be followed up upon by the editors was refused. Ap= parently that is not done and I would go so far as to suggest that blanket = of anonymity diminished the quality of the liaison. The result of this pro= cess was that the only recourse to go "what does this mean?" was a complete= liaison cycle. For some comments, stomaching a multi-month delay to clarif= y what the actual issue was that resulted in a comment like "describe the s= tart-up procedure" was not reasonable, especially given SG15s continual com= plaint on how slow the IETF was. Such comments had to be weighed against th= e nature of comments from the larger reviewing community that seemed to hav= e no issue with the completeness of the document content and perhaps had ac= tually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the lia= ison was "clarify the raising/clearing of defects as well as any consequent= actions" which I can only interpret as section 3.7 of the document not hav= ing been read. E.g. the TOC is: 3.7.1. Session initiation and Modification 13 3.7.2. Defect entry criteria 13 3.7.3. Defect entry consequent action 14 3.7.4. Defect exit criteria 15 3.7.5. State machines 15 ...and if there was a deficiency in the descriptions it was not identified,= and we're not mind readers. So that is both the history and why some comments were rejected. If you can= suggest a constructive way to proceed that is not simply a waste of everyo= ne's time, I'll listen.. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it]=20 Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defec= t indication for MPLS Transport Profile) to Proposed Standard Do you mean that ITU-T comments were discussed and resolution agreed during= the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agre= ed resolution? Why some ITU-T comments have been then rejected? >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 6-lug-2011 19.35 >A: "erminio.ottone_69@libero.it", "loa@pi.nu" , "Rui Costa" >Cc: "mpls@ietf.org", "ietf@ietf.org",=20 >"IETF- Announce" >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt&= gt;=09 (Proactive Connectivity Verification, Continuity Check and Remote Defect=20 indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > >Two of the three document editors were present at SG15 plenary in=20 >February where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. > >Cheers >Dave > From mach.chen@huawei.com Wed Jul 13 19:23:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0911E8089 for ; Wed, 13 Jul 2011 19:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJf4qxqe9MfC for ; Wed, 13 Jul 2011 19:23:06 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AD11E8092 for ; Wed, 13 Jul 2011 19:23:06 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00LXNX9DSC@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 14 Jul 2011 10:22:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00DQZX9D8P@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 14 Jul 2011 10:22:25 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACE89850; Thu, 14 Jul 2011 10:22:24 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Jul 2011 10:22:19 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.35]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 10:22:24 +0800 Date: Thu, 14 Jul 2011 02:22:23 +0000 From: Mach Chen X-Originating-IP: [10.110.98.37] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: PW LSP Ping for IPv6//FW: New Version Notification for draft-chen-pwe3-ipv6-lsp-ping-vccv-01.txt Thread-index: AQHMPVUBBB5+QsOj+Uya1/3S4O3RaZTrHHwQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [mpls] PW LSP Ping for IPv6//FW: New Version Notification for draft-chen-pwe3-ipv6-lsp-ping-vccv-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 02:23:07 -0000 Hi, We uploaded a new draft that is about extensions to LSP Ping for IPv6 PW LSP Ping, here is the pointer: http://tools.ietf.org/html/draft-chen-pwe3-ipv6-lsp-ping-vccv-01 . We'd appreciate that you could spend some time to read the draft and give your comments! Best regards, Mach > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 08, 2011 5:54 PM > To: Mach Chen > Cc: ppan@infinera.com; Mach Chen > Subject: New Version Notification for draft-chen-pwe3-ipv6-lsp-ping-vccv-01.txt > > A new version of I-D, draft-chen-pwe3-ipv6-lsp-ping-vccv-01.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-chen-pwe3-ipv6-lsp-ping-vccv > Revision: 01 > Title: IPv6 Pseudowire Label Switched Path (LSP) Ping > Creation date: 2011-07-05 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > The existing Pseudowire LSP Ping can only work in IPv4 scenario, this > document extends Pseudowire LSP Ping to IPv6 scenario where IPv6 > target LDP session is used to signal Pseudowire and the Sender and > Receiver's IP addresses are IPv6 addresses. > > > > > > The IETF Secretariat From gregimirsky@gmail.com Wed Jul 13 19:49:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3811E8092; Wed, 13 Jul 2011 19:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43fKcpoo0o0F; Wed, 13 Jul 2011 19:49:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A687B21F89AC; Wed, 13 Jul 2011 19:49:58 -0700 (PDT) Received: by vxi40 with SMTP id 40so6862868vxi.31 for ; Wed, 13 Jul 2011 19:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=udOEXZs9A9tP3UiUcs2Ad3iMWLmcYFR0sGsnJvGrk7E=; b=cwVGA2jhQP2saKnmeZJorvb7bmboUIOfutuvToOlwLWUCG7p2PkqJaBLOtGuZLD8Eh VkVzAhfBzgHflmgURgopDLT0YvfGNbDwAaiCbC+nXuTKbBcCho/EaW5+S4NOk0uiUgrT YURmevCChjeWD8xgfvngE5GUNh4wM/X/lfxIw= MIME-Version: 1.0 Received: by 10.52.180.201 with SMTP id dq9mr2097040vdc.245.1310611797779; Wed, 13 Jul 2011 19:49:57 -0700 (PDT) Received: by 10.52.164.68 with HTTP; Wed, 13 Jul 2011 19:49:57 -0700 (PDT) In-Reply-To: <24102355.3308421310589129962.JavaMail.defaultUser@defaultHost> References: <24102355.3308421310589129962.JavaMail.defaultUser@defaultHost> Date: Wed, 13 Jul 2011 19:49:57 -0700 Message-ID: From: Greg Mirsky To: "erminio.ottone_69@libero.it" Content-Type: multipart/alternative; boundary=bcaec51a8228a5263904a7fe96d4 Cc: mpls@ietf.org, IETF-Announce , ietf@ietf.org Subject: Re: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 02:49:59 -0000 --bcaec51a8228a5263904a7fe96d4 Content-Type: text/plain; charset=ISO-8859-1 Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. "Every generalization is wrong, including this one" Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone_69@libero.it < erminio.ottone_69@libero.it> wrote: > The technical concern raised during the WG poll has not been resolved so > the > history definetely matters. > > Quoting RFC5921: > > There are thus two objectives for MPLS-TP: > > 1. To enable MPLS to be deployed in a transport network and operated > in a similar manner to existing transport technologies. > > 2. To enable MPLS to support packet transport services with a > similar degree of predictability to that found in existing > transport networks. > > Based on the extensive comments provided by transport operators and ITU-T > community, the solution in this draft is useless in case 1. > > The fact that the solution in this draft is not backward compatible with > existing IP/MPLS BFD implementations means that this solution is also > uselesee > in case 2. > > Are there other undocumented use cases for MPLS-TP deployments? > > >----Messaggio originale---- > >Da: nurit.sprecher@nsn.com > >Data: 7-lug-2011 11.59 > >A: , , >, > "IETF-Announce" > >Cc: > >Ogg: RE: [mpls] R: Re: LastCall: > <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> > (Proactive Connectivity Verification,Continuity Check and Remote > Defect > indicationfor MPLS Transport Profile) to Proposed Standard > > > >Erminio, > >I do not think the history is relevant for this specific discussion... > >Also I find it inappropriate to give statements with no justifications > >behind. > >You say: "the solution in this draft is useless for many MPLS-TP > >deployments.". in order to seriously consider your comment, you have to > >show why it is useless and which requirements are not satisfied. > >Otherwise you cannot expect anyone to refer to your point. > >Best regards, > >Nurit > > > >P.s. did you mean that the document is useless to available non-standard > >deployments, e.g. T-MPLS? > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec51a8228a5263904a7fe96d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Erminio,
even though I'm not an operator but I think that you&#= 39;ve went bit too far in your first generalization.
"Every general= ization is wrong, including this one"

Regards,
Greg

On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone_69@libero.it <erminio.ottone_= 69@libero.it> wrote:
The technical concern raised during the WG = poll has not been resolved so the
history definetely matters.

Quoting RFC5921:

=A0 There are thus two objectives for MPLS-TP:

=A0 1. =A0To enable MPLS to be deployed in a transport network and operate= d
=A0 =A0 =A0 in a similar manner to existing transport technologies.

=A0 2. =A0To enable MPLS to support packet transport services with a
=A0 =A0 =A0 similar degree of predictability to that found in existing
=A0 =A0 =A0 transport networks.

Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1.

The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also usele= see
in case 2.

Are there other undocumented use cases for MPLS-TP deployments?

>----Messaggio originale----
>Da: nurit.sprecher@nsn.com
>Data: 7-lug-2011 11.59
>A: <erminio.ottone_69= @libero.it>, <RCosta@ptin= ovacao.pt>, <ietf@ietf.org&g= t;,
"IETF-Announce"<ietf-announce@ietf.org>
>Cc: <mpls@ietf.org> >Ogg: RE: [mpls] R: Re: LastCall: =A0 =A0 =A0 &lt;draft-ietf-mpls-tp= -cc-cv-rdi-05.txt&gt;
(Proactive =A0 =A0 =A0Connectivity =A0 =A0Verification,Co= ntinuity Check and Remote Defect
indicationfor =A0 MPLS =A0 =A0Transport =A0 =A0 =A0 Profile) to Propo= sed Standard
>
>Erminio,
>I do not think the history is relevant for this specific discussion...<= br> >Also I find it inappropriate to give statements with no justifications<= br> >behind.
>You say: "the solution in this draft is useless for many MPLS-TP >deployments.". =A0in order to seriously consider your comment, you= have to
>show why it is useless and which requirements are not satisfied.
>Otherwise you cannot expect anyone to refer to your point.
>Best regards,
>Nurit
>
>P.s. did you mean that the document is useless to available non-standar= d
>deployments, e.g. T-MPLS?
>
>


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

--bcaec51a8228a5263904a7fe96d4-- From neil.2.harrison@bt.com Thu Jul 14 00:42:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8B21F877B for ; Thu, 14 Jul 2011 00:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8oYGwntCzvS for ; Thu, 14 Jul 2011 00:42:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id C47B721F8770 for ; Thu, 14 Jul 2011 00:42:30 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 14 Jul 2011 08:42:29 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Thu, 14 Jul 2011 08:42:29 +0100 From: To: Date: Thu, 14 Jul 2011 08:42:25 +0100 Thread-Topic: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxBhDqUO0ly9x4eRKO+1qs+dUkpPQAc7aLQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> References: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> In-Reply-To: <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, stbryant@cisco.com Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:42:35 -0000 curtis@occnc.com observes 13 July 2011 18:42 =20 > In message <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > UKRD.domain1.systemhost.net> > neil.2.harrison@bt.com writes: > > > > I also have a question on this draft: > > > > How do different MPLS-TP layer networks that belong to the same > > operator get differentiated...noting that these may form nested > > client/server relationships and thus be subject to inter-layer > > misconnectivity as well as intra-layer misconnectivity? > > > > Thanks.....regards, Neil >=20 >=20 > How about the operator allocates from a different IP prefix for each > layer and uses a one line policy statement to prevent inter-layer > misconnectivity even if misconfiguration were to occur. >=20 > Oops. Wrong type of identifiers. No identifier aggregation in the > ICC/CC name space. >=20 > :-) >=20 > IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > At least those could be aggregated (not that I recommend using them). Curtis, I get the feeling here you think I am pro the ITU suggested address= ing structure. I am not. The ancient Recs this stuff comes from were base= d on really old PDH layer networks where operators did not use proper addre= ssing structures but some general alpha-numeric symbol string. BT tried to= deprecate this form of 'addressing' in the SDH Recs but some US operators = wanted to keep this old addressing structure. I am merely pointing out that besides distinguishing operators we also need= to distinguish each different MPLS-TP layer network that belongs to the sa= me operator in whatever addressing structure is used. I think it should be= obvious why this is required. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 >=20 > Curtis From stbryant@cisco.com Thu Jul 14 04:18:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721821F89E9 for ; Thu, 14 Jul 2011 04:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.246 X-Spam-Level: X-Spam-Status: No, score=-110.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlRl7LAS56jr for ; Thu, 14 Jul 2011 04:18:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15F21F89C1 for ; Thu, 14 Jul 2011 04:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2717; q=dns/txt; s=iport; t=1310642318; x=1311851918; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ldwYD5s1Ipn//ptBZWD7Vxm11dtRLjnlDTkUa03NBbo=; b=NI0fKelW8hFyqlqUCk64Pg2sZkytT8fUwYh3lyte0Zc9+1Cb4vWdU6s1 EHwOU3ivimRAD6WBTxmqVdK+ZB3m+jjJEQtZLwWFLYf36TjoWj7R0rDkO xnBcY3ZqFpScsOanf9T3Se4SfXA3p19PFGRV5OTEwemymYLtxwcMssr45 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAHAEbQHk6Q/khN/2dsb2JhbABFDphVjn13rEGDFQ8BmnMCgyCDGASSZJBS X-IronPort-AV: E=Sophos;i="4.65,528,1304294400"; d="scan'208";a="102109563" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 11:18:18 +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 p6EBIEWj024833; Thu, 14 Jul 2011 11:18:18 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6EBIDu5003796; Thu, 14 Jul 2011 12:18:14 +0100 (BST) Message-ID: <4E1ED075.3090909@cisco.com> Date: Thu, 14 Jul 2011 12:18:13 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: neil.2.harrison@bt.com References: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 11:18:43 -0000 Neil Yes, I think that you are correct. Leaving aside PWs for the moment, presumably an operator should consider each of their layer networks to be considered as an individual autonomous system and identify it as such. Stewart On 14/07/2011 08:42, neil.2.harrison@bt.com wrote: > curtis@occnc.com observes 13 July 2011 18:42 > >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- >> UKRD.domain1.systemhost.net> >> neil.2.harrison@bt.com writes: >>> I also have a question on this draft: >>> >>> How do different MPLS-TP layer networks that belong to the same >>> operator get differentiated...noting that these may form nested >>> client/server relationships and thus be subject to inter-layer >>> misconnectivity as well as intra-layer misconnectivity? >>> >>> Thanks.....regards, Neil >> >> How about the operator allocates from a different IP prefix for each >> layer and uses a one line policy statement to prevent inter-layer >> misconnectivity even if misconfiguration were to occur. >> >> Oops. Wrong type of identifiers. No identifier aggregation in the >> ICC/CC name space. >> >> :-) >> >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. >> At least those could be aggregated (not that I recommend using them). > Curtis, I get the feeling here you think I am pro the ITU suggested addressing structure. I am not. The ancient Recs this stuff comes from were based on really old PDH layer networks where operators did not use proper addressing structures but some general alpha-numeric symbol string. BT tried to deprecate this form of 'addressing' in the SDH Recs but some US operators wanted to keep this old addressing structure. > > I am merely pointing out that besides distinguishing operators we also need to distinguish each different MPLS-TP layer network that belongs to the same operator in whatever addressing structure is used. I think it should be obvious why this is required. > > regards, Neil > > This email contains BT information, which may be privileged or confidential. > It's meant only for the individual(s) or entity named above. If you're not the intended > recipient, note that disclosing, copying, distributing or using this information > is prohibited. If you've received this email in error, please let me know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > >> Curtis -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From hideki.endo.es@hitachi.com Thu Jul 14 04:23:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18B821F87A8 for ; Thu, 14 Jul 2011 04:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsx--WfWri51 for ; Thu, 14 Jul 2011 04:22:57 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id B02E621F87A4 for ; Thu, 14 Jul 2011 04:22:57 -0700 (PDT) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id DC2B237C88; Thu, 14 Jul 2011 20:22:56 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id p6EBMubF005675; Thu, 14 Jul 2011 20:22:56 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p6EBMtQi007781; Thu, 14 Jul 2011 20:22:56 +0900 X-AuditID: b753bd60-a1ec5ba000003bac-69-4e1ed18fcb80 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id CF7AF7741E5; Thu, 14 Jul 2011 20:22:55 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p6EBMtR6090898; Thu, 14 Jul 2011 20:22:55 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Thu, 14 Jul 2011 20:22:42 +0900 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> Priority: normal Importance: normal X400-Content-Identifier: X4E1ED16C00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml281107142022208X0] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] Last Call: (Proactive Connectivit X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 11:23:02 -0000 The changes in this version have massive impact for CC/CV/RDI implementation. We, venders, have kept making efforts on interoperability test again and again. These changes spoil this effort. Especially, revival of Poll/Final sequence doesn't make sense. Originally, in my understanding, Poll/Final sequence was excluded from this draft to avoid making HW implementation difficult. Even though it was difficult to change CC interval arbitrary, the problem should be solved by defining how to transit DOWN/INIT state to UP state. The direction which reached consensus once should NOT be changed easily in order to respond to the market requirements. IMO, such major changes should NOT be added right before becoming RFC. I found at least four major/minor changes as follows; 1)Revival of Poll/Final sequence 2)Change of MEP ID formats 3)Change of Diag. Code 4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From neil.2.harrison@bt.com Thu Jul 14 04:28:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F6521F88D3 for ; Thu, 14 Jul 2011 04:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDguiqkhg8O8 for ; Thu, 14 Jul 2011 04:28:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7721F8520 for ; Thu, 14 Jul 2011 04:28:26 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 14 Jul 2011 12:28:25 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Thu, 14 Jul 2011 12:28:25 +0100 From: To: Date: Thu, 14 Jul 2011 12:28:21 +0100 Thread-Topic: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxCF8mNT2wrvGClR9ut0OCgj6DGdAAABirw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405B2A00AE@EMV62-UKRD.domain1.systemhost.net> References: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> <4E1ED075.3090909@cisco.com> In-Reply-To: <4E1ED075.3090909@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 11:28:27 -0000 Exactly so Stewart...I'm glad at least you get this. We have never had to deal with the issue of nested layer networks that have= ostensibly identical characteristic information in co-cs mode transport ne= tworks based on regular time-slices before (eg PDH, SDH), simply because th= e traffic unit (=3D=3Dframe) here has a fixed/deterministic resource size i= n bits...so you cannot nest them, eg we cannot have T1overT1. This is not = the case with the co-ps mode that is based on irregular time slices of reso= urce and, specifically, a variable traffic unit length in bits....such as M= PLS-TP. Traditional LSP nesting is sublayering...so this is all the same layer netw= ork. But MPLS-TP demands we can do proper layering of different MPLS-TP la= yer networks. And a single operator may want to have several MPLS-TP layer= networks for different purposes and these can form client/server relations= hips. So, the addressing structure of 'source' as used in CV flows needs to not o= nly identify the operator but also the specific layer network of that opera= tors. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 14 July 2011 12:18 > To: Harrison,N,Neil,DKQ7 R > Cc: curtis@occnc.com; mpls@ietf.org > Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 >=20 > Neil >=20 > Yes, I think that you are correct. Leaving aside PWs for the moment, > presumably an operator should consider each of their layer networks to > be considered as an individual autonomous system and identify it as > such. >=20 > Stewart >=20 >=20 > On 14/07/2011 08:42, neil.2.harrison@bt.com wrote: > > curtis@occnc.com observes 13 July 2011 18:42 > > > >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > >> UKRD.domain1.systemhost.net> > >> neil.2.harrison@bt.com writes: > >>> I also have a question on this draft: > >>> > >>> How do different MPLS-TP layer networks that belong to the same > >>> operator get differentiated...noting that these may form nested > >>> client/server relationships and thus be subject to inter-layer > >>> misconnectivity as well as intra-layer misconnectivity? > >>> > >>> Thanks.....regards, Neil > >> > >> How about the operator allocates from a different IP prefix for each > >> layer and uses a one line policy statement to prevent inter-layer > >> misconnectivity even if misconfiguration were to occur. > >> > >> Oops. Wrong type of identifiers. No identifier aggregation in the > >> ICC/CC name space. > >> > >> :-) > >> > >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > >> At least those could be aggregated (not that I recommend using > them). > > Curtis, I get the feeling here you think I am pro the ITU suggested > addressing structure. I am not. The ancient Recs this stuff comes > from were based on really old PDH layer networks where operators did > not use proper addressing structures but some general alpha-numeric > symbol string. BT tried to deprecate this form of 'addressing' in the > SDH Recs but some US operators wanted to keep this old addressing > structure. > > > > I am merely pointing out that besides distinguishing operators we > also need to distinguish each different MPLS-TP layer network that > belongs to the same operator in whatever addressing structure is used. > I think it should be obvious why this is required. > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're not the intended > > recipient, note that disclosing, copying, distributing or using this > information > > is prohibited. If you've received this email in error, please let me > know immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > >> Curtis >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From davarish@yahoo.com Thu Jul 14 06:11:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F94521F863D for ; Thu, 14 Jul 2011 06:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvxg9WVnJacc for ; Thu, 14 Jul 2011 06:11:08 -0700 (PDT) Received: from nm26.access.bullet.mail.mud.yahoo.com (nm26.access.bullet.mail.mud.yahoo.com [66.94.237.91]) by ietfa.amsl.com (Postfix) with SMTP id C9DD321F8640 for ; Thu, 14 Jul 2011 06:11:07 -0700 (PDT) Received: from [66.94.237.201] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Jul 2011 13:11:02 -0000 Received: from [66.94.237.107] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Jul 2011 13:11:02 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 14 Jul 2011 13:11:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 922383.34158.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 66879 invoked by uid 60001); 14 Jul 2011 13:11:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310649062; bh=ynSsaTwTemf1Ul4NOClYWjxf7zSsOvnTAq6pSb+9oxQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0vpPenoT2DegWmQeaNiYUSmr1TMyq0/kFdhC7zdjebIhCHVCSb6Ux8Rht1rCKM9WLV27brM6BJYSWxTGHqMc2xwQ5NbwdGzS6HLk29bMaYv9NGeL841S8qByw9l9rmUjCNFB4aHcYyXZD6ptOd/0JO0RyHnAEy8C1gC+KFbZ1fs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0xFqOUI7kCg/l4Co+jmVwkARuf49JfBwFRDrLeS4p2faBBxO42eGPNlZta+aYM6WUFpng/ABDXzX13LqjitQzLFjzokvVZ7IcoFx/yCAR9FbY6Dhd49iwfGTnq8yP1HGZUU0ujhL5WWKRFHwyEpWiyHHw6IUgORaklXLNFWZxxI=; X-YMail-OSG: n_b9PrwVM1nNzpPes3aa4iHyQw_SGpimcihNkyz5TI4wP_l YjOyssS4m7aP1s.BbLm030eISmy5rSsjS8WCBlHn7PzgYOPTTDV4bfU11D2I 3xn0Q1Nvfp2GZjz_dDCXQuAp.A3kXbi8G9NwlcQepCuKjH5331RVkllst7TR TFpdMgWdkgvcyR_mWsxnjZBGAeOuZbS4eLiiJTRSPVAtmNaXYUDj4VALYAOk kScNBj7FNaPMEar2i9oHkr1k2SR1A2oAr3ubLqw51A.bKhoYNnIjQso18arw FR1b.EYsXFOoMxV7qoxr4o753YisbpQa3sZSK7reD7dbGPUtrdNmhJCDyrRJ R3VrCjNGvqB2nD1sfO2TG2Ve2c2I4csuoW0nT1g6EiEOLS7vgE8izr3MivV_ U4sZREkvsvpMX Received: from [98.248.36.11] by web88402.mail.re1.yahoo.com via HTTP; Thu, 14 Jul 2011 06:11:02 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> Message-ID: <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com> Date: Thu, 14 Jul 2011 06:11:02 -0700 (PDT) From: "S. Davari" To: ietf@ietf.or, mpls@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1713414270-1310649062=:45643" Subject: Re: [mpls] Last Call: (Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 13:11:11 -0000 --0-1713414270-1310649062=:45643 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI also have concern regarding:=0A=0A1) Different MEP ID formats=0A= 2) CV interleaving=0A=0AThese two functions make the Hardware implementatio= n very complex and delays =0Aimplementation and deployment of this draft. I= would have 2 suggestions to fix =0Athis:=0A=0A1) Make all MEPIDs the same = size (e.g. 12 bytes) for all LSP, PW, Segments =0Ainstead of TLV. TLVs are = not hardware friendly.=0A=0A2) Default to be All CC or All CV. Have the CV = interleaving optional (if both =0Asides are capable).=0A=0AThx=0AShahram=0A= =0A=0A=0A=0A________________________________=0AFrom: "hideki.endo.es@hitach= i.com" =0ATo: ietf@ietf.or; mpls@ietf.org=0ASen= t: Thu, July 14, 2011 4:22:42 AM=0ASubject: Re: [mpls] Last Call: (Proactive =0AConnectivit=0A=0AThe changes in t= his version have massive impact for CC/CV/RDI implementation.=0AWe, venders= , have kept making efforts on interoperability test again and again.=0AThes= e changes spoil this effort.=0A=0AEspecially, revival of Poll/Final sequenc= e doesn't make sense.=0AOriginally, in my understanding, Poll/Final sequenc= e was excluded from this =0Adraft=0Ato avoid making HW implementation diffi= cult. =0A=0AEven though it was difficult to change CC interval arbitrary, = =0Athe problem should be solved by defining how to transit DOWN/INIT state = to UP =0Astate.=0A=0AThe direction which reached consensus once should NOT = be changed easily=0Ain order to respond to the market requirements.=0A=0AIM= O, such major changes should NOT be added right before becoming RFC.=0A=0AI= found at least four major/minor changes as follows;=0A1)Revival of Poll/Fi= nal sequence=0A2)Change of MEP ID formats=0A3)Change of Diag. Code=0A4)Chan= ge of CV interleaved definition=0A=0ABR,=0AHideki=0A=0A=0A>=0A>The IESG has= received a request from the Multiprotocol Label Switching WG=0A>(mpls) to = consider the following document:=0A>- 'Proactive Connectivity Verification,= Continuity Check and Remote=0A>=A0 Defect indication for MPLS Transport Pr= ofile'=0A>=A0 as a Proposed Standard= =0A>=0A>The IESG plans to make a decision in the next few weeks, and solici= ts=0A>final comments on this action. Please send substantive comments to th= e=0A>ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may= be=0A>sent to iesg@ietf.org instead. In either case, please retain the=0A>= beginning of the Subject line to allow automated sorting.=0A>=0A>Abstract= =0A>=0A>=A0 Continuity Check, Proactive Connectivity Verification and Remot= e=0A>=A0 Defect Indication functionalities are required for MPLS-TP OAM.=0A= >=0A>=A0 Continuity Check monitors the integrity of the continuity of the= =0A>=A0 label switched path for any loss of continuity defect. Connectivity= =0A>=A0 verification monitors the integrity of the routing of the label=0A>= =A0 switched path between sink and source for any connectivity issues.=0A>= =A0 Remote defect indication enables an End Point to report, to its=0A>=A0 = associated End Point, a fault or defect condition that it detects on=0A>=A0= a pseudo wire, label switched path or Section.=0A>=0A>=A0 This document sp= ecifies methods for proactive continuity check,=0A>=A0 continuity verificat= ion, and remote defect indication for MPLS-TP=0A>=A0 label switched paths, = pseudo wires and Sections using Bidirectional=0A>=A0 Forwarding Detection.= =0A>=0A>=0A>The file can be obtained via=0A>http://datatracker.ietf.org/doc= /draft-ietf-mpls-tp-cc-cv-rdi/=0A>=0A>IESG discussion can be tracked via=0A= >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/=0A>=0A>=0A>N= o IPR declarations have been submitted directly on this I-D.=0A>___________= ____________________________________=0A>mpls mailing list=0A>mpls@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/mpls=0A>=0A______________________= _________________________=0Ampls mailing list=0Ampls@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/mpls=0A --0-1713414270-1310649062=:45643 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=0A
 
=0A
I also have conce= rn regarding:
=0A
 
=0A
1) Different MEP ID formats<= BR>2) CV interleaving
=0A
 
=0A
These two functions = make the Hardware implementation very complex and delays implementation and= deployment of this draft. I would have 2 suggestions to fix this:
=0A=
 
=0A
1) Make all MEPIDs the same size (e.g. 12 bytes) f= or all LSP, PW, Segments instead of TLV. TLVs are not hardware friendly.=0A
 
=0A
2) Default to be All CC or All CV. Have the = CV interleaving optional (if both sides are capable).
=0A
 =0A
Thx
=0A
Shahram
=0A
 
=0A
=
=0A
=0A
=0AFrom: "hideki.endo.es@hitachi.com" <hideki.en= do.es@hitachi.com>
To: ietf@ietf.or; mpls@ietf.org
Sent:= Thu, July 14, 2011 4:22:42 AM
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-= cv-rdi-05.txt>(Proactive Connectivit

The changes in this v= ersion have massive impact for CC/CV/RDI implementation.
We, venders, ha= ve kept making efforts on interoperability test again and again.
These c= hanges spoil this effort.

Especially, revival of Poll/Final sequence= doesn't make sense.
Originally, in my understanding, Poll/Final sequenc= e was excluded from this draft
to avoid making HW implementation difficu= lt.

Even though it was difficult to change CC interval arbitrary, <= BR>the problem should be solved by defining how to transit DOWN/INIT state to UP state.

The direction which reached co= nsensus once should NOT be changed easily
in order to respond to the mar= ket requirements.

IMO, such major changes should NOT be added right = before becoming RFC.

I found at least four major/minor changes as fo= llows;
1)Revival of Poll/Final sequence
2)Change of MEP ID formats3)Change of Diag. Code
4)Change of CV interleaved definition

BR,=
Hideki


>
>The IESG has received a request from the = Multiprotocol Label Switching WG
>(mpls) to consider the following do= cument:
>- 'Proactive Connectivity Verification, Continuity Check and= Remote
>  Defect indication for MPLS Transport Profile'
>=   <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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 2011-07-14. E= xceptionally, comments may be
>sent to iesg@ietf.org instead. In either ca= se, please retain the
>beginning of the Subject line to allow automat= ed sorting.
>
>Abstract
>
>  Continuity Check,= Proactive Connectivity Verification and Remote
>  Defect Indica= tion functionalities are required for MPLS-TP OAM.
>
>  Co= ntinuity Check monitors the integrity of the continuity of the
> = ; label switched path for any loss of continuity defect. Connectivity
&g= t;  verification monitors the integrity of the routing of the label>  switched path between sink and source for any connectivity issu= es.
>  Remote defect indication enables an End Point to report, to its
>  associated End Point, a fault or defect condition tha= t it detects on
>  a pseudo wire, label switched path or Section= .
>
>  This document specifies methods for proactive conti= nuity check,
>  continuity verification, and remote defect indic= ation for MPLS-TP
>  label switched paths, pseudo wires and Sect= ions using Bidirectional
>  Forwarding Detection.
>
>= ;
>The file can be obtained via
>http://datatrac= ker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/
>
>IESG disc= ussion can be tracked via
>http://datatracker.ietf.org= /doc/draft-ietf-mpls-tp-cc-cv-rdi/
>
>
>No IPR declar= ations have been submitted directly on this I-D.
>_______________________________________________
>mpls ma= iling list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailin= g list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
<= /DIV>
--0-1713414270-1310649062=:45643-- From curtis@occnc.com Thu Jul 14 07:17:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5455921F8873 for ; Thu, 14 Jul 2011 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbbao6jTivoj for ; Thu, 14 Jul 2011 07:17:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D03EB21F8799 for ; Thu, 14 Jul 2011 07:17:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6EEHbfv058404; Thu, 14 Jul 2011 10:17:37 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141417.p6EEHbfv058404@harbor.orleans.occnc.com> To: neil.2.harrison@bt.com From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 08:42:25 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> Date: Thu, 14 Jul 2011 10:17:37 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, stbryant@cisco.com Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:17:46 -0000 In message <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> neil.2.harrison@bt.com writes: > > curtis@occnc.com observes 13 July 2011 18:42 > > > In message <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > > UKRD.domain1.systemhost.net> > > neil.2.harrison@bt.com writes: > > > > > > I also have a question on this draft: > > > > > > How do different MPLS-TP layer networks that belong to the same > > > operator get differentiated...noting that these may form nested > > > client/server relationships and thus be subject to inter-layer > > > misconnectivity as well as intra-layer misconnectivity? > > > > > > Thanks.....regards, Neil > > > > > > How about the operator allocates from a different IP prefix for each > > layer and uses a one line policy statement to prevent inter-layer > > misconnectivity even if misconfiguration were to occur. > > > > Oops. Wrong type of identifiers. No identifier aggregation in the > > ICC/CC name space. > > > > :-) > > > > IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > > At least those could be aggregated (not that I recommend using them). > > Curtis, I get the feeling here you think I am pro the ITU suggested > addressing structure. I am not. The ancient Recs this stuff comes > from were based on really old PDH layer networks where operators did > not use proper addressing structures but some general alpha-numeric > symbol string. BT tried to deprecate this form of 'addressing' in the > SDH Recs but some US operators wanted to keep this old addressing > structure. > > I am merely pointing out that besides distinguishing operators we also > need to distinguish each different MPLS-TP layer network that belongs > to the same operator in whatever addressing structure is used. I > think it should be obvious why this is required. > > regards, Neil Neil, I understood that you were pointing out a limitation in the ICC/CC as an identifier. I was sort of adding to that. In addition to the absolutely trivial approach of assigning from different prefixes, there is also all of the IGP MT work and the GMPLS MLN/MRN work to isolate layers in routing and signaling. The IGP instance used in these is not carried into the OAM. If we look at the tp-identifiers draft, we have a 4 byte or 16 byte Node_ID but no IGP instance. So using a prefix works even if Global_ID is set to zero. I don't see a need to add IGP instance to Node_ID since the AS number is available and there is a large pool of numbers reserved as private AS numbers for use within a provider (originally intended for use in BGP Conferations). Where IGP instance never leaves the provider the reserved private AS numbers can be used. OTOH why should we settle for something simple that works when we could have a committee design something complicated. This isn't your grandfather's IETF, where simple solutions and running code matters. We have ITU-T helping us now. :-) Curtis From malcolm.betts@zte.com.cn Thu Jul 14 07:29:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA48A21F8AD3; Thu, 14 Jul 2011 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDD7a94tk+K0; Thu, 14 Jul 2011 07:29:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3535621F8A57; Thu, 14 Jul 2011 07:28:59 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Thu, 14 Jul 2011 22:27:24 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1784411434; Thu, 14 Jul 2011 22:28:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6EESmiC096163; Thu, 14 Jul 2011 22:28:48 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405B2A00AE@EMV62-UKRD.domain1.systemhost.net> References: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> <4E1ED075.3090909@cisco.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B2A00AE@EMV62-UKRD.domain1.systemhost.net> To: mpls@ietf.org, mpls-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: E2320E87:E338828B-852578CD:0044D5DD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Thu, 14 Jul 2011 10:28:25 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-14 22:28:50, Serialize complete at 2011-07-14 22:28:50 Content-Type: multipart/alternative; boundary="=_alternative 004F8998852578CD_=" X-MAIL: mse01.zte.com.cn p6EESmiC096163 Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC must be unique X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:29:04 -0000 This is a multipart message in MIME format. --=_alternative 004F8998852578CD_= Content-Type: text/plain; charset="US-ASCII" As Neil points out below each operator must ensure that the MEG identifier is unique for each LSP that is being monitored within the scope of that operator. This is also stated in section 5 of the draft "The UMC MUST be unique within the organization identified by the ICC." The need to make the UMC unique is independent of the method used to identify the operator. Regards, Malcolm Sent by: mpls-bounces@ietf.org 14/07/2011 07:28 AM To cc mpls@ietf.org Subject Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 Exactly so Stewart...I'm glad at least you get this. We have never had to deal with the issue of nested layer networks that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply because the traffic unit (==frame) here has a fixed/deterministic resource size in bits...so you cannot nest them, eg we cannot have T1overT1. This is not the case with the co-ps mode that is based on irregular time slices of resource and, specifically, a variable traffic unit length in bits....such as MPLS-TP. Traditional LSP nesting is sublayering...so this is all the same layer network. But MPLS-TP demands we can do proper layering of different MPLS-TP layer networks. And a single operator may want to have several MPLS-TP layer networks for different purposes and these can form client/server relationships. So, the addressing structure of 'source' as used in CV flows needs to not only identify the operator but also the specific layer network of that operators. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 14 July 2011 12:18 > To: Harrison,N,Neil,DKQ7 R > Cc: curtis@occnc.com; mpls@ietf.org > Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 > > Neil > > Yes, I think that you are correct. Leaving aside PWs for the moment, > presumably an operator should consider each of their layer networks to > be considered as an individual autonomous system and identify it as > such. > > Stewart > > > On 14/07/2011 08:42, neil.2.harrison@bt.com wrote: > > curtis@occnc.com observes 13 July 2011 18:42 > > > >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > >> UKRD.domain1.systemhost.net> > >> neil.2.harrison@bt.com writes: > >>> I also have a question on this draft: > >>> > >>> How do different MPLS-TP layer networks that belong to the same > >>> operator get differentiated...noting that these may form nested > >>> client/server relationships and thus be subject to inter-layer > >>> misconnectivity as well as intra-layer misconnectivity? > >>> > >>> Thanks.....regards, Neil > >> > >> How about the operator allocates from a different IP prefix for each > >> layer and uses a one line policy statement to prevent inter-layer > >> misconnectivity even if misconfiguration were to occur. > >> > >> Oops. Wrong type of identifiers. No identifier aggregation in the > >> ICC/CC name space. > >> > >> :-) > >> > >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > >> At least those could be aggregated (not that I recommend using > them). > > Curtis, I get the feeling here you think I am pro the ITU suggested > addressing structure. I am not. The ancient Recs this stuff comes > from were based on really old PDH layer networks where operators did > not use proper addressing structures but some general alpha-numeric > symbol string. BT tried to deprecate this form of 'addressing' in the > SDH Recs but some US operators wanted to keep this old addressing > structure. > > > > I am merely pointing out that besides distinguishing operators we > also need to distinguish each different MPLS-TP layer network that > belongs to the same operator in whatever addressing structure is used. > I think it should be obvious why this is required. > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're not the intended > > recipient, note that disclosing, copying, distributing or using this > information > > is prohibited. If you've received this email in error, please let me > know immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > >> Curtis > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 004F8998852578CD_= Content-Type: text/html; charset="US-ASCII" As Neil points out below each operator must ensure that the MEG identifier is unique for each LSP that is being monitored within the scope of that operator.  This is also stated in section 5 of the draft   "The UMC MUST be unique within the organization identified by the ICC."   The need to make the UMC unique is independent of the method used to identify the operator.

Regards,

Malcolm
 


<neil.2.harrison@bt.com>
Sent by: mpls-bounces@ietf.org

14/07/2011 07:28 AM

To
<stbryant@cisco.com>
cc
mpls@ietf.org
Subject
Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01





Exactly so Stewart...I'm glad at least you get this.

We have never had to deal with the issue of nested layer networks that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply because the traffic unit (==frame) here has a fixed/deterministic resource size in bits...so you cannot nest them, eg we cannot have T1overT1.  This is not the case with the co-ps mode that is based on irregular time slices of resource and, specifically, a variable traffic unit length in bits....such as MPLS-TP.

Traditional LSP nesting is sublayering...so this is all the same layer network.  But MPLS-TP demands we can do proper layering of different MPLS-TP layer networks.  And a single operator may want to have several MPLS-TP layer networks for different purposes and these can form client/server relationships.

So, the addressing structure of 'source' as used in CV flows needs to not only identify the operator but also the specific layer network of that operators.

regards, Neil

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




> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: 14 July 2011 12:18
> To: Harrison,N,Neil,DKQ7 R
> Cc: curtis@occnc.com; mpls@ietf.org
> Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01
>
> Neil
>
> Yes, I think that you are correct. Leaving aside PWs for the moment,
> presumably an operator should consider each of their layer networks to
> be considered as an individual autonomous system and identify it as
> such.
>
> Stewart
>
>
> On 14/07/2011 08:42, neil.2.harrison@bt.com wrote:
> > curtis@occnc.com observes 13 July 2011 18:42
> >
> >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-
> >> UKRD.domain1.systemhost.net>
> >> neil.2.harrison@bt.com writes:
> >>> I also have a question on this draft:
> >>>
> >>> How do different MPLS-TP layer networks that belong to the same
> >>> operator get differentiated...noting that these may form nested
> >>> client/server relationships and thus be subject to inter-layer
> >>> misconnectivity as well as intra-layer misconnectivity?
> >>>
> >>> Thanks.....regards, Neil
> >>
> >> How about the operator allocates from a different IP prefix for each
> >> layer and uses a one line policy statement to prevent inter-layer
> >> misconnectivity even if misconfiguration were to occur.
> >>
> >> Oops.  Wrong type of identifiers.  No identifier aggregation in the
> >> ICC/CC name space.
> >>
> >> :-)
> >>
> >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses.
> >> At least those could be aggregated (not that I recommend using
> them).
> > Curtis, I get the feeling here you think I am pro the ITU suggested
> addressing structure.  I am not.  The ancient Recs this stuff comes
> from were based on really old PDH layer networks where operators did
> not use proper addressing structures but some general alpha-numeric
> symbol string.  BT tried to deprecate this form of 'addressing' in the
> SDH Recs but some US operators wanted to keep this old addressing
> structure.
> >
> > I am merely pointing out that besides distinguishing operators we
> also need to distinguish each different MPLS-TP layer network that
> belongs to the same operator in whatever addressing structure is used.
> I think it should be obvious why this is required.
> >
> > regards, Neil
> >
> > This email contains BT information, which may be privileged or
> confidential.
> > It's meant only for the individual(s) or entity named above. If
> you're not the intended
> > recipient, note that disclosing, copying, distributing or using this
> information
> > is prohibited. If you've received this email in error, please let me
> know immediately
> > on the email address above. Thank you.
> > We monitor our email system, and may record your emails.
> > British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no: 1800000
> >
> >
> >
> >> Curtis
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 004F8998852578CD_=-- From kam.lam@alcatel-lucent.com Thu Jul 14 07:36:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B855921F86EE for ; Thu, 14 Jul 2011 07:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqlclbc8bAqB for ; Thu, 14 Jul 2011 07:36:14 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 282E721F86EB for ; Thu, 14 Jul 2011 07:36:14 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6EEaBLQ018755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 09:36:13 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6EEaBW1017448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Jul 2011 09:36:11 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 14 Jul 2011 09:36:11 -0500 From: "Lam, Hing-Kam (Kam)" To: Ross Callon , "mpls@ietf.org" Date: Thu, 14 Jul 2011 09:36:10 -0500 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gBinqTQ Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD57D79C98B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F76AEFB05C38145BABA0D545E3CFFD57D79C98BUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:36:15 -0000 --_000_7F76AEFB05C38145BABA0D545E3CFFD57D79C98BUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support --Kam From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 11:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_7F76AEFB05C38145BABA0D545E3CFFD57D79C98BUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/= Support

 

--Kam

=

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@= ietf.org] On Behalf Of Ross Callon
Sent: Tuesday, July 12,= 2011 11:32 AM
To: mpls@ietf.org
Cc: Ross Callon; draft= -win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: [mpls] Pol= l on draft-win-mpls-tp-itu-t-identifiers-01

 

Working Grou= p,

 

this is to start a 12 day poll on making

 

draft-win-mpls-tp-itu-t-identifiers-01

 

an mpls working group document.

 

If you suppor= t the document becoming a working group document please <= /p>

respond to this poll with "yes/support&quo= t;

 

If you do not support the document becoming a wo= rking group document

= please = respond to this poll with "no/do not support" and at the same tim= e

give the technical reasons= why you are not supporting the document.

<= p class=3DMsoNormal> 

If you ha= ve technical comments or in any other way want to discuss the

document, please send these comments to t= he mpls working group mailing

list, but with another subject than what is on this mail. Please include = the

string “draft-win-= mpls-tp-itu-t-identifiers” in the subject line.

 

The poll ends 2011-07-24.  Please note that this is the Sunday b= efore the

IETF. Also note th= at the length of the poll has  been shortened by two days <= /span>

so that the poll can be completed prior = to our first WG meeting in Quebec City. 

<= div>

 

Ross=

 

=
= --_000_7F76AEFB05C38145BABA0D545E3CFFD57D79C98BUSNAVSXCHMBSA2n_-- From hongk@cisco.com Thu Jul 14 08:47:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3521F85F9; Thu, 14 Jul 2011 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skk1xtIMF1+T; Thu, 14 Jul 2011 08:47:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A13521F8698; Thu, 14 Jul 2011 08:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=23192; q=dns/txt; s=iport; t=1310658445; x=1311868045; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=2tNdUIoid16EdUBRtexsHczDbc4cHEJ2i/vuv5FYkCs=; b=MoxuuLB1OVfXw62d7e27R+L4KDFpba7gWmr38Gl8MLnG4wHSDGq1AecB 1G62Cme/UY46+UeRUXVEkJgF5+jEW6mqnGv6TZhs+3/MCrjZ00uv+ZQNk UP86KtBkgDfwqMMQMoxk4XUAluxnYS6BJg2p2OAr4gRdV2oYz6p9ugd0G Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAF4OH06tJV2c/2dsb2JhbABFDoJTlUGPQXesbp4iAoMggjlfBIdTkBqLZg X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208,217";a="2970245" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jul 2011 15:47:24 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6EFlOd1023537; Thu, 14 Jul 2011 15:47:24 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 10:47:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC423D.531E7F42" Date: Thu, 14 Jul 2011 10:47:21 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC047E8758@XMB-RCD-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC must beunique thread-index: AcxCMmgXaCcpdBbrQ0eryMtaPUG+IAAB2n0g References: Your message of "Wed, 13 Jul 2011 10:31:01BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net><201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net><4E1ED075.3090909@cisco.com><6D3D47CB84BDE349BC23BF1C94E316E4405B2A00AE@EMV62-UKRD.domain1.systemhost.net> From: "Kyung-Yeop Hong (hongk)" To: , , X-OriginalArrivalTime: 14 Jul 2011 15:47:24.0211 (UTC) FILETIME=[53228030:01CC423D] Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC must beunique X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:47:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC423D.531E7F42 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm and Yes/Supporters, MEG ID is unique for each LSP.=20 As I pointed out in my earlier email (re: "No / Do not support"), the unique MEG ID code (UMC) is limited to 4 characters as defined in Section 5 of draft-win-mpls-tp-itu-t-identifiers. In case of MPLS-TP associated bidirectional LSP ID, each of the unidirectional LSPs require LSP_nums (16-bit unsigned integer). So the 32 bits are required just for LSP ID, and additional 32 x 2 bits for Node ID and so on. =20 How can you identify it only with 4 characters? You cannot simply say it's a matter for the operator to use a different method and provide unique IDs. =20 KY =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: Thursday, July 14, 2011 10:28 AM To: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC must beunique =20 As Neil points out below each operator must ensure that the MEG identifier is unique for each LSP that is being monitored within the scope of that operator. This is also stated in section 5 of the draft "The UMC MUST be unique within the organization identified by the ICC." The need to make the UMC unique is independent of the method used to identify the operator.=20 Regards,=20 Malcolm=20 =20 =20 Sent by: mpls-bounces@ietf.org=20 14/07/2011 07:28 AM=20 To =20 cc mpls@ietf.org=20 Subject Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 =20 =09 Exactly so Stewart...I'm glad at least you get this. We have never had to deal with the issue of nested layer networks that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply because the traffic unit (=3D=3Dframe) here has a = fixed/deterministic resource size in bits...so you cannot nest them, eg we cannot have T1overT1. This is not the case with the co-ps mode that is based on irregular time slices of resource and, specifically, a variable traffic unit length in bits....such as MPLS-TP. Traditional LSP nesting is sublayering...so this is all the same layer network. But MPLS-TP demands we can do proper layering of different MPLS-TP layer networks. And a single operator may want to have several MPLS-TP layer networks for different purposes and these can form client/server relationships. So, the addressing structure of 'source' as used in CV flows needs to not only identify the operator but also the specific layer network of that operators. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com ] > Sent: 14 July 2011 12:18 > To: Harrison,N,Neil,DKQ7 R > Cc: curtis@occnc.com; mpls@ietf.org > Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 >=20 > Neil >=20 > Yes, I think that you are correct. Leaving aside PWs for the moment, > presumably an operator should consider each of their layer networks to > be considered as an individual autonomous system and identify it as > such. >=20 > Stewart >=20 >=20 > On 14/07/2011 08:42, neil.2.harrison@bt.com wrote: > > curtis@occnc.com observes 13 July 2011 18:42 > > > >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > >> UKRD.domain1.systemhost.net> > >> neil.2.harrison@bt.com writes: > >>> I also have a question on this draft: > >>> > >>> How do different MPLS-TP layer networks that belong to the same > >>> operator get differentiated...noting that these may form nested > >>> client/server relationships and thus be subject to inter-layer > >>> misconnectivity as well as intra-layer misconnectivity? > >>> > >>> Thanks.....regards, Neil > >> > >> How about the operator allocates from a different IP prefix for each > >> layer and uses a one line policy statement to prevent inter-layer > >> misconnectivity even if misconfiguration were to occur. > >> > >> Oops. Wrong type of identifiers. No identifier aggregation in the > >> ICC/CC name space. > >> > >> :-) > >> > >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > >> At least those could be aggregated (not that I recommend using > them). > > Curtis, I get the feeling here you think I am pro the ITU suggested > addressing structure. I am not. The ancient Recs this stuff comes > from were based on really old PDH layer networks where operators did > not use proper addressing structures but some general alpha-numeric > symbol string. BT tried to deprecate this form of 'addressing' in the > SDH Recs but some US operators wanted to keep this old addressing > structure. > > > > I am merely pointing out that besides distinguishing operators we > also need to distinguish each different MPLS-TP layer network that > belongs to the same operator in whatever addressing structure is used. > I think it should be obvious why this is required. > > > > regards, Neil > > > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're not the intended > > recipient, note that disclosing, copying, distributing or using this > information > > is prohibited. If you've received this email in error, please let me > know immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > >> Curtis >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------_=_NextPart_001_01CC423D.531E7F42 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm and Yes/Supporters,

MEG ID is unique for each LSP.

As I pointed out in my earlier email (re: “No / Do = not support”), the unique MEG ID code (UMC) is limited to 4 characters = as defined in Section 5 of = draft-win-mpls-tp-itu-t-identifiers.

In case of MPLS-TP associated bidirectional LSP ID, each = of the unidirectional LSPs require LSP_nums (16-bit unsigned integer). So the = 32 bits are required just for LSP ID, and additional 32 x 2 bits for Node ID and = so on.

 

How can you identify it only with 4 = characters?

You cannot simply say it’s a matter for the = operator to use a different method and provide unique IDs.

 

KY

 

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Malcolm.BETTS@zte.com.cn
Sent: Thursday, July 14, 2011 10:28 AM
To: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the = UMC must beunique

 

As Neil points out below each operator = must ensure that the MEG identifier is unique for each LSP that is being = monitored within the scope of that operator.  This is also stated in section = 5 of the draft   "The UMC MUST be unique within the organization identified by the = ICC." =   The need to make the UMC unique is independent of the method used to = identify the operator.

Regards,

Malcolm
 =

<neil.2.har= rison@bt.com> =
Sent = by: mpls-bounces@ietf.org

14/07/2011 07:28 AM

To=

<stbryant@c= isco.com>

cc=

mpls@ietf.org<= /span>

Subject=

Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01

 




Exactly so Stewart...I'm glad at = least you get this.

We have never had to deal with the issue of nested layer networks = that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply = because the traffic unit (=3D=3Dframe) here has a fixed/deterministic resource size = in bits...so you cannot nest them, eg we cannot have T1overT1.  This = is not the case with the co-ps mode that is based on irregular time slices of = resource and, specifically, a variable traffic unit length in bits....such as = MPLS-TP.

Traditional LSP nesting is sublayering...so this is all the same = layer network.  But MPLS-TP demands we can do proper layering of = different MPLS-TP layer networks.  And a single operator may want to have = several MPLS-TP layer networks for different purposes and these can form = client/server relationships.

So, the addressing structure of 'source' as used in CV flows needs = to not only identify the operator but also the specific layer network of that operators.

regards, Neil

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




> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com<= span style=3D'font-size:10.0pt'>]
> Sent: 14 July 2011 12:18
> To: Harrison,N,Neil,DKQ7 R
> Cc: curtis@occnc.com; mpls@ietf.org
> Subject: Re: [mpls] = draft-win-mpls-tp-itu-t-identifiers-01
>
> Neil
>
> Yes, I think that you are correct. Leaving aside PWs for the = moment,
> presumably an operator should consider each of their layer = networks to
> be considered as an individual autonomous system and identify = it as
> such.
>
> Stewart
>
>
> On 14/07/2011 08:42, neil.2.harrison@bt.com wrote:
> > curtis@occnc.com observes 13 July 2011 18:42
> >
> >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-
> >> UKRD.domain1.systemhost.net>
> >> neil.2.harrison@bt.com writes:
> >>> I also have a question on this draft:
> >>>
> >>> How do different MPLS-TP layer networks that = belong to the same
> >>> operator get differentiated...noting that these = may form nested
> >>> client/server relationships and thus be subject to inter-layer
> >>> misconnectivity as well as intra-layer = misconnectivity?
> >>>
> >>> Thanks.....regards, Neil
> >>
> >> How about the operator allocates from a different IP = prefix for each
> >> layer and uses a one line policy statement to prevent inter-layer
> >> misconnectivity even if misconfiguration were to = occur.
> >>
> >> Oops.  Wrong type of identifiers.  No = identifier aggregation in the
> >> ICC/CC name space.
> >>
> >> :-)
> >>
> >> IMHO ICC/CC makes even less sense than using 20 byte = OSI addresses.
> >> At least those could be aggregated (not that I = recommend using
> them).
> > Curtis, I get the feeling here you think I am pro the ITU suggested
> addressing structure.  I am not.  The ancient Recs = this stuff comes
> from were based on really old PDH layer networks where = operators did
> not use proper addressing structures but some general = alpha-numeric
> symbol string.  BT tried to deprecate this form of = 'addressing' in the
> SDH Recs but some US operators wanted to keep this old = addressing
> structure.
> >
> > I am merely pointing out that besides distinguishing = operators we
> also need to distinguish each different MPLS-TP layer network = that
> belongs to the same operator in whatever addressing structure = is used.
> I think it should be obvious why this is required.
> >
> > regards, Neil
> >
> > This email contains BT information, which may be = privileged or
> confidential.
> > It's meant only for the individual(s) or entity named = above. If
> you're not the intended
> > recipient, note that disclosing, copying, distributing or = using this
> information
> > is prohibited. If you've received this email in error, = please let me
> know immediately
> > on the email address above. Thank you.
> > We monitor our email system, and may record your = emails.
> > British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A = 7AJ
> > Registered in England no: 1800000
> >
> >
> >
> >> Curtis
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/= legal/cri/index.html
>

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

------_=_NextPart_001_01CC423D.531E7F42-- From stbryant@cisco.com Thu Jul 14 09:11:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6A21F8D00 for ; Thu, 14 Jul 2011 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.937 X-Spam-Level: X-Spam-Status: No, score=-109.937 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOtY5DDO1nvw for ; Thu, 14 Jul 2011 09:11:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B51A321F853B for ; Thu, 14 Jul 2011 09:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=20161; q=dns/txt; s=iport; t=1310659892; x=1311869492; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=phGUEgLkhp8Ezjv/55aUFU+v9ikBEngftjPDkZWKg0w=; b=JiAksWohUYHdKH2WWUesGlMV54He3jUYzRjXPDAnAfEI2MRrg4ukZGQm Eodl4UdqeWPPP7u62KVtU9JeSNnSfr+YNrpp5HXBZbuMklXLYfijAD9No ArWJ3yXZ4lCLD/lDoyWGyrYccZO6rF3c3I+319ZIrezRvCj0k9MF24o6M M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD4UH06Q/khM/2dsb2JhbABFDqdVd60AgxUPAZsAAoMggxgEgk2QF5BS X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208,217";a="102208975" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 16:11:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6EGBVBg010831 for ; Thu, 14 Jul 2011 16:11:31 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6EGBUGm024601; Thu, 14 Jul 2011 17:11:30 +0100 (BST) Message-ID: <4E1F1532.1050705@cisco.com> Date: Thu, 14 Jul 2011 17:11:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mpls@ietf.org References: Your message of "Wed, 13 Jul 2011 10:31:01 BST." <6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-UKRD.domain1.systemhost.net> <201107131742.p6DHgMXl093080@harbor.orleans.occnc.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B29FDA2@EMV62-UKRD.domain1.systemhost.net> <4E1ED075.3090909@cisco.com> <6D3D47CB84BDE349BC23BF1C94E316E4405B2A00AE@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070407080008020500030706" Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC must be unique X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:11:41 -0000 This is a multi-part message in MIME format. --------------070407080008020500030706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Malcolm There some outstanding questions I raised, in particular whether there was enough address apace in your proposal which I think only leaves space for 65535 discrete values. Stewart On 14/07/2011 15:28, Malcolm.BETTS@zte.com.cn wrote: > As Neil points out below each operator must ensure that the MEG > identifier is unique for each LSP that is being monitored within the > scope of that operator. This is also stated in section 5 of the draft > "The UMC MUST be unique within the organization identified by the > ICC." The need to make the UMC unique is independent of the method > used to identify the operator. > > Regards, > > Malcolm > > > > ** > Sent by: mpls-bounces@ietf.org > > 14/07/2011 07:28 AM > > > To > > cc > mpls@ietf.org > Subject > Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 > > > > > > > > > > Exactly so Stewart...I'm glad at least you get this. > > We have never had to deal with the issue of nested layer networks that > have ostensibly identical characteristic information in co-cs mode > transport networks based on regular time-slices before (eg PDH, SDH), > simply because the traffic unit (==frame) here has a > fixed/deterministic resource size in bits...so you cannot nest them, > eg we cannot have T1overT1. This is not the case with the co-ps mode > that is based on irregular time slices of resource and, specifically, > a variable traffic unit length in bits....such as MPLS-TP. > > Traditional LSP nesting is sublayering...so this is all the same layer > network. But MPLS-TP demands we can do proper layering of different > MPLS-TP layer networks. And a single operator may want to have > several MPLS-TP layer networks for different purposes and these can > form client/server relationships. > > So, the addressing structure of 'source' as used in CV flows needs to > not only identify the operator but also the specific layer network of > that operators. > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > It's meant only for the individual(s) or entity named above. If you're > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: 14 July 2011 12:18 > > To: Harrison,N,Neil,DKQ7 R > > Cc: curtis@occnc.com; mpls@ietf.org > > Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 > > > > Neil > > > > Yes, I think that you are correct. Leaving aside PWs for the moment, > > presumably an operator should consider each of their layer networks to > > be considered as an individual autonomous system and identify it as > > such. > > > > Stewart > > > > > > On 14/07/2011 08:42, neil.2.harrison@bt.com wrote: > > > curtis@occnc.com observes 13 July 2011 18:42 > > > > > >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62- > > >> UKRD.domain1.systemhost.net> > > >> neil.2.harrison@bt.com writes: > > >>> I also have a question on this draft: > > >>> > > >>> How do different MPLS-TP layer networks that belong to the same > > >>> operator get differentiated...noting that these may form nested > > >>> client/server relationships and thus be subject to inter-layer > > >>> misconnectivity as well as intra-layer misconnectivity? > > >>> > > >>> Thanks.....regards, Neil > > >> > > >> How about the operator allocates from a different IP prefix for each > > >> layer and uses a one line policy statement to prevent inter-layer > > >> misconnectivity even if misconfiguration were to occur. > > >> > > >> Oops. Wrong type of identifiers. No identifier aggregation in the > > >> ICC/CC name space. > > >> > > >> :-) > > >> > > >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses. > > >> At least those could be aggregated (not that I recommend using > > them). > > > Curtis, I get the feeling here you think I am pro the ITU suggested > > addressing structure. I am not. The ancient Recs this stuff comes > > from were based on really old PDH layer networks where operators did > > not use proper addressing structures but some general alpha-numeric > > symbol string. BT tried to deprecate this form of 'addressing' in the > > SDH Recs but some US operators wanted to keep this old addressing > > structure. > > > > > > I am merely pointing out that besides distinguishing operators we > > also need to distinguish each different MPLS-TP layer network that > > belongs to the same operator in whatever addressing structure is used. > > I think it should be obvious why this is required. > > > > > > regards, Neil > > > > > > This email contains BT information, which may be privileged or > > confidential. > > > It's meant only for the individual(s) or entity named above. If > > you're not the intended > > > recipient, note that disclosing, copying, distributing or using this > > information > > > is prohibited. If you've received this email in error, please let me > > know immediately > > > on the email address above. Thank you. > > > We monitor our email system, and may record your emails. > > > British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ > > > Registered in England no: 1800000 > > > > > > > > > > > >> Curtis > > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070407080008020500030706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Malcolm

There some outstanding questions I raised, in particular whether there was enough address apace in your proposal which I think only leaves space for 65535 discrete values.

Stewart

On 14/07/2011 15:28, Malcolm.BETTS@zte.com.cn wrote:
As Neil points out below each operator must ensure that the MEG identifier is unique for each LSP that is being monitored within the scope of that operator.  This is also stated in section 5 of the draft   "The UMC MUST be unique within the organization identified by the ICC."   The need to make the UMC unique is independent of the method used to identify the operator.

Regards,

Malcolm
 


<neil.2.harrison@bt.com>
Sent by: mpls-bounces@ietf.org

14/07/2011 07:28 AM

To
 <stbryant@cisco.com>
cc
 mpls@ietf.org
Subject
 Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01







Exactly so Stewart...I'm glad at least you get this.

We have never had to deal with the issue of nested layer networks that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply because the traffic unit (==frame) here has a fixed/deterministic resource size in bits...so you cannot nest them, eg we cannot have T1overT1.  This is not the case with the co-ps mode that is based on irregular time slices of resource and, specifically, a variable traffic unit length in bits....such as MPLS-TP.

Traditional LSP nesting is sublayering...so this is all the same layer network.  But MPLS-TP demands we can do proper layering of different MPLS-TP layer networks.  And a single operator may want to have several MPLS-TP layer networks for different purposes and these can form client/server relationships.

So, the addressing structure of 'source' as used in CV flows needs to not only identify the operator but also the specific layer network of that operators.

regards, Neil

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




> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: 14 July 2011 12:18
> To: Harrison,N,Neil,DKQ7 R
> Cc: curtis@occnc.com; mpls@ietf.org
> Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01
>
> Neil
>
> Yes, I think that you are correct. Leaving aside PWs for the moment,
> presumably an operator should consider each of their layer networks to
> be considered as an individual autonomous system and identify it as
> such.
>
> Stewart
>
>
> On 14/07/2011 08:42, neil.2.harrison@bt.com wrote:
> > curtis@occnc.com observes 13 July 2011 18:42
> >
> >> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-
> >> UKRD.domain1.systemhost.net>
> >> neil.2.harrison@bt.com writes:
> >>> I also have a question on this draft:
> >>>
> >>> How do different MPLS-TP layer networks that belong to the same
> >>> operator get differentiated...noting that these may form nested
> >>> client/server relationships and thus be subject to inter-layer
> >>> misconnectivity as well as intra-layer misconnectivity?
> >>>
> >>> Thanks.....regards, Neil
> >>
> >> How about the operator allocates from a different IP prefix for each
> >> layer and uses a one line policy statement to prevent inter-layer
> >> misconnectivity even if misconfiguration were to occur.
> >>
> >> Oops.  Wrong type of identifiers.  No identifier aggregation in the
> >> ICC/CC name space.
> >>
> >> :-)
> >>
> >> IMHO ICC/CC makes even less sense than using 20 byte OSI addresses.
> >> At least those could be aggregated (not that I recommend using
> them).
> > Curtis, I get the feeling here you think I am pro the ITU suggested
> addressing structure.  I am not.  The ancient Recs this stuff comes
> from were based on really old PDH layer networks where operators did
> not use proper addressing structures but some general alpha-numeric
> symbol string.  BT tried to deprecate this form of 'addressing' in the
> SDH Recs but some US operators wanted to keep this old addressing
> structure.
> >
> > I am merely pointing out that besides distinguishing operators we
> also need to distinguish each different MPLS-TP layer network that
> belongs to the same operator in whatever addressing structure is used.
> I think it should be obvious why this is required.
> >
> > regards, Neil
> >
> > This email contains BT information, which may be privileged or
> confidential.
> > It's meant only for the individual(s) or entity named above. If
> you're not the intended
> > recipient, note that disclosing, copying, distributing or using this
> information
> > is prohibited. If you've received this email in error, please let me
> know immediately
> > on the email address above. Thank you.
> > We monitor our email system, and may record your emails.
> > British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no: 1800000
> >
> >
> >
> >> Curtis
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

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

 


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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070407080008020500030706-- From RCosta@ptinovacao.pt Thu Jul 14 10:32:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9936A21F8BD7; Thu, 14 Jul 2011 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po4UTSxi31XY; Thu, 14 Jul 2011 10:32:54 -0700 (PDT) Received: from owa.ptinovacao.pt (webmail.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5C42121F8BCF; Thu, 14 Jul 2011 10:32:53 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Thu, 14 Jul 2011 18:32:51 +0100 From: Rui Costa To: David Allan I Date: Thu, 14 Jul 2011 18:32:48 +0100 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAApIjzAABwiuqg Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53BBBB@INOAVREX11.ptin.corpPT.com> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <60C093A41B5E45409A19D42CF7786DFD522135449A@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522135449A@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:32:58 -0000 David, T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the simpl= e/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in T-= MPLS or MPLS-TP would be rather pointless. ITU-T was historically the right place to define such OAM. So, our interest= started with ITU-T's work in T-MPLS and not when IETF joined. We value IETF's work, and in 2008, when the IETF rose doubts about future i= nteroperability between T-MPLS and MPLS/IP (and the "danger to the internet= "), even though all T-MPLS Recommendations were approved and the OAM one wa= s ready for approval, a decision was made to listen carefully to MPLS/IP's = top experts' input. IETF's unilateral decision to select BFD was IMHO a surprise: being a prima= ry goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/exp= ertise or at least a compromise between the 2 SDOs. ITU-T's not just a boil= erplate stamper. Hearing that "the decision was expressed in mpls-tp-analysis draft" was ano= ther surprise: among the possible ways, the document showed, IMHO, 1731 as = the closest one to requirements. We don't need a requirement to agree on reusing as most as possible MPLS an= d PW: it's common sense. However, it can't distract us from primary goals. "The issue is not code point, which is the trivial part. It is reuse of the= majority of the implementation. Again, pretty basic." In other words, the problem is not backwards compatibility, (ergo the "dang= er to the internet" problem never really existed) but maintaining particula= r deployed platforms. If we had to convert cars into planes, we couldn't sa= y "to reuse the implementation, we can't add wings": they wouldn't fly. I'm used to FW/HW development and i don't share your cost/simplicity view. = (Please check other LC responses on this particular point.) I know field ne= twork support and think you'd change your opinion if you had to work on 24h= field network support. I agree with you that other opinions exist, counting not only manufacturers= but also operators. On the operators that don't agree with you are certain= ly clients of yours. It's none of my business that you view their opinions = as "grumblings", but that's far from describing the polls' results in the F= eb2011 WG3 and SG15 plenaries, showing a minority sharing your view, and th= at, although those not subscribing it tolerate its evolution, you don't the= irs. Operators and their clients are the ones that, at the end of the day, pay f= or networks. From the above, it'll be IMHO impossible to understand if thes= e Recommendations don't take into account these "grumblers'" view, other th= an the obsession of those insisting to sell swiss knifes to those who just = want sharp scalpels. Why don't we call that also "not constructive"? "[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more= difficult to tell which is which. [D:]That is because MPLS-TP is not a new techology, it is an addition to th= e entire MPLS protocol suite." Yes, i understand your view, David, but i'm sure you and i don't subscribe = this one: "The creatures outside looked from pig to man, and from man to pig, and fro= m pig to man again; but already it was impossible to say which was which". Hope this helps. My comrade cents, Rui -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: sexta-feira, 8 de Julho de 2011 17:13 To: Rui Costa; Stewart Bryant Cc: erminio.ottone_69@libero.it; mpls@ietf.org; ietf@ietf.org; IETF-Announc= e Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Rui: You wrote: >Reading something, keeping it on record, without effect in the draft and "= ignoring comments" have IMHO similar outcomes. As author of the draft you a= re free to do it. These standards have a great impact >in our work, so i'm also free to write what i did. Numerous comments did have effect on the draft and those that didn't were e= ither simply not actionable, were rhetorical or not constructive, and a few= had to be balanced against comments coming from the MPLS & BFD WGs. I woul= d translate "ingored" or "without effect" to "did not get one'e way". In th= e standards process it happens. >My technical concerns regarding this draft were expressed... >...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe= ); >...in operators' meetings' that took place during ITU-T's Feb/2011 plenary= meeting; I and the WG don't really have access to private grumblings. Lots of other opinions were expressed as well, and they did not all agree w= ith you. >Some: >CC/CV >I don't understand the need for 2 types of packets: a single type allows C= C; mismatching identifiers in the same CC packets allow CV. >Besides adding complexity, we whether always activate both or potentiate u= ndetected mismerges. OK, lets walk through this. We want CV all the time so that any misconectivity can be detected, but on = the list it was expressed that the group did not want the overhead of proce= ssing the source MEP TLV in every packet in order to achieve this. We could= carry it in every packet and have the receiver simply ignore most of them,= but then that would make the defect entry criteria compeltely random and t= he exit criteria unreliable as well, not really a good design. Hence they a= re separated using different ACH code points and the receiver is obliged to= process every source MEP TLV it receives. I hope this is clear. >(BTW: can't understand how we propose one ACH codepoint to CC, another for= CV, [counting other drafts, another for frame loss ...] but don't consider= assigning 1 single ACH protocol identifier codepoint >as requested by ITU-= T) Because that puts you into two protocol ID demultiplexing steps per OAM PDU= recevied to determine the intended function. Hence COSTS MORE. That is pre= tty basic... > Uni P2P / P2MP > I can't see how BFD will support unidir and hence P2MP other than... > ...eliminating the session "state variable" (down, init, up), aiming just= the state variables we really need, bringing us to something similar to 17= 31, eventually with other bits on the wire or... > ...using IP to create the reverse way, which we cannot assume per require= ments; > Will we create a complete different tool for that? > (BFD's B=3D"bidirectional") I would not go so far as to say "similar to 1731", there is actually a lot = of difference under the hood. As for uni-directional BFD, that is a BFD WG = problem at the moment. > Provisioning list > This is an MPLS profile/subset (and i heard) achievable through a particu= lar configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that = profile/configuration. However, i keep seeing > references f.i. to IP encapsulations unexpected under TP's OAM. > I don't thus understand what the aim is: do we expect this in TP, are we = talking about MPLS in general?... The TP profile is never quite delimited. > Does chapter 4 contain ALL the configurable parameters list agreed to pro= vide in the comparison session? It should. As for encapsulations, unless TP is in a complete island not con= nected to anything (which as a network is rather useless) it will be expect= ed to interoperate with the rest of the MPLS architecture, and the stated i= ntention of tool development was that what resulted was applicable to the b= roader MPLS architecture. Which means backwards compatiblity and procedures= for interoperation. > Backwards compatibility > This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a= better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployme= nt plus coherence with SDH, OTN, as defended by ITU-T. > For reasons like the above, however, MPLS-TP BFD won't be backwards compa= tible with previous BFD (even considering just CC/CV). They don't even shar= e the same codepoint. The issue is not code point, which is the trivial part. It is reuse of the = majority of the implementation. Again, pretty basic. >Simplicity >Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler= : in each flow, a standard defined nr of constant heartbeat signals (with s= tandard constant or provisioned period - no >auto/negotiated -) means OK. A standard defined number of misses means los= t Rx connection. An RDI, the only articulation between Rx and Tx flows, mea= ningful in bidirectional applications, allows each >pear to identify Tx problems. >This OAM simplicity is the key for reliable fail finger pointing, performa= nce reports and protection. Also to allow scaling, more implementation oppo= rtunities/manufacturers, which is valuable for >operators. Well IMO there was not a lot of interest in T-MPLS until the IETF was going= to re-define it and make it compatible with IP/MPLS. So there was an indus= try wide "design intent" implied here. > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more dif= ficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the en= tire MPLS protocol suite. Hope this helps D -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: >Several service providers regarded this draft as not meeting their >transport networks' needs. E> This is a true statement: the solution in this draft is useless for many= MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was = that the issue some service providers had was that the IETF BFD solution ex= ceeded their requirements in that there was additional functionality they d= id not see a need for, and that they considered any additional functionalit= y parasitic. However this is a consequence of adapting an existing technology to a new a= pplication. I do not see any way around that. And the entire joint project = was based on the premise of engineering re-use not greenfield design. That = is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mai= nstream, so it is a bit late to cry foul.... My 2 cents Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February = where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair = because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by= several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been r= esolved. >Several service providers regarded this draft as not meeting their >transport networks' needs. This is a true statement: the solution in this draft is useless for many MP= LS- TP deployments. -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC commen= ts were correctly with minor comments. It also says: The comments has been carefully discussed between the authors and people making the c= omments and has been resolved. But it seems that some comments have not been discussed with the authors of= the comments. When ITU-T Q10/15 has been involved in discussing its commen= ts? -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: quarta-feira, 6 de Julho de 2011 16:44 To: Rui Costa Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without doubt that no comments been ignored. Loa mpls wg document shepherd -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 14:58 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well a= s those collected from the MPLS WG was presented at the last IETF. My sprea= dsheet from which that report was generated and has been augmented to inclu= de the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last= -Call-Comments.xls So you know... Dave -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui= Costa Sent: segunda-feira, 4 de Julho de 2011 23:03 To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transpor= t networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From nurit.sprecher@nsn.com Thu Jul 14 10:50:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C631111E809F; Thu, 14 Jul 2011 10:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.955 X-Spam-Level: X-Spam-Status: No, score=-3.955 tagged_above=-999 required=5 tests=[AWL=2.044, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgPgPMAiJUXg; Thu, 14 Jul 2011 10:50:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D311E8098; Thu, 14 Jul 2011 10:50:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6EHo1fr016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 19:50:01 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6EHnw2M020909; Thu, 14 Jul 2011 19:50:01 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jul 2011 19:50:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 19:49:57 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264042047D1@DEMUEXC014.nsn-intra.net> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53BBBB@INOAVREX11.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defectindication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAApIjzAABwiuqgAMFxdjA= References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com><60C093A41B5E45409A19D42CF7786DFD522135449A@EUSAACMS0703.eamcs.ericsson.se> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53BBBB@INOAVREX11.ptin.corpPT.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Rui Costa" , "David Allan I" X-OriginalArrivalTime: 14 Jul 2011 17:50:00.0977 (UTC) FILETIME=[741BE810:01CC424E] Cc: mpls@ietf.org, ietf@ietf.org, IETF-Announce Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defectindication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:50:09 -0000 Rui, I kindly propose not to refer in this context to the Feb2011 WP3 and SG15 plenary meetings.... Very unfortunately, it was far away from being a technical discussion.....or technical poll.=20 Therefore it cannot be a reference to any argument in this context. =20 Regards, Nurit -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of ext Rui Costa Sent: Thursday, July 14, 2011 8:33 PM To: David Allan I Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defectindication for MPLS Transport Profile) to Proposed Standard David, T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in T-MPLS or MPLS-TP would be rather pointless. ITU-T was historically the right place to define such OAM. So, our interest started with ITU-T's work in T-MPLS and not when IETF joined. We value IETF's work, and in 2008, when the IETF rose doubts about future interoperability between T-MPLS and MPLS/IP (and the "danger to the internet"), even though all T-MPLS Recommendations were approved and the OAM one was ready for approval, a decision was made to listen carefully to MPLS/IP's top experts' input. IETF's unilateral decision to select BFD was IMHO a surprise: being a primary goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/expertise or at least a compromise between the 2 SDOs. ITU-T's not just a boilerplate stamper. Hearing that "the decision was expressed in mpls-tp-analysis draft" was another surprise: among the possible ways, the document showed, IMHO, 1731 as the closest one to requirements. We don't need a requirement to agree on reusing as most as possible MPLS and PW: it's common sense. However, it can't distract us from primary goals. "The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic." In other words, the problem is not backwards compatibility, (ergo the "danger to the internet" problem never really existed) but maintaining particular deployed platforms. If we had to convert cars into planes, we couldn't say "to reuse the implementation, we can't add wings": they wouldn't fly. I'm used to FW/HW development and i don't share your cost/simplicity view. (Please check other LC responses on this particular point.) I know field network support and think you'd change your opinion if you had to work on 24h field network support. I agree with you that other opinions exist, counting not only manufacturers but also operators. On the operators that don't agree with you are certainly clients of yours. It's none of my business that you view their opinions as "grumblings", but that's far from describing the polls' results in the Feb2011 WG3 and SG15 plenaries, showing a minority sharing your view, and that, although those not subscribing it tolerate its evolution, you don't theirs. Operators and their clients are the ones that, at the end of the day, pay for networks. From the above, it'll be IMHO impossible to understand if these Recommendations don't take into account these "grumblers'" view, other than the obsession of those insisting to sell swiss knifes to those who just want sharp scalpels. Why don't we call that also "not constructive"? "[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. [D:]That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite." Yes, i understand your view, David, but i'm sure you and i don't subscribe this one: "The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which". Hope this helps. My comrade cents, Rui -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: sexta-feira, 8 de Julho de 2011 17:13 To: Rui Costa; Stewart Bryant Cc: erminio.ottone_69@libero.it; mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Rui: You wrote: >Reading something, keeping it on record, without effect in the draft and "ignoring comments" have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact >in our work, so i'm also free to write what i did. Numerous comments did have effect on the draft and those that didn't were either simply not actionable, were rhetorical or not constructive, and a few had to be balanced against comments coming from the MPLS & BFD WGs. I would translate "ingored" or "without effect" to "did not get one'e way". In the standards process it happens. >My technical concerns regarding this draft were expressed... >...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe); >...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; I and the WG don't really have access to private grumblings. Lots of other opinions were expressed as well, and they did not all agree with you. >Some: >CC/CV >I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. >Besides adding complexity, we whether always activate both or potentiate undetected mismerges. OK, lets walk through this. We want CV all the time so that any misconectivity can be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear. >(BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T) Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic... > Uni P2P / P2MP > I can't see how BFD will support unidir and hence P2MP other than... > ...eliminating the session "state variable" (down, init, up), aiming just the state variables we really need, bringing us to something similar to 1731, eventually with other bits on the wire or... > ...using IP to create the reverse way, which we cannot assume per requirements; > Will we create a complete different tool for that? > (BFD's B=3D"bidirectional") I would not go so far as to say "similar to 1731", there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment. > Provisioning list > This is an MPLS profile/subset (and i heard) achievable through a particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on that profile/configuration. However, i keep seeing > references f.i. to IP encapsulations unexpected under TP's OAM. > I don't thus understand what the aim is: do we expect this in TP, are we talking about MPLS in general?... The TP profile is never quite delimited. > Does chapter 4 contain ALL the configurable parameters list agreed to provide in the comparison session? It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation. > Backwards compatibility > This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment plus coherence with SDH, OTN, as defended by ITU-T. > For reasons like the above, however, MPLS-TP BFD won't be backwards compatible with previous BFD (even considering just CC/CV). They don't even share the same codepoint. The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic. >Simplicity >Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is simpler: in each flow, a standard defined nr of constant heartbeat signals (with standard constant or provisioned period - no >auto/negotiated -) means OK. A standard defined number of misses means lost Rx connection. An RDI, the only articulation between Rx and Tx flows, meaningful in bidirectional applications, allows each >pear to identify Tx problems. >This OAM simplicity is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more implementation opportunities/manufacturers, which is valuable for >operators. Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide "design intent" implied here. > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite. Hope this helps D -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Erminio: >Several service providers regarded this draft as not meeting their >transport networks' needs. E> This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul.... My 2 cents Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been resolved. >Several service providers regarded this draft as not meeting their >transport networks' needs. This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC comments were correctly with minor comments. It also says: The comments has been carefully discussed between the authors and people making the comments and has been resolved. But it seems that some comments have not been discussed with the authors of the comments. When ITU-T Q10/15 has been involved in discussing its comments? -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: quarta-feira, 6 de Julho de 2011 16:44 To: Rui Costa Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without doubt that no comments been ignored. Loa mpls wg document shepherd -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 14:58 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well as those collected from the MPLS WG was presented at the last IETF. My spreadsheet from which that report was generated and has been augmented to include the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls So you know... Dave -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui Costa Sent: segunda-feira, 4 de Julho de 2011 23:03 To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transport networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. 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 Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From Rolf.Winter@neclab.eu Thu Jul 14 12:17:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594D711E807E for ; Thu, 14 Jul 2011 12:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFb0yjosUBPU for ; Thu, 14 Jul 2011 12:17:03 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9711E8070 for ; Thu, 14 Jul 2011 12:17:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0AFEF28000328 for ; Thu, 14 Jul 2011 21:17:03 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Fq+ZNm3mNq for ; Thu, 14 Jul 2011 21:17:02 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E01FB28000305 for ; Thu, 14 Jul 2011 21:16:57 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.188]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 21:16:58 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01) Thread-Index: AcxCWR6EPIPE3+QvRQui1DLmh8y5Cw== Date: Thu, 14 Jul 2011 19:16:58 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 19:17:04 -0000 Hello, I changed the subject line since this is I think orthogonal to the call for= adoption. I also try to address a set of comments from different people th= at have been raised in this one Email. The main discussion has been revolving around the actual format of the MEG_= ID, in particular the length of the whole ID and the length of the operator= -definable part. The length results from Y.1731 using 13 bytes for MEG_IDs = and the document is following ITU-T conventions after all. So that is where= the length comes from. If the WG decides that the remaining UMC is not lon= g enough then we need to define another identifier. That's regular WG proce= ss I'd say. In either event this document will be liaised with the ITU-T en= suring we follow the right ITU-T conventions. Regarding the UMC. It is at least 4 characters long. If you restrict yourse= lf to alphanumeric you will have 36 states per character resulting in 36^4 = possible combinations which is around 1.6 million. I think the sheer number= might not the problem but rather the structure, i.e. existing structures m= ight not fit into these 4 characters and again, the WG needs to figure this= out. The need for a delimiter is based on the fact that you have three fields, t= wo of which are of variable length. Let me illustrate this with an example = to show that the delimiter is needed independent of the ordering. (and yes = there are other ways to deal with this which I'd be happy to discuss). Say = you do CC:ICC:UMC and take country "AB". Take also operator "C" and operato= r "CD". If "C" decides to use a UMC "DE" and "CD" to use a UMC "E" the resu= lting MEG IDs would be equal. A delimiter will solve this issue. The same p= rinciple applies to the ordering ICC:CC:UMC only here this could happen eve= n with different country codes but if you want to be 100% sure that such a = situation cannot arise, then you need another token in the ID (or used fixe= d sized fields or use another trick...). Generally, there have been comments that the adoption call is either too ea= rly or the content should go into the identifiers draft. Well, the content = in fact has been in that document. So, in principle the need for this alrea= dy has been acked by the WG. This draft addresses the shortcoming which cau= sed the content to be removed. That is why I asked the chairs to do the pol= l now (so please don't blame Ross, blame me).=20 Anyway, I am happy to discuss this further. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From stbryant@cisco.com Thu Jul 14 12:51:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0A11E8070 for ; Thu, 14 Jul 2011 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg3+mN3m9QBc for ; Thu, 14 Jul 2011 12:51:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7942111E8079 for ; Thu, 14 Jul 2011 12:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3139; q=dns/txt; s=iport; t=1310673082; x=1311882682; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=WlL6Es5WwtqBW5BqqSGPqbW/V9C3EifDs0iXQqpeUX4=; b=Y2Nxg/mwASbz2o/o6jlymBJQPOMVXZVc1L5siHCYtAzt2fJUzYRhsYYa l5ONFIMgVZw7uAoUAhrpI5RUWxx/De+ZAHpCdSOjGkrEe+g0vYkzUtAnx gt1bnmgMxzibNq8y1j391LHXow2F6E/Kr5xwS586nnY1XfpLO2f5bg09Y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMZHH06Q/khR/2dsb2JhbABUp153rHWDFQ8Bi06PI4Y6BJJkkFI X-IronPort-AV: E=Sophos;i="4.65,531,1304294400"; d="scan'208";a="102255207" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 19:51:19 +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 p6EJpJrC006595 for ; Thu, 14 Jul 2011 19:51:19 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6EJpIfR009317; Thu, 14 Jul 2011 20:51:18 +0100 (BST) Message-ID: <4E1F48B6.7040802@cisco.com> Date: Thu, 14 Jul 2011 20:51:18 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mpls@ietf.org References: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 19:51:23 -0000 Rolf So the 16 bit identifier in section 5 is an additional identifier? Please could you reduce the confusion by drawing up the proposed data structure in octet/longword format as per traditional IETF representation. - Stewart On 14/07/2011 20:16, Rolf Winter wrote: > Hello, > > > I changed the subject line since this is I think orthogonal to the call for adoption. I also try to address a set of comments from different people that have been raised in this one Email. > > The main discussion has been revolving around the actual format of the MEG_ID, in particular the length of the whole ID and the length of the operator-definable part. The length results from Y.1731 using 13 bytes for MEG_IDs and the document is following ITU-T conventions after all. So that is where the length comes from. If the WG decides that the remaining UMC is not long enough then we need to define another identifier. That's regular WG process I'd say. In either event this document will be liaised with the ITU-T ensuring we follow the right ITU-T conventions. > > Regarding the UMC. It is at least 4 characters long. If you restrict yourself to alphanumeric you will have 36 states per character resulting in 36^4 possible combinations which is around 1.6 million. I think the sheer number might not the problem but rather the structure, i.e. existing structures might not fit into these 4 characters and again, the WG needs to figure this out. > > The need for a delimiter is based on the fact that you have three fields, two of which are of variable length. Let me illustrate this with an example to show that the delimiter is needed independent of the ordering. (and yes there are other ways to deal with this which I'd be happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take also operator "C" and operator "CD". If "C" decides to use a UMC "DE" and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A delimiter will solve this issue. The same principle applies to the ordering ICC:CC:UMC only here this could happen even with different country codes but if you want to be 100% sure that such a situation cannot arise, then you need another token in the ID (or used fixed sized fields or use another trick...). > > Generally, there have been comments that the adoption call is either too early or the content should go into the identifiers draft. Well, the content in fact has been in that document. So, in principle the need for this already has been acked by the WG. This draft addresses the shortcoming which caused the content to be removed. That is why I asked the chairs to do the poll now (so please don't blame Ross, blame me). > > Anyway, I am happy to discuss this further. > > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Robert.Rennison@ecitele.com Thu Jul 14 13:39:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B9611E807B for ; Thu, 14 Jul 2011 13:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh-Cc8xJTORR for ; Thu, 14 Jul 2011 13:39:40 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id AC06821F8B1E for ; Thu, 14 Jul 2011 13:39:40 -0700 (PDT) X-AuditID: 3f5e7f87-b7b84ae000006dce-18-4e1f79aafcdc Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.A0.28110.BA97F1E4; Thu, 14 Jul 2011 19:20:11 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Thu, 14 Jul 2011 16:39:38 -0400 From: Robert Rennison To: "S. Davari" , "ietf@ietf.or" , "mpls@ietf.org" Date: Thu, 14 Jul 2011 16:39:37 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity) Thread-Index: AcxCJ4+bAYYNcfTXSEaat0fmCGMeXAAPRO6Y Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> , <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com> In-Reply-To: <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTURz37G7zulpd5+skheOEQZri8sF6zAQ/OLOHlH0p0K7babt4d7d2 ZyoUjSwKidLsQZPKYoVZbCnRy15akFlpFBZpRuVjuPqSRpI97+2WLTqffv/ze5w/hx9JaA4q 40mGc2EnR7NIqZKrwsLyUs5VJaxKm7yToG8P7AD6p32b9X2nzypyCOONsUaF0ev9LDN6PHdk hcR6N1hKc5zdRbuw1ox5kwEVOpkttKkKaRmzAemQ1sHSJmzDnMuAaIcDc2aUrdL+d5YKMobT Ys5kNzOcxYDy165O0eszF6XoUPa8ubr0JaoiK8NrcYqNZlitDfM8bcFa4WbjRcLafajA0Te/ ssEzqHCDJlQDIkhIZcD66sMyCcfCx6/8yhqgIjVUG4DfPA1AGvYC+KB/OFxUKal0eGHskULE 0dQm2NzZCUQspxJh4NiAXMRRVDEMBl7IJU0JfHSkBUh4ITx1rYUQsZoqhDvfPyOkB/wA1k7s EQaSjKDy4O1BnagBwkYTXed/bUdQcbBv6MTvTSnovd5DSDgGjg5+V0j6GPhytx9I+gWwsW1M KeFkeObku9/vRsL7R4fktSDGExLrCbF4QiyeEEsjkDeD2HLewbhKbZY0XSo2MS7M4lST3dYK hFYsK96++wrYfzCpA8wiZShG/WVNwirNjFK7ucpK89YSZzmL+Q6gFz6rjoifZrILjeJcJelp af8MKE59dY93pYayCH0pw9iBnX+ss0kSQTVbIMRGOrEFV25iWNdfWkZGdABITkfRattaQaPm HbSNZywS3wVmxcepsUhQImEt56a8QRBHAhSlZkV2ulD1KVdQCJQJgb7Fc8RAocNTVLwb3PtY Odqas03lLRpFRSPVVGfG1sCSpq9Z7p5dua8vR4009x4oCvouVBinXeoZuJn1JneYwxvW1fvu jmd0y57sW+y+dSU5vTf71Olb+cHe8MDtnpkrYmu5isz64Laye75MVb/GOMT++JSYNFm8/FB1 u3/yORMgH457j5/4UHf17UQNkvNWWpdEOHn6J51TD9KnAwAA Subject: Re: [mpls] Last Call: (Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 20:39:44 -0000 Sharam, The CV packets are sent at one per second i.e at a rate which does not reall= y need hardware assist, and as such the format of these packets is not real= ly optimized for HW implementation. The CC packets can be sent at whatever rate both ends can support, typically= today this can be around one per milli-second hence HW assist is required f= or CC packets and indeed the baseline BFD is designed around this premise. So, quite contrary to your statement of: >These two functions make the Hardware implementation very complex and delay= s > implementation and deployment of this draft. I would have 2 suggestions to= fix this: The decisions made are in fact aimed at allowing for fast hardware implemen= tation of CC, it is after all the same packet as baseline bFD with a differe= nt codepoint, and not requiring it for the CV. In fact with CV having a dif= ferent codepoint, as Dave explained in an earlier reply this makes for a ve= ry simple filtering/classification of which packets are to be handled by HW= and which can be punted to a slowpath. Cheers Rob Rennison ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [= davarish@yahoo.com] Sent: Thursday, July 14, 2011 9:11 AM To: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proact= ive Connectivity) Hi, I also have concern regarding: 1) Different MEP ID formats 2) CV interleaving These two functions make the Hardware implementation very complex and delays= implementation and deployment of this draft. I would have 2 suggestions to= fix this: 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments i= nstead of TLV. TLVs are not hardware friendly. 2) Default to be All CC or All CV. Have the CV interleaving optional (if bot= h sides are capable). Thx Shahram ________________________________ From: "hideki.endo.es@hitachi.com" To: ietf@ietf.or; mpls@ietf.org Sent: Thu, July 14, 2011 4:22:42 AM Subject: Re: [mpls] Last Call: (Proacti= ve Connectivit The changes in this version have massive impact for CC/CV/RDI implementation= . We, venders, have kept making efforts on interoperability test again and aga= in. These changes spoil this effort. Especially, revival of Poll/Final sequence doesn't make sense. Originally, in my understanding, Poll/Final sequence was excluded from this= draft to avoid making HW implementation difficult. Even though it was difficult to change CC interval arbitrary, the problem should be solved by defining how to transit DOWN/INIT state to U= P state. The direction which reached consensus once should NOT be changed easily in order to respond to the market requirements. IMO, such major changes should NOT be added right before becoming RFC. I found at least four major/minor changes as follows; 1)Revival of Poll/Final sequence 2)Change of MEP ID formats 3)Change of Diag. Code 4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. Exceptiona= lly, 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From davarish@yahoo.com Thu Jul 14 13:44:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C687111E8079 for ; Thu, 14 Jul 2011 13:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgFDkMrZbeV2 for ; Thu, 14 Jul 2011 13:44:03 -0700 (PDT) Received: from smtp108-mob.biz.mail.gq1.yahoo.com (smtp108-mob.biz.mail.gq1.yahoo.com [98.136.185.199]) by ietfa.amsl.com (Postfix) with SMTP id 6639B11E8076 for ; Thu, 14 Jul 2011 13:44:02 -0700 (PDT) Received: (qmail 7599 invoked from network); 14 Jul 2011 20:43:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:From:Date:Content-Type:MIME-Version; b=JZT+/2P66N4ZyTGEWPumZOzbkvmF+DGreT6fCmBdUVz19HNCbA5VixXC4ZpODso+0Z2NveYmEkRaLYNGf4kFtf//9mgeRGacNZED15MYeujFkH2sWG/Mw4pMkariaqY7deJ83f7/hfxt7/DNlkOVckD7aaX1rSGEXjuXkb7+dqs= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310676236; bh=LvUDr/rPntIXF4MaMkkXR1lIPOZ7Y/VHRsv0rgRL7XE=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:From:Date:Content-Type:MIME-Version; b=4zTEqpM/HW36rgnsWx/xONmoWRYyo8wiAXFQYsK+jDTjVWc9G3PYMtexImVb9CryllOWslAJpgMVlZDY430NNUnbmzjCMHbNgj5yhPizZ+gAgxNJ+FZj8s7t14TTpeTgnCH1uVB+hxVxQhonVZ6U0jofKPoIPBD5nSIhrKfCWjc= Received: from b15.c27.bise6.blackberry (davarish@74.82.86.201 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 14 Jul 2011 13:43:56 -0700 PDT X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-YMail-OSG: FoPW5HIVM1nSXTsvEGefUI9tWyzWrUJ7SixM9Mdk7Wmpmhk tHpST2byCYt02JVoGObarSOcCJ2.Gcxe4li0qgtmLZ2wfNjf5XlzyIFjEwHE sa0jY.9FDfcJvSzZRS9IuXV2Tk1lCWKen3JN3pOt0ZXvxXsakWf4155qajcF EAaepToN811cWQNBG2AAvbJT8p93ZeeOosTvCBYhCMr8yOKP_fofJht0y7Dg g_uJk5lc4V4mEUME0c9ckNn52sB8GGhPFt9uXV8wFqUojGHRqp2qNoIMo12G DxFfb_KgzP1Uf3A9ORluwJbNZZszMtXjqEdqTz9SCUXbIoDK2g7TRd_aySuD SaJcaR3kIr7c9poKmlcAxbr.p7ZRoMWRGE3y_ujLo X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 1466780933 Message-ID: <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com> Sensitivity: Normal Importance: Normal To: "Robert Rennison" , "ietf@ietf.or" , "mpls@ietf.org" From: davarish@yahoo.com Date: Thu, 14 Jul 2011 20:43:20 +0000 Content-Type: text/plain MIME-Version: 1.0 Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: davarish@yahoo.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 20:44:03 -0000 U28geW91ciBpZGVhIGlzIHRvIHJ1biBDViBpbiBTVy4gVGhhdCBpcyBxdWl0ZSBwb3NzaWJsZSBi dXQgdGhpcyBtZWFucyB0aGUgQkZEIGVuZ2luZSBuZWVkcyB0byBiZSBkdXBsaWNhdGVkLCBvbmUg aW4gSFcgYW5kIG9uZSBpbiBTVy4gDQoNCklzIHRoYXQgdGhlIGludGVudGlvbiBvZiB0aGUgZ3Jv dXA/IElmIHNvIGl0IGlzIG5vdCBhbiBlZmZpY2llbnQgd2F5IG9mIHVzaW5nIHRoZSByZXNvdXJj ZXMgaW4gYSByb3V0ZXIuDQoNClRoeA0KU0QNClNlbnQgdmlhIEJsYWNrQmVycnkgYnkgQVQmVA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iZXJ0IFJlbm5pc29uIDxSb2Jl cnQuUmVubmlzb25AZWNpdGVsZS5jb20+DQpEYXRlOiBUaHUsIDE0IEp1bCAyMDExIDE2OjM5OjM3 IA0KVG86IFMuIERhdmFyaTxkYXZhcmlzaEB5YWhvby5jb20+OyBpZXRmQGlldGYub3I8aWV0ZkBp ZXRmLm9yPjsgbXBsc0BpZXRmLm9yZzxtcGxzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFttcGxz XSBMYXN0IENhbGw6DQoJPGRyYWZ0LWlldGYtbXBscy10cC1jYy1jdi1yZGktMDUudHh0PihQcm9h Y3RpdmUgQ29ubmVjdGl2aXR5KQ0KDQpTaGFyYW0sDQoNClRoZSBDViBwYWNrZXRzIGFyZSBzZW50 IGF0IG9uZSBwZXIgc2Vjb25kIGkuZSBhdCBhIHJhdGUgd2hpY2ggZG9lcyBub3QgcmVhbGx5IG5l ZWQgaGFyZHdhcmUgYXNzaXN0LCBhbmQgYXMgc3VjaCB0aGUgZm9ybWF0IG9mIHRoZXNlIHBhY2tl dHMgaXMgbm90ICByZWFsbHkgb3B0aW1pemVkIGZvciBIVyBpbXBsZW1lbnRhdGlvbi4NCg0KDQpU aGUgQ0MgcGFja2V0cyBjYW4gYmUgc2VudCBhdCB3aGF0ZXZlciByYXRlIGJvdGggZW5kcyBjYW4g c3VwcG9ydCwgdHlwaWNhbGx5IHRvZGF5IHRoaXMgY2FuIGJlIGFyb3VuZCBvbmUgcGVyIG1pbGxp LXNlY29uZCBoZW5jZSBIVyBhc3Npc3QgaXMgcmVxdWlyZWQgZm9yIENDIHBhY2tldHMgYW5kIGlu ZGVlZCB0aGUgYmFzZWxpbmUgQkZEIGlzIGRlc2lnbmVkIGFyb3VuZCB0aGlzIHByZW1pc2UuDQoN Cg0KU28sICAgcXVpdGUgY29udHJhcnkgdG8geW91ciBzdGF0ZW1lbnQgb2Y6DQoNCj5UaGVzZSB0 d28gZnVuY3Rpb25zIG1ha2UgdGhlIEhhcmR3YXJlIGltcGxlbWVudGF0aW9uIHZlcnkgY29tcGxl eCBhbmQgZGVsYXlzDQo+IGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50IG9mIHRoaXMgZHJh ZnQuIEkgd291bGQgaGF2ZSAyIHN1Z2dlc3Rpb25zIHRvIGZpeCB0aGlzOg0KDQpUaGUgZGVjaXNp b25zIG1hZGUgYXJlIGluIGZhY3QgIGFpbWVkIGF0IGFsbG93aW5nIGZvciBmYXN0IGhhcmR3YXJl IGltcGxlbWVudGF0aW9uIG9mIENDLCBpdCBpcyBhZnRlciBhbGwgdGhlIHNhbWUgcGFja2V0IGFz IGJhc2VsaW5lIGJGRCB3aXRoIGEgZGlmZmVyZW50IGNvZGVwb2ludCwgIGFuZCBub3QgcmVxdWly aW5nIGl0IGZvciB0aGUgQ1YuIEluIGZhY3Qgd2l0aCBDViBoYXZpbmcgYSBkaWZmZXJlbnQgY29k ZXBvaW50LCBhcyBEYXZlIGV4cGxhaW5lZCBpbiBhbiBlYXJsaWVyIHJlcGx5IHRoaXMgbWFrZXMg IGZvciBhIHZlcnkgc2ltcGxlIGZpbHRlcmluZy9jbGFzc2lmaWNhdGlvbiBvZiB3aGljaCBwYWNr ZXRzIGFyZSB0byBiZSBoYW5kbGVkIGJ5IEhXIGFuZCB3aGljaCBjYW4gYmUgcHVudGVkIHRvIGEg c2xvd3BhdGguDQoNCkNoZWVycw0KDQpSb2IgUmVubmlzb24NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTLiBEYXZhcmkgW2RhdmFyaXNoQHlhaG9v LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAyMDExIDk6MTEgQU0NClRvOiBpZXRmQGll dGYub3I7IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOiAgPGRy YWZ0LWlldGYtbXBscy10cC1jYy1jdi1yZGktMDUudHh0PihQcm9hY3RpdmUgQ29ubmVjdGl2aXR5 KQ0KDQpIaSwNCg0KSSBhbHNvIGhhdmUgY29uY2VybiByZWdhcmRpbmc6DQoNCjEpIERpZmZlcmVu dCBNRVAgSUQgZm9ybWF0cw0KMikgQ1YgaW50ZXJsZWF2aW5nDQoNClRoZXNlIHR3byBmdW5jdGlv bnMgbWFrZSB0aGUgSGFyZHdhcmUgaW1wbGVtZW50YXRpb24gdmVyeSBjb21wbGV4IGFuZCBkZWxh eXMgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgdGhpcyBkcmFmdC4gSSB3b3VsZCBo YXZlIDIgc3VnZ2VzdGlvbnMgdG8gZml4IHRoaXM6DQoNCjEpIE1ha2UgYWxsIE1FUElEcyB0aGUg c2FtZSBzaXplIChlLmcuIDEyIGJ5dGVzKSBmb3IgYWxsIExTUCwgUFcsIFNlZ21lbnRzIGluc3Rl YWQgb2YgVExWLiBUTFZzIGFyZSBub3QgaGFyZHdhcmUgZnJpZW5kbHkuDQoNCjIpIERlZmF1bHQg dG8gYmUgQWxsIENDIG9yIEFsbCBDVi4gSGF2ZSB0aGUgQ1YgaW50ZXJsZWF2aW5nIG9wdGlvbmFs IChpZiBib3RoIHNpZGVzIGFyZSBjYXBhYmxlKS4NCg0KVGh4DQpTaGFocmFtDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206ICJoaWRla2kuZW5kby5lc0BoaXRhY2hp LmNvbSIgPGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tPg0KVG86IGlldGZAaWV0Zi5vcjsgbXBs c0BpZXRmLm9yZw0KU2VudDogVGh1LCBKdWx5IDE0LCAyMDExIDQ6MjI6NDIgQU0NClN1YmplY3Q6 IFJlOiBbbXBsc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLXRwLWNjLWN2LXJkaS0wNS50 eHQ+KFByb2FjdGl2ZSBDb25uZWN0aXZpdA0KDQpUaGUgY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24g aGF2ZSBtYXNzaXZlIGltcGFjdCBmb3IgQ0MvQ1YvUkRJIGltcGxlbWVudGF0aW9uLg0KV2UsIHZl bmRlcnMsIGhhdmUga2VwdCBtYWtpbmcgZWZmb3J0cyBvbiBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qg YWdhaW4gYW5kIGFnYWluLg0KVGhlc2UgY2hhbmdlcyBzcG9pbCB0aGlzIGVmZm9ydC4NCg0KRXNw ZWNpYWxseSwgcmV2aXZhbCBvZiBQb2xsL0ZpbmFsIHNlcXVlbmNlIGRvZXNuJ3QgbWFrZSBzZW5z ZS4NCk9yaWdpbmFsbHksIGluIG15IHVuZGVyc3RhbmRpbmcsIFBvbGwvRmluYWwgc2VxdWVuY2Ug d2FzIGV4Y2x1ZGVkIGZyb20gdGhpcyBkcmFmdA0KdG8gYXZvaWQgbWFraW5nIEhXIGltcGxlbWVu dGF0aW9uIGRpZmZpY3VsdC4NCg0KRXZlbiB0aG91Z2ggaXQgd2FzIGRpZmZpY3VsdCB0byBjaGFu Z2UgQ0MgaW50ZXJ2YWwgYXJiaXRyYXJ5LA0KdGhlIHByb2JsZW0gc2hvdWxkIGJlIHNvbHZlZCBi eSBkZWZpbmluZyBob3cgdG8gdHJhbnNpdCBET1dOL0lOSVQgc3RhdGUgdG8gVVAgc3RhdGUuDQoN ClRoZSBkaXJlY3Rpb24gd2hpY2ggcmVhY2hlZCBjb25zZW5zdXMgb25jZSBzaG91bGQgTk9UIGJl IGNoYW5nZWQgZWFzaWx5DQppbiBvcmRlciB0byByZXNwb25kIHRvIHRoZSBtYXJrZXQgcmVxdWly ZW1lbnRzLg0KDQpJTU8sIHN1Y2ggbWFqb3IgY2hhbmdlcyBzaG91bGQgTk9UIGJlIGFkZGVkIHJp Z2h0IGJlZm9yZSBiZWNvbWluZyBSRkMuDQoNCkkgZm91bmQgYXQgbGVhc3QgZm91ciBtYWpvci9t aW5vciBjaGFuZ2VzIGFzIGZvbGxvd3M7DQoxKVJldml2YWwgb2YgUG9sbC9GaW5hbCBzZXF1ZW5j ZQ0KMilDaGFuZ2Ugb2YgTUVQIElEIGZvcm1hdHMNCjMpQ2hhbmdlIG9mIERpYWcuIENvZGUNCjQp Q2hhbmdlIG9mIENWIGludGVybGVhdmVkIGRlZmluaXRpb24NCg0KQlIsDQpIaWRla2kNCg0KDQo+ DQo+VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZyBXRw0KPihtcGxzKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRv Y3VtZW50Og0KPi0gJ1Byb2FjdGl2ZSBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uLCBDb250aW51 aXR5IENoZWNrIGFuZCBSZW1vdGUNCj4gIERlZmVjdCBpbmRpY2F0aW9uIGZvciBNUExTIFRyYW5z cG9ydCBQcm9maWxlJw0KPiAgPGRyYWZ0LWlldGYtbXBscy10cC1jYy1jdi1yZGktMDUudHh0PiBh cyBhIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lz aW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQo+ZmluYWwgY29tbWVudHMg b24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0K PmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAx MS0wNy0xNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQo+c2VudCB0byBpZXNnQGll dGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIHJldGFpbiB0aGUNCj5iZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBh dXRvbWF0ZWQgc29ydGluZy4NCj4NCj5BYnN0cmFjdA0KPg0KPiAgQ29udGludWl0eSBDaGVjaywg UHJvYWN0aXZlIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24gYW5kIFJlbW90ZQ0KPiAgRGVmZWN0 IEluZGljYXRpb24gZnVuY3Rpb25hbGl0aWVzIGFyZSByZXF1aXJlZCBmb3IgTVBMUy1UUCBPQU0u DQo+DQo+ICBDb250aW51aXR5IENoZWNrIG1vbml0b3JzIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGNv bnRpbnVpdHkgb2YgdGhlDQo+ICBsYWJlbCBzd2l0Y2hlZCBwYXRoIGZvciBhbnkgbG9zcyBvZiBj b250aW51aXR5IGRlZmVjdC4gQ29ubmVjdGl2aXR5DQo+ICB2ZXJpZmljYXRpb24gbW9uaXRvcnMg dGhlIGludGVncml0eSBvZiB0aGUgcm91dGluZyBvZiB0aGUgbGFiZWwNCj4gIHN3aXRjaGVkIHBh dGggYmV0d2VlbiBzaW5rIGFuZCBzb3VyY2UgZm9yIGFueSBjb25uZWN0aXZpdHkgaXNzdWVzLg0K PiAgUmVtb3RlIGRlZmVjdCBpbmRpY2F0aW9uIGVuYWJsZXMgYW4gRW5kIFBvaW50IHRvIHJlcG9y dCwgdG8gaXRzDQo+ICBhc3NvY2lhdGVkIEVuZCBQb2ludCwgYSBmYXVsdCBvciBkZWZlY3QgY29u ZGl0aW9uIHRoYXQgaXQgZGV0ZWN0cyBvbg0KPiAgYSBwc2V1ZG8gd2lyZSwgbGFiZWwgc3dpdGNo ZWQgcGF0aCBvciBTZWN0aW9uLg0KPg0KPiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgbWV0aG9k cyBmb3IgcHJvYWN0aXZlIGNvbnRpbnVpdHkgY2hlY2ssDQo+ICBjb250aW51aXR5IHZlcmlmaWNh dGlvbiwgYW5kIHJlbW90ZSBkZWZlY3QgaW5kaWNhdGlvbiBmb3IgTVBMUy1UUA0KPiAgbGFiZWwg c3dpdGNoZWQgcGF0aHMsIHBzZXVkbyB3aXJlcyBhbmQgU2VjdGlvbnMgdXNpbmcgQmlkaXJlY3Rp b25hbA0KPiAgRm9yd2FyZGluZyBEZXRlY3Rpb24uDQo+DQo+DQo+VGhlIGZpbGUgY2FuIGJlIG9i dGFpbmVkIHZpYQ0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t cGxzLXRwLWNjLWN2LXJkaS8NCj4NCj5JRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlh DQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtY2Mt Y3YtcmRpLw0KPg0KPg0KPk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBk aXJlY3RseSBvbiB0aGlzIEktRC4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPm1wbHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt cGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNClRoaXMgZS1tYWls IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJp ZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBh bmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQoNCg== From Robert.Rennison@ecitele.com Thu Jul 14 13:56:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA021F8A91 for ; Thu, 14 Jul 2011 13:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX0nscUEcdya for ; Thu, 14 Jul 2011 13:56:04 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0921F8A70 for ; Thu, 14 Jul 2011 13:56:04 -0700 (PDT) X-AuditID: 3f5e7f87-b7b84ae000006dce-e0-4e1f7d846001 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 32.B0.28110.48D7F1E4; Thu, 14 Jul 2011 19:36:36 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Thu, 14 Jul 2011 16:56:03 -0400 From: Robert Rennison To: "hideki.endo.es@hitachi.com" , "ietf@ietf.or" , "mpls@ietf.org" Date: Thu, 14 Jul 2011 16:56:03 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivit Thread-Index: AcxCGGy3mTXAVp9TS4ijL9PAKJ83CgATgWba Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB872@USPITMAIL01.ecitele.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIJsWRmVeSWpSXmKPExsXCxcDgrttSK+9n8KNL0+L6l/dMFpdvFVrc WrqS1YHZo/XMGhaPvZ8WsHosWfKTKYA5qoHRJjEvL78ksSRVISW1ONlWKaAosywxuVJJITPF VslQSaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq 2akpGxpbc4VkZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBn7O5tZS34Kldx4sQb1gbGw5JdjJwc EgImEhvW7WCHsMUkLtxbz9bFyMUhJLCbUaL/YwM7hNPDKNF5CqKKTcBYYsOns6wgtohAvcTR hT/B4iwCqhLHns5gArGFBWIkth89xQRREytx+MRtFgjbSOLn1UVgNq9AgMSkq4/BbCGBIomG z9MZQWxOAXuJE//egfUyAl30/dQaMJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rRL2oxJ32 9YwQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFZaXJBZ kpSbbmCol5qcWZKak6qXnJ+7iRGYLOzj6tt3MPZP0TrEKMnBpCTKuyVM3k+ILyk/pTIjsTgj vqg0J7X4EKMFMLAmMktxJ+cDk1ReSbyxgQEKR0mcd2fHEl8hgXRggslOTS1ILYJpleHgUJLg zfEGGitYlJqeWpGWmVOCkGbi4DzEKMHBoyTC+xpkNW9xQWJucWY6RP4UoypH/+a5RxiFWPLy 81KlxHkngRQJgBRllObBzXnFKM7BqCTMuxokywNM93ATXgENZwIavs5KFmQ4MEHDpaQaGB2S Dy4tFJFRky0rnX0u/4Su/srMD9+/ZrXqMosqzKi43lr/95aN/9Z3ExKCmARmGU4OdTBYXXr9 9qcPWnXbz2pdXP8ywEB0j/rM1C9/c57YbeQ6d1aqcGrrUvsAWR2H8tALNptPqLB+WtJTnCJ3 +Vvm2zPu00o95nlNSjVacF+36taGqR36H5RYijMSDbWYi4oTAVgqVr+0AwAA Subject: Re: [mpls] Last Call: (Proactive Connectivit X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 20:56:08 -0000 ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of hideki.endo= .es@hitachi.com [hideki.endo.es@hitachi.com] Sent: Thursday, July 14, 2011 7:22 AM To: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proact= ive Connectivit >The changes in this version have massive impact for CC/CV/RDI implementatio= n. >We, venders, have kept making efforts on interoperability test again and ag= ain. >These changes spoil this effort. >Especially, revival of Poll/Final sequence doesn't make sense. >Originally, in my understanding, Poll/Final sequence was excluded from this= draft >to avoid making HW implementation difficult. [RR] preventing a peer from modifying the rate once the initial target rate= was achieved i.e arbitrary re-negotiation was and is excluded, that was t= he "problem" the group consensus was to solve. However P/F is needed to get from the initial 1 per second default rate to t= he desired rate. This and the rational for an initial P/F were discussed in= detail back in March /April. >Even though it was difficult to change CC interval arbitrary, >the problem should be solved by defining how to transit DOWN/INIT state to= UP state. [RR] There is no problem in defining how to transit from Down/Init to UP sta= te, it's covered in the existing state machine and is not changed. Cheers Rob >The direction which reached consensus once should NOT be changed easily >in order to respond to the market requirements. >IMO, such major changes should NOT be added right before becoming RFC. >I found at least four major/minor changes as follows; >1)Revival of Poll/Final sequence >2)Change of MEP ID formats >3)Change of Diag. Code >4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From curtis@occnc.com Thu Jul 14 14:51:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11F21F87C5 for ; Thu, 14 Jul 2011 14:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMY2NLfcteFH for ; Thu, 14 Jul 2011 14:51:50 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2321F87C3 for ; Thu, 14 Jul 2011 14:51:49 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6ELpnSe063248; Thu, 14 Jul 2011 17:51:49 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107142151.p6ELpnSe063248@harbor.orleans.occnc.com> To: mpls@ietf.org From: Curtis Villamizar Date: Thu, 14 Jul 2011 17:51:49 -0400 Sender: curtis@occnc.com Subject: [mpls] draft-villamizar-mpls-tp-multipath-te-extn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 21:51:50 -0000 This internet-draft defines extensions to OSPF-TE and ISIS-TE and to RSVP-TE to support the requirements and framework described in: draft-villamizar-mpls-tp-multipath-01.txt Use of Multipath with MPLS-TP and MPLS The requirements were presented at IETF-80. Among the comments were that it would be useful to see the specifics of the protocol changes. Review and comments on either or both of these drafts would be appreciated. Curtis ------- Forwarded Message A new version of I-D, draft-villamizar-mpls-tp-multipath-te-extn-00.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath-te-extn Revision: 00 Title: Multipath Extensions for MPLS Traffic Engineering Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 26 Abstract: Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability reagrding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order at a given depth in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. The IETF Secretariat ------- End of Forwarded Message From david.i.allan@ericsson.com Thu Jul 14 14:57:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCEC21F8B0A for ; Thu, 14 Jul 2011 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy8fzoLgtzWX for ; Thu, 14 Jul 2011 14:57:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 682F921F8B08 for ; Thu, 14 Jul 2011 14:57:07 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6ELv46W001916; Thu, 14 Jul 2011 16:57:07 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 14 Jul 2011 17:56:57 -0400 From: David Allan I To: Rui Costa Date: Thu, 14 Jul 2011 17:56:57 -0400 Thread-Topic: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: Acw3LJ0GTOqQfPcUQOGUhgK/1kXgjgDPfXWgACJLxEAApIjzAABwiuqgAMecfTA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD5221437EA0@EUSAACMS0703.eamcs.ericsson.se> References: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53B6BC@INOAVREX11.ptin.corpPT.com> <60C093A41B5E45409A19D42CF7786DFD522135449A@EUSAACMS0703.eamcs.ericsson.se> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53BBBB@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53BBBB@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 21:57:11 -0000 Hi Receiver list clipped as the whole IETF does not need to listen to us.... > T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the sim= ple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in > T-MPLS or MPLS-TP would be rather pointless. ITU-T was historically the r= ight place to define such OAM. So, our interest started with ITU-T's work i= n > T-MPLS and not when IETF joined. Having edited some of Y.1711, 1712, 1713 original OAM framework RFC etc. I'= m rather intimately familiar with the history of (and limitations of) MPLS = OAM in all its incarnations. > We value IETF's work, and in 2008, when the IETF rose doubts about future= interoperability between T-MPLS and MPLS/IP (and the "danger to the > internet"), even though all T-MPLS Recommendations were approved and the = OAM one was ready for approval, a decision was made to listen carefully to > MPLS/IP's top experts' input. "Listen carefully or acknowldege design authority?" would be the question t= hat immediately comes to mind. > IETF's unilateral decision to select BFD was IMHO a surprise: being a pri= mary goal in T-MPLS, i'd assume OAM definition was ITU-T's > responsibility/expertise or at least a compromise between the 2 SDOs. ITU= -T's not just a boilerplate stamper. > Hearing that "the decision was expressed in mpls-tp-analysis draft" was a= nother surprise: among the possible ways, the document showed, IMHO, 1731 a= s > the closest one to requirements. I'm not sure why you were surprised. The MEAD team decision at the Stockhol= m IETF (and it was clear as a bell even to the casual observer) was to ackn= owledge the functionalities of 1731 but not adopt the protocol. The protoco= ls would be redesigned. Adopting BFD itself as one component came much late= r. Saying the IETF "unilaterally" adopted BFD seems to confuse the nature of t= he TP project, and again this predates my more than casual interest so I'm = willing to be corrected by my betters. My understanding was ITU was to prov= ide requirements and the IETF design the protocols. And ironically the atti= tude expressed by some is that the IETF should be a boilerplate stamper for= draft-bhh.... Hmmmm fallacy of outrageous classification here? > We don't need a requirement to agree on reusing as most as possible MPLS = and PW: it's common sense. However, it can't distract us from primary goals= . > "The issue is not code point, which is the trivial part. It is reuse of t= he majority of the implementation. Again, pretty basic." > In other words, the problem is not backwards compatibility, (ergo the "da= nger to the internet" problem never really existed) but maintaining particu= lar > deployed platforms. If we had to convert cars into planes, we couldn'= t say "to reuse the implementation, we can't add wings": they wouldn't fly. > I'm used to FW/HW development and i don't share your cost/simplicity view= . (Please check other LC responses on this particular point.) I know field > network support and think you'd change your opinion if you had to work on= 24h field network support. If there is a community that wanted a new greenfield technology completely = divorced from existing platforms, the route to get there existed back at th= e start: ITU gets it's own code points define's its own technology. Gives i= t some cool name and market it. This was called option 1 IIRC. In fact that= SHOULD have been an option presented at the end of the Feb SG15 plenary vs= . the current somewhat more artificial G.8113.1/2 split. > I agree with you that other opinions exist, counting not only manufacture= rs but also operators. On the operators that don't agree with you are certa= inly > clients of yours. It's none of my business that you view their opini= ons as "grumblings", but that's far from describing the polls' results in t= he > Feb2011 WG3 and SG15 plenaries, showing a minority sharing your view, and= that, although those not subscribing it tolerate its evolution, you don't > theirs. The view from within one's own church is usually pretty myopic. The view I = get at MPLS conferences, IETF, BBF and from my customers is different. My o= bservation is that the majority of the folks who want MPLS want the IETF ve= rsion. Those who want PTN have valid options for getting it standardized, t= hey just do not involve the MPLS codepoints or the MPLS name. For some reas= on those are not palatable. IMO this is commercial and trademark issues, no= t technical. > Operators and their clients are the ones that, at the end of the day, pay= for networks. My last estimate was that MPLS kit was shipping at a rate of $14B USD annua= lly. > From the above, it'll be IMHO impossible to understand if these Recommend= ations don't take into account these "grumblers'" view, other than the > obsession of those insisting to sell swiss knifes to those who just want = sharp scalpels. Ignoring the implied slight in the analogy but simply re-using it, those wh= o want sharp scalpels have a recourse other than demanding the swiss army k= nife industry make scalpels. And vendors have the option of selling scalpel= s to scalpel users. It's been done. > Why don't we call that also "not constructive"? > "[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and mo= re difficult to tell which is which. > [D:]That is because MPLS-TP is not a new techology, it is an addition to = the entire MPLS protocol suite." > Yes, i understand your view, David, but i'm sure you and i don't subscrib= e this one: I've been on all sides of this fence over the years. And witnessed previous= attempts to sell scalpels against swiss army knives. Scalpels are a minori= ty sport and ultimately cost more as most folks want a swiss army knife bec= ause their business is more than bit-trucking transport. That's my experien= ce. "The creatures outside looked from pig to man, and from man to pig, and fro= m pig to man again; but already it was impossible to say which was which". I think we'll agree to disagree... Both on technology and underlying drive= rs... Cheers Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: sexta-feira, 8 de Julho de 2011 17:13 To: Rui Costa; Stewart Bryant Cc: erminio.ottone_69@libero.it; mpls@ietf.org; ietf@ietf.org; IETF-Announc= e Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Rui: You wrote: >Reading something, keeping it on record, without effect in the draft >and "ignoring comments" have IMHO similar outcomes. As author of the draft= you are free to do it. These standards have a great impact in our work, so= i'm also free to write what i did. Numerous comments did have effect on the draft and those that didn't were e= ither simply not actionable, were rhetorical or not constructive, and a few= had to be balanced against comments coming from the MPLS & BFD WGs. I woul= d translate "ingored" or "without effect" to "did not get one'e way". In th= e standards process it happens. >My technical concerns regarding this draft were expressed... >...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i >believe); ...in operators' meetings' that took place during ITU-T's >Feb/2011 plenary meeting; I and the WG don't really have access to private grumblings. Lots of other opinions were expressed as well, and they did not all agree w= ith you. >Some: >CC/CV >I don't understand the need for 2 types of packets: a single type allows C= C; mismatching identifiers in the same CC packets allow CV. >Besides adding complexity, we whether always activate both or potentiate u= ndetected mismerges. OK, lets walk through this. We want CV all the time so that any misconectivity can be detected, but on = the list it was expressed that the group did not want the overhead of proce= ssing the source MEP TLV in every packet in order to achieve this. We could= carry it in every packet and have the receiver simply ignore most of them,= but then that would make the defect entry criteria compeltely random and t= he exit criteria unreliable as well, not really a good design. Hence they a= re separated using different ACH code points and the receiver is obliged to= process every source MEP TLV it receives. I hope this is clear. >(BTW: can't understand how we propose one ACH codepoint to CC, another >for CV, [counting other drafts, another for frame loss ...] but don't >consider assigning 1 single ACH protocol identifier codepoint >as >requested by ITU-T) Because that puts you into two protocol ID demultiplexing steps per OAM PDU= recevied to determine the intended function. Hence COSTS MORE. That is pre= tty basic... > Uni P2P / P2MP > I can't see how BFD will support unidir and hence P2MP other than... > ...eliminating the session "state variable" (down, init, up), aiming just= the state variables we really need, bringing us to something similar to 17= 31, eventually with other bits on the wire or... > ...using IP to create the reverse way, which we cannot assume per > requirements; Will we create a complete different tool for that? > (BFD's B=3D"bidirectional") I would not go so far as to say "similar to 1731", there is actually a lot = of difference under the hood. As for uni-directional BFD, that is a BFD WG = problem at the moment. > Provisioning list > This is an MPLS profile/subset (and i heard) achievable through a > particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus= on that profile/configuration. However, i keep seeing references f.i. to I= P encapsulations unexpected under TP's OAM. > I don't thus understand what the aim is: do we expect this in TP, are we = talking about MPLS in general?... The TP profile is never quite delimited. > Does chapter 4 contain ALL the configurable parameters list agreed to pro= vide in the comparison session? It should. As for encapsulations, unless TP is in a complete island not con= nected to anything (which as a network is rather useless) it will be expect= ed to interoperate with the rest of the MPLS architecture, and the stated i= ntention of tool development was that what resulted was applicable to the b= roader MPLS architecture. Which means backwards compatiblity and procedures= for interoperation. > Backwards compatibility > This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a= better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployme= nt plus coherence with SDH, OTN, as defended by ITU-T. > For reasons like the above, however, MPLS-TP BFD won't be backwards compa= tible with previous BFD (even considering just CC/CV). They don't even shar= e the same codepoint. The issue is not code point, which is the trivial part. It is reuse of the = majority of the implementation. Again, pretty basic. >Simplicity >Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is >simpler: in each flow, a standard defined nr of constant heartbeat >signals (with standard constant or provisioned period - no auto/negotiated= -) means OK. A standard defined number of misses means lost Rx connection.= An RDI, the only articulation between Rx and Tx flows, meaningful in bidir= ectional applications, allows each pear to identify Tx problems. >This OAM simplicity is the key for reliable fail finger pointing, >performance reports and protection. Also to allow scaling, more implementa= tion opportunities/manufacturers, which is valuable for operators. Well IMO there was not a lot of interest in T-MPLS until the IETF was going= to re-define it and make it compatible with IP/MPLS. So there was an indus= try wide "design intent" implied here. > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more dif= ficult to tell which is which. That is because MPLS-TP is not a new techology, it is an addition to the en= tire MPLS protocol suite. Hope this helps D -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 19:25 To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: >Several service providers regarded this draft as not meeting their >transport networks' needs. E> This is a true statement: the solution in this draft is useless for many= MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was = that the issue some service providers had was that the IETF BFD solution ex= ceeded their requirements in that there was additional functionality they d= id not see a need for, and that they considered any additional functionalit= y parasitic. However this is a consequence of adapting an existing technology to a new a= pplication. I do not see any way around that. And the entire joint project = was based on the premise of engineering re-use not greenfield design. That = is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mai= nstream, so it is a bit late to cry foul.... My 2 cents Dave -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 18:36 To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: [mpls] R: Re: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February = where the comments originated. The revised meeting schedule resulted in a d= ay spent going through the document with the editors. IMO there were lots o= f discussion and legitimate issues with the document identified and correct= ed so it was a useful session. The liaison of same was in many ways *after = the fact*. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:34 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard The way this draft has been developed is a bit strange. The poll for its adoption as a WG document was halted by the MPLS WG chair = because "it is not possible to judge consensus": http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html The lack of consensus was motivated by serious technical concerns raised by= several transport experts during the poll. Nevertheless the MPLS WG chair decided to adopt the draft as a WG document: http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html After several WG revisions and WG LCs, the technical issues have not been r= esolved. >Several service providers regarded this draft as not meeting their >transport networks' needs. This is a true statement: the solution in this draft is useless for many MP= LS- TP deployments. -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: quarta-feira, 6 de Julho de 2011 18:26 To: loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: Re: [mpls] Last Call: (Pr= oactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent > June 29th. > So when the WG LC to confirm the LC comment resolution has been launched? The proto write-up says: It has also passed a working roup call to verify that LC commen= ts were correctly with minor comments. It also says: The comments has been carefully discussed between the authors and people making the c= omments and has been resolved. But it seems that some comments have not been discussed with the authors of= the comments. When ITU-T Q10/15 has been involved in discussing its commen= ts? -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: quarta-feira, 6 de Julho de 2011 16:44 To: Rui Costa Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard All, Since someone has commented about the process used for resolving questions = on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is= : On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS work= ing group last call; these comments - and the intended resolution - is inc= luded in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 = days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a "New ID needed" due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without do= ubt that no comments been ignored. Loa mpls wg document shepherd -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: quarta-feira, 6 de Julho de 2011 14:58 To: Rui Costa; ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard Hi Rui: The comments were not ignored, the resolution of the Q10 comments as well a= s those collected from the MPLS WG was presented at the last IETF. My sprea= dsheet from which that report was generated and has been augmented to inclu= de the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last= -Call-Comments.xls So you know... Dave -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rui= Costa Sent: segunda-feira, 4 de Julho de 2011 23:03 To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: (Proac= tive Connectivity Verification, Continuity Check and Remote Defect indicati= on for MPLS Transport Profile) to Proposed Standard IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but w= ere simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transpor= t networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (sam= e date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: (Proactive= Connectivity Verification, Continuity Check and Remote Defect indication f= or MPLS Transport Profile) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' 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 2011-07-14. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From hongk@cisco.com Thu Jul 14 15:21:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F2421F8B18 for ; Thu, 14 Jul 2011 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgjNcj9tq6VH for ; Thu, 14 Jul 2011 15:21:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8150C21F86B9 for ; Thu, 14 Jul 2011 15:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=3924; q=dns/txt; s=iport; t=1310682076; x=1311891676; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+gcGMdTbV2+d1aWeNIn73yUuzfhjoIsivSlm+yxCDRc=; b=LmiTXZT0PKzG6Q6IZOjMqDtJbTCq3WXuoxYpP6I2phse1F4JAcSaQmkI 6o54Z1f7/ezvi+GlizrzlWq/RmV4zkd+0xe+NMsM2X0bSrkwzk4ixE1ke /g6NZn49F36VbOb0XmYvLkxhZ35C1NECRbecguN4OOjshInSWRwtUY9Bk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAJZqH06tJV2d/2dsb2JhbABUmCCPPneuA45zjxaFW18Eh1OQGotm X-IronPort-AV: E=Sophos;i="4.65,531,1304294400"; d="scan'208";a="3092605" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jul 2011 22:21:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6EMLGr6006187 for ; Thu, 14 Jul 2011 22:21:16 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 17:21:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 17:21:14 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> In-Reply-To: <4E1F48B6.7040802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) thread-index: AcxCX3LIRIu4mcjSQEuVm70RwMlv6wAE8BfA References: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> <4E1F48B6.7040802@cisco.com> From: "Kyung-Yeop Hong (hongk)" To: "Stewart Bryant (stbryant)" , X-OriginalArrivalTime: 14 Jul 2011 22:21:16.0146 (UTC) FILETIME=[58DD9D20:01CC4274] Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 22:21:17 -0000 Rolf et al, As the content had been in the draft-ietf-mpls-tp-identifiers and removed due to the shortcoming until resolved, I propose to discuss and figure out the resolution first before the adoption call. I also believe the content should go back into the identifiers draft once resolved. Regards, KY -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant (stbryant) Sent: Thursday, July 14, 2011 3:51 PM To: mpls@ietf.org Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) Rolf So the 16 bit identifier in section 5 is an additional identifier? Please could you reduce the confusion by drawing up the proposed data=20 structure in octet/longword format as per traditional IETF representation. - Stewart On 14/07/2011 20:16, Rolf Winter wrote: > Hello, > > > I changed the subject line since this is I think orthogonal to the call for adoption. I also try to address a set of comments from different people that have been raised in this one Email. > > The main discussion has been revolving around the actual format of the MEG_ID, in particular the length of the whole ID and the length of the operator-definable part. The length results from Y.1731 using 13 bytes for MEG_IDs and the document is following ITU-T conventions after all. So that is where the length comes from. If the WG decides that the remaining UMC is not long enough then we need to define another identifier. That's regular WG process I'd say. In either event this document will be liaised with the ITU-T ensuring we follow the right ITU-T conventions. > > Regarding the UMC. It is at least 4 characters long. If you restrict yourself to alphanumeric you will have 36 states per character resulting in 36^4 possible combinations which is around 1.6 million. I think the sheer number might not the problem but rather the structure, i.e. existing structures might not fit into these 4 characters and again, the WG needs to figure this out. > > The need for a delimiter is based on the fact that you have three fields, two of which are of variable length. Let me illustrate this with an example to show that the delimiter is needed independent of the ordering. (and yes there are other ways to deal with this which I'd be happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take also operator "C" and operator "CD". If "C" decides to use a UMC "DE" and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A delimiter will solve this issue. The same principle applies to the ordering ICC:CC:UMC only here this could happen even with different country codes but if you want to be 100% sure that such a situation cannot arise, then you need another token in the ID (or used fixed sized fields or use another trick...). > > Generally, there have been comments that the adoption call is either too early or the content should go into the identifiers draft. Well, the content in fact has been in that document. So, in principle the need for this already has been acked by the WG. This draft addresses the shortcoming which caused the content to be removed. That is why I asked the chairs to do the poll now (so please don't blame Ross, blame me). > > Anyway, I am happy to discuss this further. > > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Robert.Rennison@ecitele.com Thu Jul 14 16:39:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90021F86D7 for ; Thu, 14 Jul 2011 16:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cch6ssczSKLE for ; Thu, 14 Jul 2011 16:39:46 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFB21F86D6 for ; Thu, 14 Jul 2011 16:39:46 -0700 (PDT) X-AuditID: 3f5e7f87-b7b84ae000006dce-06-4e1fa3e0a73f Received: from uspitexch02.ecitele.com ( [10.0.0.72]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 74.C0.28110.0E3AF1E4; Thu, 14 Jul 2011 22:20:17 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Thu, 14 Jul 2011 19:39:43 -0400 From: Robert Rennison To: "davarish@yahoo.com" , "ietf@ietf.or" , "mpls@ietf.org" Date: Thu, 14 Jul 2011 19:39:42 -0400 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxCZsbo1QwfG582Rkq45G58j3TBWQAFNmLO Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> In-Reply-To: <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEJsWRmVeSWpSXmKPExsXCxcDgoftwsbyfwcaNLBYHnzcxWly+VWhx a+lKVgdmj72fFrB6LFnyk8lj1qzDTAHMUQ2MNol5efkliSWpCimpxcm2SgFFmWWJyZVKCpkp tkqGSgoFOYnJqbmpeSW2SokFBal5KUp2XAoYwAaoLDNPITUvOT8lMy/dVskz2F/XwsLUUtdQ yU5N2dDYmiskI7NYIVU3NzEzRyE3tbg4MT1VASiSsIU549rV+ywFp60qjs/dzN7A+Em/i5GT Q0LARGLX2ndMELaYxIV769m6GLk4hAR2M0rMnt/ODOH0MErsun+IGaSKTcBYYsOns6wgtohA vsT3RXvB4iwCqhK/bi1kBLGFBWIlDq2HsEUE4iRmr+iCqjeS6Jt0FMzmFQiQuPNqIjvEgqtM Es27OsEaOAUKJabdfMwCYjMCnfT91Bqw85gFxCVuPZkPdaqAxJI955khbFGJl4//sULUi0rc aV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYxipcUF mSVJuekGhnqpyZklqTmpesn5uZsYgenCPq6+fQdj/xStQ4ySHExKory/q+X9hPiS8lMqMxKL M+KLSnNSiw8xWgBDayKzFHdyPjBN5ZXEGxsYoHCUxHl3dizxFRJIB6aY7NTUgtQimFYZDg4l CV7TWqCxgkWp6akVaZk5JQhpJg7OQ4wSHDxKIrwpIDW8xQWJucWZ6RD5U4yqHH9uPjrCKMSS l5+XKiXO2w5SJABSlFGaBzfnFaM4B6OSMMQIHmDCh5vwCmg4E9DwdVayIMOBKRouJdXAaPz+ sWDY6qxpdQySGrvTn+byT2Dy/vvM3+/co0mreKXro1/fLL26MHyWptADf9GvO9j03h5oarjv cJzjgw8/R/1vC97U6puPmBt0JirGHC54whzLf6NlqXR69+f1ej4sHhPmmB4/uSGx7+S8N4w5 C09un2ry2nnmKefmmq1NF1annl4ccergPCWW4oxEQy3mouJEAEQr9DO1AwAA Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 23:39:50 -0000 Sharam, Where one runs the protocol and how one divides it up, is up to the implemen= tation, you may choose to run it all in SW all in HW or a combination, just= like for any protocol. I am merely pointing out those aspects which are mo= st optimal for HW assist, in case you desire to have a more "efficient" impl= ementation. I'd have thought you'd appreciate that! Regarding running duplicate BFD "engines", I'm not sure in your review of t= he draft you spotted the following, but in case you did not. " All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored." As you can see there's no generic BFD "engine" /state machine required for= the CV messages, they do not directly affect the BFD state, they of course= affect whether you enter or exit the defect state as described in defect en= try and exit criteria sections. Cheers Rob ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Thursday, July 14, 2011 4:43 PM To: Robert Rennison; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proactiv= e Connectivity) So your idea is to run CV in SW. That is quite possible but this means the B= FD engine needs to be duplicated, one in HW and one in SW. Is that the intention of the group? If so it is not an efficient way of usin= g the resources in a router. Thx SD Sent via BlackBerry by AT&T -----Original Message----- From: Robert Rennison Date: Thu, 14 Jul 2011 16:39:37 To: S. Davari; ietf@ietf.or; mpls@ietf.org= Subject: RE: [mpls] Last Call: (Proactive Connectivity) Sharam, The CV packets are sent at one per second i.e at a rate which does not reall= y need hardware assist, and as such the format of these packets is not real= ly optimized for HW implementation. The CC packets can be sent at whatever rate both ends can support, typically= today this can be around one per milli-second hence HW assist is required f= or CC packets and indeed the baseline BFD is designed around this premise. So, quite contrary to your statement of: >These two functions make the Hardware implementation very complex and delay= s > implementation and deployment of this draft. I would have 2 suggestions to= fix this: The decisions made are in fact aimed at allowing for fast hardware implemen= tation of CC, it is after all the same packet as baseline bFD with a differe= nt codepoint, and not requiring it for the CV. In fact with CV having a dif= ferent codepoint, as Dave explained in an earlier reply this makes for a ve= ry simple filtering/classification of which packets are to be handled by HW= and which can be punted to a slowpath. Cheers Rob Rennison ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [= davarish@yahoo.com] Sent: Thursday, July 14, 2011 9:11 AM To: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proact= ive Connectivity) Hi, I also have concern regarding: 1) Different MEP ID formats 2) CV interleaving These two functions make the Hardware implementation very complex and delays= implementation and deployment of this draft. I would have 2 suggestions to= fix this: 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments i= nstead of TLV. TLVs are not hardware friendly. 2) Default to be All CC or All CV. Have the CV interleaving optional (if bot= h sides are capable). Thx Shahram ________________________________ From: "hideki.endo.es@hitachi.com" To: ietf@ietf.or; mpls@ietf.org Sent: Thu, July 14, 2011 4:22:42 AM Subject: Re: [mpls] Last Call: (Proacti= ve Connectivit The changes in this version have massive impact for CC/CV/RDI implementation= . We, venders, have kept making efforts on interoperability test again and aga= in. These changes spoil this effort. Especially, revival of Poll/Final sequence doesn't make sense. Originally, in my understanding, Poll/Final sequence was excluded from this= draft to avoid making HW implementation difficult. Even though it was difficult to change CC interval arbitrary, the problem should be solved by defining how to transit DOWN/INIT state to U= P state. The direction which reached consensus once should NOT be changed easily in order to respond to the market requirements. IMO, such major changes should NOT be added right before becoming RFC. I found at least four major/minor changes as follows; 1)Revival of Poll/Final sequence 2)Change of MEP ID formats 3)Change of Diag. Code 4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. Exceptiona= lly, 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 > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls 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. From davari@broadcom.com Thu Jul 14 17:04:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7221F899D for ; Thu, 14 Jul 2011 17:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 136gp1UUMUvb for ; Thu, 14 Jul 2011 17:04:09 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id ABB4F21F862B for ; Thu, 14 Jul 2011 17:04:09 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 14 Jul 2011 17:08:48 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 14 Jul 2011 17:03:55 -0700 From: "Shahram Davari" To: "Robert Rennison" , "davarish@yahoo.com" , "ietf@ietf.or" , "mpls@ietf.org" Date: Thu, 14 Jul 2011 17:03:53 -0700 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxCZsbo1QwfG582Rkq45G58j3TBWQAFNmLOAAF520A= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62015A9A5ZC1067969-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 00:04:13 -0000 Robert, May be I am missing something here. Is the intention to have 2 separate BFD= sessions: one BFD CC and one BFD CV each with their own rate and state mac= hine? Or this is all one BFD sessions in which some of the BFD packets are = CV rather than CC. If these are two separate BFD sessions then there are 3 choices: 1) process CC and CV in HW, in which case this is very complex since CC and= CV have different format and different processing as well as different sta= te Machine. Also I would need to separate BFD generator in HW at different = rates 2) process CC and CV in SW, which is not practical due to fast rate of CC 3) Process CC in HW and CV in SW, which is not efficient since we are dupli= cating the HW logic in SW as well. If there is only one BFD session and the CC and CV are part of the same sta= te machine, then we only have option (1) and (2). In either case these are not good practical choices. After all RFC's are no= t university thesis, they have to be reasonably implementable. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rob= ert Rennison Sent: Thursday, July 14, 2011 4:40 PM To: davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Sharam, Where one runs the protocol and how one divides it up, is up to the impleme= ntation, you may choose to run it all in SW all in HW or a combination, jus= t like for any protocol. I am merely pointing out those aspects which are = most optimal for HW assist, in case you desire to have a more "efficient" i= mplementation. I'd have thought you'd appreciate that!=20 Regarding running duplicate BFD "engines", I'm not sure in your review of = the draft you spotted the following, but in case you did not. " All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored." As you can see there's no generic BFD "engine" /state machine required for= the CV messages, they do not directly affect the BFD state, they of course= affect whether you enter or exit the defect state as described in defect e= ntry and exit criteria sections.=20 Cheers Rob ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Thursday, July 14, 2011 4:43 PM To: Robert Rennison; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) So your idea is to run CV in SW. That is quite possible but this means the = BFD engine needs to be duplicated, one in HW and one in SW. Is that the intention of the group? If so it is not an efficient way of usi= ng the resources in a router. Thx SD Sent via BlackBerry by AT&T -----Original Message----- From: Robert Rennison Date: Thu, 14 Jul 2011 16:39:37 To: S. Davari; ietf@ietf.or; mpls@ietf.or= g Subject: RE: [mpls] Last Call: (Proactive Connectivity) Sharam, The CV packets are sent at one per second i.e at a rate which does not real= ly need hardware assist, and as such the format of these packets is not re= ally optimized for HW implementation. The CC packets can be sent at whatever rate both ends can support, typicall= y today this can be around one per milli-second hence HW assist is required= for CC packets and indeed the baseline BFD is designed around this premise= . So, quite contrary to your statement of: >These two functions make the Hardware implementation very complex and dela= ys > implementation and deployment of this draft. I would have 2 suggestions t= o fix this: The decisions made are in fact aimed at allowing for fast hardware impleme= ntation of CC, it is after all the same packet as baseline bFD with a diffe= rent codepoint, and not requiring it for the CV. In fact with CV having a = different codepoint, as Dave explained in an earlier reply this makes for = a very simple filtering/classification of which packets are to be handled b= y HW and which can be punted to a slowpath. Cheers Rob Rennison ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari = [davarish@yahoo.com] Sent: Thursday, July 14, 2011 9:11 AM To: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity) Hi, I also have concern regarding: 1) Different MEP ID formats 2) CV interleaving These two functions make the Hardware implementation very complex and delay= s implementation and deployment of this draft. I would have 2 suggestions t= o fix this: 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments = instead of TLV. TLVs are not hardware friendly. 2) Default to be All CC or All CV. Have the CV interleaving optional (if bo= th sides are capable). Thx Shahram ________________________________ From: "hideki.endo.es@hitachi.com" To: ietf@ietf.or; mpls@ietf.org Sent: Thu, July 14, 2011 4:22:42 AM Subject: Re: [mpls] Last Call: (Proact= ive Connectivit The changes in this version have massive impact for CC/CV/RDI implementatio= n. We, venders, have kept making efforts on interoperability test again and ag= ain. These changes spoil this effort. Especially, revival of Poll/Final sequence doesn't make sense. Originally, in my understanding, Poll/Final sequence was excluded from this= draft to avoid making HW implementation difficult. Even though it was difficult to change CC interval arbitrary, the problem should be solved by defining how to transit DOWN/INIT state to = UP state. The direction which reached consensus once should NOT be changed easily in order to respond to the market requirements. IMO, such major changes should NOT be added right before becoming RFC. I found at least four major/minor changes as follows; 1)Revival of Poll/Final sequence 2)Change of MEP ID formats 3)Change of Diag. Code 4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. Exception= ally, comments may be >sent to iesg@ietf.org instead. In either case, pleas= e retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls 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. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Jul 14 17:35:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23CC21F876E for ; Thu, 14 Jul 2011 17:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-XcBzZF9rMG for ; Thu, 14 Jul 2011 17:35:40 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA6B21F8710 for ; Thu, 14 Jul 2011 17:35:40 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 14 Jul 2011 17:39:54 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 14 Jul 2011 17:35:01 -0700 From: "Shahram Davari" To: "Shahram Davari" , "Robert Rennison" , "davarish@yahoo.com" , "ietf@ietf.or" , "mpls@ietf.org" Date: Thu, 14 Jul 2011 17:34:59 -0700 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxCZsbo1QwfG582Rkq45G58j3TBWQAFNmLOAAF520AAAUvg4A== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B5388@SJEXCHCCR02.corp.ad.broadcom.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620153D05ZC1079099-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 00:35:41 -0000 On another note: When any of the defects in section 3.7.2. happens, it seems that the State = Machine should move to DOWN state. But the defects in section 3.7.2. are no= t shown as a trigger to transition to DOWN State in any of the State Machin= e figures. Am I missing something? Thx Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Thursday, July 14, 2011 5:04 PM To: Robert Rennison; davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Robert, May be I am missing something here. Is the intention to have 2 separate BFD= sessions: one BFD CC and one BFD CV each with their own rate and state mac= hine? Or this is all one BFD sessions in which some of the BFD packets are = CV rather than CC. If these are two separate BFD sessions then there are 3 choices: 1) process CC and CV in HW, in which case this is very complex since CC and= CV have different format and different processing as well as different sta= te Machine. Also I would need to separate BFD generator in HW at different = rates 2) process CC and CV in SW, which is not practical due to fast rate of CC 3) Process CC in HW and CV in SW, which is not efficient since we are dupli= cating the HW logic in SW as well. If there is only one BFD session and the CC and CV are part of the same sta= te machine, then we only have option (1) and (2). In either case these are not good practical choices. After all RFC's are no= t university thesis, they have to be reasonably implementable. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rob= ert Rennison Sent: Thursday, July 14, 2011 4:40 PM To: davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Sharam, Where one runs the protocol and how one divides it up, is up to the impleme= ntation, you may choose to run it all in SW all in HW or a combination, jus= t like for any protocol. I am merely pointing out those aspects which are = most optimal for HW assist, in case you desire to have a more "efficient" i= mplementation. I'd have thought you'd appreciate that!=20 Regarding running duplicate BFD "engines", I'm not sure in your review of = the draft you spotted the following, but in case you did not. " All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored." As you can see there's no generic BFD "engine" /state machine required for= the CV messages, they do not directly affect the BFD state, they of course= affect whether you enter or exit the defect state as described in defect e= ntry and exit criteria sections.=20 Cheers Rob ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Thursday, July 14, 2011 4:43 PM To: Robert Rennison; ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) So your idea is to run CV in SW. That is quite possible but this means the = BFD engine needs to be duplicated, one in HW and one in SW. Is that the intention of the group? If so it is not an efficient way of usi= ng the resources in a router. Thx SD Sent via BlackBerry by AT&T -----Original Message----- From: Robert Rennison Date: Thu, 14 Jul 2011 16:39:37 To: S. Davari; ietf@ietf.or; mpls@ietf.or= g Subject: RE: [mpls] Last Call: (Proactive Connectivity) Sharam, The CV packets are sent at one per second i.e at a rate which does not real= ly need hardware assist, and as such the format of these packets is not re= ally optimized for HW implementation. The CC packets can be sent at whatever rate both ends can support, typicall= y today this can be around one per milli-second hence HW assist is required= for CC packets and indeed the baseline BFD is designed around this premise= . So, quite contrary to your statement of: >These two functions make the Hardware implementation very complex and dela= ys > implementation and deployment of this draft. I would have 2 suggestions t= o fix this: The decisions made are in fact aimed at allowing for fast hardware impleme= ntation of CC, it is after all the same packet as baseline bFD with a diffe= rent codepoint, and not requiring it for the CV. In fact with CV having a = different codepoint, as Dave explained in an earlier reply this makes for = a very simple filtering/classification of which packets are to be handled b= y HW and which can be punted to a slowpath. Cheers Rob Rennison ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari = [davarish@yahoo.com] Sent: Thursday, July 14, 2011 9:11 AM To: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call: (Proac= tive Connectivity) Hi, I also have concern regarding: 1) Different MEP ID formats 2) CV interleaving These two functions make the Hardware implementation very complex and delay= s implementation and deployment of this draft. I would have 2 suggestions t= o fix this: 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments = instead of TLV. TLVs are not hardware friendly. 2) Default to be All CC or All CV. Have the CV interleaving optional (if bo= th sides are capable). Thx Shahram ________________________________ From: "hideki.endo.es@hitachi.com" To: ietf@ietf.or; mpls@ietf.org Sent: Thu, July 14, 2011 4:22:42 AM Subject: Re: [mpls] Last Call: (Proact= ive Connectivit The changes in this version have massive impact for CC/CV/RDI implementatio= n. We, venders, have kept making efforts on interoperability test again and ag= ain. These changes spoil this effort. Especially, revival of Poll/Final sequence doesn't make sense. Originally, in my understanding, Poll/Final sequence was excluded from this= draft to avoid making HW implementation difficult. Even though it was difficult to change CC interval arbitrary, the problem should be solved by defining how to transit DOWN/INIT state to = UP state. The direction which reached consensus once should NOT be changed easily in order to respond to the market requirements. IMO, such major changes should NOT be added right before becoming RFC. I found at least four major/minor changes as follows; 1)Revival of Poll/Final sequence 2)Change of MEP ID formats 3)Change of Diag. Code 4)Change of CV interleaved definition BR, Hideki > >The IESG has received a request from the Multiprotocol Label Switching WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile' > 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 2011-07-14. Exception= ally, comments may be >sent to iesg@ietf.org instead. In either case, pleas= e retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > Continuity Check, Proactive Connectivity Verification and Remote > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of the > label switched path for any loss of continuity defect. Connectivity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issues. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detects on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-TP > label switched paths, pseudo wires and Sections using Bidirectional > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls 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. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mjethanandani@gmail.com Thu Jul 14 18:31:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845421F84F5 for ; Thu, 14 Jul 2011 18:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX+YW4ekeCOm for ; Thu, 14 Jul 2011 18:31:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3196921F84A1 for ; Thu, 14 Jul 2011 18:31:03 -0700 (PDT) Received: by iye7 with SMTP id 7so803867iye.31 for ; Thu, 14 Jul 2011 18:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mZtUk7JO5IYj7lrhn69PnaL3o09kRoHRJJGbZ+96DsM=; b=nZ0CrQ115FfTmd6WbU8lZJd/T8Y0OMxMktuoHwWFUn66yHP7ouoQq5c3Xa08LYYStq nhb+OEQqc+ahliApB8PCzk9skjlMcY8I2K+WWhvXiZazaP/F0ChtPGq1/5XbxsdUE+uh SWdUfJYMiNEUE/qKPZM6UE7cp0ZUpKPg2ON4o= Received: by 10.231.61.9 with SMTP id r9mr1877257ibh.140.1310693462648; Thu, 14 Jul 2011 18:31:02 -0700 (PDT) Received: from [192.168.1.147] (c-24-6-173-225.hsd1.ca.comcast.net [24.6.173.225]) by mx.google.com with ESMTPS id fw9sm501209ibb.30.2011.07.14.18.31.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 18:31:01 -0700 (PDT) Message-ID: <4E1F9853.5030206@gmail.com> Date: Thu, 14 Jul 2011 18:30:59 -0700 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mpls@ietf.org References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 01:31:07 -0000 Shahram, Having done a implementation of CC/CV, here are some notes I can share. - Completely agree on not wanting to duplicate the BFD engine in h/w and s/w. Use s/w for managing all session including those that are run in h/w. That includes managing the different formats of sessions. - Have s/w setup the session in h/w as necessary. But limit the functionality to what h/w is good at. E.g. sending of BFD packets at the (ms) rate agreed upon and for detection of these ms sessions when the BFD session has failed. - Pass the failure of BFD session notification to s/w for it to handle the state machine change (including switching the LSPs). On 7/14/2011 5:03 PM, Shahram Davari wrote: > Robert, > > May be I am missing something here. Is the intention to have 2 separate BFD sessions: one BFD CC and one BFD CV each with their own rate and state machine? Or this is all one BFD sessions in which some of the BFD packets are CV rather than CC. > > If these are two separate BFD sessions then there are 3 choices: > > 1) process CC and CV in HW, in which case this is very complex since CC and CV have different format and different processing as well as different state Machine. Also I would need to separate BFD generator in HW at different rates > > 2) process CC and CV in SW, which is not practical due to fast rate of CC > > 3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well. > > If there is only one BFD session and the CC and CV are part of the same state machine, then we only have option (1) and (2). > > In either case these are not good practical choices. After all RFC's are not university thesis, they have to be reasonably implementable. > > > Regards, > Shahram > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Rennison > Sent: Thursday, July 14, 2011 4:40 PM > To: davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:(Proactive Connectivity) > > Sharam, > > Where one runs the protocol and how one divides it up, is up to the implementation, you may choose to run it all in SW all in HW or a combination, just like for any protocol. I am merely pointing out those aspects which are most optimal for HW assist, in case you desire to have a more "efficient" implementation. I'd have thought you'd appreciate that! > > > Regarding running duplicate BFD "engines", I'm not sure in your review of the draft you spotted the following, but in case you did not. > > " All BFD state changes and P/F exchanges MUST be done using CC > packets. P/F and session state information in CV packets MUST be > ignored." > > As you can see there's no generic BFD "engine" /state machine required for the CV messages, they do not directly affect the BFD state, they of course affect whether you enter or exit the defect state as described in defect entry and exit criteria sections. > > Cheers > > Rob > > ________________________________________ > From: davarish@yahoo.com [davarish@yahoo.com] > Sent: Thursday, July 14, 2011 4:43 PM > To: Robert Rennison; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:(Proactive Connectivity) > > So your idea is to run CV in SW. That is quite possible but this means the BFD engine needs to be duplicated, one in HW and one in SW. > > Is that the intention of the group? If so it is not an efficient way of using the resources in a router. > > Thx > SD > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Robert Rennison > Date: Thu, 14 Jul 2011 16:39:37 > To: S. Davari; ietf@ietf.or; mpls@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity) > > Sharam, > > The CV packets are sent at one per second i.e at a rate which does not really need hardware assist, and as such the format of these packets is not really optimized for HW implementation. > > > The CC packets can be sent at whatever rate both ends can support, typically today this can be around one per milli-second hence HW assist is required for CC packets and indeed the baseline BFD is designed around this premise. > > > So, quite contrary to your statement of: > >> These two functions make the Hardware implementation very complex and delays >> implementation and deployment of this draft. I would have 2 suggestions to fix this: > The decisions made are in fact aimed at allowing for fast hardware implementation of CC, it is after all the same packet as baseline bFD with a different codepoint, and not requiring it for the CV. In fact with CV having a different codepoint, as Dave explained in an earlier reply this makes for a very simple filtering/classification of which packets are to be handled by HW and which can be punted to a slowpath. > > Cheers > > Rob Rennison > > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [davarish@yahoo.com] > Sent: Thursday, July 14, 2011 9:11 AM > To: ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:(Proactive Connectivity) > > Hi, > > I also have concern regarding: > > 1) Different MEP ID formats > 2) CV interleaving > > These two functions make the Hardware implementation very complex and delays implementation and deployment of this draft. I would have 2 suggestions to fix this: > > 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments instead of TLV. TLVs are not hardware friendly. > > 2) Default to be All CC or All CV. Have the CV interleaving optional (if both sides are capable). > > Thx > Shahram > > > ________________________________ > From: "hideki.endo.es@hitachi.com" > To: ietf@ietf.or; mpls@ietf.org > Sent: Thu, July 14, 2011 4:22:42 AM > Subject: Re: [mpls] Last Call:(Proactive Connectivit > > The changes in this version have massive impact for CC/CV/RDI implementation. > We, venders, have kept making efforts on interoperability test again and again. > These changes spoil this effort. > > Especially, revival of Poll/Final sequence doesn't make sense. > Originally, in my understanding, Poll/Final sequence was excluded from this draft > to avoid making HW implementation difficult. > > Even though it was difficult to change CC interval arbitrary, > the problem should be solved by defining how to transit DOWN/INIT state to UP state. > > The direction which reached consensus once should NOT be changed easily > in order to respond to the market requirements. > > IMO, such major changes should NOT be added right before becoming RFC. > > I found at least four major/minor changes as follows; > 1)Revival of Poll/Final sequence > 2)Change of MEP ID formats > 3)Change of Diag. Code > 4)Change of CV interleaved definition > > BR, > Hideki > > >> The IESG has received a request from the Multiprotocol Label Switching WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 2011-07-14. 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 >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > 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 us by e-mail, phone or fax, and then delete the original and all copies thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Thu Jul 14 21:50:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EAA21F8652 for ; Thu, 14 Jul 2011 21:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua4R7NyHg4PD for ; Thu, 14 Jul 2011 21:50:57 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E5FD621F8651 for ; Thu, 14 Jul 2011 21:50:56 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTh/HLWkQ8kMzOHG7fwZcpC9Yt+KQH0I4@postini.com; Thu, 14 Jul 2011 21:50:56 PDT 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; Thu, 14 Jul 2011 21:48:10 -0700 From: John E Drake To: Shahram Davari Date: Thu, 14 Jul 2011 21:47:58 -0700 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxCqmTobBAWbuSZSDmUlvmdQBE/jw== Message-ID: <673D8857-DE11-4249-8B2D-624DA3028379@juniper.net> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B5388@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B5388@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 04:50:58 -0000 Shahram, The last time I checked, there was no 'Let's make sure Shahram is =20 happy before proceeding' clause in the approval process. If you're =20 asleep at the wheel, I think that is your problem. Thanks, John Sent from my iPhone On Jul 14, 2011, at 5:35 PM, "Shahram Davari" =20 wrote: > On another note: > > When any of the defects in section 3.7.2. happens, it seems that the =20 > State Machine should move to DOWN state. But the defects in section =20 > 3.7.2. are not shown as a trigger to transition to DOWN State in any =20 > of the State Machine figures. > > Am I missing something? > > Thx > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf =20 > Of Shahram Davari > Sent: Thursday, July 14, 2011 5:04 PM > To: Robert Rennison; davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:=20 > (Proactive Connectivity) > > Robert, > > May be I am missing something here. Is the intention to have 2 =20 > separate BFD sessions: one BFD CC and one BFD CV each with their own =20 > rate and state machine? Or this is all one BFD sessions in which =20 > some of the BFD packets are CV rather than CC. > > If these are two separate BFD sessions then there are 3 choices: > > 1) process CC and CV in HW, in which case this is very complex since =20 > CC and CV have different format and different processing as well as =20 > different state Machine. Also I would need to separate BFD generator =20 > in HW at different rates > > 2) process CC and CV in SW, which is not practical due to fast rate =20 > of CC > > 3) Process CC in HW and CV in SW, which is not efficient since we =20 > are duplicating the HW logic in SW as well. > > If there is only one BFD session and the CC and CV are part of the =20 > same state machine, then we only have option (1) and (2). > > In either case these are not good practical choices. After all RFC's =20 > are not university thesis, they have to be reasonably implementable. > > > Regards, > Shahram > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf =20 > Of Robert Rennison > Sent: Thursday, July 14, 2011 4:40 PM > To: davarish@yahoo.com; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:=20 > (Proactive Connectivity) > > Sharam, > > Where one runs the protocol and how one divides it up, is up to the =20 > implementation, you may choose to run it all in SW all in HW or a =20 > combination, just like for any protocol. I am merely pointing out =20 > those aspects which are most optimal for HW assist, in case you =20 > desire to have a more "efficient" implementation. I'd have thought =20 > you'd appreciate that! > > > Regarding running duplicate BFD "engines", I'm not sure in your =20 > review of the draft you spotted the following, but in case you did =20 > not. > > " All BFD state changes and P/F exchanges MUST be done using CC > packets. P/F and session state information in CV packets MUST be > ignored." > > As you can see there's no generic BFD "engine" /state machine =20 > required for the CV messages, they do not directly affect the BFD =20 > state, they of course affect whether you enter or exit the defect =20 > state as described in defect entry and exit criteria sections. > > Cheers > > Rob > > ________________________________________ > From: davarish@yahoo.com [davarish@yahoo.com] > Sent: Thursday, July 14, 2011 4:43 PM > To: Robert Rennison; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call:=20 > (Proactive Connectivity) > > So your idea is to run CV in SW. That is quite possible but this =20 > means the BFD engine needs to be duplicated, one in HW and one in SW. > > Is that the intention of the group? If so it is not an efficient way =20 > of using the resources in a router. > > Thx > SD > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Robert Rennison > Date: Thu, 14 Jul 2011 16:39:37 > To: S. Davari; ietf@ietf.or; mpls@ietf.= org=20 > > Subject: RE: [mpls] Last Call: > (Proactive Connectivity) > > Sharam, > > The CV packets are sent at one per second i.e at a rate which does =20 > not really need hardware assist, and as such the format of these =20 > packets is not really optimized for HW implementation. > > > The CC packets can be sent at whatever rate both ends can support, =20 > typically today this can be around one per milli-second hence HW =20 > assist is required for CC packets and indeed the baseline BFD is =20 > designed around this premise. > > > So, quite contrary to your statement of: > >> These two functions make the Hardware implementation very complex =20 >> and delays >> implementation and deployment of this draft. I would have 2 =20 >> suggestions to fix this: > > The decisions made are in fact aimed at allowing for fast hardware =20 > implementation of CC, it is after all the same packet as baseline =20 > bFD with a different codepoint, and not requiring it for the CV. In =20 > fact with CV having a different codepoint, as Dave explained in an =20 > earlier reply this makes for a very simple filtering/classification =20 > of which packets are to be handled by HW and which can be punted to =20 > a slowpath. > > Cheers > > Rob Rennison > > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. =20 > Davari [davarish@yahoo.com] > Sent: Thursday, July 14, 2011 9:11 AM > To: ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call: =20 > (Proactive Connectivity) > > Hi, > > I also have concern regarding: > > 1) Different MEP ID formats > 2) CV interleaving > > These two functions make the Hardware implementation very complex =20 > and delays implementation and deployment of this draft. I would have =20 > 2 suggestions to fix this: > > 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, =20 > Segments instead of TLV. TLVs are not hardware friendly. > > 2) Default to be All CC or All CV. Have the CV interleaving optional =20 > (if both sides are capable). > > Thx > Shahram > > > ________________________________ > From: "hideki.endo.es@hitachi.com" > To: ietf@ietf.or; mpls@ietf.org > Sent: Thu, July 14, 2011 4:22:42 AM > Subject: Re: [mpls] Last Call: =20 > (Proactive Connectivit > > The changes in this version have massive impact for CC/CV/RDI =20 > implementation. > We, venders, have kept making efforts on interoperability test again =20 > and again. > These changes spoil this effort. > > Especially, revival of Poll/Final sequence doesn't make sense. > Originally, in my understanding, Poll/Final sequence was excluded =20 > from this draft > to avoid making HW implementation difficult. > > Even though it was difficult to change CC interval arbitrary, > the problem should be solved by defining how to transit DOWN/INIT =20 > state to UP state. > > The direction which reached consensus once should NOT be changed =20 > easily > in order to respond to the market requirements. > > IMO, such major changes should NOT be added right before becoming RFC. > > I found at least four major/minor changes as follows; > 1)Revival of Poll/Final sequence > 2)Change of MEP ID formats > 3)Change of Diag. Code > 4)Change of CV interleaved definition > > BR, > Hideki > > >> >> The IESG has received a request from the Multiprotocol Label =20 >> Switching WG >> (mpls) to consider the following document: >> - 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 =20 >> the >> ietf@ietf.org mailing lists by 2011-07-14. =20 >> Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either =20 >> case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > This e-mail message is intended for the recipient only and contains =20 > information which is CONFIDENTIAL and which may be proprietary to =20 > ECI Telecom. If you have received this transmission in error, please =20 > inform us by e-mail, phone or fax, and then delete the original and =20 > all copies thereof. > > > > This e-mail message is intended for the recipient only and contains =20 > information which is CONFIDENTIAL and which may be proprietary to =20 > ECI Telecom. If you have received this transmission in error, please =20 > inform us by e-mail, phone or fax, and then delete the original and =20 > all copies thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Thu Jul 14 23:58:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD20621F863F for ; Thu, 14 Jul 2011 23:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU06mTm-D93p for ; Thu, 14 Jul 2011 23:58:46 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8887821F863E for ; Thu, 14 Jul 2011 23:58:45 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 15 Jul 2011 07:58:44 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 15 Jul 2011 07:58:44 +0100 From: To: , , , Date: Fri, 15 Jul 2011 07:58:39 +0100 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxCZsyD2cclLVYJTEKsLGk4F7uz6wAUDw4Q Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405B34C953@EMV62-UKRD.domain1.systemhost.net> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com> <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> In-Reply-To: <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 06:58:49 -0000 I agree Shahram. We knew 15 or so years ago CC was a mistake in ATM so I'm= not sure why we want to repeat ATM's mistake in MPLS-TP. =20 Important aside=3D> OAM needs to be as simple as is possible...because it n= eeds to be super reliable. For defect detection we only need CV and BDI fu= nctions. AIS is a also a mistake in any packet-switching networks from tha= t same ATM era (though I have to confess it took me a while to fully realis= e just what a bad mistake this was). TCM is another mistake with the all t= he a priori configured false 'sublayered' hierarchies. I don't seem to hear= many operators crying out for more complexity and potential worse reliabil= ity. What they want is increased reliability, simple config and simple ope= rations...so that their existing Ops folks can handle it.=20 regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > davarish@yahoo.com > Sent: 14 July 2011 21:43 > To: Robert Rennison; ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call: 05.txt>(Proactive Connectivity) >=20 > So your idea is to run CV in SW. That is quite possible but this means > the BFD engine needs to be duplicated, one in HW and one in SW. >=20 > Is that the intention of the group? If so it is not an efficient way of > using the resources in a router. >=20 > Thx > SD > Sent via BlackBerry by AT&T >=20 > -----Original Message----- > From: Robert Rennison > Date: Thu, 14 Jul 2011 16:39:37 > To: S. Davari; ietf@ietf.or; > mpls@ietf.org > Subject: RE: [mpls] Last Call: > (Proactive Connectivity) >=20 > Sharam, >=20 > The CV packets are sent at one per second i.e at a rate which does not > really need hardware assist, and as such the format of these packets is > not really optimized for HW implementation. >=20 >=20 > The CC packets can be sent at whatever rate both ends can support, > typically today this can be around one per milli-second hence HW assist > is required for CC packets and indeed the baseline BFD is designed > around this premise. >=20 >=20 > So, quite contrary to your statement of: >=20 > >These two functions make the Hardware implementation very complex and > delays > > implementation and deployment of this draft. I would have 2 > suggestions to fix this: >=20 > The decisions made are in fact aimed at allowing for fast hardware > implementation of CC, it is after all the same packet as baseline bFD > with a different codepoint, and not requiring it for the CV. In fact > with CV having a different codepoint, as Dave explained in an earlier > reply this makes for a very simple filtering/classification of which > packets are to be handled by HW and which can be punted to a slowpath. >=20 > Cheers >=20 > Rob Rennison >=20 > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. > Davari [davarish@yahoo.com] > Sent: Thursday, July 14, 2011 9:11 AM > To: ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last Call: 05.txt>(Proactive Connectivity) >=20 > Hi, >=20 > I also have concern regarding: >=20 > 1) Different MEP ID formats > 2) CV interleaving >=20 > These two functions make the Hardware implementation very complex and > delays implementation and deployment of this draft. I would have 2 > suggestions to fix this: >=20 > 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, > Segments instead of TLV. TLVs are not hardware friendly. >=20 > 2) Default to be All CC or All CV. Have the CV interleaving optional > (if both sides are capable). >=20 > Thx > Shahram >=20 >=20 > ________________________________ > From: "hideki.endo.es@hitachi.com" > To: ietf@ietf.or; mpls@ietf.org > Sent: Thu, July 14, 2011 4:22:42 AM > Subject: Re: [mpls] Last Call: 05.txt>(Proactive Connectivit >=20 > The changes in this version have massive impact for CC/CV/RDI > implementation. > We, venders, have kept making efforts on interoperability test again > and again. > These changes spoil this effort. >=20 > Especially, revival of Poll/Final sequence doesn't make sense. > Originally, in my understanding, Poll/Final sequence was excluded from > this draft > to avoid making HW implementation difficult. >=20 > Even though it was difficult to change CC interval arbitrary, > the problem should be solved by defining how to transit DOWN/INIT state > to UP state. >=20 > The direction which reached consensus once should NOT be changed easily > in order to respond to the market requirements. >=20 > IMO, such major changes should NOT be added right before becoming RFC. >=20 > I found at least four major/minor changes as follows; > 1)Revival of Poll/Final sequence > 2)Change of MEP ID formats > 3)Change of Diag. Code > 4)Change of CV interleaved definition >=20 > BR, > Hideki >=20 >=20 > > > >The IESG has received a request from the Multiprotocol Label Switching > WG > >(mpls) to consider the following document: > >- 'Proactive Connectivity Verification, Continuity Check and Remote > > Defect indication for MPLS Transport Profile' > > 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 2011-07-14. > 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 > > > > Continuity Check, Proactive Connectivity Verification and Remote > > Defect Indication functionalities are required for MPLS-TP OAM. > > > > Continuity Check monitors the integrity of the continuity of the > > label switched path for any loss of continuity defect. Connectivity > > verification monitors the integrity of the routing of the label > > switched path between sink and source for any connectivity issues. > > Remote defect indication enables an End Point to report, to its > > associated End Point, a fault or defect condition that it detects on > > a pseudo wire, label switched path or Section. > > > > This document specifies methods for proactive continuity check, > > continuity verification, and remote defect indication for MPLS-TP > > label switched paths, pseudo wires and Sections using Bidirectional > > Forwarding Detection. > > > > > >The file can be obtained via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > >IESG discussion can be tracked via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > >No IPR declarations have been submitted directly on this I-D. > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Fri Jul 15 00:35:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925E921F863F for ; Fri, 15 Jul 2011 00:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0VnKLc+vNzl for ; Fri, 15 Jul 2011 00:35:37 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0465D21F868A for ; Fri, 15 Jul 2011 00:35:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1EBE82800032B; Fri, 15 Jul 2011 09:35:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJey8akPRNk2; Fri, 15 Jul 2011 09:35:33 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0339E2800032A; Fri, 15 Jul 2011 09:35:18 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.188]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 15 Jul 2011 09:35:17 +0200 From: Rolf Winter To: "Kyung-Yeop Hong (hongk)" , "Stewart Bryant (stbryant)" , "mpls@ietf.org" Thread-Topic: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) Thread-Index: AQHMQnSCcHS3/6FA90aoGUgf+y4zY5Ts+xSA Date: Fri, 15 Jul 2011 07:35:16 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFDFB7C@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> <4E1F48B6.7040802@cisco.com> <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> In-Reply-To: <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 07:35:41 -0000 Hi KY, Please see inline: > As the content had been in the draft-ietf-mpls-tp-identifiers and > removed due to the shortcoming until resolved, I propose to discuss and > figure out the resolution first before the adoption call. The shortcoming was the lack of ICC global-uniqueness. We address this in t= he draft. =20 > I also believe the content should go back into the identifiers draft > once resolved. I suggested just that not so long ago. But the chairs' suggestion was to wr= ite a new document (see: http://www.ietf.org/mail-archive/web/mpls/current/= msg06623.html) which might be able to swiftly go through the WG processes. = So in short: I agree with you but this alternative has been dismissed in th= e past already. Best, Rolf From stbryant@cisco.com Fri Jul 15 01:12:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6192621F86A2 for ; Fri, 15 Jul 2011 01:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iqMGoNMfckU for ; Fri, 15 Jul 2011 01:12:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 720AD21F86A8 for ; Fri, 15 Jul 2011 01:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=367; q=dns/txt; s=iport; t=1310717528; x=1311927128; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PR/jI1jrZhRp7ECrCE9RuBK8uPmNx1ilFvNvxBjxw2o=; b=RQrVC2VZnxV+Ekg5A0/cQC+WBsHCiPt+mMkmgTgfPom36TE6idqCzHBm hAs2d+p+PLhXjJIejvSiPyehOH9Q2EOcov7tente5UO5M8yVFhy1L6qFu 0KFvU2IOooBp4K/EjuAexS+4rXi7DAjEY2SoWpOCMi9d2qHmA7FAQL4dE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEf1H06Q/khN/2dsb2JhbABUp153rgKDFQ8BmwKGOgSSZpBU X-IronPort-AV: E=Sophos;i="4.65,534,1304294400"; d="scan'208";a="102432066" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2011 08:12: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 p6F8C7kP027619; Fri, 15 Jul 2011 08:12:07 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6F8C3g5011781; Fri, 15 Jul 2011 09:12:04 +0100 (BST) Message-ID: <4E1FF655.8090005@cisco.com> Date: Fri, 15 Jul 2011 09:12:05 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Shahram Davari References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 08:12:09 -0000 On 15/07/2011 01:03, Shahram Davari wrote: > > 3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well. > Now I know that it depends on your implementation, but just how many lines of code are we talking about here? The elements of this function that you would put in h/w do not seem complex. - Stewart From zhang.fei3@zte.com.cn Fri Jul 15 02:13:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B622021F86A2; Fri, 15 Jul 2011 02:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.219 X-Spam-Level: X-Spam-Status: No, score=-100.219 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZU7a9CGPHXx; Fri, 15 Jul 2011 02:13:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2EE21F86A0; Fri, 15 Jul 2011 02:13:39 -0700 (PDT) Received: from [10.30.18.203] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Fri, 15 Jul 2011 17:07:23 +0800 (CST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48642203882679; Fri, 15 Jul 2011 17:10:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2203882679; Fri, 15 Jul 2011 16:22:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6F8Mg8O005421; Fri, 15 Jul 2011 16:22:42 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: "pwe3@ietf.org" , MIME-Version: 1.0 X-KeepSent: C7F96C5D:251C819B-482578CE:002B6A4D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 15 Jul 2011 16:22:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-15 16:22:43, Serialize complete at 2011-07-15 16:22:43 Content-Type: multipart/alternative; boundary="=_alternative 002DFF46482578CE_=" X-MAIL: mse01.zte.com.cn p6F8Mg8O005421 Subject: [mpls] Changes to draft: http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 09:13:41 -0000 This is a multipart message in MIME format. --=_alternative 002DFF46482578CE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQgYWJvdXQgdGhlIE1QTFMtVFAg UFcgT0FNIGNvbmZpZ3VyYXRpb25zLCANCmJlbG93IGlzIHRoZSBsaW5rOg0KDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25maWctMDUgDQoN CkNvbXBhcmVkIHRvIGxhc3QgdmVyc2lvbiwgd2UgYWRkIG9uZSBzdWJzZWN0aW9uIDcuMS4xIHRv IGFkZHJlc3MgdGhlIA0KYmFja3dhcmQgY29tcGF0aWJpbGl0eSAodGhhbmsgR3JlZ6GiTHVjYSBh bmQgTWF0dGhldyBmb3IgdGhlIGNvbW1lbnRzKS4NCg0KSWYgYm90aCBvZiB0aGUgVC1QRXMgc3Vw cG9ydCB0aGUgQ0MtQ1YtUkRJIGZ1bmN0aW9uLCB0aGUgQkZEIGNvbmZpZ3VyYWl0b24gDQpwcm9k ZWN1cmUgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZDsgb3RoZXJ3aXNlIGlm IGF0IGxlYXN0IG5vdCANCm9mDQoNCnRoZW0gZG8gbm90IHN1cHBvcnQgdGhlIENDLUNWLVJESSBm dW50aW9uLCB0aGUgb2xkIFZDQ1YgQkZEIHdpbGwgYmUgDQpwZXJmb3JtZWQuDQoNCg0KVGhlIG90 aGVyIHJldmlzaW9ucyBhcmUgZWRpdG9yaWFsIGluIG5hdHVyZSwgcGxlYXNlIGNoZWNrIHRoZW0g Zm9yIG1vcmUgDQpkZXRhaWxzLg0KDQoNCkFueSBvdGhlciBjb21tZW50cyBhcmUgd2VsY29tZS4g Oi0pDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg== --=_alternative 002DFF46482578CE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSB1cGRhdGVkIHRoZSBk b2N1bWVudCBhYm91dCB0aGUNCk1QTFMtVFAgUFcgT0FNIGNvbmZpZ3VyYXRpb25zLCBiZWxvdyBp cyB0aGUgbGluazo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLW1wbHMtdHAtcHctb2Ft LWNvbmZpZy0wNQ0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5Db21wYXJlZCB0byBsYXN0IHZlcnNpb24sIHdlIGFkZCBvbmUNCnN1YnNlY3Rpb24gNy4x LjEgdG8gYWRkcmVzcyB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSAodGhhbmsgR3JlZ6GiTHVj YQ0KYW5kIE1hdHRoZXcgZm9yIHRoZSBjb21tZW50cykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBib3RoIG9mIHRoZSBULVBFcyBzdXBwb3J0IHRo ZSBDQy1DVi1SREkNCmZ1bmN0aW9uLCB0aGUgQkZEIGNvbmZpZ3VyYWl0b24gcHJvZGVjdXJlIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzDQphZG9wdGVkOyBvdGhlcndpc2UgaWYgYXQgbGVh c3Qgbm90IG9mPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGVtIGRvIG5vdCBzdXBwb3J0IHRoZSBDQy1DVi1SREkgZnVudGlvbiwNCnRoZSBvbGQgVkND ViBCRkQgd2lsbCBiZSBwZXJmb3JtZWQuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgb3RoZXIgcmV2aXNpb25zIGFyZSBlZGl0b3JpYWwg aW4NCm5hdHVyZSwgcGxlYXNlIGNoZWNrIHRoZW0gZm9yIG1vcmUgZGV0YWlscy48L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFueSBvdGhlciBj b21tZW50cyBhcmUgd2VsY29tZS4gOi0pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCg== --=_alternative 002DFF46482578CE_=-- From Rolf.Winter@neclab.eu Fri Jul 15 04:18:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6721F867A for ; Fri, 15 Jul 2011 04:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amg1Y3K6ys3H for ; Fri, 15 Jul 2011 04:18:40 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2221F85EC for ; Fri, 15 Jul 2011 04:18:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9624828000332; Fri, 15 Jul 2011 13:18:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUGzcWZKKu8t; Fri, 15 Jul 2011 13:18:39 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7698A2800032C; Fri, 15 Jul 2011 13:18:29 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.188]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 15 Jul 2011 13:18:29 +0200 From: Rolf Winter To: "stbryant@cisco.com" , "mpls@ietf.org" Thread-Topic: [mpls] Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01) Thread-Index: AQHMQl+LVg/mWvzwAkuOQTWLCWPLTZTtNuXA Date: Fri, 15 Jul 2011 11:18:29 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFE0E60@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D1CFDD776@DAPHNIS.office.hd> <4E1F48B6.7040802@cisco.com> In-Reply-To: <4E1F48B6.7040802@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 11:18:41 -0000 Stewart, Notation-wise we were following the identifiers draft which does also not i= nclude representations in ASCII art but in section 5 we indeed did forget t= o add it. I have drawn the ASCII art below, I hope it displays OK. This is = the MEG_ID format as described in section 5. The 16 bit you are referring t= o I believe (in section 6 though) is indeed another 16 bit following the ME= G_ID (MEG_ID::MEP_Index) to form the MEP_ID. If you would like me to extend= the ASCII art to also include these additional 16 bit please shout. Maybe some other pointers here, which we should have added to the document.= The characters are encoded according to recommendation T.50. Further, in c= ase the UMC space is not fully utilized by the operator the remaining space= is filled with NULL characters as per Recommendation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC cnt. | "/" | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC cnt. | UMC min | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC | "/" | CC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UMC max. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UMC cnt. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UMC cnt. | +-+-+-+-+-+-+-+-+ Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Donnerstag, 14. Juli 2011 21:51 > To: mpls@ietf.org > Subject: Re: [mpls] Identifiers following ITU-T conventions (was: > draft-win-mpls-tp-itu-t-identifiers-01) >=20 > Rolf >=20 > So the 16 bit identifier in section 5 is an additional identifier? >=20 > Please could you reduce the confusion by drawing up the proposed data > structure in octet/longword format as per traditional IETF > representation. >=20 > - Stewart >=20 >=20 > On 14/07/2011 20:16, Rolf Winter wrote: > > Hello, > > > > > > I changed the subject line since this is I think orthogonal to the > call for adoption. I also try to address a set of comments from > different people that have been raised in this one Email. > > > > The main discussion has been revolving around the actual format of > the MEG_ID, in particular the length of the whole ID and the length of > the operator-definable part. The length results from Y.1731 using 13 > bytes for MEG_IDs and the document is following ITU-T conventions after > all. So that is where the length comes from. If the WG decides that the > remaining UMC is not long enough then we need to define another > identifier. That's regular WG process I'd say. In either event this > document will be liaised with the ITU-T ensuring we follow the right > ITU-T conventions. > > > > Regarding the UMC. It is at least 4 characters long. If you restrict > yourself to alphanumeric you will have 36 states per character > resulting in 36^4 possible combinations which is around 1.6 million. I > think the sheer number might not the problem but rather the structure, > i.e. existing structures might not fit into these 4 characters and > again, the WG needs to figure this out. > > > > The need for a delimiter is based on the fact that you have three > fields, two of which are of variable length. Let me illustrate this > with an example to show that the delimiter is needed independent of the > ordering. (and yes there are other ways to deal with this which I'd be > happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take > also operator "C" and operator "CD". If "C" decides to use a UMC "DE" > and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A > delimiter will solve this issue. The same principle applies to the > ordering ICC:CC:UMC only here this could happen even with different > country codes but if you want to be 100% sure that such a situation > cannot arise, then you need another token in the ID (or used fixed > sized fields or use another trick...). > > > > Generally, there have been comments that the adoption call is either > too early or the content should go into the identifiers draft. Well, > the content in fact has been in that document. So, in principle the > need for this already has been acked by the WG. This draft addresses > the shortcoming which caused the content to be removed. That is why I > asked the chairs to do the poll now (so please don't blame Ross, blame > me). > > > > Anyway, I am happy to discuss this further. > > > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Fri Jul 15 04:56:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96C21F86CA for ; Fri, 15 Jul 2011 04:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz7QXNVfTfVo for ; Fri, 15 Jul 2011 04:56:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2721F86C4 for ; Fri, 15 Jul 2011 04:56:14 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C645E1CF70EA; Fri, 15 Jul 2011 07:56:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4E1FF655.8090005@cisco.com> Date: Fri, 15 Jul 2011 07:56:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1084) Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 11:56:15 -0000 It is less efficient not really due to the duplication, but = because the SW path is a relatively very slow path for processing CV packets. It is also a = relatively less scaleable one as well as compared to doing in HW. So the a number of lines of = processing or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >>=20 >> 3) Process CC in HW and CV in SW, which is not efficient since we are = duplicating the HW logic in SW as well. >>=20 > Now I know that it depends on your implementation, but just how many = lines of code are we talking about here? > The elements of this function that you would put in h/w do not seem = complex. >=20 > - Stewart >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From hideki.endo.es@hitachi.com Fri Jul 15 05:17:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96E21F868A; Fri, 15 Jul 2011 05:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0h1NAAMESt4; Fri, 15 Jul 2011 05:17:35 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB3521F8681; Fri, 15 Jul 2011 05:17:34 -0700 (PDT) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 3EE9C37AC4; Fri, 15 Jul 2011 21:17:33 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id p6FCHXSn026561; Fri, 15 Jul 2011 21:17:33 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p6FCHW6W029918; Fri, 15 Jul 2011 21:17:32 +0900 X-AuditID: b753bd60-a1e7aba0000050a4-ac-4e202fdc2e3e Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 138108B0306; Fri, 15 Jul 2011 21:17:32 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p6FCHWc29958168; Fri, 15 Jul 2011 21:17:32 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Fri, 15 Jul 2011 21:17:10 +0900 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB872@USPITMAIL01.ecitele.c> Priority: normal Importance: normal X400-Content-Identifier: X4E202FB700000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110715211655MD7] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Last Call:(Proactive Connecti X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 12:17:39 -0000 Hi Robert, Thank you very much for your reply, and I am sorry for my late response. See inline, marked with [HE]; > >________________________________________ >From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of hideki.endo.es@hitachi.com [hideki.endo.es@hitachi.com] >Sent: Thursday, July 14, 2011 7:22 AM >To: ietf@ietf.or; mpls@ietf.org >Subject: Re: [mpls] Last Call: (Proactive Connectivit > >>The changes in this version have massive impact for CC/CV/RDI implementation. >>We, venders, have kept making efforts on interoperability test again and again. >>These changes spoil this effort. > >>Especially, revival of Poll/Final sequence doesn't make sense. >>Originally, in my understanding, Poll/Final sequence was excluded from this draft >>to avoid making HW implementation difficult. > >[RR] preventing a peer from modifying the rate once the initial target rate was achieved i.e arbitrary re-negotiation was and is excluded, that was the "problem" the group consensus was to solve. > > >However P/F is needed to get from the initial 1 per second default rate to the desired rate. This and the rational for an initial P/F were discussed in detail back in March /April. [HE]My understanding is far from yours. The cc-cv-rdi-03 said "Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.". In my understanding, this meant that Poll/Final Sequence MUST NOT be used for GAL/G-ACh. In other words, GAL/G-ACh MUST work well without Poll/Final Sequence in the case of getting from initial state. I think this was the group consensus. If the consensus was only for re-negotiation, why was P/F excluded from GAL/G-ACh? > > >>Even though it was difficult to change CC interval arbitrary, >>the problem should be solved by defining how to transit DOWN/INIT state to UP state. > >[RR] There is no problem in defining how to transit from Down/Init to UP state, it's covered in the existing state machine and is not changed. [HE]Sorry for lack of explanation. I meant the interval change timing should be defined in the case of transition DOWN/INIT to UP state without P/F sequence for GAL/G-ACh. BR, Hideki > >Cheers > >Rob > > >>The direction which reached consensus once should NOT be changed easily >>in order to respond to the market requirements. > >>IMO, such major changes should NOT be added right before becoming RFC. > >>I found at least four major/minor changes as follows; >>1)Revival of Poll/Final sequence >>2)Change of MEP ID formats >>3)Change of Diag. Code >>4)Change of CV interleaved definition > >BR, >Hideki > > >> >>The IESG has received a request from the Multiprotocol Label Switching WG >>(mpls) to consider the following document: >>- 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> 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 2011-07-14. 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 >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >>The file can be obtained via >>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >>IESG discussion can be tracked via >>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >>No IPR declarations have been submitted directly on this I-D. >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls >> >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >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. > > From davarish@yahoo.com Fri Jul 15 05:24:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4621F86E9 for ; Fri, 15 Jul 2011 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9+9bAg-OQFD for ; Fri, 15 Jul 2011 05:24:23 -0700 (PDT) Received: from nm25.access.bullet.mail.mud.yahoo.com (nm25.access.bullet.mail.mud.yahoo.com [66.94.237.90]) by ietfa.amsl.com (Postfix) with SMTP id 1796221F86DD for ; Fri, 15 Jul 2011 05:24:23 -0700 (PDT) Received: from [66.94.237.126] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 12:24:22 -0000 Received: from [66.94.237.98] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 12:24:22 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 12:24:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 758472.48255.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 61471 invoked by uid 60001); 15 Jul 2011 12:24:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310732662; bh=VzLZEApnXJtI2D+OLTzv1Yi75jj/TbKY//aOP07G6zg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=o4WLp4vbjdz7V3b5gE0GnYsCkbL16J6jF5ghKAseerMzI2CMaoRdKuTBa00DqyaOwSf1X14j6UnokhdYBlWBVnn5k/0fPEb7VMFYqF9AJKWe4dl0IAtGlKQTe6o11QkmSCWQRBMR7lY0RvzNC7wqAPQuZT7PXoez7WKYNpoQS/o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ulXecGgWLbgNFKq/A4YrIFrmVnuYqqGcZSxPO+rD+qukWT3vbttAKmb1H+eWYqOkRmzNIedg1iz9zv2lJGnjJzSR8LyGjY/bhHXJkHgPfCML8EbdXgjBzhFsmF57tLUZE/3RV75AKEPJUAQhY/7MkysMVHuGqA477J1le53RkBQ=; X-YMail-OSG: PIErzwcVM1l5FRClLB.4JkWkJd65c7f16lw78DUv3e9uyC8 XPwfDpvDzP5AxQpir_gEac6hOjXwz3.2lRr6rBVutkPSRkYQDXlEtuyHmFo8 4I65BUBOzq5BBYRgOu5zUkP74Zx4gQsqJYqTN5QA5icxopzqK4kwBtfFw0SR wf6hAB7lBzQlZVTsyR9mjHs.81bXib85kM8L4BZ8Ml5L_vajo.FmxvklPSwl 8T5KShp4rBKhkWU1upkmtPSyuzwKGmJlHWKMmJzvASsY4v.TICzHYt9DywGx Yc5.gACPHNEgX6WvGZSc6nlgvZmZ_CMT6.iRdmAbVwaW79_HN0lCCD.bSNHq D6mGnPAuQeB2ub9ytNAasRZwJcKogqe6oZBbHC.A99YwzPCIKlrlOaCmfdQw jWw2R1Ro3p_u5 Received: from [98.248.36.11] by web88406.mail.re1.yahoo.com via HTTP; Fri, 15 Jul 2011 05:24:21 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com> Message-ID: <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> Date: Fri, 15 Jul 2011 05:24:21 -0700 (PDT) From: "S. Davari" To: Thomas Nadeau , stbryant@cisco.com In-Reply-To: <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-826922899-1310732661=:58009" Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 12:24:23 -0000 --0-826922899-1310732661=:58009 Content-Type: text/plain; charset=us-ascii Tom is is correct. I meant to say not scalable. Shahram ________________________________ From: Thomas Nadeau To: stbryant@cisco.com Cc: "ietf@ietf.or" ; "mpls@ietf.org" Sent: Fri, July 15, 2011 4:56:13 AM Subject: Re: [mpls] Last Call:(Proactive Connectivity) It is less efficient not really due to the duplication, but because the SW path is a relatively very slow path for processing CV packets. It is also a relatively less scaleable one as well as compared to doing in HW. So the a number of lines of processing or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >> >> 3) Process CC in HW and CV in SW, which is not efficient since we are >>duplicating the HW logic in SW as well. >> > Now I know that it depends on your implementation, but just how many lines of >code are we talking about here? > The elements of this function that you would put in h/w do not seem complex. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --0-826922899-1310732661=:58009 Content-Type: text/html; charset=us-ascii
Tom is is correct. I meant to say not scalable.

Shahram


From: Thomas Nadeau <tnadeau@lucidvision.com>
To: stbryant@cisco.com
Cc: "ietf@ietf.or" <ietf@ietf.or>; "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)


    It is less efficient not really due to the duplication, but because the SW path is
a relatively very slow path for processing CV packets. It is also a relatively less scaleable
one as well as compared to doing in HW. So the a number of lines of processing or duplication
of code therein is a bit of a red herring if you ask me.

    --Tom



On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> On 15/07/2011 01:03, Shahram Davari wrote:
>>
>> 3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well.
>>
> Now I know that it depends on your implementation, but just how many lines of code are we talking about here?
> The elements of this function that you would put in h/w do not seem complex.
>
> - Stewart
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--0-826922899-1310732661=:58009-- From curtis@occnc.com Fri Jul 15 06:47:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24F421F859C for ; Fri, 15 Jul 2011 06:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RALwx6LZGhUj for ; Fri, 15 Jul 2011 06:47:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0E8C21F8576 for ; Fri, 15 Jul 2011 06:47:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FDkvY9087161; Fri, 15 Jul 2011 09:46:57 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151346.p6FDkvY9087161@harbor.orleans.occnc.com> To: "Kyung-Yeop Hong (hongk)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 17:21:14 CDT." <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> Date: Fri, 15 Jul 2011 09:46:57 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 13:47:04 -0000 In message <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> "Kyung-Yeop Hong (hongk)" writes: > > Rolf et al, > > As the content had been in the draft-ietf-mpls-tp-identifiers and > removed due to the shortcoming until resolved, I propose to discuss and > figure out the resolution first before the adoption call. > > I also believe the content should go back into the identifiers draft > once resolved. > > Regards, > KY +1 Yes and either way all of the issues have to be resolved before it is added back or proceeds on its own. A means to identify MPLS tunnels and LSP are needed. All of the named entities listed in draft-ietf-mpls-tp-identifiers-01.txt need to be accomodated. If the name space doesn't match the existing name spaces in OSPF-TE, ISIS-TE, and RSVP-TE (ie: doesn't fit into existing GMPLS work) which are based on IPv4 and IPv6, before accepting the work the entire effort must be scoped. A second limited functionality option is to acknowledge that ICC/CC style Global_ID is not applicable if a control plane is used. The MPLS WG and the IETF would need to decide whether to go forward with a lame approach, not something IETF tends to do. Mixing IPv4 and IPv6 identifiers in the control plane and ICC/CC in the OAM makes little sense. If ICC/CC is needed for the benefit of an antiquated OSS system, then a management shim, either on the OSS side or the NE side or in a management proxy would be preferable. It is worth noting that the 5 characters in ICC/CC can be fit into four bytes since only 36 values are used per character. There are 2 bits left over. 5 characters of 36 bits can be packet into 26 bits, leaving 6 bits unused. If this is acceptable, then there are two Global_ID spaces, both fitting into four bytes. If 1/64th of the four byte AS space can be set aside, the ICC/CC space can be fit into the AS space, setting the 6 unused bits to a fixed value, perhaps all ones, if ICC/CC numbering is used. That could be proposed within the IDR WG or somewhere in the OPS area. Just as easily as the microprocessor in network equipment or management software displays the AS number in its current notation (typically as two 16 bit decimal values), the ICC encoding can be converted to ASCII ICC/CC representation for display purposes. Curtis > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant (stbryant) > Sent: Thursday, July 14, 2011 3:51 PM > To: mpls@ietf.org > Subject: Re: [mpls] Identifiers following ITU-T conventions > (was:draft-win-mpls-tp-itu-t-identifiers-01) > > Rolf > > So the 16 bit identifier in section 5 is an additional identifier? > > Please could you reduce the confusion by drawing up the proposed data > structure in octet/longword format as per traditional IETF > representation. > > - Stewart > > > On 14/07/2011 20:16, Rolf Winter wrote: > > Hello, > > > > > > I changed the subject line since this is I think orthogonal to the > call for adoption. I also try to address a set of comments from > different people that have been raised in this one Email. > > > > The main discussion has been revolving around the actual format of the > MEG_ID, in particular the length of the whole ID and the length of the > operator-definable part. The length results from Y.1731 using 13 bytes > for MEG_IDs and the document is following ITU-T conventions after all. > So that is where the length comes from. If the WG decides that the > remaining UMC is not long enough then we need to define another > identifier. That's regular WG process I'd say. In either event this > document will be liaised with the ITU-T ensuring we follow the right > ITU-T conventions. > > > > Regarding the UMC. It is at least 4 characters long. If you restrict > yourself to alphanumeric you will have 36 states per character resulting > in 36^4 possible combinations which is around 1.6 million. I think the > sheer number might not the problem but rather the structure, i.e. > existing structures might not fit into these 4 characters and again, the > WG needs to figure this out. > > > > The need for a delimiter is based on the fact that you have three > fields, two of which are of variable length. Let me illustrate this with > an example to show that the delimiter is needed independent of the > ordering. (and yes there are other ways to deal with this which I'd be > happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take > also operator "C" and operator "CD". If "C" decides to use a UMC "DE" > and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A > delimiter will solve this issue. The same principle applies to the > ordering ICC:CC:UMC only here this could happen even with different > country codes but if you want to be 100% sure that such a situation > cannot arise, then you need another token in the ID (or used fixed sized > fields or use another trick...). > > > > Generally, there have been comments that the adoption call is either > too early or the content should go into the identifiers draft. Well, the > content in fact has been in that document. So, in principle the need for > this already has been acked by the WG. This draft addresses the > shortcoming which caused the content to be removed. That is why I asked > the chairs to do the poll now (so please don't blame Ross, blame me). > > > > Anyway, I am happy to discuss this further. > > > > > > Best, > > > > Rolf From Rolf.Winter@neclab.eu Fri Jul 15 07:43:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60CF21F856C for ; Fri, 15 Jul 2011 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LamvIS8ZySrl for ; Fri, 15 Jul 2011 07:43:25 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B29FB21F8513 for ; Fri, 15 Jul 2011 07:43:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0CBEC28000330; Fri, 15 Jul 2011 16:43:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYNOCg86JCjt; Fri, 15 Jul 2011 16:43:23 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E351C2800032F; Fri, 15 Jul 2011 16:43:03 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.188]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 15 Jul 2011 16:43:03 +0200 From: Rolf Winter To: "curtis@occnc.com" , "Kyung-Yeop Hong (hongk)" Thread-Topic: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) Thread-Index: AQHMQvWpcHS3/6FA90aoGUgf+y4zY5TtcKZw Date: Fri, 15 Jul 2011 14:43:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFE210B@DAPHNIS.office.hd> References: Your message of "Thu, 14 Jul 2011 17:21:14 CDT." <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD-103.cisco.com> <201107151346.p6FDkvY9087161@harbor.orleans.occnc.com> In-Reply-To: <201107151346.p6FDkvY9087161@harbor.orleans.occnc.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:43:29 -0000 Curtis, Interesting encoding but the ICC is up to 6 characters long and the CC is a= nother 2. You could do the CC ones in 5 bits/character but you'd still lack= bits. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Freitag, 15. Juli 2011 15:47 > To: Kyung-Yeop Hong (hongk) > Cc: mpls@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft- > win-mpls-tp-itu-t-identifiers-01) >=20 >=20 > In message <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD- > 103.cisco.com> > "Kyung-Yeop Hong (hongk)" writes: > > > > Rolf et al, > > > > As the content had been in the draft-ietf-mpls-tp-identifiers and > > removed due to the shortcoming until resolved, I propose to discuss > and > > figure out the resolution first before the adoption call. > > > > I also believe the content should go back into the identifiers draft > > once resolved. > > > > Regards, > > KY >=20 >=20 > +1 >=20 > Yes and either way all of the issues have to be resolved before it is > added back or proceeds on its own. >=20 > A means to identify MPLS tunnels and LSP are needed. All of the named > entities listed in draft-ietf-mpls-tp-identifiers-01.txt need to be > accomodated. If the name space doesn't match the existing name spaces > in OSPF-TE, ISIS-TE, and RSVP-TE (ie: doesn't fit into existing GMPLS > work) which are based on IPv4 and IPv6, before accepting the work the > entire effort must be scoped. >=20 > A second limited functionality option is to acknowledge that ICC/CC > style Global_ID is not applicable if a control plane is used. The > MPLS WG and the IETF would need to decide whether to go forward with a > lame approach, not something IETF tends to do. >=20 > Mixing IPv4 and IPv6 identifiers in the control plane and ICC/CC in > the OAM makes little sense. If ICC/CC is needed for the benefit of an > antiquated OSS system, then a management shim, either on the OSS side > or the NE side or in a management proxy would be preferable. >=20 > It is worth noting that the 5 characters in ICC/CC can be fit into > four bytes since only 36 values are used per character. There are 2 > bits left over. 5 characters of 36 bits can be packet into 26 bits, > leaving 6 bits unused. If this is acceptable, then there are two > Global_ID spaces, both fitting into four bytes. If 1/64th of the four > byte AS space can be set aside, the ICC/CC space can be fit into the > AS space, setting the 6 unused bits to a fixed value, perhaps all > ones, if ICC/CC numbering is used. That could be proposed within the > IDR WG or somewhere in the OPS area. Just as easily as the > microprocessor in network equipment or management software displays > the AS number in its current notation (typically as two 16 bit decimal > values), the ICC encoding can be converted to ASCII ICC/CC > representation for display purposes. >=20 > Curtis >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Stewart Bryant (stbryant) > > Sent: Thursday, July 14, 2011 3:51 PM > > To: mpls@ietf.org > > Subject: Re: [mpls] Identifiers following ITU-T conventions > > (was:draft-win-mpls-tp-itu-t-identifiers-01) > > > > Rolf > > > > So the 16 bit identifier in section 5 is an additional identifier? > > > > Please could you reduce the confusion by drawing up the proposed data > > structure in octet/longword format as per traditional IETF > > representation. > > > > - Stewart > > > > > > On 14/07/2011 20:16, Rolf Winter wrote: > > > Hello, > > > > > > > > > I changed the subject line since this is I think orthogonal to the > > call for adoption. I also try to address a set of comments from > > different people that have been raised in this one Email. > > > > > > The main discussion has been revolving around the actual format of > the > > MEG_ID, in particular the length of the whole ID and the length of > the > > operator-definable part. The length results from Y.1731 using 13 > bytes > > for MEG_IDs and the document is following ITU-T conventions after all. > > So that is where the length comes from. If the WG decides that the > > remaining UMC is not long enough then we need to define another > > identifier. That's regular WG process I'd say. In either event this > > document will be liaised with the ITU-T ensuring we follow the right > > ITU-T conventions. > > > > > > Regarding the UMC. It is at least 4 characters long. If you > restrict > > yourself to alphanumeric you will have 36 states per character > resulting > > in 36^4 possible combinations which is around 1.6 million. I think > the > > sheer number might not the problem but rather the structure, i.e. > > existing structures might not fit into these 4 characters and again, > the > > WG needs to figure this out. > > > > > > The need for a delimiter is based on the fact that you have three > > fields, two of which are of variable length. Let me illustrate this > with > > an example to show that the delimiter is needed independent of the > > ordering. (and yes there are other ways to deal with this which I'd > be > > happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take > > also operator "C" and operator "CD". If "C" decides to use a UMC "DE" > > and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A > > delimiter will solve this issue. The same principle applies to the > > ordering ICC:CC:UMC only here this could happen even with different > > country codes but if you want to be 100% sure that such a situation > > cannot arise, then you need another token in the ID (or used fixed > sized > > fields or use another trick...). > > > > > > Generally, there have been comments that the adoption call is > either > > too early or the content should go into the identifiers draft. Well, > the > > content in fact has been in that document. So, in principle the need > for > > this already has been acked by the WG. This draft addresses the > > shortcoming which caused the content to be removed. That is why I > asked > > the chairs to do the poll now (so please don't blame Ross, blame me). > > > > > > Anyway, I am happy to discuss this further. > > > > > > > > > Best, > > > > > > Rolf > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Robert.Rennison@ecitele.com Fri Jul 15 08:42:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EBF21F891D for ; Fri, 15 Jul 2011 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMNgIcmOKx9M for ; Fri, 15 Jul 2011 08:42:02 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id C9AAA21F8794 for ; Fri, 15 Jul 2011 08:42:00 -0700 (PDT) X-AuditID: 3f5e7f87-b7b61ae000005fea-78-4e20856499e8 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 85.40.24554.465802E4; Fri, 15 Jul 2011 14:22:29 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Fri, 15 Jul 2011 11:41:59 -0400 From: Robert Rennison To: "S. Davari" , Thomas Nadeau , "stbryant@cisco.com" Date: Fri, 15 Jul 2011 11:41:59 -0400 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxC6iox+xVGtqnDQsmBP8RNg7cTkwAD4wU0 Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com>, <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> In-Reply-To: <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2VTe0hTURj33LvHdbW6zsdOUng5UZQ127JgpesBhfZHJSkEhdp1O263tru1 e43yn6Ty0QgqkrIlpDSLMrSyolCiFlRKWkkFmWmmUfbAEiul573eMqPz1+98v8f3cfgORRpq NfEUx4vYz7NupNGpdBERaSZczKwx327TWW+82gWsHTWn1da2l5XA2nOoXbtMlV7+9bw6PRQa IdIv9YW06cHgTSJDtaEIpLI87xVZETMOLNhtKMPPbWPtOxDDOWzIghifm7VjD+ZFG2J9Psw7 0BId899JlWQcz2De7nVwvNOGVmWuNVmtCxeZLGjJzOmW5BRdlosTGGzysJyb8WBBYJ2YkSqb LpKu603DpK982vaed11kEbhkDACKgvQCeO3uygCIlGAcvN9VrwkAHWWgGwGs2VdKKJd9AHZW hFWySkMnw3ODrWoZx9CFsPnFEbUcRNLTYcuzqXJZRc+Alw/+1Mo4ms6GL/qfEIo8B3Y/bgUK ng/DJc0aGevpDNhwaPh342I1PHaie9QQSafBb5UDo32BNN2XlrOjdZI2wo6+44QyNQ1DTfdI BcfC/t4fakUfCztL64GinwurGgc1Cp4DT1a/JZXGUbD5aJ/qAIgLjosNjrMEx1mC4yxVQHUG xBUIPk7M8zjNliRs50Tsxkl2r+cCkJZlac7O0itgf3liGEyhCBSrf5vDrDFMyvM6drhYwZXr L3BjIQys0msdJOMn2L3SovFibrLZ/M8FGfVXy0KrDbRT2p0tGPuw/491KkUhqP8kx0b5sRNv z+fc4l+aoCLDAFITUYx+dq6k0Qs+1iNwToVvAVPijXogE7RMuAr4Me8bYKQAitZ3ydETpR8w 5nojBRJSYN3iaXKgtM9jVHwRKP7w+vPe2u7oebdn+beWRdZYen0N2vY5NwxtnVpPRRtq6X4Q M0zWVqG6RNuPhAws8uxm3TrjqVvEEHjeZV5x+Cn13mRYV7+tJyUpUPV0xVD1wJ3DAw8rg3hP oGTGx51RG0cSlvsLd2dunpx/daTDmdW4aULjo/XfowrZWJp4lI1Ugou1JJJ+gf0F1AiBer4D AAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:42:03 -0000 Se we're in agreement that there's no duplication of effort required; good. I'll agree at a general level with a part of Tom's overall statement that > It is also a relatively less scaleable >one as well as compared to doing= in HW. A HW implementation of a protocol can be made to be more scaleable than a SW= only one, ok that's agreed. >From implementation experience with shipping scaleable and interoperable B= FD and has also been pointed out by Mahesh, many vendors implement a combin= ed approach, one needs software to manage the HW assist and the overall stat= e machines, so a blended approach is usually done using HW for heavy lifting= , and distributing SW functions where necessary / desirable. The division of this work and the decision of what to accelerate with HW ass= ist. is a function of where in the network the equipment is situated and the= anticipated scale on it, these are descions made by vendors and born from e= xperiences with implementations. However one can if, desired accelerate aspects of CV with "HW" assist too= , it's a cos/ scale tradeoff that an implementation will make. One could hav= e HW assist to send the one per second CV messages, and one could add a "HW= " function to match the CV messages if desired. Would the RX match portion be more efficient with no TLVs for the various i= dentifiers ? Yes. Would the extra efficiency make a substantial difference to the HW cost, I d= oubt it. Is this a hard requirement ? Not that I've seen. Note: all of this talk of HW vs SW is also not precise enough, vendors have= so called Fast-path logic to play with too. so HW and SW are not necessaril= y sharp boundaries. But this is the stuff of a more general exposition and n= ot germane to last call comments on the specific draft on the table. Cheers Rob ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [= davarish@yahoo.com] Sent: Friday, July 15, 2011 8:24 AM To: Thomas Nadeau; stbryant@cisco.com Cc: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proactiv= e Connectivity) Tom is is correct. I meant to say not scalable. Shahram ________________________________ From: Thomas Nadeau To: stbryant@cisco.com Cc: "ietf@ietf.or" ; "mpls@ietf.org" Sent: Fri, July 15, 2011 4:56:13 AM Subject: Re: [mpls] Last Call:(Proactiv= e Connectivity) It is less efficient not really due to the duplication, but because the= SW path is a relatively very slow path for processing CV packets. It is also a relative= ly less scaleable one as well as compared to doing in HW. So the a number of lines of processi= ng or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >> >> 3) Process CC in HW and CV in SW, which is not efficient since we are dup= licating the HW logic in SW as well. >> > Now I know that it depends on your implementation, but just how many lines= of code are we talking about here? > The elements of this function that you would put in h/w do not seem comple= x. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From davarish@yahoo.com Fri Jul 15 08:50:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368D21F880D for ; Fri, 15 Jul 2011 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfYVyPxyBRzV for ; Fri, 15 Jul 2011 08:50:15 -0700 (PDT) Received: from nm12-vm0.access.bullet.mail.mud.yahoo.com (nm12-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.11]) by ietfa.amsl.com (Postfix) with SMTP id AEA2121F899D for ; Fri, 15 Jul 2011 08:50:14 -0700 (PDT) Received: from [66.94.237.126] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 15:50:14 -0000 Received: from [66.94.237.107] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 15:50:14 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 15:50:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 323647.95770.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 41856 invoked by uid 60001); 15 Jul 2011 15:50:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310745013; bh=HN9n68bsT+uw9X1pOc+UA9whqBu4b4twBHMArZuv+bU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BzZWq4thEXEfakk/WiXBG4bxgdziClEYCfImP4DGpDIeHLjgMDqWuFUiHDAHnm3PDWU0Szrr0nm4rlVyZelJbGk0gEGooNWmzMZb+bf6P0mVRQjQ03JCDulxtfz9ATEG/+HgN+vM73S8/eS1pF4uSheGD8Z8HXCEk3mmC1RqEUc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bh4UKvVzP01OeCJsMLFsh3lVF1x1yH/GqJXSxrNz+DXcdIeklUyMSG2+OPTMmmVJ9o2fnZq+fYX++uKn1ri44dBjkzyOP3uuaVdD8iZCQoP5301emRnx6s5jILqaLZ5kWkeIE/QjKJ/7ekd/Uuklt1mLFu+FZDMztFwU4Ae0/v0=; X-YMail-OSG: uSU5_.wVM1lgEdfqc4tWtoGhv4flJKNwtfqz_Nf_0xefkDa MN1vLklPj9V8djS4yvCpUXrRkCXjcSdMTtRHkszPynguI1Qgp.yM_Pt8dbxl p1zbyS707xo4QUOfoPmqRWV2ypIqdpx96Vtc.qqKUkr3zYyQT2KumkFiOgYT q9VrIGpUtKVfPdTMIkClYttDW1oelSii1Bqm5TcE9S9nG5_MjV4vDayu.API Uk5De0lZvhTU3.dKgJ_bQilXuY7P0enDxTqyeJNqc3wr_iRU7ReKYQ2MUX2Q vWIGQptaodKz6uReN2ypLvpJyTgZJFvobajSWR1OuAJV_pP7xzH7pz2rkT.n bJIpOt_mSwkvDElrTB95Noich1Qo7MM2KiEVaCBhr6yOlvd_gIOAQpErxGvu DAUxpz_px1oEJ Received: from [98.248.36.11] by web88407.mail.re1.yahoo.com via HTTP; Fri, 15 Jul 2011 08:50:13 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com>, <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> Message-ID: <1310745013.23819.YahooMailRC@web88407.mail.re1.yahoo.com> Date: Fri, 15 Jul 2011 08:50:13 -0700 (PDT) From: "S. Davari" To: Robert Rennison , Thomas Nadeau , "stbryant@cisco.com" In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2119043292-1310745013=:23819" Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:50:15 -0000 --0-2119043292-1310745013=:23819 Content-Type: text/plain; charset=us-ascii Robert, Forget about HW and SW. The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it. I suggest either running CC or CV and of they are run together they should be 2 separate independent BFD flow. -Shahram ________________________________ From: Robert Rennison To: S. Davari ; Thomas Nadeau ; "stbryant@cisco.com" Cc: "mpls@ietf.org" Sent: Fri, July 15, 2011 8:41:59 AM Subject: RE: [mpls] Last Call:(Proactive Connectivity) Se we're in agreement that there's no duplication of effort required; good. I'll agree at a general level with a part of Tom's overall statement that > It is also a relatively less scaleable >one as well as compared to doing in >HW. A HW implementation of a protocol can be made to be more scaleable than a SW only one, ok that's agreed. >From implementation experience with shipping scaleable and interoperable BFD and has also been pointed out by Mahesh, many vendors implement a combined approach, one needs software to manage the HW assist and the overall state machines, so a blended approach is usually done using HW for heavy lifting, and distributing SW functions where necessary / desirable. The division of this work and the decision of what to accelerate with HW assist. is a function of where in the network the equipment is situated and the anticipated scale on it, these are descions made by vendors and born from experiences with implementations. However one can if, desired accelerate aspects of CV with "HW" assist too, it's a cos/ scale tradeoff that an implementation will make. One could have HW assist to send the one per second CV messages, and one could add a "HW" function to match the CV messages if desired. Would the RX match portion be more efficient with no TLVs for the various identifiers ? Yes. Would the extra efficiency make a substantial difference to the HW cost, I doubt it. Is this a hard requirement ? Not that I've seen. Note: all of this talk of HW vs SW is also not precise enough, vendors have so called Fast-path logic to play with too. so HW and SW are not necessarily sharp boundaries. But this is the stuff of a more general exposition and not germane to last call comments on the specific draft on the table. Cheers Rob ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [davarish@yahoo.com] Sent: Friday, July 15, 2011 8:24 AM To: Thomas Nadeau; stbryant@cisco.com Cc: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proactive Connectivity) Tom is is correct. I meant to say not scalable. Shahram ________________________________ From: Thomas Nadeau To: stbryant@cisco.com Cc: "ietf@ietf.or" ; "mpls@ietf.org" Sent: Fri, July 15, 2011 4:56:13 AM Subject: Re: [mpls] Last Call:(Proactive Connectivity) It is less efficient not really due to the duplication, but because the SW path is a relatively very slow path for processing CV packets. It is also a relatively less scaleable one as well as compared to doing in HW. So the a number of lines of processing or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >> >> 3) Process CC in HW and CV in SW, which is not efficient since we are >>duplicating the HW logic in SW as well. >> > Now I know that it depends on your implementation, but just how many lines of >code are we talking about here? > The elements of this function that you would put in h/w do not seem complex. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls 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. --0-2119043292-1310745013=:23819 Content-Type: text/html; charset=us-ascii
Robert,

Forget about HW and SW. The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it. I suggest either running CC or CV and of they are run together they should be 2 separate independent BFD flow.

-Shahram


From: Robert Rennison <Robert.Rennison@ecitele.com>
To: S. Davari <davarish@yahoo.com>; Thomas Nadeau <tnadeau@lucidvision.com>; "stbryant@cisco.com" <stbryant@cisco.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 8:41:59 AM
Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Se we're in agreement that there's no duplication of effort required; good.

I'll agree at a general level with a part of  Tom's overall statement that

>  It is also a relatively less scaleable >one as well as compared to doing in HW.

A HW implementation of a protocol can be made to be more scaleable than a SW only one, ok that's agreed.


From  implementation experience with shipping scaleable and interoperable  BFD and has also  been pointed out by Mahesh, many vendors implement a combined approach, one needs software to manage the HW assist and the overall state machines, so a blended approach is usually done using HW for heavy lifting,  and distributing SW functions where necessary / desirable.

The division of this work and the decision of what to accelerate with HW assist. is a function of where in the network the equipment is situated and the anticipated scale on it, these are descions made by vendors and born from experiences with implementations.

However one can if,  desired  accelerate aspects of CV  with "HW" assist too, it's a cos/ scale tradeoff that an implementation will make. One could have HW assist to send the one per second CV messages, and one could  add a "HW"  function to  match the CV messages if desired.

Would  the RX match portion be more efficient with no TLVs for the various identifiers  ? Yes.
Would the extra efficiency make a substantial difference to the HW cost, I doubt it.
Is this a hard requirement ? Not that I've seen.

Note: all of this talk of HW vs SW is also not precise enough, vendors have so called Fast-path logic to play with too. so HW and SW are not necessarily sharp boundaries. But this is the stuff of a more general exposition and not germane to last call comments on the specific draft on the table.



Cheers

Rob

________________________________________
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [davarish@yahoo.com]
Sent: Friday, July 15, 2011 8:24 AM
To: Thomas Nadeau; stbryant@cisco.com
Cc: ietf@ietf.or; mpls@ietf.org
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive  Connectivity)

Tom is is correct. I meant to say not scalable.

Shahram


________________________________
From: Thomas Nadeau <tnadeau@lucidvision.com>
To: stbryant@cisco.com
Cc: "ietf@ietf.or" <ietf@ietf.or>; "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)


    It is less efficient not really due to the duplication, but because the SW path is
a relatively very slow path for processing CV packets. It is also a relatively less scaleable
one as well as compared to doing in HW. So the a number of lines of processing or duplication
of code therein is a bit of a red herring if you ask me.

    --Tom



On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> On 15/07/2011 01:03, Shahram Davari wrote:
>>
>> 3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well.
>>
> Now I know that it depends on your implementation, but just how many lines of code are we talking about here?
> The elements of this function that you would put in h/w do not seem complex.
>
> - Stewart
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org<mailto:mpls@ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls
>

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


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.

--0-2119043292-1310745013=:23819-- From tnadeau@lucidvision.com Fri Jul 15 08:52:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C290B21F8A30 for ; Fri, 15 Jul 2011 08:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOkyljIrjmgu for ; Fri, 15 Jul 2011 08:52:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 762DC21F8A23 for ; Fri, 15 Jul 2011 08:52:12 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B9E3D1CF8548; Fri, 15 Jul 2011 11:52:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21--422033825 From: Thomas Nadeau In-Reply-To: <1310745013.23819.YahooMailRC@web88407.mail.re1.yahoo.com> Date: Fri, 15 Jul 2011 11:52:11 -0400 Message-Id: <97E700BD-DBB4-4841-B550-A1E151E99F9B@lucidvision.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com>, <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> <1310745013.23819.YahooMailRC@web88407.mail.re1.yahoo.com> To: "S. Davari" X-Mailer: Apple Mail (2.1084) Cc: "mpls@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:52:13 -0000 --Apple-Mail-21--422033825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While I personally agree, I'd leave how it is actually run up to = the operators. They might know a thing or two about running their = networks. *) --Tom > Robert, >=20 > Forget about HW and SW. The mix of CC and CV makes any implementation = complex. I don't see any significant benefit in it. I suggest either = running CC or CV and of they are run together they should be 2 separate = independent BFD flow. >=20 > -Shahram >=20 >=20 > From: Robert Rennison > To: S. Davari ; Thomas Nadeau = ; "stbryant@cisco.com" > Cc: "mpls@ietf.org" > Sent: Fri, July 15, 2011 8:41:59 AM > Subject: RE: [mpls] Last = Call:(Proactive Connectivity) >=20 > Se we're in agreement that there's no duplication of effort required; = good. >=20 > I'll agree at a general level with a part of Tom's overall statement = that >=20 > > It is also a relatively less scaleable >one as well as compared to = doing in HW. >=20 > A HW implementation of a protocol can be made to be more scaleable = than a SW only one, ok that's agreed. >=20 >=20 > =46rom implementation experience with shipping scaleable and = interoperable BFD and has also been pointed out by Mahesh, many = vendors implement a combined approach, one needs software to manage the = HW assist and the overall state machines, so a blended approach is = usually done using HW for heavy lifting, and distributing SW functions = where necessary / desirable. >=20 > The division of this work and the decision of what to accelerate with = HW assist. is a function of where in the network the equipment is = situated and the anticipated scale on it, these are descions made by = vendors and born from experiences with implementations. >=20 > However one can if, desired accelerate aspects of CV with "HW" = assist too, it's a cos/ scale tradeoff that an implementation will make. = One could have HW assist to send the one per second CV messages, and one = could add a "HW" function to match the CV messages if desired. >=20 > Would the RX match portion be more efficient with no TLVs for the = various identifiers ? Yes. > Would the extra efficiency make a substantial difference to the HW = cost, I doubt it. > Is this a hard requirement ? Not that I've seen. >=20 > Note: all of this talk of HW vs SW is also not precise enough, vendors = have so called Fast-path logic to play with too. so HW and SW are not = necessarily sharp boundaries. But this is the stuff of a more general = exposition and not germane to last call comments on the specific draft = on the table. >=20 >=20 >=20 > Cheers >=20 > Rob >=20 > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. = Davari [davarish@yahoo.com] > Sent: Friday, July 15, 2011 8:24 AM > To: Thomas Nadeau; stbryant@cisco.com > Cc: ietf@ietf.or; mpls@ietf.org > Subject: Re: [mpls] Last = Call:(Proactive Connectivity) >=20 > Tom is is correct. I meant to say not scalable. >=20 > Shahram >=20 >=20 > ________________________________ > From: Thomas Nadeau > To: stbryant@cisco.com > Cc: "ietf@ietf.or" ; "mpls@ietf.org" > Sent: Fri, July 15, 2011 4:56:13 AM > Subject: Re: [mpls] Last = Call:(Proactive Connectivity) >=20 >=20 > It is less efficient not really due to the duplication, but = because the SW path is > a relatively very slow path for processing CV packets. It is also a = relatively less scaleable > one as well as compared to doing in HW. So the a number of lines of = processing or duplication > of code therein is a bit of a red herring if you ask me. >=20 > --Tom >=20 >=20 >=20 > On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: >=20 > > On 15/07/2011 01:03, Shahram Davari wrote: > >> > >> 3) Process CC in HW and CV in SW, which is not efficient since we = are duplicating the HW logic in SW as well. > >> > > Now I know that it depends on your implementation, but just how many = lines of code are we talking about here? > > The elements of this function that you would put in h/w do not seem = complex. > > > > - Stewart > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 --Apple-Mail-21--422033825 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
While I personally agree, I'd = leave how it is actually run up to the operators. They might know a = thing or two about running their networks. = *)

= --Tom


Robert,

Forget about HW and SW. The mix = of CC and CV makes any implementation complex. I don't see any = significant benefit in it. I suggest either running CC or CV and of they = are run together they should be 2 separate independent BFD = flow.

-Shahram


 Robert Rennison <Robert.Rennison@ecitele.com>
To: S. Davari <davarish@yahoo.com>; Thomas = Nadeau <tnadeau@lucidvision.com>; = "stbryant@cisco.com" <stbryant@cisco.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 8:41:59 = AM
Subject: RE: [mpls] Last = Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive = Connectivity)

Se we're in agreement that there's no = duplication of effort required; good.

I'll agree at a general = level with a part of  Tom's overall statement = that

>  It is also a relatively less scaleable >one as = well as compared to doing in HW.

A HW implementation of a = protocol can be made to be more scaleable than a SW only one, ok that's = agreed.


From  implementation experience with shipping = scaleable and interoperable  BFD and has also  been pointed = out by Mahesh, many vendors implement a combined approach, one needs = software to manage the HW assist and the overall state machines, so a = blended approach is usually done using HW for heavy lifting,  and = distributing SW functions where necessary / desirable.

The = division of this work and the decision of what to accelerate with HW = assist. is a function of where in the network the equipment is situated = and the anticipated scale on it, these are descions made by vendors and = born from experiences with implementations.

However one can = if,  desired  accelerate aspects of CV  with "HW" assist = too, it's a cos/ scale tradeoff that an implementation will make. One = could have HW assist to send the one per second CV messages, and one = could  add a "HW"  function to  match the CV messages if = desired.

Would  the RX match portion be more efficient with = no TLVs for the various identifiers  ? Yes.
Would the extra = efficiency make a substantial difference to the HW cost, I doubt = it.
Is this a hard requirement ? Not that I've seen.

Note: all = of this talk of HW vs SW is also not precise enough, vendors have so = called Fast-path logic to play with too. so HW and SW are not = necessarily sharp boundaries. But this is the stuff of a more general = exposition and not germane to last call comments on the specific draft = on the = table.



Cheers

Rob

___________________________= _____________
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On = Behalf Of S. Davari [davarish@yahoo.com]
Sent: = Friday, July 15, 2011 8:24 AM
To: Thomas Nadeau; stbryant@cisco.com
Cc: ietf@ietf.or; mpls@ietf.org
Subject: Re: [mpls] = Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive  = Connectivity)

Tom is is correct. I meant to say not = scalable.

Shahram


________________________________
Fr= om: Thomas Nadeau <tnadeau@lucidvision.com>To: stbryant@cisco.com
Cc: "ietf@ietf.or" <ietf@ietf.or>; "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July = 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last = Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive = Connectivity)


    It is less efficient not really = due to the duplication, but because the SW path is
a relatively very = slow path for processing CV packets. It is also a relatively less = scaleable
one as well as compared to doing in HW. So the a number of = lines of processing or duplication
of code therein is a bit of a red = herring if you ask me.

    --Tom



On Jul = 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> On 15/07/2011 = 01:03, Shahram Davari wrote:
>>
>> 3) Process CC in HW = and CV in SW, which is not efficient since we are duplicating the HW = logic in SW as well.
>>
> Now I know that it depends on = your implementation, but just how many lines of code are we talking = about here?
> The elements of this function that you would put in = h/w do not seem complex.
>
> - = Stewart
>
>
> = _______________________________________________
> mpls mailing = list
> mpls@ietf.org<mailto:mpls@ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing = list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls

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.


= --Apple-Mail-21--422033825-- From curtis@occnc.com Fri Jul 15 09:05:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5EB21F8A97 for ; Fri, 15 Jul 2011 09:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8gYweoskKA6 for ; Fri, 15 Jul 2011 09:05:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9183121F8A80 for ; Fri, 15 Jul 2011 09:05:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FG5G8S092594; Fri, 15 Jul 2011 12:05:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151605.p6FG5G8S092594@harbor.orleans.occnc.com> To: stbryant@cisco.com From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 09:12:05 BST." <4E1FF655.8090005@cisco.com> Date: Fri, 15 Jul 2011 12:05:16 -0400 Sender: curtis@occnc.com Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:05:25 -0000 In message <4E1FF655.8090005@cisco.com> Stewart Bryant writes: > > On 15/07/2011 01:03, Shahram Davari wrote: > > > > 3) Process CC in HW and CV in SW, which is not efficient since we > > are duplicating the HW logic in SW as well. > > Now I know that it depends on your implementation, but just how many > lines of code are we talking about here? The elements of this > function that you would put in h/w do not seem complex. > > - Stewart Depending on performance requirements for a particular platform, less functionality may be done with hardware assist in one platform and more functionality may go into hardware. That doesn't matter as far as standardization is concerned. What does matter is than anything which is time critical can be implemented in hardware with reasonable simplicity. It is a lot harder to get accurate counters in for every LSP for the purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in hardware. Timestamps for DM are also not trivial. These really can't be done satisfactorily without hardware assist. As mentioned, in many platforms CV in software will be adequate and maybe even hardware assist for CC detection and down transition actions in software will be adequate for some platforms. This is all implementation specifics. As simple as possible but no simpler. I think the current mpls-tp-cc-cv-rdi meets this criteria. This is all doable with many currently shipping chips that can parse the OAM packets and direct the OAM to an external FPGA. It would save some watts and board space when this goes onto forwarding ASICs, but it is doable at very high speeds at reasonable density today. (At extremely high performance and insane density its challenging, but that too is just a small matter of implementation detail and it is doable). Curtis From davarish@yahoo.com Fri Jul 15 09:29:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3620721F8AFF for ; Fri, 15 Jul 2011 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM5KWSYWydBr for ; Fri, 15 Jul 2011 09:29:14 -0700 (PDT) Received: from nm15-vm1.access.bullet.mail.mud.yahoo.com (nm15-vm1.access.bullet.mail.mud.yahoo.com [66.94.236.18]) by ietfa.amsl.com (Postfix) with SMTP id 2EF8521F8AFE for ; Fri, 15 Jul 2011 09:29:11 -0700 (PDT) Received: from [66.94.237.195] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 16:29:10 -0000 Received: from [66.94.237.123] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 16:29:10 -0000 Received: from [127.0.0.1] by omp1028.access.mail.mud.yahoo.com with NNFMP; 15 Jul 2011 16:29:10 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 892344.64815.bm@omp1028.access.mail.mud.yahoo.com Received: (qmail 66860 invoked by uid 60001); 15 Jul 2011 16:29:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310747350; bh=9SVntOxZk8ZPbhVWVhA0dkYjYBAUn8aOyS8eWX8o1zI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fw0YeeR8EsRn9qe4IgJ44tWsstqber+zJp5H9vLZ8jd35M5ygxpXHf/+yEe/BC99shWZiLyawWug79u1vuGedZ9A582+UwMcSu3yyO489ci/1GtOh/MKGzCCpg6y2RYee1h6IXZlEtBdtOcrZLWP6zN3sbIp6TROdABzx1YO5M8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yIq9WymP9ptDoJUXRSjBPvpmvsM5fKdM9U0xESjkUaC5Hb/Jg0v9kMtQQFC5IYaU/jO+6HH6we1yPcUVNC0l+B9IkkUvNVESlGLTlUCGjYnuxRwhV9tGn12H6V+HxdATVJuNX7T9j49M56Dph2VA0B4j9YnV4fxaGzUl6oHEixQ=; X-YMail-OSG: kI4gFAQVM1mEGSRF.1Nc9oI3yK7OJ.cysxAzs7uSfpuaKGq MNCfm0ULIx4VfZ8OFME1PjeRQxynSADQC8tA6x6XpNj5xi1WzS7YlHlaZN83 mvMNVdLheA1iCHdY8.h4U2XPpUcU7JPqYZc2N8zyrFjEPwIW7l8UWKFugOMG i6xDCW0cXxIeL0ac05cJ56OYSmryk11I5vxjlLQEcWJuqjLwQ9cAIWVC2ArE mzmtHzJe2nsANhx7AYd3dJNVeRotBql2QyJj596Hx5nltrn0MXjjywt0GIgC n0D9QSnbXnjHxGx8lB3p6xJm.Zwj3oHxqy5ifIUqs4lk2Ge9FKhVuiILbDMa CQ_.kPWoyNpfcZDFa7ENWIs6E1SeIXaOoO9ymumKqUV4FJVboavixCsUbQI8 SqCNO7Rl.J3Yc Received: from [98.248.36.11] by web88408.mail.re1.yahoo.com via HTTP; Fri, 15 Jul 2011 09:29:09 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <201107151605.p6FG5G8S092594@harbor.orleans.occnc.com> Message-ID: <1310747349.66804.YahooMailRC@web88408.mail.re1.yahoo.com> Date: Fri, 15 Jul 2011 09:29:09 -0700 (PDT) From: "S. Davari" To: curtis@occnc.com, stbryant@cisco.com In-Reply-To: <201107151605.p6FG5G8S092594@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-336285777-1310747349=:66804" Cc: "ietf@ietf.or" , "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:29:15 -0000 --0-336285777-1310747349=:66804 Content-Type: text/plain; charset=us-ascii Everything is doable if you don't defy the laws of physics. But Simplicity is preferred. I think running CC alone or CV alone should satisfy most SP requirements. Mixing them together in a single BFD flow is also doable but more complex since the processing of BFD packets in a single BFD flows is now not unique rather two types of processing is needed. Also the draft doesn't specify whether the CV packets are counted toward the Sliding window or not (added complexity). Shahram ________________________________ From: Curtis Villamizar To: stbryant@cisco.com Cc: "ietf@ietf.or" ; "mpls@ietf.org" Sent: Fri, July 15, 2011 9:05:16 AM Subject: Re: [mpls] Last Call:(Proactive Connectivity) In message <4E1FF655.8090005@cisco.com> Stewart Bryant writes: > > On 15/07/2011 01:03, Shahram Davari wrote: > > > > 3) Process CC in HW and CV in SW, which is not efficient since we > > are duplicating the HW logic in SW as well. > > Now I know that it depends on your implementation, but just how many > lines of code are we talking about here? The elements of this > function that you would put in h/w do not seem complex. > > - Stewart Depending on performance requirements for a particular platform, less functionality may be done with hardware assist in one platform and more functionality may go into hardware. That doesn't matter as far as standardization is concerned. What does matter is than anything which is time critical can be implemented in hardware with reasonable simplicity. It is a lot harder to get accurate counters in for every LSP for the purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in hardware. Timestamps for DM are also not trivial. These really can't be done satisfactorily without hardware assist. As mentioned, in many platforms CV in software will be adequate and maybe even hardware assist for CC detection and down transition actions in software will be adequate for some platforms. This is all implementation specifics. As simple as possible but no simpler. I think the current mpls-tp-cc-cv-rdi meets this criteria. This is all doable with many currently shipping chips that can parse the OAM packets and direct the OAM to an external FPGA. It would save some watts and board space when this goes onto forwarding ASICs, but it is doable at very high speeds at reasonable density today. (At extremely high performance and insane density its challenging, but that too is just a small matter of implementation detail and it is doable). Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --0-336285777-1310747349=:66804 Content-Type: text/html; charset=us-ascii
Everything is doable if you don't defy the laws of physics. But Simplicity is preferred. I think running CC alone or CV alone should satisfy most SP requirements. Mixing them together in a single BFD flow is also doable but more complex since the processing of BFD packets in a single BFD flows is now not unique rather two types of processing is needed. Also the draft doesn't specify whether the CV packets are counted toward the Sliding window or not (added complexity).

Shahram


From: Curtis Villamizar <curtis@occnc.com>
To: stbryant@cisco.com
Cc: "ietf@ietf.or" <ietf@ietf.or>; "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 9:05:16 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)


In message <4E1FF655.8090005@cisco.com>
Stewart Bryant writes:
> 
> On 15/07/2011 01:03, Shahram Davari wrote:
> >
> > 3) Process CC in HW and CV in SW, which is not efficient since we
> > are duplicating the HW logic in SW as well.
> 
> Now I know that it depends on your implementation, but just how many
> lines of code are we talking about here?  The elements of this
> function that you would put in h/w do not seem complex.
> 
> - Stewart


Depending on performance requirements for a particular platform, less
functionality may be done with hardware assist in one platform and
more functionality may go into hardware.

That doesn't matter as far as standardization is concerned.  What does
matter is than anything which is time critical can be implemented in
hardware with reasonable simplicity.

It is a lot harder to get accurate counters in for every LSP for the
purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in
hardware.  Timestamps for DM are also not trivial.  These really can't
be done satisfactorily without hardware assist.  As mentioned, in many
platforms CV in software will be adequate and maybe even hardware
assist for CC detection and down transition actions in software will
be adequate for some platforms.  This is all implementation specifics.

As simple as possible but no simpler.  I think the current
mpls-tp-cc-cv-rdi meets this criteria.  This is all doable with many
currently shipping chips that can parse the OAM packets and direct the
OAM to an external FPGA.  It would save some watts and board space
when this goes onto forwarding ASICs, but it is doable at very high
speeds at reasonable density today.  (At extremely high performance
and insane density its challenging, but that too is just a small
matter of implementation detail and it is doable).

Curtis
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--0-336285777-1310747349=:66804-- From curtis@occnc.com Fri Jul 15 10:02:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB121F88AC for ; Fri, 15 Jul 2011 10:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ0Eg8aE6M-5 for ; Fri, 15 Jul 2011 10:02:01 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id B14FC21F87B9 for ; Fri, 15 Jul 2011 10:01:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FH1oWL094221; Fri, 15 Jul 2011 13:01:50 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151701.p6FH1oWL094221@harbor.orleans.occnc.com> To: Rolf Winter From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 14:43:04 -0000." <791AD3077F94194BB2BDD13565B6295D1CFE210B@DAPHNIS.office.hd> Date: Fri, 15 Jul 2011 13:01:50 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-win-mpls-tp-itu-t-identifiers-01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:02:05 -0000 In message <791AD3077F94194BB2BDD13565B6295D1CFE210B@DAPHNIS.office.hd> Rolf Winter writes: > > Curtis, > > Interesting encoding but the ICC is up to 6 characters long and the > CC is another 2. You could do the CC ones in 5 bits/character but > you'd still lack bits. > > Best, > > Rolf Rolf, Yes that was a mistake on my part. Better density is achievable, but we can't get it into 4 bytes by a simple mapping. Curtis > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Curtis Villamizar > > Sent: Freitag, 15. Juli 2011 15:47 > > To: Kyung-Yeop Hong (hongk) > > Cc: mpls@ietf.org; Stewart Bryant (stbryant) > > Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft- > > win-mpls-tp-itu-t-identifiers-01) > > > > > > In message <515703B08A3A064C9CC8C09ACCC710DC047E89BA@XMB-RCD- > > 103.cisco.com> > > "Kyung-Yeop Hong (hongk)" writes: > > > > > > Rolf et al, > > > > > > As the content had been in the draft-ietf-mpls-tp-identifiers and > > > removed due to the shortcoming until resolved, I propose to discuss > > and > > > figure out the resolution first before the adoption call. > > > > > > I also believe the content should go back into the identifiers draft > > > once resolved. > > > > > > Regards, > > > KY > > > > > > +1 > > > > Yes and either way all of the issues have to be resolved before it is > > added back or proceeds on its own. > > > > A means to identify MPLS tunnels and LSP are needed. All of the named > > entities listed in draft-ietf-mpls-tp-identifiers-01.txt need to be > > accomodated. If the name space doesn't match the existing name spaces > > in OSPF-TE, ISIS-TE, and RSVP-TE (ie: doesn't fit into existing GMPLS > > work) which are based on IPv4 and IPv6, before accepting the work the > > entire effort must be scoped. > > > > A second limited functionality option is to acknowledge that ICC/CC > > style Global_ID is not applicable if a control plane is used. The > > MPLS WG and the IETF would need to decide whether to go forward with a > > lame approach, not something IETF tends to do. > > > > Mixing IPv4 and IPv6 identifiers in the control plane and ICC/CC in > > the OAM makes little sense. If ICC/CC is needed for the benefit of an > > antiquated OSS system, then a management shim, either on the OSS side > > or the NE side or in a management proxy would be preferable. > > > > It is worth noting that the 5 characters in ICC/CC can be fit into > > four bytes since only 36 values are used per character. There are 2 > > bits left over. 5 characters of 36 bits can be packet into 26 bits, > > leaving 6 bits unused. If this is acceptable, then there are two > > Global_ID spaces, both fitting into four bytes. If 1/64th of the four > > byte AS space can be set aside, the ICC/CC space can be fit into the > > AS space, setting the 6 unused bits to a fixed value, perhaps all > > ones, if ICC/CC numbering is used. That could be proposed within the > > IDR WG or somewhere in the OPS area. Just as easily as the > > microprocessor in network equipment or management software displays > > the AS number in its current notation (typically as two 16 bit decimal > > values), the ICC encoding can be converted to ASCII ICC/CC > > representation for display purposes. > > > > Curtis > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Stewart Bryant (stbryant) > > > Sent: Thursday, July 14, 2011 3:51 PM > > > To: mpls@ietf.org > > > Subject: Re: [mpls] Identifiers following ITU-T conventions > > > (was:draft-win-mpls-tp-itu-t-identifiers-01) > > > > > > Rolf > > > > > > So the 16 bit identifier in section 5 is an additional identifier? > > > > > > Please could you reduce the confusion by drawing up the proposed data > > > structure in octet/longword format as per traditional IETF > > > representation. > > > > > > - Stewart > > > > > > > > > On 14/07/2011 20:16, Rolf Winter wrote: > > > > Hello, > > > > > > > > > > > > I changed the subject line since this is I think orthogonal to the > > > call for adoption. I also try to address a set of comments from > > > different people that have been raised in this one Email. > > > > > > > > The main discussion has been revolving around the actual format of > > the > > > MEG_ID, in particular the length of the whole ID and the length of > > the > > > operator-definable part. The length results from Y.1731 using 13 > > bytes > > > for MEG_IDs and the document is following ITU-T conventions after all. > > > So that is where the length comes from. If the WG decides that the > > > remaining UMC is not long enough then we need to define another > > > identifier. That's regular WG process I'd say. In either event this > > > document will be liaised with the ITU-T ensuring we follow the right > > > ITU-T conventions. > > > > > > > > Regarding the UMC. It is at least 4 characters long. If you > > restrict > > > yourself to alphanumeric you will have 36 states per character > > resulting > > > in 36^4 possible combinations which is around 1.6 million. I think > > the > > > sheer number might not the problem but rather the structure, i.e. > > > existing structures might not fit into these 4 characters and again, > > the > > > WG needs to figure this out. > > > > > > > > The need for a delimiter is based on the fact that you have three > > > fields, two of which are of variable length. Let me illustrate this > > with > > > an example to show that the delimiter is needed independent of the > > > ordering. (and yes there are other ways to deal with this which I'd > > be > > > happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take > > > also operator "C" and operator "CD". If "C" decides to use a UMC "DE" > > > and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A > > > delimiter will solve this issue. The same principle applies to the > > > ordering ICC:CC:UMC only here this could happen even with different > > > country codes but if you want to be 100% sure that such a situation > > > cannot arise, then you need another token in the ID (or used fixed > > sized > > > fields or use another trick...). > > > > > > > > Generally, there have been comments that the adoption call is > > either > > > too early or the content should go into the identifiers draft. Well, > > the > > > content in fact has been in that document. So, in principle the need > > for > > > this already has been acked by the WG. This draft addresses the > > > shortcoming which caused the content to be removed. That is why I > > asked > > > the chairs to do the poll now (so please don't blame Ross, blame me). > > > > > > > > Anyway, I am happy to discuss this further. > > > > > > > > > > > > Best, > > > > > > > > Rolf > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Robert.Rennison@ecitele.com Fri Jul 15 10:10:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1137421F8AFA for ; Fri, 15 Jul 2011 10:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nKuEQWCdqko for ; Fri, 15 Jul 2011 10:10:15 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF2321F8AF8 for ; Fri, 15 Jul 2011 10:10:15 -0700 (PDT) X-AuditID: 3f5e7f87-b7b61ae000005fea-17-4e209a0dd5e2 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 0A.50.24554.D0A902E4; Fri, 15 Jul 2011 15:50:37 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Fri, 15 Jul 2011 13:10:08 -0400 From: Robert Rennison To: "hideki.endo.es@hitachi.com" Date: Fri, 15 Jul 2011 13:10:06 -0400 Thread-Topic: Re[2]: [mpls] Last Call:(Proactive Connecti Thread-Index: AcxC6TLsAqa5jqPdQP6lzMw9hFFKkQAJuEMa Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB877@USPITMAIL01.ecitele.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB872@USPITMAIL01.ecitele.c>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WSWUwTQRzGmd2lLtXVpQgdiSTrIj5ga6jVWI8KJhIwKpKgxKgR1nZsN7Tb TXfrQUzEeFJFwfAANUHQqgHPgHgENbHqAyji8YDBoyRtNN6KRqMP4rYbEeM8fTP/7/vNZPKR uO64Jp3kBRl5Bc7FarSENiGhwEgFmKKcpqoJlv6vHzHLwInWxDyscPe9M0RhMPgDK8bWVIEF nCB4ZE5GjB1JNitb7OU3cbatLMPbrayJZUQXZ0NuJMhWlhNFJNjZhVrmv7VAsfECgwSbx84L Diu7pGSF0WKZPddoYhdOyzSZ52tXOnmJQUY3x7sYN5IkzoEY5aT8Iu7csdMuNmi3dHRfBlWg jvSDJBLSs2D72V9A1WnwwYvzGj/Qkjq6C8DhD91j1M0BAG9WR8bEXBraDC8M9SbG9ETaCnc9 byL8gCRxOhP2PJ8cOyboLPj09UssplPoMvjqyUNMtZfDhpovGlXPhI3nwnEMRRfD4eAeXL3r HYADX1vjpiQ6F56KDMbDQHnd954zcY3TejgQPYqpr6Zh8FofrupU+DryK1H1p8Jne88D1W+A zV1DGlVPhydb3uLqxcmwuzFK1IK0wChsYFQkMCoSGBVpBkQbSPNJIi9vcDtyTDOQjZeRC82w edztQClG7vrte6+AQ/XZITCJxNhUivcyRbrxGzz2rU5OcpZ5fS4khYBF+a06PH2szaOUSpDL zDk5/2xYPXV1X3C5jnYo3alASETeP9HJJMlCaoKsYJO9yIG2bORd8t8xRiaFACTHsROp+5Li oSSRc0u8Q533gCwy/DR8G+gIwSOgdD0FYiA6ZnL6hBHOG6AnAZtCcTHEOKX5I4Q3ChxT4Ofm ZcTgSrdHRulV4LpYw4QXNzYuWurPMh6ue5u3rnNsX8aPfaG1WjNe23GprPJBvUGPCT/7a/Mr Blu+3Rm+NYU2EOXvfW1yuPqTmFv6aP63YMmckrrotiM3kuf2T426N78rNdQWnOrlllVM6kys PLj6s7/9cUplBzotWwbt+1vyc1cNuSMDodS7zmMsITk5Uzbulbjfv/70QLYDAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connecti X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:10:16 -0000 Hideki, > >>However P/F is needed to get from the initial 1 per second default rate to= the desired rate. >>This and the rational for an initial P/F were discussed in detail back in= March /April. >[HE]My understanding is far from yours. >The cc-cv-rdi-03 said >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD."= . >In my understanding, this meant that Poll/Final Sequence MUST NOT be used f= or GAL/G-ACh. >In other words, GAL/G-ACh MUST work well without Poll/Final Sequence >in the case of getting from initial state. >I think this was the group consensus. >If the consensus was only for re-negotiation, why was P/F excluded from GAL= /G-ACh? You are correct, the text in -03 does state this, this was back in April and= I made many comments on the list as a result of the initial last-call expla= ining why some initial level of P/F was necessary, Please check the thread= on the list re Poll / Final in draft-cc-cv-rdi, for my reasoning. The aut= hors took these concrete points into consideration and we worked together to= come up with the current proposal. I have seen no substantive concrete alternative approaches proposed since A= pril for modifying the rate from the starting rate to the desired rate. Cheers Rob This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From neil.2.harrison@bt.com Fri Jul 15 10:11:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23D021F8B0A for ; Fri, 15 Jul 2011 10:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZw8MKL5jzlm for ; Fri, 15 Jul 2011 10:11:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 563F021F8B09 for ; Fri, 15 Jul 2011 10:11:13 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 15 Jul 2011 18:11:11 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 15 Jul 2011 18:11:12 +0100 From: To: , , Date: Fri, 15 Jul 2011 18:11:07 +0100 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxDDHOOsqqyAHFZS86LPpWTviK+7wAAz+3g Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405B34CFAC@EMV62-UKRD.domain1.systemhost.net> References: <201107151605.p6FG5G8S092594@harbor.orleans.occnc.com> <1310747349.66804.YahooMailRC@web88408.mail.re1.yahoo.com> In-Reply-To: <1310747349.66804.YahooMailRC@web88408.mail.re1.yahoo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E4405B34CFACEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:11:18 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E4405B34CFACEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shahram, I could not agree with you more. And if folks want to cogitate on the unne= cessary complexity angle have a think about these points: - Consider PM flows. These need stopping/starting in accordance with= the entry/exit criteria of unavailability....else they are not worth bothe= ring with. - All layers and sublayers need harmonising wrt unavailability entry/= exit states.....now think about artificial TCM sublayers and how E2E paths = move their routing at intermediate nodes in response to a failure whilst ha= ving fixed end nodes....noting there is a need to keep all the PM counters = at all levels in sync here. - Now add a raft of different QoS classes per LSP/connection (hint=3D= > this violates the rule of transparency anyway, and is thus just a really = bad idea for something that is supposed to be a transport network) to what = is noted above. So if folks think the always-on defect handling can be complex, just wait u= ntil TCM and multiple QoS classes get added to the mix. Simplicity is the = key in OAM. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of S. = Davari Sent: 15 July 2011 17:29 To: curtis@occnc.com; stbryant@cisco.com Cc: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Everything is doable if you don't defy the laws of physics. But Simplicity = is preferred. I think running CC alone or CV alone should satisfy most SP r= equirements. Mixing them together in a single BFD flow is also doable but m= ore complex since the processing of BFD packets in a single BFD flows is no= w not unique rather two types of processing is needed. Also the draft doesn= 't specify whether the CV packets are counted toward the Sliding window or = not (added complexity). Shahram ________________________________ From: Curtis Villamizar To: stbryant@cisco.com Cc: "ietf@ietf.or" ; "mpls@ietf.org" Sent: Fri, July 15, 2011 9:05:16 AM Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) In message <4E1FF655.8090005@cisco.com> Stewart Bryant writes: > > On 15/07/2011 01:03, Shahram Davari wrote: > > > > 3) Process CC in HW and CV in SW, which is not efficient since we > > are duplicating the HW logic in SW as well. > > Now I know that it depends on your implementation, but just how many > lines of code are we talking about here? The elements of this > function that you would put in h/w do not seem complex. > > - Stewart Depending on performance requirements for a particular platform, less functionality may be done with hardware assist in one platform and more functionality may go into hardware. That doesn't matter as far as standardization is concerned. What does matter is than anything which is time critical can be implemented in hardware with reasonable simplicity. It is a lot harder to get accurate counters in for every LSP for the purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in hardware. Timestamps for DM are also not trivial. These really can't be done satisfactorily without hardware assist. As mentioned, in many platforms CV in software will be adequate and maybe even hardware assist for CC detection and down transition actions in software will be adequate for some platforms. This is all implementation specifics. As simple as possible but no simpler. I think the current mpls-tp-cc-cv-rdi meets this criteria. This is all doable with many currently shipping chips that can parse the OAM packets and direct the OAM to an external FPGA. It would save some watts and board space when this goes onto forwarding ASICs, but it is doable at very high speeds at reasonable density today. (At extremely high performance and insane density its challenging, but that too is just a small matter of implementation detail and it is doable). Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_6D3D47CB84BDE349BC23BF1C94E316E4405B34CFACEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shahram,

 

I could not agree with you more.  And if folks want to cogitate on the u= nnecessary complexity angle have a think about these points:

-       Consider PM flows.  These need stopping/starting in accordance with the entry/e= xit criteria of unavailability....else they are not worth bothering with.<= /o:p>

-       All layers and sublayers need harmonising wrt unavailability entry/exit states.= ....now think about artificial TCM sublayers and how E2E paths move their routing a= t intermediate nodes in response to a failure whilst having fixed end nodes..= ..noting there is a need to keep all the PM counters at all levels in sync here.

-       Now add a raft of different QoS classes per LSP/connection (hint=3D> this vi= olates the rule of transparency anyway, and is thus just a really bad idea for som= ething that is supposed to be a transport network) to what is noted above.

 

So if folks think the always-on defect handling can be complex, just wait unti= l TCM and multiple QoS classes get added to the mix.  Simplicity is the = key in OAM. 

 

regards, Neil

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

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of S. Davari
Sent: 15 July 2011 17:29
To: curtis@occnc.com; stbryant@cisco.com
Cc: ietf@ietf.or; mpls@ietf.org
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

 

Everything is doable = if you don't defy the laws of physics. But Simplicity is preferred. I think runnin= g CC alone or CV alone should satisfy most SP requirements. Mixing them together= in a single BFD flow is also doable but more complex since the processing of B= FD packets in a single BFD flows is now not unique rather two types of process= ing is needed. Also the draft doesn't specify whether the CV packets are counte= d toward the Sliding window or not (added complexity).

Shahram

 

 

From: Curtis Villam= izar <curtis@occnc.com>
To: stbryant@cisco.com
Cc: "ietf@ietf.or" <ietf@ietf.or>; "mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 9:05:16 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)
In message <4E1FF655.80900= 05@cisco.com>
Stewart Bryant writes:
> 
> On 15/07/2011 01:03, Shahram Davari wrote:
> >
> > 3) Process CC in HW and CV in SW, which is not efficient since we=
> > are duplicating the HW logic in SW as well.
> 
> Now I know that it depends on your implementation, but just how many > lines of code are we talking about here?  The elements of this > function that you would put in h/w do not seem complex.
> 
> - Stewart


Depending on performance requirements for a particular platform, less
functionality may be done with hardware assist in one platform and
more functionality may go into hardware.

That doesn't matter as far as standardization is concerned.  What does=
matter is than anything which is time critical can be implemented in
hardware with reasonable simplicity.

It is a lot harder to get accurate counters in for every LSP for the
purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in
hardware.  Timestamps for DM are also not trivial.  These really can't
be done satisfactorily without hardware assist.  As mentioned, in many=
platforms CV in software will be adequate and maybe even hardware
assist for CC detection and down transition actions in software will
be adequate for some platforms.  This is all implementation specifics.=

As simple as possible but no simpler.  I think the current
mpls-tp-cc-cv-rdi meets this criteria.  This is all doable with many currently shipping chips that can parse the OAM packets and direct the
OAM to an external FPGA.  It would save some watts and board space
when this goes onto forwarding ASICs, but it is doable at very high
speeds at reasonable density today.  (At extremely high performance and insane density its challenging, but that too is just a small
matter of implementation detail and it is doable).

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

--_000_6D3D47CB84BDE349BC23BF1C94E316E4405B34CFACEMV62UKRDdoma_-- From curtis@occnc.com Fri Jul 15 10:51:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524C421F8BB5 for ; Fri, 15 Jul 2011 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fbsQuMk-iXV for ; Fri, 15 Jul 2011 10:51:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7821F8BA0 for ; Fri, 15 Jul 2011 10:51:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FHp3WE095797; Fri, 15 Jul 2011 13:51:03 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151751.p6FHp3WE095797@harbor.orleans.occnc.com> To: mpls@ietf.org From: Curtis Villamizar Date: Fri, 15 Jul 2011 13:51:03 -0400 Sender: curtis@occnc.com Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:51:04 -0000 Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt Mach, Ping, et al, The second issue which I pointed out in the last revision is that there is no way to indicate the characteristics required of a mid-segment of a MS-PW. The ingress (a T-PE) can specify the nodes, but it cannot specify which tunnel from S-PE to S-PE to use. It must specify the required characteristics of the tunnel to allow the S-PE to pick an appropriate tunnel. For example, an LSP contains sufficient information, such as bandwidth, holding and setup priority, resource affinitiy expressed as include-any, include-all, and exclude to be applied over the 32 bit administrative atrribute bit map. This allows simple things such as loose hops and not so simple things such as BRPC. It might be best to cite the RSVP-TE work and encapsulate the TLVs defined there into the PW. This is a bit like reinventing CR-LDP and if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW should be defined instead. I'm not really sure what the best way is to solve this. Curtis From hideki.endo.es@hitachi.com Fri Jul 15 20:58:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27221F8713 for ; Fri, 15 Jul 2011 20:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.743 X-Spam-Level: X-Spam-Status: No, score=0.743 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM+60J80H1pf for ; Fri, 15 Jul 2011 20:58:37 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB621F8710 for ; Fri, 15 Jul 2011 20:58:36 -0700 (PDT) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id A854537AC5; Sat, 16 Jul 2011 12:58:35 +0900 (JST) Received: from mfilter01.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p6G3wZBX010757; Sat, 16 Jul 2011 12:58:35 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter01.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p6G3wYl6010666; Sat, 16 Jul 2011 12:58:35 +0900 X-AuditID: b753bd60-a3c7dba0000050a4-96-4e210c690605 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 3DE5B8B0276; Sat, 16 Jul 2011 12:58:33 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p6G3wXN12513510; Sat, 16 Jul 2011 12:58:33 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Sat, 16 Jul 2011 12:58:17 +0900 References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB872@USPITMAIL01.ecitele.c> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB877@USPITMAIL01.ecitele.c> Priority: normal Importance: normal X400-Content-Identifier: X4E210C4700000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110716125759O06] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] LastCall:(Proactive Co X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 03:58:38 -0000 Robert, >Hideki, > > >> >>>However P/F is needed to get from the initial 1 per second default rate to the desired rate. >>>This and the rational for an initial P/F were discussed in detail back in March /April. >>[HE]My understanding is far from yours. >>The cc-cv-rdi-03 said >>"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.". >>In my understanding, this meant that Poll/Final Sequence MUST NOT be used for GAL/G-ACh. >>In other words, GAL/G-ACh MUST work well without Poll/Final Sequence >>in the case of getting from initial state. >>I think this was the group consensus. >>If the consensus was only for re-negotiation, why was P/F excluded from GAL/G-ACh? > >You are correct, the text in -03 does state this, this was back in April and I made many comments on the list as a result of the initial last-call explaining why some initial level of P/F was necessary, Please check the thread on the list re Poll / Final in draft-cc-cv-rdi, for my reasoning. The authors took these concrete points into consideration and we worked together to come up with the current proposal. > >I have seen no substantive concrete alternative approaches proposed since April for modifying the rate from the starting rate to the desired rate. [HE]You are also correct. I know that discussion. I'm very sorry for no reply at that time. However, I don't think P/F is only solution for this problem. Based on initial group consensus, the solution should be without P/F. Therefore, I said that the interval change timing should be defined in the case of transition DOWN/INIT to UP state without P/F sequence for GAL/G-ACh. BR, Hideki > > >Cheers > >Rob > > >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. > > From maarten.vissers@huawei.com Sun Jul 17 17:34:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60021F8906 for ; Sun, 17 Jul 2011 17:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhayTebKgnYk for ; Sun, 17 Jul 2011 17:34:29 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id AB65221F887C for ; Sun, 17 Jul 2011 17:34:29 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI0029R6XGHJ@lhrga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jul 2011 01:34:28 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LOI00K7Q6XFGN@lhrga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jul 2011 01:34:27 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 01:34:25 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 18 Jul 2011 01:34:26 +0100 Date: Mon, 18 Jul 2011 00:34:26 +0000 From: Maarten vissers X-Originating-IP: [10.47.140.126] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-index: AQHL1zcqtyz+QO1ioUOlD8ckZLDEdpQWyHlAgNGz0KSACOYxwIAAtCpw X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [mpls] FW: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 00:34:30 -0000 Resend.. -----Original Message----- From: Maarten vissers Sent: 18 July 2011 00:38 To: 'George Swallow'; 'Maarten vissers'; 'mpls-tp@ietf.org' Subject: RE: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 George, Your response below made me aware of an unnoticed terminology issue in the draft. I.e. > Within the Defect class, a further category, Fault is identified. A > fault is the inability of a function to perform a required action. A > fault is a persistent defect. The above text from the draft puts the things upside down... in the ITU-T recommendations, a fault is the actual problem which results in the detection of anomalies and when those anomalies are persistent into a defect. I.e. fault => anomaly detection => defect detection (persistent anomalies). In your draft you extend the above with a "second type of fault"; i.e. fault => anomaly detection => defect detection (persistent anomalies) => fault (persistent defect). This is not a good approach in my opinion. In the LDI text in section 2.1.1 you talk about a "fatal defect", and it would be better to use this term instead. The text would then become as follows: "Within the Defect class, a further category, Fatal Defect is identified. A fatal defect is a defect for which there is no recovery function available locally (after defect detector) or upstream (before defect detector)." Regards, Maarten > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 11 July 2011 23:56 > To: Maarten vissers; mpls-tp@ietf.org > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > > Maarten - > > You seem to be extrapolating behavior of higher level entities based on > text > that is about server MEPs. The important text for MEP4 and MEP2 is > "The > L-flag MUST NOT be set until the defect has been determined to be a > fault." > > I updated the next paragraph to make it clear that it is an example and > also > made the should(s) in that paragraph lowercase to make it clear that it > is > not normative text. > > You also cause me to release that I should have a few words on fault > propagation. I added a small section. > > ...George > > > On 2/28/11 7:48 AM, "Maarten Vissers" > wrote: > > > Comment on LDI operation: > > > > LSPs can be nested, and it is possible to have an LSP stack with e.g. > five > > LSPs (A,B,C,D,E) as follows: > > > > MEP1-----------------------(A)--------------------------MEP2 > > MEP3----------(B)----------MEP4 MEP5--(C)---MEP6 > > W.MEP7--(D)--W.MEP8 > > P.MEP9--(E)--P.MEP10 > > > > When LSP(D) fails, LSP(B) and LSP(A) fail as well. > > W.MEP8, MEP4 and MEP2 will detect this failure and will insert AIS. > > - W.MEP8 can send AIS(L-flag=0). > > - MEP4 and MEP2 have no immediate knowledge of the > > server layer/sublayer protection, and send AIS(L-flag=1). > > > > As there is protection present at a server (sub)layer and both > working and > > protection paths are available before the fault occurs, MEP4 and MEP2 > should > > have send AIS(L-flag=0) instead of AIS(L-flag=1). > > > > How to control that MEP4 and MEP2 set the LDI flag to "clear" when > working and > > protection paths are both available in this case? > > > > Regards, > > Maarten > > > > > > (2011/02/03 20:36), Loa Andersson wrote: > >> Working Group, > >> > >> this is to start a four week working group last call > >> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). > >> > >> Please send comments to the mpls-tp@ietf.org mailing list. > >> > >> This working group last call ends on February 28, 2011. > >> > >> Loa, George and Ross > >> MPLS wg co-chairs > >> -- > >> Loa Andersson email: loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Sun Jul 17 17:37:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01921F86E1 for ; Sun, 17 Jul 2011 17:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aTh95bfRvjN for ; Sun, 17 Jul 2011 17:37:13 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6525D21F86DF for ; Sun, 17 Jul 2011 17:37:13 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI002AP720HJ@lhrga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jul 2011 01:37:12 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LOI00KA871ZGN@lhrga02-in.huawei.com> for mpls@ietf.org; Mon, 18 Jul 2011 01:37:11 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 01:37:09 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 18 Jul 2011 01:37:11 +0100 Date: Mon, 18 Jul 2011 00:37:10 +0000 From: Maarten vissers X-Originating-IP: [10.47.140.126] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-index: AQHL1zcqtyz+QO1ioUOlD8ckZLDEdpQWyHlAgNGz0KSACOz18IAArYMg X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [mpls] FW: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 00:37:14 -0000 Resend.. -----Original Message----- From: Maarten vissers Sent: 18 July 2011 00:38 To: 'George Swallow'; 'mpls-tp@ietf.org' Subject: RE: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 George, MEP2 is in a network of e.g. operator Y and W.MEP8 is in a network of e.g. operator X. How does operator Y know that operator X has protected a part of LSP B? If Y has not told X, then MEP2 will be in a node not supporting any protection, and thus must generate AIS with LDI set to 1 as per specification; i.e. based on: The setting of the LDI flag can be predetermined based on the protection state. If the Server Layer is protected and both the working and protection paths are available, both the active and standby MEPs should be programmed to send AIS with LDI clear upon detecting a defect condition. If the Server Layer is unprotected or the Server Layer is protected but only the active path is available, the active MEP should be programmed to send AIS with LDI set upon detecting a defect condition. MEP2's LDI configuration is based on unprotected server layer in network Y and has its LDI thus set to 1. Similarly, if MEP4 is in a different node in network X than W.MEP8/P.MEP10, then LDI should be set to 1 in MEP4 as there is no communication channel from the node with W.MEP8/10 and the protection switching function and the node with MEP4 to control the setting of the LDI bit in MEP4 (and also in MEP2). In this example, MEP4 and MEP2 have either 1) configured the value of LDI by NMS to 1 (LDI set), or have 2) a communication channel from W.MEP8/P.MEP10 to MEP4 and MEP2 to control the LDI value (expensive!), or have 3) a timer which on expiry changes the LDI value from LDI=0 (clear) to LDI=1 (set). Regards, Maarten PS. The timer value should be standardized, and have e.g. a value of 100 ms; i.e. AIS is initially generated with LDI=0 (clear) and after 100 ms either the defect condition in MEP4/2 was cleared and AIS insertion stopped, or AIS is now generated with LDI=1. The defect condition in W.MEP8 is still present and AIS is now generated with LDI=1 after 100 ms (get dropped if protection switch selected signal from P.MEP9). If we would use a timer with fixed value, then LDI indication can be dropped, and the AIS receiver can interpret the first 100 ms of AIS as potentially protected connection upstream, and after 100ms as unprotected or unable to protect connection; i.e. LDI detection is ">100 ms AIS" detection. > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 11 July 2011 23:56 > To: Maarten vissers; mpls-tp@ietf.org > Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 > > Maarten - > > You seem to be extrapolating behavior of higher level entities based on > text > that is about server MEPs. The important text for MEP4 and MEP2 is > "The > L-flag MUST NOT be set until the defect has been determined to be a > fault." > > I updated the next paragraph to make it clear that it is an example and > also > made the should(s) in that paragraph lowercase to make it clear that it > is > not normative text. > > You also cause me to release that I should have a few words on fault > propagation. I added a small section. > > ...George > > > On 2/28/11 7:48 AM, "Maarten Vissers" > wrote: > > > Comment on LDI operation: > > > > LSPs can be nested, and it is possible to have an LSP stack with e.g. > five > > LSPs (A,B,C,D,E) as follows: > > > > MEP1-----------------------(A)--------------------------MEP2 > > MEP3----------(B)----------MEP4 MEP5--(C)---MEP6 > > W.MEP7--(D)--W.MEP8 > > P.MEP9--(E)--P.MEP10 > > > > When LSP(D) fails, LSP(B) and LSP(A) fail as well. > > W.MEP8, MEP4 and MEP2 will detect this failure and will insert AIS. > > - W.MEP8 can send AIS(L-flag=0). > > - MEP4 and MEP2 have no immediate knowledge of the > > server layer/sublayer protection, and send AIS(L-flag=1). > > > > As there is protection present at a server (sub)layer and both > working and > > protection paths are available before the fault occurs, MEP4 and MEP2 > should > > have send AIS(L-flag=0) instead of AIS(L-flag=1). > > > > How to control that MEP4 and MEP2 set the LDI flag to "clear" when > working and > > protection paths are both available in this case? > > > > Regards, > > Maarten > > > > > > (2011/02/03 20:36), Loa Andersson wrote: > >> Working Group, > >> > >> this is to start a four week working group last call > >> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). > >> > >> Please send comments to the mpls-tp@ietf.org mailing list. > >> > >> This working group last call ends on February 28, 2011. > >> > >> Loa, George and Ross > >> MPLS wg co-chairs > >> -- > >> Loa Andersson email: loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp From mach.chen@huawei.com Sun Jul 17 20:54:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E679E21F8B12; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH-ArE8nGW42; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4177B21F8B08; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI00BD8G70RD@szxga04-in.huawei.com>; Mon, 18 Jul 2011 11:54:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI00ACUG6Z2O@szxga04-in.huawei.com>; Mon, 18 Jul 2011 11:54:36 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACH79664; Mon, 18 Jul 2011 11:54:35 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 11:54:33 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Mon, 18 Jul 2011 11:54:26 +0800 Date: Mon, 18 Jul 2011 03:54:24 +0000 From: Mach Chen In-reply-to: <201107151751.p6FHp3WE095797@harbor.orleans.occnc.com> X-Originating-IP: [10.110.98.37] To: "curtis@occnc.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue Thread-index: AQHMQxfO+dvJGiMscE+yyQjr2dKmnJTxZ/ng X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201107151751.p6FHp3WE095797@harbor.orleans.occnc.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 03:54:39 -0000 Hi Curtis, Thanks for your comments! The original purpose of this draft was for binding a PW to a co-routed PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed" is the major characteristic. In the draft, this is archived by setting the "C" bit of the PSN Tunnel TLV. As for other characteristics, I am not sure whether we need carry all those characteristics(at least for now), and as you said, if we do that, it may eventually reinvent another CR-LDP. So, IMHO, it may be better to limit the scope of the draft to the current form and leave others for future study. If there are requirements for adding new characteristic, we could incorporate it then. BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth Signaling) has already defined a PW Bandwidth TLV to indicate bandwidth characteristic, it also can apply in this draft. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Saturday, July 16, 2011 1:51 AM > To: mpls@ietf.org > Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue > > > Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > Mach, Ping, et al, > > The second issue which I pointed out in the last revision is that > there is no way to indicate the characteristics required of a > mid-segment of a MS-PW. The ingress (a T-PE) can specify the nodes, > but it cannot specify which tunnel from S-PE to S-PE to use. It must > specify the required characteristics of the tunnel to allow the S-PE > to pick an appropriate tunnel. > > For example, an LSP contains sufficient information, such as > bandwidth, holding and setup priority, resource affinitiy expressed as > include-any, include-all, and exclude to be applied over the 32 bit > administrative atrribute bit map. This allows simple things such as > loose hops and not so simple things such as BRPC. > > It might be best to cite the RSVP-TE work and encapsulate the TLVs > defined there into the PW. This is a bit like reinventing CR-LDP and > if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW > should be defined instead. I'm not really sure what the best way is > to solve this. > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From iesg-secretary@ietf.org Mon Jul 18 07:12:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6612821F8BAF; Mon, 18 Jul 2011 07:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSnJg-VBZkZG; Mon, 18 Jul 2011 07:12:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25A21F86DE; Mon, 18 Jul 2011 07:12:46 -0700 (PDT) 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.55 Message-ID: <20110718141246.14299.89956.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2011 07:12:46 -0700 Cc: mpls@ietf.org Subject: [mpls] Second Last Call: (A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:12:47 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' as an Informational RFC This is a second last call. The last call is only necessary because of a late-received IPR disclosure. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-01. 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 Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC XXXX. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] [RFC Editor, please replace XXXX with the RFC number assigned to draft-ietf-mpls-loss-delay.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1583/ From Alexander.Vainshtein@ecitele.com Mon Jul 18 08:15:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667D321F8B8D for ; Mon, 18 Jul 2011 08:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13k2ZJtgrbeB for ; Mon, 18 Jul 2011 08:15:26 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9E21F8B8C for ; Mon, 18 Jul 2011 08:15:19 -0700 (PDT) X-AuditID: 93eaf2e7-b7c75ae000005b42-b3-4e244dfdb4d2 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 44.DB.23362.DFD442E4; Mon, 18 Jul 2011 18:15:09 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 18 Jul 2011 18:15:16 +0300 From: Alexander Vainshtein To: George Swallow Date: Mon, 18 Jul 2011 18:15:14 +0300 Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVgGWmdWp8B6/z8MA== 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_A3C5DF08D38B6049839A6F553B331C76EBF2D3AB9AILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURTOndndTqvTTFdrrxJZo+o51VV0PVZEkTbUW4QQxuy1O7o7s90Z ogSNxmtT0mpDdxEl26pXmiIb1LMatKSkEpEWRdWjFUKE1KtmTFpNxP313fN953wnJ+cQuPFo WBzBCzLyCqyLNkToCts+fWZ+ZsTPTiprGWD9deggbr3hewKsra+mWRtLj+utTUVbwRR92rZX l/VpRd8r9WnBYAeWFti/3TBXtzQHTGIFQZRZGZntSOJs9Fwvv47lsmkzb7fRFtrscbEcciNB ttGsx4MEOz05wvzPm6TIeMGMBE6084LDRqcvmMNYrWPHMxZ6csIgS/LEiIVOXjIjxs3yLrMb SRLrQGYlsvIc7gz5GoAnlIutL93fjOeAqufABwgCUmNg5ZUtPhCuwD7w/tMKgw9EEEbqKoAn nwV02mcfgL7yUJiqMlA2eObkE4OKY6gE+D5YrFdFOOUH8GnpO1wldNRg+OZ2m17Fvamp0N9U iKluMVQqLCnktNyp8PmeekzFJDUHlvtLw1SJkZLhXn+6Gg6nRsGq4ro/VkBp7mvdqT9ynDLB xpeHMa1pCgYv3cM1HAvftvzSa/pY+HhHBdD0IixozwOaVTSs9b/Uafq+8Hr5I10+6BPoUTbQ IyXQI0WLj4QlVZ8MGh4By46041347rUWrGe8BISdALG8yyOvcjuSLImI42XkQomc6D4DtKV6 fR58OxxfDSgC0JHkzuRBs416dp2U7a4GfQmMjiXHKztnjFol2rOdrORc4V3rQlI1gAROx5DH RiscaWezNyCv2EVNV2ZfgMf14kRlfQV5RXJS0v8/tIls5d5lGCmHspqZCHmQt6tOf4KgITlB tY/2Igdav5p3yX9pjAhX24hU2sifqbYheVi3xDs0vg4wRHNTcw0w6gRRQHEm8sEsRUSpIuda obuOelpbOjs724BJGUBv8ouqilQOr7tSm2KCKSY7mIGqiXJC3VRcDtg9rqK9hLk2Y/CVgw1D CvrfbMyUNvzY9T396LyPtpT5TFTKrWGLTQujauSfWYtrzq9Z+jVr0bJDTmHo8tDVjE3Rz1K8 d2o33r1Qm5d1aTNWmRzq13A6N7UjP8r0YkF9IpHeEFqW+WXi2+aOXdWe1czKh2UpZ+vxSpz4 cMeRO+LAkhMXRVonOVnLcNwrsb8Bi6NdwjUEAAA= Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:15:31 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76EBF2D3AB9AILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable George, Lots of thanks for your response, and apologies for a delayed reaction. I would like to present to you and the WG my reading of your responses, and= my conclusions. Regarding my comment about effect of FRR (or segment protection) on AIS/LDI,= your response includes two statements: 1. The draft only applies to "the operation of PWs, bi-directional LSP= s and sections and LSP 1:1 and 1+1 protection as that is the current scope o= f MPLS-TP" a. This seems to imply that FRR and segment protection are out of scop= e. b. To the best of my understanding, the draft does not explicitly state= that LSPs protected by FRR are out of scope. c. It only says "Fault OAM messages are applicable to Bidirectional Co= -Routed LSPs and to Multi-Segment Pseudowires" d. One could possibly imply that any actions (like FRR in link-and-node= protection mode) that break co-routed nature of a bidirectional LSP are bey= ond the scope of the draft (not sure about the scope MPLS-TP). However: i. It is= not clear (at least, to me) why bi-directionality is so important for the d= raft which only defines downstream messages ii. IMHO a= n explicit statement of this kind (preferably in the Applicability Statement= section) would make the life of a potential reader much easier. 2. The draft states that "action based on the receipt of an LDI flag i= s optional": a. I've scanned the draft for the word "OPTIONAL", (case-insensitive)= and did not find this statement. Did I miss something? b. The text that I've found in Section 2.3 of the draft and that looks= relevant states: "If the CC function is disabled, a MEP SHOULD generate AIS= messages toward any client when either the AIS or LCK indication is raised= ." IMHO this is not OPTIONAL, it is RECOMMENDED c. The quoted text in the draft contains a couple of types (I've remov= ed them). Regarding my comment about association between links and LSPs that pass thru= these links - I think that the text to which you refer clarifies this issue= . Regards, Sasha From: George Swallow [mailto:swallow@cisco.com] Sent: Friday, July 08, 2011 10:48 PM To: Alexander Vainshtein; Loa Andersson Cc: mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Sasha - On 3/1/11 7:36 AM, "Alexander Vainshtein" = wrote: Loa, and all, I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to th= e best of my understanding, have not been resolved in the -03 version. My first issue deals with potential dangers of sending fault OAM messages in= conjunction with certain protection mechanisms. The example I've presented to George and Matthew deals with the situation w= hen the LSP in question employs Facility FRR for node protection. The topology is shown below: |------| |-----| |-----| |-----| |-----| | A |<--->| B |<--->| C |<--->| D |<--->| E | |------| |-----| |-----| |-----| |-----| \ / \ / \ / \ / \ / \ / \ |------| / \| C' |/ |------| The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs in t= he rest of the nodes. If the link BC is broken, the link-level MEP at C detects that and initiates= (I'll skip the details) insertion of AIS (with LDI flag set after some stab= ilization) into the LSP. These AIS/LDI packets will be captured by the LSP M= EP in D. I believe you mean E here. Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this LS= P, starting at B and terminated at D, D would be the merge point. Note that= C would not be aware of this action, and D would not aware of AIS insertion= undertaken by C. As a consequence, E would receive both AIS/LDI generated by C and valid traf= fic coming thru bypass. The current draft is limited to the operation of PWs, bi-directional LSPs an= d sections and LSP 1:1 and 1+1 protection as that is the current scope of MP= LS-TP. The draft states that action based on the receipt of an LDI flag is= optional. In this situation you would clearly want to ignore the flag. Th= e only other affect is to suppress alarms. But as there is no alarm to supp= ress, that will have no effect. This is definitely not healthy, and the draft does not define any ways to av= oid that. If you would like to begin a draft on applying AIS to other types of LSPs, t= hat would be much appreciated. The text in the draft that deals with protection seems to refer to link prot= ection rather than to LSP protection. I agree that that is not clear. I've updated section 2 para 3 with, "When a= server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP fail= s,...." IMHO the same problem would appear in the case of segment protection if a li= nk in the middle of a segment is broken, so this issue is not limited just t= o FRR. My second issue deals with association between links and LSPs that pass thru= these links. Ability to insert Fault OAM messages into all the LSPs crossin= g a certain link may be compromised IMHO in the case LSPs that use labels fr= om the per-platform space. It is not clear from the draft how the LSR that h= as detected a link failure could decide whether Fault OAM messages should be= inserted in a transit LSP (which it perceives as an ILM table entry) or not= - because the actual LSP could be running thru a different link. The proble= m would presumably disappear if per-interface label space were used; but RFC= 5960 does not restrict MPLS-TP from using per-platform label space. The issue is not per platform labels per se, but to the binding of PWs and L= SPs to specific links (which includes hierarchical LSPs). I've updated sect= ion 2 para 3 with "Fault OAM messages are generated by intermediate nodes wh= ere a bidir-LSP is switched and bound to specific server layers based upon s= tatic configuration or signaling. ...George I apologize for sending these comments so late in the LC. Regards, Sasha -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf O= f Loa Andersson Sent: Thursday, February 03, 2011 1:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp 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_A3C5DF08D38B6049839A6F553B331C76EBF2D3AB9AILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable Re: [mpls-tp] wg last call on draft-ietf-mpls= -tp-fault-03

George,=

Lots of thanks for your response= , and apologies for a delayed reaction.

 

I would l= ike to present to you and the WG my reading of your responses, and my conclu= sions.

 

Regarding my comment about effect of FRR (= or segment protection) on AIS/LDI, your response includes two statements:

1.   &nb= sp;   The draft only applies to “the operation of PWs, bi-directi= onal LSPs and sections and LSP 1:1 and 1+1 protection as that is the current= scope of MPLS-TP”

a.       <= /span>This seems to imp= ly that FRR and segment protection are out of scope.

b.    = ;  To the b= est of my understanding, the draft does not explicitly state that LSPs prote= cted by FRR are out of scope.

c.    &n= bsp;  It on= ly says “Fault OAM messages are applicable to Bidirectional Co-Routed LSPs and t= o Multi-Segment Pseudowires”

d. &n= bsp;    One could possibly imply that any actions (like FRR in link-and-node= protection mode) that break co-routed nature of a bidirectional LSP are bey= ond the scope of the draft (not sure about the scope MPLS-TP). However:=

     &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;      i.      <= span dir=3DLTR>It is not clear (at least, to me) why bi-directi= onality is so important for the draft which only defines downstream messages=

     = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;     ii.      IMHO an explicit statement of this kind (preferably in= the Applicability Statement section) would make the life of a potential rea= der much easier.

2.       <= ![endif]>The draft states that “action based on the receipt of an LDI flag is optional”:

a.       I’ve scanned the draft for t= he word “OPTIONAL”, (case-insensitive) and did not find this sta= tement. Did I miss something?

b.    &nb= sp; The text tha= t I’ve found in Section 2.3 of the draft  and that looks relevant= states: “If the CC function is disabled, a MEP SHOULD generate AIS messages to= ward any client when either the AIS or LCK indication is  raised.”  IMHO this is not OPTIONAL, it is RECOMMENDED=

= c.       The quoted text in the draft contains a couple= of types (I’ve removed them).

 

Regarding my comment about <= /span>as= sociation between links and LSPs that pass thru these links – I think= that the text to which you refer clarifies this issue.

 

Regards,

 = ;    Sasha

 

= From: G= eorge Swallow [mailto:swallow@cisco.com]
Sent: Friday, July 08, 2= 011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc:= mpls-tp@ietf.org; mpls@ietf.org; BOCCI Matthew
Subject: Re: [mpls= -tp] wg last call on draft-ietf-mpls-tp-fault-03

=

 


Sasha -

On 3/= 1/11 7:36 AM, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:

Loa, and all,
I= have two LC comments on the draft. in question. They both refer to issues I= 've raised in private discussions with George and Matthew and which, to the= best of my understanding, have not been resolved in the -03 version.
My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms.

The example I've pr= esented to George and Matthew  deals with the situation when the LSP in= question employs Facility FRR for node protection.

The topology is s= hown below:


|------|     |-----|   =   |-----|     |-----|     = |-----|
|  A   |<--->|  B  |<--->| &= nbsp;C  |<--->|  D  |<--->|  E  |
|-= -----|     |-----|     |-----|  = ;   |-----|     |-----|
  &n= bsp;            =  \            &n= bsp;         /
  &= nbsp;            = ;  \           &= nbsp;        /
   =             &nbs= p;  \           =        /
     = ;            &nb= sp; \            = ;    /
       &nbs= p;            \=             &nb= sp;/
           &n= bsp;         \   &nbs= p;        /
   &nb= sp;            &= nbsp;     \ |------| /
    &= nbsp;            = ;      \|   C' |/
  &nb= sp;            &= nbsp;        |------|

The LSP= runs A-->B-->C-->D-->E with LSP-level MEPs at A and D  and= MIPs in the rest of the nodes.
If the link BC is broken, the link-level= MEP at C detects that and initiates (I'll skip the details) insertion of AI= S (with LDI flag set after some stabilization) into the LSP. These AIS/LDI p= ackets will be captured by the LSP MEP in D.

I believe you mean E here.


Meanwhile, B could operate a node protec= tion bypass (B-->C'-->D) for this LSP, starting at B and terminated at= D, D would be the merge point. Note that C would not be aware of this actio= n, and D would not aware of AIS insertion undertaken by C.
As a consequen= ce, E would receive both AIS/LDI generated by C and valid traffic coming thr= u bypass.

The current draft is= limited to the operation of PWs, bi-directional LSPs and sections and LSP 1= :1 and 1+1 protection as that is the current scope of MPLS-TP.  The dra= ft  states that action based on the receipt of an LDI flag is optional.=  In this situation you would clearly want to ignore the flag.  Th= e only other affect is to suppress alarms.  But as there is no alarm to= suppress, that will have no effect.


This is definitely not healthy, and the draft= does not define any ways to avoid that.

If you would like to begin a draft on applying AIS to other types= of LSPs, that would be much appreciated.


The text in the draft that deals with pro= tection seems to refer to link protection rather than to LSP protection.

I agree that that is not clear.=  I’ve updated section 2 para 3 with, “When a server layer,= (e.g. a link or bidirectional LSP) used by the bidir-LSP fails,....”<= /span>


IMHO th= e same problem would appear in the case of segment protection if a link in t= he middle of a segment is broken, so this issue is not limited just to FRR.<= br>
My second issue deals with association between links and LSPs that pa= ss thru these links. Ability to insert Fault OAM messages into all the LSPs= crossing a certain link may be compromised IMHO in the case LSPs that use l= abels from the per-platform space. It is not clear from the draft how the LS= R that has detected a link failure could decide whether Fault OAM messages s= hould be inserted in a transit LSP (which it perceives as an ILM table entry= ) or not - because the actual LSP could be running thru a different link. Th= e problem would presumably disappear if per-interface label space were used;= but RFC 5960 does not restrict MPLS-TP from using per-platform label space.=

The issue is not per platform= labels per se, but to the binding of PWs and LSPs to specific links (which= includes hierarchical LSPs).  I’ve updated section 2 para 3 with= “Fault OAM messages are generated by intermediate nodes where a bidir= -LSP is switched and bound to specific server layers based upon static confi= guration or signaling.

...George


I apologize for sending these comments so= late in the LC.

Regards,
     Sasha
<= br>-----Original Message-----
From: = mpls-tp-bounces@ietf.org [ma= ilto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Thurs= day, February 03, 2011 1:37 PM
To: mpls-tp@i= etf.org; mpls@ietf.org
Cc: ahmpls-tp@lists.itu.int
Subject: [mpls-tp] wg= last call on draft-ietf-mpls-tp-fault-03

Working Group,

this= is to start a four week working group last call
on "MPLS Fault Mana= gement OAM" (draft-ietf-mpls-tp-fault-03).

Please send comments= to the mpls-tp@ietf.org mailing list.
<= br>This working group last call ends on February 28, 2011.



Lo= a, George and Ross

MPLS wg co-chairs

--

Loa Andersson &= nbsp;            = ;           email: loa.andersson@ericsson.com
Sr St= rategy and Standards Manager         = ;   loa@pi.nu
Ericsson Inc  = ;            &nb= sp;           phone:= +46 10 717 52 13
         &= nbsp;            = ;            &nb= sp;           +46 767= 72 92 13



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

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_A3C5DF08D38B6049839A6F553B331C76EBF2D3AB9AILPTMAIL02eci_-- From iesg-secretary@ietf.org Mon Jul 18 08:28:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5321F8C64; Mon, 18 Jul 2011 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnE62k22QuKH; Mon, 18 Jul 2011 08:28:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC9D21F8B91; Mon, 18 Jul 2011 08:28:57 -0700 (PDT) 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.55 Message-ID: <20110718152857.16050.43263.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2011 08:28:57 -0700 Cc: mpls@ietf.org Subject: [mpls] Third Last Call: (Packet Loss and Delay Measurement for MPLS Networks) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:28:58 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' as a Proposed Standard This is a third last call. The last call is only necessary because of a further late-received IPR disclosure. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-01. 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 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1574/ http://datatracker.ietf.org/ipr/1584/ From curtis@occnc.com Mon Jul 18 08:55:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C703621F8C83; Mon, 18 Jul 2011 08:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2RioLhRf-9y; Mon, 18 Jul 2011 08:55:06 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D203E21F8CA1; Mon, 18 Jul 2011 08:55:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6IFsw0P067519; Mon, 18 Jul 2011 11:54:58 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107181554.p6IFsw0P067519@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Mon, 18 Jul 2011 03:54:24 -0000." Date: Mon, 18 Jul 2011 11:54:58 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:55:06 -0000 In message Mach Chen writes: > > Hi Curtis, > > Thanks for your comments! > > The original purpose of this draft was for binding a PW to a co-routed > PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed" > is the major characteristic. In the draft, this is archived by setting > the "C" bit of the PSN Tunnel TLV. There is generally only one LSP between any A-Z in a provider core with PW carried inside the one LSP. Where there are multiple LSP it is generally because there are different QoS requirements, with more recent dicsussion focusing on delay requirements. > As for other characteristics, I am not sure whether we need carry all > those characteristics(at least for now), and as you said, if we do > that, it may eventually reinvent another CR-LDP. So, IMHO, it may be > better to limit the scope of the draft to the current form and leave > others for future study. If there are requirements for adding new > characteristic, we could incorporate it then. We would not reinvent CR-LDP if there was one loose hop specifying QoS requirments. The shortest path is followed, stopping at S-PE along the way. RSVP-TE is providing the ERO between PE and therefore handling the traffic engineering. > BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth > Signaling) has already defined a PW Bandwidth TLV to indicate > bandwidth characteristic, it also can apply in this draft. Yes. Bandwidth is covered. Resource affinity, holding priority. RFC4124 class type, etc is not covered. > Best regards, > Mach Thanks for the prompt reply. Best regards, Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Curtis Villamizar > > Sent: Saturday, July 16, 2011 1:51 AM > > To: mpls@ietf.org > > Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue > > > > > > Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > Mach, Ping, et al, > > > > The second issue which I pointed out in the last revision is that > > there is no way to indicate the characteristics required of a > > mid-segment of a MS-PW. The ingress (a T-PE) can specify the nodes, > > but it cannot specify which tunnel from S-PE to S-PE to use. It must > > specify the required characteristics of the tunnel to allow the S-PE > > to pick an appropriate tunnel. > > > > For example, an LSP contains sufficient information, such as > > bandwidth, holding and setup priority, resource affinitiy expressed as > > include-any, include-all, and exclude to be applied over the 32 bit > > administrative atrribute bit map. This allows simple things such as > > loose hops and not so simple things such as BRPC. > > > > It might be best to cite the RSVP-TE work and encapsulate the TLVs > > defined there into the PW. This is a bit like reinventing CR-LDP and > > if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW > > should be defined instead. I'm not really sure what the best way is > > to solve this. > > > > Curtis > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From scott.mansfield@ericsson.com Mon Jul 18 12:03:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976B921F855C for ; Mon, 18 Jul 2011 12:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OxxXz5ldPIT for ; Mon, 18 Jul 2011 12:03:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5535011E808B for ; Mon, 18 Jul 2011 12:03:19 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6IJ3Hbt019121; Mon, 18 Jul 2011 14:03:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 18 Jul 2011 15:03:12 -0400 From: Scott Mansfield To: Ross Callon , "mpls@ietf.org" Date: Mon, 18 Jul 2011 15:01:01 -0400 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gE0/8bA 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_FDC72027C316A44F82F425284E1C4C320B2D5968E0EUSAACMS0701e_" MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:03:53 -0000 --_000_FDC72027C316A44F82F425284E1C4C320B2D5968E0EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG adoption will be an excellent way to work through the issues in the curr= ent individual draft. Yes/support adoption. regards, -scott. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 11:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_FDC72027C316A44F82F425284E1C4C320B2D5968E0EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG=20 adoption will be an excellent way to work through the issues in the current= =20 individual draft.  Yes/support adoption.
 
regards,
-scott.

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent= :=20 Tuesday, July 12, 2011 11:32 AM
To: mpls@ietf.org
Cc:= Ross=20 Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject:= =20 [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please= =20
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document= =20
please respond to this poll with "no/do not support" and at the same= time=20
give the technical reasons why you are not supporting the document.<= /DIV>
 
If you have technical comments or in any other way want to discuss t= he=20
document, please send these comments to the mpls working group maili= ng=20
list, but with another subject than what is on this mail. Please inc= lude=20 the
string “draft-win-mpls-tp-itu-t-identifiers” in the subj= ect line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday= =20 before the
IETF. Also note that the length of the poll has  been shortened= by=20 two days
so that the poll can be completed prior to our first WG meeting in Q= uebec=20 City. 
 
Ross
 
--_000_FDC72027C316A44F82F425284E1C4C320B2D5968E0EUSAACMS0701e_-- From martin.vigoureux@alcatel-lucent.com Mon Jul 18 12:38:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CC821F8AD9 for ; Mon, 18 Jul 2011 12:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAH+mwSECeJK for ; Mon, 18 Jul 2011 12:38:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0457321F89BA for ; Mon, 18 Jul 2011 12:38:29 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6IJcLAX017168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2011 14:38:21 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6IJbwbA010657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Jul 2011 14:38:21 -0500 Received: from [135.244.19.124] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 18 Jul 2011 14:38:19 -0500 Message-ID: <4E248BA2.8060903@alcatel-lucent.com> Date: Mon, 18 Jul 2011 21:38:10 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Agenda of MPLS Sessions at IETF81 uploaded X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:38:30 -0000 all, the agenda is uploaded: http://www.ietf.org/proceedings/81/agenda/mpls.txt As you'll notice we are packed so please respect your slot duration. Please consider that the slot duration accounts for both your presentation and the potential questions that it might trigger. martin ps: if you are not on the agenda this is most surely because you did not send me any request ... From yaacov.weingarten@nsn.com Tue Jul 19 06:09:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0167D21F86B1 for ; Tue, 19 Jul 2011 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2vnns2sA9hu for ; Tue, 19 Jul 2011 06:08:59 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9DA21F85A7 for ; Tue, 19 Jul 2011 06:08:58 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6JD8smX027144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 15:08:55 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6JD8sUI012597; Tue, 19 Jul 2011 15:08:54 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jul 2011 15:08:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4615.028BEE3E" Date: Tue, 19 Jul 2011 15:08:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gE0/8bAACYEI/A= References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Scott Mansfield" , "Ross Callon" , X-OriginalArrivalTime: 19 Jul 2011 13:08:53.0932 (UTC) FILETIME=[02A1D6C0:01CC4615] Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:09:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4615.028BEE3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Yes/Support =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Scott Mansfield Sent: Monday, July 18, 2011 10:01 PM To: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 WG adoption will be an excellent way to work through the issues in the current individual draft. Yes/support adoption. =20 regards, -scott. =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, July 12, 2011 11:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same time=20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include the=20 string "draft-win-mpls-tp-itu-t-identifiers" in the subject line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before the=20 IETF. Also note that the length of the poll has been shortened by two days=20 so that the poll can be completed prior to our first WG meeting in Quebec City. =20 =20 Ross =20 ------_=_NextPart_001_01CC4615.028BEE3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1  Yes/Support

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Scott Mansfield
Sent: Monday, July 18, 2011 10:01 = PM
To: Ross Callon; mpls@ietf.org
Cc: = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = Re: [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

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

WG= adoption will be an excellent way to work through the issues in the = current individual draft.  Yes/support = adoption.

 

re= gards,

-s= cott.

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: Tuesday, July 12, 2011 11:32 = AM
To: mpls@ietf.org
Cc: Ross Callon; = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

Working = Group,

 =

this is to = start a 12 day poll on making

 =

draft-win-m= pls-tp-itu-t-identifiers-01

 =

an mpls = working group document.

 =

If you = support the document becoming a working group document please =

respond to = this poll with = "yes/support"

 =

If you do = not support the document becoming a working group document =

please = respond to this poll with "no/do not support" and at the same = time

give the = technical reasons why you are not supporting the = document.

 =

If you = have technical comments or in any other way want to discuss the =

document, = please send these comments to the mpls working group mailing =

list, but = with another subject than what is on this mail. Please include the =

string = “draft-win-mpls-tp-itu-t-identifiers” in the subject line. =

 =

The poll = ends 2011-07-24.  Please note that this is the Sunday before the =

IETF. Also = note that the length of the poll has  been shortened by two days =

so that = the poll can be completed prior to our first WG meeting in Quebec = City. 

 =

Ross

 =

------_=_NextPart_001_01CC4615.028BEE3E-- From matthew.bocci@alcatel-lucent.com Tue Jul 19 06:43:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6421F874E for ; Tue, 19 Jul 2011 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dPv8zIu2IMR for ; Tue, 19 Jul 2011 06:43:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B176321F855D for ; Tue, 19 Jul 2011 06:43:41 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6JDQJNB015181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Jul 2011 15:43:37 +0200 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; Tue, 19 Jul 2011 15:42:54 +0200 From: "Bocci, Matthew (Matthew)" To: "mpls@ietf.org" Date: Tue, 19 Jul 2011 15:42:51 +0200 Thread-Topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGcJlNrU73XoaQQuTuMMHqoR0ww== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CA4B479E14360matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:43:42 -0000 --_004_CA4B479E14360matthewboccialcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_CA4B479E14360matthewboccialcatellucentcom_" --_000_CA4B479E14360matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have just started a poll of the PWE3 mailing list for PWE3 WG adoption o= f draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant = to MPLS-TP. Please send any comments to the PWE3 mailing list. Best regards Matthew On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" > wrote: This email begins a poll of the list to see if there is consensus to adopt = draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working gro= up draft. Please indicate whether or not you support adoption of this draft, and send= any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. --_000_CA4B479E14360matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We have just started a p= oll of the PWE3 mailing list for PWE3 WG adoption of draft-martini-pwe= 3-status-aggregation-protocol-03.txt, which is relevant to MPLS-TP.

Please send any comments to the PWE3 mailing list.
<= div>
Best regards

Matthew
=
On 19/07/2011 14:36, = "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> wrote:
This email begins a poll of the list to see if there i= s consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03= .txt as a PWE3 working group draft.

Please indicat= e whether or not you support adoption of this draft, and send any comments = to the PWE3 list.

This poll ends on Tuesday 9th Au= gust.

Regards,

Matthew an= d Andy.
 --_000_CA4B479E14360matthewboccialcatellucentcom_-- --_004_CA4B479E14360matthewboccialcatellucentcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 19 Jul 2011 15:42:53 GMT"; modification-date="Tue, 19 Jul 2011 15:42:53 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFp bGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3B3ZTMNCg== --_004_CA4B479E14360matthewboccialcatellucentcom_-- From tnadeau@lucidvision.com Tue Jul 19 07:16:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3246721F8606 for ; Tue, 19 Jul 2011 07:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThX2wBmQxhlV for ; Tue, 19 Jul 2011 07:16:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EF72121F8507 for ; Tue, 19 Jul 2011 07:16:01 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E54EB1D094B4; Tue, 19 Jul 2011 10:16:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-37--82213911 From: Thomas Nadeau In-Reply-To: Date: Tue, 19 Jul 2011 10:15:51 -0400 Message-Id: <2A26CE60-2615-4A3A-8A02-9554062C1470@lucidvision.com> References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1084) Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 14:16:06 -0000 --Apple-Mail-37--82213911 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On Jul 19, 2011, at 9:42 AM, Bocci, Matthew (Matthew) wrote: > We have just started a poll of the PWE3 mailing list for PWE3 WG = adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, which = is relevant to MPLS-TP. >=20 > Please send any comments to the PWE3 mailing list. >=20 > Best regards >=20 > Matthew >=20 > On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" = wrote: >=20 >> This email begins a poll of the list to see if there is consensus to = adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 = working group draft. >>=20 >> Please indicate whether or not you support adoption of this draft, = and send any comments to the PWE3 list. >>=20 >> This poll ends on Tuesday 9th August. >>=20 >> Regards, >>=20 >> Matthew and Andy. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-37--82213911 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
We have just = started a poll of the PWE3 mailing list for PWE3 WG adoption = of draft-martini-pwe3-status-aggregation-protocol-03.txt, which is = relevant to MPLS-TP.

Please send any comments = to the PWE3 mailing list.

Best = regards

Matthew

On 19/07/2011 14:36, "Bocci, = Matthew (Matthew)" <matthew.bocci@alcatel-luc= ent.com> wrote:

This email begins a poll = of the list to see if there is consensus to = adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a = PWE3 working group draft.

Please indicate = whether or not you support adoption of this draft, and send any comments = to the PWE3 list.

This poll ends on Tuesday 9th = August.

Regards,

Matthew= and Andy.
_______________________________________________
pwe3 mailing = list
pwe3@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pwe3
_______________________________________________
= mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

= --Apple-Mail-37--82213911-- From Internet-Drafts@ietf.org Tue Jul 19 08:45:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D63D11E8073; Tue, 19 Jul 2011 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzkXj+2lJiKo; Tue, 19 Jul 2011 08:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1421F8A4E; Tue, 19 Jul 2011 08:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110719154501.23591.37418.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 08:45:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-loss-delay-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:45:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Packet Loss and Delay Measurement for MPLS Networks Author(s) : D. Frost, et al Filename : draft-ietf-mpls-loss-delay-04.txt Pages : 52 Date : 2011-07-19 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-loss-delay-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-loss-delay-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-19084223.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jul 19 09:00:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3111E8086; Tue, 19 Jul 2011 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBHPJzSf3Yfj; Tue, 19 Jul 2011 09:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEAC11E807A; Tue, 19 Jul 2011 09:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110719160002.28865.1569.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 09:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-loss-delay-profile-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:00:07 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks Author(s) : D. Frost, et al Filename : draft-ietf-mpls-tp-loss-delay-profile-04.txt Pages : 6 Date : 2011-07-19 Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC XXXX. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-loss-delay-profile-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-loss-delay-profile-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-19084805.I-D@ietf.org> --NextPart-- From prvs=4181279894=edwin.mallette@bhnis.com Tue Jul 19 09:10:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9218021F84DF for ; Tue, 19 Jul 2011 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW6JgWUvgFSk for ; Tue, 19 Jul 2011 09:10:32 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8551321F85F3 for ; Tue, 19 Jul 2011 09:10:31 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p6JFvl6X014217; Tue, 19 Jul 2011 12:10:28 -0400 Received: from cntpacas2.corp.local ([10.225.1.125]) by mx3.mybrighthouse.com with ESMTP id xnby3rce9-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Jul 2011 12:10:28 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpacas2.corp.local ([10.225.1.125]) with mapi; Tue, 19 Jul 2011 12:10:28 -0400 From: "Mallette, Edwin" To: "Bocci, Matthew (Matthew)" , "mpls@ietf.org" Date: Tue, 19 Jul 2011 12:10:27 -0400 Thread-Topic: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGLl/qqhrYFqBfSB6kDK/zb+sSgQ== 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.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA4AFA4011DFBedwinmallettebhniscom_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107190104 Subject: Re: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:10:32 -0000 --_000_CA4AFA4011DFBedwinmallettebhniscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Cheers! Ed From: "Bocci, Matthew (Matthew)" > Date: Tue, 19 Jul 2011 09:42:51 -0400 To: "mpls@ietf.org" > Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregatio= n-protocol-03.txt We have just started a poll of the PWE3 mailing list for PWE3 WG adoption o= f draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant = to MPLS-TP. Please send any comments to the PWE3 mailing list. Best regards Matthew On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" > wrote: This email begins a poll of the list to see if there is consensus to adopt = draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working gro= up draft. Please indicate whether or not you support adoption of this draft, and send= any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_CA4AFA4011DFBedwinmallettebhniscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.

Cheers!

Ed

From: "Bocci, Matthew (Matthew= )" <matthew.boc= ci@alcatel-lucent.com>
Date: Tue, 19 Jul 2011 09:42:51 -04= 00
To: "mpls@ietf.org" <mpls@i= etf.org>
Subject: [mpls] FW: [PWE3] WG Poll = for draft-martini-pwe3-status-aggregation-protocol-03.txt

We have just started a poll of the PWE3 mailing list for PWE3 WG adopt= ion of draft-martini-pwe3-status-aggregation-protocol-03.txt, which is= relevant to MPLS-TP.

Please send any comments to the PWE3 mailing list.

Best regards

Matthew

On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.c= om> wrote:

This email begins a poll of the list to see if there is consensus to a= dopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 w= orking group draft.

Please indicate whether or not you support adoption of this draft, and= send any comments to the PWE3 list.

This poll ends on Tuesday 9th August.

Regards,

Matthew and Andy.

CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
 --_000_CA4AFA4011DFBedwinmallettebhniscom_-- From davari@broadcom.com Tue Jul 19 09:59:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39A21F8581 for ; Tue, 19 Jul 2011 09:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pINlDwzGG5BE for ; Tue, 19 Jul 2011 09:59:23 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7142021F857D for ; Tue, 19 Jul 2011 09:59:23 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 19 Jul 2011 10:04:33 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 19 Jul 2011 09:59:15 -0700 From: "Shahram Davari" To: "Bocci, Matthew (Matthew)" , "mpls@ietf.org" Date: Tue, 19 Jul 2011 09:59:13 -0700 Thread-Topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGcJlNrU73XoaQQuTuMMHqoR0wwAG2JxQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93234E087@SJEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 623B66AB3DK517995-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6A93234E087SJEXCHCCR02co_ Subject: Re: [mpls] [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:59:24 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A93234E087SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support., Shahram From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Tuesday, July 19, 2011 6:43 AM To: mpls@ietf.org Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregatio= n-protocol-03.txt We have just started a poll of the PWE3 mailing list for PWE3 WG adoption o= f draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant = to MPLS-TP. Please send any comments to the PWE3 mailing list. Best regards Matthew On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" > wrote: This email begins a poll of the list to see if there is consensus to adopt = draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working gro= up draft. Please indicate whether or not you support adoption of this draft, and send= any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. --_000_2C2F1EBA8050E74EA81502D5740B4BD6A93234E087SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Support.,

 

Shahram

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On Behalf Of Bocci, Matthew (Matthew)
Sent: Tuesday, J= uly 19, 2011 6:43 AM
To: mpls@ietf.org
Subject: [mpls] = FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.tx= t

 

We have just started a poll of the PWE3 ma= iling list for PWE3 WG adoption of draft-martini-pwe3-status-aggregati= on-protocol-03.txt, which is relevant to MPLS-TP.

 

Please send any comments to the PWE3 mailing list.

 <= /span>

Best regards

 

Matthew

 

On 19/07/2011 14:36, "Bocci, Matthew (Matthew)"= ; <matthew.bocci@alc= atel-lucent.com> wrote:

 

<= div>

This email begins a poll of the lis= t to see if there is consensus to adopt draft-martini-pwe3-status-aggr= egation-protocol-03.txt as a PWE3 working group draft.

 

Please indicate whether or not you support adop= tion of this draft, and send any comments to the PWE3 list.

 

This poll ends on Tuesday 9th August.=

 

Regards,

<= /div>

 

=

Matthew and Andy.

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6A93234E087SJEXCHCCR02co_-- From adrian@olddog.co.uk Tue Jul 19 13:12:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642BC21F8AB9; Tue, 19 Jul 2011 13:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNlJW4EXTtsU; Tue, 19 Jul 2011 13:12:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7584B21F89CC; Tue, 19 Jul 2011 13:12:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JK9GSk007746; Tue, 19 Jul 2011 21:09:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JK9Ewr007724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 21:09:16 +0100 From: "Adrian Farrel" To: , "'CCAMP'" Date: Tue, 19 Jul 2011 21:12:48 +0100 Message-ID: <00fa01cc4650$3c1997e0$b44cc7a0$@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: AcxGT+Xet643lgRjQNalrlcZ/HFG5A== Content-Language: en-gb Subject: [mpls] FW: Last Call: (Applicability of Keying Methods for RSVP Security) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:12:53 -0000 MPLS and CCAMP working groups. Please be aware of and participate in this IETF last call. Thanks, Adrian > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > The IESG > Sent: 18 July 2011 14:29 > To: IETF-Announce > Cc: tsvwg@ietf.org > Subject: Last Call: > (Applicability of Keying Methods for RSVP Security) to Informational RFC > > > The IESG has received a request from the Transport Area Working Group > (tsvwg) to consider the following document: > - 'Applicability of Keying Methods for RSVP Security' > as an Informational > RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-01. 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 > > > The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity > protection of RSVP neighbors. This requires messages to be > cryptographically protected using a shared secret between > participating nodes. This document compares group keying for RSVP > with per neighbor or per interface keying, and discusses the > associated key provisioning methods as well as applicability and > limitations of these approaches. The document also discusses > applicability of encrypting RSVP messages. > > The Responsible AD notes that the IPR declaration terms seem to apply to > standards-track documents, but not necessarily to an Informational document. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/988/ > From rcallon@juniper.net Tue Jul 19 13:29:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09F521F8B26 for ; Tue, 19 Jul 2011 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbUl6oPVBnSJ for ; Tue, 19 Jul 2011 13:29:51 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE321F8B18 for ; Tue, 19 Jul 2011 13:29:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXpO/HYoYIoemgrMOLEs8B10EfJrTh6@postini.com; Tue, 19 Jul 2011 13:29:50 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Jul 2011 13:27:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 19 Jul 2011 16:27:25 -0400 From: Ross Callon To: John E Drake Date: Tue, 19 Jul 2011 16:27:23 -0400 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaAAWGobxA= Message-ID: References: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> 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_DF7F294AF4153D498141CBEFADB17704C2A0072DE9EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:29:52 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2A0072DE9EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John; Accepting a document as a working group document is very different from dec= iding whether it is ready to pass WG last call. In deciding whether to accept a document as a working group document, we ne= ed to think about whether this is an appropriate work for the WG to take on= , is in the WG's charter, and whether the document is a reasonable start to= wards a working group document. It certainly does not need to be complete o= r in a finished form. In this case, the notion of having identifiers based on the ITU-T's ICC cod= es was previously in a working group document, but was removed because we f= ound technical issues with it. This document is a start at resolving those = issues. Ross From: John E Drake Sent: Tuesday, July 12, 2011 2:50 PM To: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Ross, Isn't it a bit premature to be asking to make this a working group document= ? Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_DF7F294AF4153D498141CBEFADB17704C2A0072DE9EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John;

 

<= p class=3DMsoNormal>Accepting a document as a working group document= is very different from deciding whether it is ready to pass WG last call. =

 <= /p>

In deciding whether to accept a document as = a working group document, we need to think about whether this is an appropr= iate work for the WG to take on, is in the WG’s charter, and whether = the document is a reasonable start towards a working group document. It cer= tainly does not need to be complete or in a finished form.

 

In this case, the notion of having identifiers based on the = ITU-T’s ICC codes was previously in a working group document, but was= removed because we found technical issues with it. This document is a star= t at resolving those issues.

 

Ross=

 

From: John E Drake
Sent: Tuesday, July = 12, 2011 2:50 PM
To: Ross Callon; mpls@ietf.org
Cc: dra= ft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: RE: Poll= on draft-win-mpls-tp-itu-t-identifiers-01

 

Ross= ,

 =

Isn’t it a bit premature to be asking= to make this a working group document?

 

Than= ks,

 

John

 

S= ent from my iPhone

<= o:p> 

From: mp= ls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross= Callon
Sent: Tuesday, July 12, 2011 8:32 AM
To: mpls@i= etf.org
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tool= s.ietf.org
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identi= fiers-01

 <= /o:p>

Working Group,

=

 

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>this is = to start a 12 day poll on making

 

draft-win-mpls-t= p-itu-t-identifiers-01

 =

an mpls working group docume= nt.

 <= /p>

If you support the document becoming a working = group document please

respon= d to this poll with "yes/support"

 

= If you = do not support the document becoming a working group document

please respond to this poll with "no= /do not support" and at the same time

give the technical reasons why you are not supporting the do= cument.

 

If you have technical comments or in any ot= her way want to discuss the

= document, please send these comments to the mpls working group mailing

list, but with another subject t= han what is on this mail. Please include the

string “draft-win-mpls-tp-itu-t-identifiers” i= n the subject line.

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'> 

The poll ends 2011-07-24. = ; Please note that this is the Sunday before the

IETF. Also note that the length of the poll has  = been shortened by two days

s= o that the poll can be completed prior to our first WG meeting in Quebec Ci= ty. 

 <= /span>

Ross

 

= --_000_DF7F294AF4153D498141CBEFADB17704C2A0072DE9EMBX01WFjnprn_-- From jdrake@juniper.net Tue Jul 19 13:48:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9559321F8ADC for ; Tue, 19 Jul 2011 13:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNC-+nmyZyMv for ; Tue, 19 Jul 2011 13:48:34 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 6150F21F8AD8 for ; Tue, 19 Jul 2011 13:48:34 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXtno8LZU+Vb+IBR5ZjGkgtzceACaqk@postini.com; Tue, 19 Jul 2011 13:48:34 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 19 Jul 2011 13:46:16 -0700 From: John E Drake To: Ross Callon Date: Tue, 19 Jul 2011 13:46:14 -0700 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaAAWGobxAAAmtLUA== Message-ID: <5E893DB832F57341992548CDBB333163A0A9711B42@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0A91E82B2@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_5E893DB832F57341992548CDBB333163A0A9711B42EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:48:36 -0000 --_000_5E893DB832F57341992548CDBB333163A0A9711B42EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross, Thanks for your clarification and I will answer yes to your question. John Sent from my iPhone From: Ross Callon Sent: Tuesday, July 19, 2011 1:27 PM To: John E Drake Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org; mpls@ietf.org Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01 John; Accepting a document as a working group document is very different from dec= iding whether it is ready to pass WG last call. In deciding whether to accept a document as a working group document, we ne= ed to think about whether this is an appropriate work for the WG to take on= , is in the WG's charter, and whether the document is a reasonable start to= wards a working group document. It certainly does not need to be complete o= r in a finished form. In this case, the notion of having identifiers based on the ITU-T's ICC cod= es was previously in a working group document, but was removed because we f= ound technical issues with it. This document is a start at resolving those = issues. Ross From: John E Drake Sent: Tuesday, July 12, 2011 2:50 PM To: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Ross, Isn't it a bit premature to be asking to make this a working group document= ? Thanks, John Sent from my iPhone From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_5E893DB832F57341992548CDBB333163A0A9711B42EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ross,

 

<= p class=3DMsoNormal>Thanks for your clarification and I will answer = yes to your question.

 

John    =

 <= /p>

Sent from my iPhone

 

From: Ross Callon
Sent: Tuesday, J= uly 19, 2011 1:27 PM
To: John E Drake
Cc: draft-win-mpl= s-tp-itu-t-identifiers@tools.ietf.org; mpls@ietf.org
Subject: RE:= Poll on draft-win-mpls-tp-itu-t-identifiers-01

=

 

John;

 

Accepting a document as a working grou= p document is very different from deciding whether it is ready to pass WG l= ast call.

 

In deciding whether to accept a do= cument as a working group document, we need to think about whether this is = an appropriate work for the WG to take on, is in the WG’s charter, an= d whether the document is a reasonable start towards a working group docume= nt. It certainly does not need to be complete or in a finished form. <= /o:p>

 

In this case, the notion of having identifiers bas= ed on the ITU-T’s ICC codes was previously in a working group documen= t, but was removed because we found technical issues with it. This document= is a start at resolving those issues.

 

Ross=

 <= /p>

From: John E Drake
Sent: Tue= sday, July 12, 2011 2:50 PM
To: Ross Callon; mpls@ietf.org
= Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01

=

 

= Ross,

 

Isn’t it a bit premature t= o be asking to make this a working group document?

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Thanks,

 <= /o:p>

John

 

Sent from my iPhone

 

F= rom: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f Ross Callon
Sent: Tuesday, July 12, 2011 8:32 AM
To:<= /b> mpls@ietf.org
Cc: Ross Callon; draft-win-mpls-tp-itu-t-identi= fiers@tools.ietf.org
Subject: [mpls] Poll on draft-win-mpls-tp-it= u-t-identifiers-01

 

Working Group,

<= /div>

 

this is to start a 12 day poll on making

=

 

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'>draft-wi= n-mpls-tp-itu-t-identifiers-01

 

an mpls working gr= oup document.

 

If you support the document becoming = a working group document please

respond to this poll with "yes/support"

 

If you do not support the document becoming a working group document =

please respond to this poll = with "no/do not support" and at the same time <= /p>

give the technical reasons why you are not supp= orting the document.

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif"'> 

If you have technical comments= or in any other way want to discuss the

<= p class=3DMsoNormal>document, please send these comments to the mpls working group= mailing

list, but with ano= ther subject than what is on this mail. Please include the

string “draft-win-mpls-tp-itu-t-identi= fiers” in the subject line.

 

The poll ends 20= 11-07-24.  Please note that this is the Sunday before the <= /span>

IETF. Also note that the length of the p= oll has  been shortened by two days

<= p class=3DMsoNormal>so that the poll can be completed prior to our first WG meetin= g in Quebec City. 

&nbs= p;

Ross

=

 

= --_000_5E893DB832F57341992548CDBB333163A0A9711B42EMBX01HQjnprn_-- From adrian@olddog.co.uk Tue Jul 19 14:48:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF1221F8512 for ; Tue, 19 Jul 2011 14:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY+OL978rkRQ for ; Tue, 19 Jul 2011 14:48:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1802E21F850F for ; Tue, 19 Jul 2011 14:48:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JLmWbk031439; Tue, 19 Jul 2011 22:48:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JLmVWj031431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 22:48:32 +0100 From: "Adrian Farrel" To: Date: Tue, 19 Jul 2011 22:48:31 +0100 Message-ID: <011701cc465d$9a341870$ce9c4950$@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: AcxGXZgVVzEprL13TjarkY4rUioyqw== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD Review of draft-ietf-mpls-tp-on-demand-cv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:48:35 -0000 Hi, I have performed my AD review of your draft prior to IETF last call and IESG review. The purpose is to find any issues that might be raised at those stages and to try to achieve a smoother progress through the system. My review has thrown up a number of minor editorial issues and a couple of concerns with the IANA section. Otherwise the I-D is in pretty good shape - thanks. Can you please have a look at the issues below and spin a new revision. All issues are, of course, open for debate. I have put the I-D into Revised ID Needed state, and as soon as I see a revision, I will start the IETF last call. Thanks, Adrian --- Please expand LSP in the Abstract Ditto in Section 1 --- Section 1.1 Immediately after your careful text explaining terms you use "traceroute" without explanation! --- Please expand LSR in Section 1.2 --- Please expand ACH in Section 1.3 --- Section 2.2.3 When sending On-demand CV packets using ACH, without IP encapsulation, there MAY be a need to identify the destination of the packet. I think s/MAY/may/ You mean "may" as in "might" not as in "an implementation is permitted" --- Section 2.3 In order to identify a statically provisioned LSP and PW, new target FEC stack sub-TLVs are being defined. The new sub-TLVs are assigned sub-type identifiers as follows, and are described in the following sections. The present continuous tense is unhelpful. Do you mean "are defined in this document"? --- Section 2.3.1 and 2.3.2 s/global/Global/ --- Section 3.4.1 The MBZ field is not defined or explained. 0 on TX, ignore on RX? --- Section 7.1, 7.2, 7.3 In all three subsections you have misnamed the registry. Should read... "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" --- Section 7.2 IANA is requested to assign sub-type values to the following sub-TLVs Should read IANA has made early assignment of sub-type values to the following sub-TLVs. IANA is requested to make the assignments permanent. --- Section 7.5 It would help IANA if you named the new sub-registry and told them which is the parent registry. Because the field in this case is an 8-octet field, the basis for all future allocations SHOULD be "Standards Based." I think this is an 8 bit field! But also, I think that the reasoning is not important to IANA. You just have to tell them what to do. Please don't use RFC 2119 language in the IANA section. "Standards Based" does not a recognised allocation policy. So... NEW The allocation policy for this registry is "Standards Action" [RFC5226]. END --- Heads-up on manageability. We are currently attracting a bit of interest from the Ops ADs on our drafts wrt how to make them manageable. There is not a requirement to specify MIB or YANG modules, but there is pressure to draw out the "objects" that should be configurable, and those that should be inspectable in a "Normal" implementation. I don't think this is a lot of work (and you have done it a bit in some places such as Section 3.6. Can you look to see whether you can draw something together for a small new section called "Guidance on Manageability" From fu.xihua@zte.com.cn Tue Jul 19 21:07:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA3221F8B01; Tue, 19 Jul 2011 21:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.137 X-Spam-Level: X-Spam-Status: No, score=-99.137 tagged_above=-999 required=5 tests=[AWL=1.212, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUE91Rf0Juyk; Tue, 19 Jul 2011 21:07:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A1EC021F8B00; Tue, 19 Jul 2011 21:07:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322623888924; Wed, 20 Jul 2011 12:00:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2623888924; Wed, 20 Jul 2011 12:07:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6K47W8X085309; Wed, 20 Jul 2011 12:07:32 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: mpls@ietf.org, ospf@ietf.org, ccamp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Wed, 20 Jul 2011 12:07:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-20 12:07:33, Serialize complete at 2011-07-20 12:07:33 Content-Type: multipart/alternative; boundary="=_alternative 0016AAA4482578D3_=" X-MAIL: mse01.zte.com.cn p6K47W8X085309 Subject: [mpls] Request for your comments on Delay/Loss TE X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 04:07:56 -0000 This is a multipart message in MIME format. --=_alternative 0016AAA4482578D3_= Content-Type: text/plain; charset="US-ASCII" Hi All, http://tools.ietf.org/html/draft-fuxh-ccamp-delay-loss-te-framework-00 http://tools.ietf.org/html/draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00 These document are about the requirement of delay/loss TE application and solutions in the level of control plane. The purpose of delay/loss TE application is to make an accurate prediction of latency and packet loss before a path is establish is required. We have presented them in 79th and 80th in CCAMP. Chairs (Ross and Lou) suggest latency/loss framework and rsvp-te document should be presented in MPLS WG. We will rename the document having title "mpls" and post them to MPLS WG later. There is also a related document about the OSPF extension http://tools.ietf.org/html/draft-giacalone-ospf-te-express-path-01 Wish for your comments. Xihua Fu (One of Authors) --=_alternative 0016AAA4482578D3_= Content-Type: text/html; charset="US-ASCII"
Hi All,

http://tools.ietf.org/html/draft-fuxh-ccamp-delay-loss-te-framework-00
http://tools.ietf.org/html/draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00
These document are about the requirement of delay/loss TE application and solutions in the level of control plane.
The purpose of delay/loss TE application is to make an accurate prediction of latency and packet loss before a path is establish is required.

We have presented them in 79th and 80th in CCAMP.
Chairs (Ross and Lou) suggest latency/loss framework and rsvp-te document should be presented in MPLS WG.
We will rename the document having title "mpls" and post them to MPLS WG later.

There is also a related document about the OSPF extension
http://tools.ietf.org/html/draft-giacalone-ospf-te-express-path-01

Wish for your comments.

Xihua Fu (One of Authors) --=_alternative 0016AAA4482578D3_=-- From nurit.sprecher@nsn.com Tue Jul 19 23:05:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7EA21F8915 for ; Tue, 19 Jul 2011 23:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=1.945, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWItDKW7d85p for ; Tue, 19 Jul 2011 23:05:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D5DBD21F89CC for ; Tue, 19 Jul 2011 23:05:49 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p6K65jCd013113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 08:05:45 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p6K65eLq010790; Wed, 20 Jul 2011 08:05:42 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 07:43:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC46A0.02C87934" Date: Wed, 20 Jul 2011 07:43:53 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264042432E9@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAG4SaAAWGobxAAFSSYIA== References: <5E893DB832F57341992548CDBB333163A0A91E82B2@EMBX01-HQ.jnpr.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Ross Callon" , "John E Drake" X-OriginalArrivalTime: 20 Jul 2011 05:43:54.0636 (UTC) FILETIME=[030654C0:01CC46A0] Cc: mpls@ietf.org, draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 06:05:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC46A0.02C87934 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ross hi, I fully agree with your point. As mentioned before, I think we need to work on this. My concern is how we ensure that ITU-T code is defined appropriately and in consistent way with other definitions in transport networks? I have seen technical debates on the definition both in the ITU-T and the IETF mailing lists.=20 I would prefer we refer to a definition in an ITU-T recommendation.=20 Best regards, Nurit=20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Ross Callon Sent: Tuesday, July 19, 2011 11:27 PM To: John E Drake Cc: mpls@ietf.org; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 John; =20 Accepting a document as a working group document is very different from deciding whether it is ready to pass WG last call.=20 =20 In deciding whether to accept a document as a working group document, we need to think about whether this is an appropriate work for the WG to take on, is in the WG's charter, and whether the document is a reasonable start towards a working group document. It certainly does not need to be complete or in a finished form.=20 =20 In this case, the notion of having identifiers based on the ITU-T's ICC codes was previously in a working group document, but was removed because we found technical issues with it. This document is a start at resolving those issues.=20 =20 Ross =20 From: John E Drake=20 Sent: Tuesday, July 12, 2011 2:50 PM To: Ross Callon; mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 Ross, =20 Isn't it a bit premature to be asking to make this a working group document? =20 Thanks, =20 John =20 Sent from my iPhone =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, July 12, 2011 8:32 AM To: mpls@ietf.org Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 =20 Working Group, =20 this is to start a 12 day poll on making =20 draft-win-mpls-tp-itu-t-identifiers-01 =20 an mpls working group document. =20 If you support the document becoming a working group document please=20 respond to this poll with "yes/support" =20 If you do not support the document becoming a working group document=20 please respond to this poll with "no/do not support" and at the same time=20 give the technical reasons why you are not supporting the document. =20 If you have technical comments or in any other way want to discuss the=20 document, please send these comments to the mpls working group mailing=20 list, but with another subject than what is on this mail. Please include the=20 string "draft-win-mpls-tp-itu-t-identifiers" in the subject line.=20 =20 The poll ends 2011-07-24. Please note that this is the Sunday before the=20 IETF. Also note that the length of the poll has been shortened by two days=20 so that the poll can be completed prior to our first WG meeting in Quebec City. =20 =20 Ross =20 ------_=_NextPart_001_01CC46A0.02C87934 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ross hi,

I fully agree with your point.

As mentioned before, I think we need to work on = this.

My concern is how we ensure that ITU-T code is defined appropriately = and in consistent way with other definitions in transport networks? I = have seen technical debates on the definition both in the ITU-T and the = IETF mailing lists.

I would prefer we refer to a definition in an ITU-T recommendation. =

Best regards,

Nurit

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Ross Callon
Sent: Tuesday, July 19, 2011 11:27 = PM
To: John E Drake
Cc: mpls@ietf.org; = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = Re: [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

<= p class=3DMsoNormal> 

John;

 

Accepting a document as a working group document is very different = from deciding whether it is ready to pass WG last call. =

 

In deciding whether to accept a document as a working group document, = we need to think about whether this is an appropriate work for the WG to = take on, is in the WG’s charter, and whether the document is a = reasonable start towards a working group document. It certainly does not = need to be complete or in a finished form.

 

In this case, the notion of having identifiers based on the = ITU-T’s ICC codes was previously in a working group document, but = was removed because we found technical issues with it. This document is = a start at resolving those issues.

 

Ross

 

From:= = John E Drake
Sent: Tuesday, July 12, 2011 2:50 = PM
To: Ross Callon; mpls@ietf.org
Cc: = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = RE: Poll on = draft-win-mpls-tp-itu-t-identifiers-01

<= p class=3DMsoNormal> 

Ross,

 

Isn’t it a bit premature to be asking to make this a working = group document?

 

Thanks,

 

John

 

Sent from my iPhone

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: Tuesday, July 12, 2011 8:32 = AM
To: mpls@ietf.org
Cc: Ross Callon; = draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org
Subject: = [mpls] Poll on = draft-win-mpls-tp-itu-t-identifiers-01

<= p class=3DMsoNormal> 

Working = Group,

 =

this is to = start a 12 day poll on making

 =

draft-win-m= pls-tp-itu-t-identifiers-01

 =

an mpls = working group document.

 =

If you = support the document becoming a working group document please =

respond to = this poll with = "yes/support"

 =

If you do = not support the document becoming a working group document =

please = respond to this poll with "no/do not support" and at the same = time

give the = technical reasons why you are not supporting the = document.

 =

If you = have technical comments or in any other way want to discuss the =

document, = please send these comments to the mpls working group mailing =

list, but = with another subject than what is on this mail. Please include the =

string = “draft-win-mpls-tp-itu-t-identifiers” in the subject line. =

 =

The poll = ends 2011-07-24.  Please note that this is the Sunday before the =

IETF. Also = note that the length of the poll has  been shortened by two days =

so that = the poll can be completed prior to our first WG meeting in Quebec = City. 

 =

Ross

 =

------_=_NextPart_001_01CC46A0.02C87934-- From martin.vigoureux@alcatel-lucent.com Wed Jul 20 08:48:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FC421F8A62 for ; Wed, 20 Jul 2011 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aHLtCkO8TIx for ; Wed, 20 Jul 2011 08:48:46 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2532321F899F for ; Wed, 20 Jul 2011 08:48:45 -0700 (PDT) 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 p6KFmdk0028223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Jul 2011 17:48:44 +0200 Received: from [172.27.205.189] (135.120.57.7) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 20 Jul 2011 17:48:40 +0200 Message-ID: <4E26F8D8.2060308@alcatel-lucent.com> Date: Wed, 20 Jul 2011 17:48:40 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Deadline for the slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:48:47 -0000 Hello To those who have a slot, on Monday: please send me the slides, no later than Sunday, 2pm, Quebec time on Wednesday: please send me the slides, no later than Tuesday, 10pm, Quebec time Failure to provide the slides in time will most likely lead to the move of your slot at the end of the session. Knowing that the agenda is full, it would be a pity to loose your slot. Please take into account that the slot duration is both for your presentation and the Q&As after. Thank you martin From rcallon@juniper.net Wed Jul 20 16:35:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170B21F8AB9 for ; Wed, 20 Jul 2011 16:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHeMk9xV1Mgd for ; Wed, 20 Jul 2011 16:35:45 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E521F880C for ; Wed, 20 Jul 2011 16:35:45 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTidmUM9ApO9OxJGiCO1z83GagwejihlH@postini.com; Wed, 20 Jul 2011 16:35:45 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Jul 2011 16:35:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 20 Jul 2011 19:35:42 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 20 Jul 2011 19:35:41 -0400 Thread-Topic: MPLS liaison manager to ITU-T Thread-Index: AcxDChattQxGzO+CT9+mljHDJuqHkAD1FFtwAA7purA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2A024C45EEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "iab@iab.org" Subject: [mpls] MPLS liaison manager to ITU-T X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:35:47 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2A024C45EEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current liaison manager from the IETF to ITU-T for MPLS is Stewart Brya= nt. However, Stewart is intending to step down from this liaison manager ro= le. The IAB intends to make a decision next week (during the IETF in Quebec= City) on Stewart's replacement. If anyone would like to volunteer for this position then please send email = preferably by Friday of this week to the IAB (iab@iab.org), CC me (rcallon@juniper.net) with a subject= line that includes "MPLS liaison manager to ITU-T". A job description is i= ncluded below. Thanks, Ross (as IAB member and liaison shepherd for this position) ---------------------------------------------------------------------------= -------------------------------------------------------------------- MPLS Liaison Manager from IETF to ITU-T; Job Description: The MPLS Liaison Manager from the IETF to ITU-T reports directly to the IAB= . Related tasks include: - Represent IETF interests wrt MPLS-related activities in the ITU-T - Keep track of MPLS-related activities in SG15 and other ITU-T study = groups that may be relevant to the IETF. Ensure that developments are brought to the attention at the appropriate level = in the IETF. - Coordinate activities with appropriate IETF leadership (IETF liaison= manager to the ITU-T, IAB, IESG, chairs of related IETF WGs). - Track MPLS-related liaisons - Keep track of (with the help of the liaison tool) incoming and outgo= ing liaisons - Assign actions on incoming liaisons that do not have a clear destina= tion - Approximately quarterly plus at IETF meeting -- summarize status on = issues to IESG, IAB, and MPLS co-chairs - Independence - MUST be able to convey and defend IAB/IETF positions, independent of= any conflict with employer positions or national positions - Time allocation - Estimate is one half day a week, not counting travel, but very uneve= nly distributed. - Attend the IETF meetings - Be prepared to attend appropriate ITU-T meetings Skill Set: - Experience with IETF process - Knowledge of MPLS protocol standards - Experience from the ITU-T process - Understanding of the difference between contribution driven processes in = ITU and IETF - Knowledge of the IETF/ITU-T relationship - Ability to act diplomatically and under stress --_000_DF7F294AF4153D498141CBEFADB17704C2A024C45EEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The current liaison manager from the IETF to I= TU-T for MPLS is Stewart Bryant. However, Stewart is intending to step down= from this liaison manager role. The IAB intends to make a decision next we= ek (during the IETF in Quebec City) on Stewart’s replacement.
 
If anyone would like to volunteer for this pos= ition then please send email preferably by Friday of this week to the IAB (= iab@iab.org), CC me (rcallon@juniper.net) with a subject line that includes “MPLS liaison manager to ITU-T̶= 1;. A job description is included below.
 
Thanks, Ross
(as IAB member and liaison shepherd for this p= osition)
----------------------------------------------------------------------= -------------------------------------------------------------------------
MPLS Liaison Manager from IETF to ITU-T;
 
Job Description:
 
The MPLS Liaison Manager from the IETF to ITU-T reports directly to th= e IAB. Related tasks include: 
 
- Represent IETF interests wrt MPLS-related activities in the ITU-T
 
     - Keep track of MPLS-related activities in SG= 15 and other ITU-T study groups that may be relevant to the IETF. Ensure th= at
        developments are brought to= the attention at the appropriate level in the IETF. 
     - Coordinate activities with appropriate IETF= leadership (IETF liaison manager to the ITU-T, IAB, IESG, chairs of relate= d IETF WGs).
 
- Track MPLS-related liaisons
 
     - Keep track of (with the help of the liaison= tool) incoming and outgoing liaisons
     - Assign actions on incoming liaisons that do= not have a clear destination
     - Approximately quarterly plus at IETF meetin= g -- summarize status on issues to IESG, IAB, and MPLS co-chairs
 
- Independence
 
     - MUST be able to convey and defend IAB/IETF = positions, independent of any conflict with employer positions or national = positions
 
- Time allocation
 
     - Estimate is one half day a week, not counti= ng travel, but very unevenly distributed.
     - Attend the IETF meetings
     - Be prepared to attend appropriate ITU-T mee= tings
 
 
Skill Set:
 
- Experience with IETF process
 
- Knowledge of MPLS protocol standards
 
- Experience from the ITU-T process 
 
- Understanding of the difference between contribution driven processe= s in ITU and IETF
 
- Knowledge of the IETF/ITU-T relationship
 
- Ability to act diplomatically and under stress
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C2A024C45EEMBX01WFjnprn_-- From curtis@occnc.com Thu Jul 21 11:33:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6521F85E3 for ; Thu, 21 Jul 2011 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk1Cq2X2ViNw for ; Thu, 21 Jul 2011 11:33:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0B21F8589 for ; Thu, 21 Jul 2011 11:33:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6LIVxS5000599; Thu, 21 Jul 2011 14:31:59 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107211831.p6LIVxS5000599@harbor.orleans.occnc.com> To: "Bocci, Matthew (Matthew)" From: Curtis Villamizar In-reply-to: Your message of "Tue, 19 Jul 2011 15:42:51 +0200." Date: Thu, 21 Jul 2011 14:31:59 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:33:25 -0000 In message "Bocci, Matthew (Matthew)" writes: > > We have just started a poll of the PWE3 mailing list for PWE3 WG > adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, > which is relevant to MPLS-TP. > > Please send any comments to the PWE3 mailing list. > > Best regards > > Matthew +1 yes/support > > On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" > > > > > wrote: > > > > This email begins a poll of the list to see if there is consensus to > > adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 > > working group draft. > > > > Please indicate whether or not you support adoption of this draft, and > > send any comments to the PWE3 list. > > > > This poll ends on Tuesday 9th August. > > > > Regards, > > > > Matthew and Andy. From lufang@cisco.com Thu Jul 21 11:47:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88321F85FF for ; Thu, 21 Jul 2011 11:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzsHQZFBwg-G for ; Thu, 21 Jul 2011 11:47:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2DA21F856D for ; Thu, 21 Jul 2011 11:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=8256; q=dns/txt; s=iport; t=1311274040; x=1312483640; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=dfYo9Vw1cGtlnE3CJLDb8y+EfwLIU7lh2boFtnKP/Nc=; b=ga9pSKfXV8GaYew5yolWOfxXmcTG3N+O+lfLq+k+AV6NhNNvxRTtgC1c p5M3j2P9GeoaoXRfY+IVGmn+zu3YgJlv8iGQedgjRZ5jrUZaWMVEYhyoq CvUyry1vgxDObW4XlIw8asVtU5+kgWGmKw7S+/R3FOpj88aYMOJR8tsnG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAIpzKE6tJXHA/2dsb2JhbABSglOVHo9Qd6YIniSFX18Eh1WQKYtr X-IronPort-AV: E=Sophos;i="4.67,242,1309737600"; d="scan'208,217";a="5218631" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jul 2011 18:47:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6LIlJbP028570; Thu, 21 Jul 2011 18:47:19 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 13:47:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC47D6.9E59D2A2" Date: Thu, 21 Jul 2011 13:47:17 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25066FA592@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGcJlNrU73XoaQQuTuMMHqoR0wwBvL55w References: From: "Luyuan Fang (lufang)" To: "Bocci, Matthew (Matthew)" , X-OriginalArrivalTime: 21 Jul 2011 18:47:20.0042 (UTC) FILETIME=[9ED7D4A0:01CC47D6] Subject: Re: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:47:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC47D6.9E59D2A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Luyuan =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Tuesday, July 19, 2011 9:43 AM To: mpls@ietf.org Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt =20 We have just started a poll of the PWE3 mailing list for PWE3 WG adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant to MPLS-TP. =20 Please send any comments to the PWE3 mailing list. =20 Best regards =20 Matthew =20 On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" wrote: =20 This email begins a poll of the list to see if there is consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group draft. =20 Please indicate whether or not you support adoption of this draft, and send any comments to the PWE3 list. =20 This poll ends on Tuesday 9th August. =20 Regards, =20 Matthew and Andy. ------_=_NextPart_001_01CC47D6.9E59D2A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

Luyuan

 

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew)
Sent: Tuesday, July 19, 2011 9:43 AM
To: mpls@ietf.org
Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt

 

We have just started a poll of the PWE3 mailing list for = PWE3 WG adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, = which is relevant to MPLS-TP.

 

Please send any comments to the PWE3 mailing = list.

 

Best regards

 

Matthew

 

On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" = <matthew.bocci@alcatel-lu= cent.com> wrote:

 

This email begins a poll of the list to see if there is = consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a = PWE3 working group draft.

 

Please indicate whether or not you support adoption of this = draft, and send any comments to the PWE3 list.

 

This poll ends on Tuesday 9th August.

 

Regards,

 

Matthew and Andy.

------_=_NextPart_001_01CC47D6.9E59D2A2-- From curtis@occnc.com Thu Jul 21 12:21:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD921F87E2 for ; Thu, 21 Jul 2011 12:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDCkM4+9PN9f for ; Thu, 21 Jul 2011 12:21:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFBF21F8784 for ; Thu, 21 Jul 2011 12:21:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6LJKJlN001178; Thu, 21 Jul 2011 15:20:19 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107211920.p6LJKJlN001178@harbor.orleans.occnc.com> To: Ross Callon From: Curtis Villamizar In-reply-to: Your message of "Tue, 19 Jul 2011 16:27:23 EDT." Date: Thu, 21 Jul 2011 15:20:19 -0400 Sender: curtis@occnc.com Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 19:21:42 -0000 Ross, Inline ... In message Ross Callon writes: > > John; > > Accepting a document as a working group document is very different > from deciding whether it is ready to pass WG last call. > > In deciding whether to accept a document as a working group document, > we need to think about whether this is an appropriate work for the WG > to take on, is in the WG's charter, and whether the document is a > reasonable start towards a working group document. It certainly does > not need to be complete or in a finished form. I think the objections are related to "and whether the document is a reasonable start towards a working group document". It covers only OAM identifiers and not tunnel, LSP, PW, etc and therefor it is too incomplete to be a reasonable start. If either the same author or another provided a more complete document, then it would be a reasonable start. If the WG feels that it is acceptable to specify use of ICC/CC restricted to no use of a control plane, then that must be very agreed to by the WG and very clearly stated in the draft. So far MPLS-TP will support a control plane but make it optional to use it and therefore this is a major departure. > In this case, the notion of having identifiers based on the ITU-T's > ICC codes was previously in a working group document, but was removed > because we found technical issues with it. This document is a start at > resolving those issues. > > Ross Regards, Curtis > From: John E Drake > Sent: Tuesday, July 12, 2011 2:50 PM > To: Ross Callon; mpls@ietf.org > Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org > Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01 > > Ross, > > Isn't it a bit premature to be asking to make this a working group > document? > > Thanks, > > John > > Sent from my iPhone > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf Of Ross Callon > Sent: Tuesday, July 12, 2011 8:32 AM > To: mpls@ietf.org > Cc: Ross Callon; draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org > Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 > > Working Group, > > this is to start a 12 day poll on making > > draft-win-mpls-tp-itu-t-identifiers-01 > > an mpls working group document. > > If you support the document becoming a working group document please > respond to this poll with "yes/support" > > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same > time give the technical reasons why you are not supporting the > document. > > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please > include the string "draft-win-mpls-tp-itu-t-identifiers" in the > subject line. > > The poll ends 2011-07-24. Please note that this is the Sunday before > the IETF. Also note that the length of the poll has been shortened by > two days so that the poll can be completed prior to our first WG > meeting in Quebec City. > > Ross From loa@pi.nu Thu Jul 21 13:29:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4EF21F8736 for ; Thu, 21 Jul 2011 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHZaHhfU9fEP for ; Thu, 21 Jul 2011 13:29:03 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC2C21F8713 for ; Thu, 21 Jul 2011 13:29:03 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 92267514044; Thu, 21 Jul 2011 22:29:01 +0200 (CEST) Message-ID: <4E288C0C.2080405@pi.nu> Date: Thu, 21 Jul 2011 22:29:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <4E1D49AE.9060707@pi.nu> In-Reply-To: <4E1D49AE.9060707@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , MPLS-TP ad hoc team , draft-ietf-mpls-tp-fault@tools.ietf.org Subject: Re: [mpls] verification call on draft-ietf-mpls-tp-fault-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 20:29:04 -0000 Working Group, this verification call has ended. The verification has generated one comment, can the authors please close loops with the commenter and agree on how to resolve that comment. /Loa On 2011-07-13 09:30, Loa Andersson wrote: > Working group, > > this is to start a one week verification call on > > http://www.ietf.org/id/draft-ietf-mpls-tp-fault-05.txt > > The authors has updated the draft after working last call and the > intention of the verification call is to verify that all comments > has been adequately addressed. > > A list detailing how the comments been addressed is found at: > > http://www.pi.nu/~loa/Version3_Comment_Resolution.xls > > Please send your comments to the working group mailing list > (mpls@ietf.org) before eob July 20, 2011. > > /Loa > > for the wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From tochio@jp.fujitsu.com Thu Jul 21 18:27:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C2811E8080 for ; Thu, 21 Jul 2011 18:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.089 X-Spam-Level: X-Spam-Status: No, score=-104.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZYl32oKVBUi for ; Thu, 21 Jul 2011 18:27:16 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1D11E8075 for ; Thu, 21 Jul 2011 18:27:15 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id E99E13EE0AE for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id CDB2345DEB6 for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id B93D845DEB2 for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id AC93D1DB8037 for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 7C6981DB803E for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id p6M1QxSx027119 for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) X-AuditID: 0a19c027-b7cb5ae0000014ec-42-4e28d1f29f38 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id 68.D3.05356.2F1D82E4; Fri, 22 Jul 2011 10:27:14 +0900 (JST) Received: from [127.0.0.1] (dhcp100.dream.flab.fujitsu.co.jp [10.25.144.155]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id p6M1RDBs012940 for ; Fri, 22 Jul 2011 10:27:14 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4E28D1E4.2050805@jp.fujitsu.com> Date: Fri, 22 Jul 2011 10:27:00 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080204040903040900050902" X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 01:27:17 -0000 This is a multi-part message in MIME format. --------------080204040903040900050902 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Yes/support Regards, Yuji (2011/07/13 0:31), Ross Callon wrote: > Working Group, > this is to start a 12 day poll on making > draft-win-mpls-tp-itu-t-identifiers-01 > an mpls working group document. > If you support the document becoming a working group document please > respond to this poll with "yes/support" > If you do not support the document becoming a working group document > please respond to this poll with "no/do not support" and at the same time > give the technical reasons why you are not supporting the document. > If you have technical comments or in any other way want to discuss the > document, please send these comments to the mpls working group mailing > list, but with another subject than what is on this mail. Please include the > string $B!H(Bdraft-win-mpls-tp-itu-t-identifiers$B!I(B in the subject line. > The poll ends 2011-07-24. Please note that this is the Sunday before the > IETF. Also note that the length of the poll has been shortened by two days > so that the poll can be completed prior to our first WG meeting in Quebec City. > Ross > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------080204040903040900050902 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Yes/support

Regards, Yuji

(2011/07/13 0:31), Ross Callon wrote:
Working Group,
 
this is to start a 12 day poll on making
 
draft-win-mpls-tp-itu-t-identifiers-01
 
an mpls working group document.
 
If you support the document becoming a working group document please
respond to this poll with "yes/support"
 
If you do not support the document becoming a working group document
please respond to this poll with "no/do not support" and at the same time
give the technical reasons why you are not supporting the document.
 
If you have technical comments or in any other way want to discuss the
document, please send these comments to the mpls working group mailing
list, but with another subject than what is on this mail. Please include the
string $B!H(Bdraft-win-mpls-tp-itu-t-identifiers$B!I(B in the subject line.
 
The poll ends 2011-07-24.  Please note that this is the Sunday before the
IETF. Also note that the length of the poll has  been shortened by two days
so that the poll can be completed prior to our first WG meeting in Quebec City. 
 
Ross
 
 

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

--------------080204040903040900050902-- From RCosta@ptinovacao.pt Fri Jul 22 00:21:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DB521F8559 for ; Fri, 22 Jul 2011 00:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxMIMBADBYGt for ; Fri, 22 Jul 2011 00:21:10 -0700 (PDT) Received: from owa.ptinovacao.pt (mail6.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id B980C21F8554 for ; Fri, 22 Jul 2011 00:21:08 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Fri, 22 Jul 2011 08:21:03 +0100 From: Rui Costa To: "rcallon@juniper.net" , "mpls@ietf.org" Date: Fri, 22 Jul 2011 08:21:02 +0100 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gAH5gawABXjK7A= Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7@INOAVREX11.ptin.corpPT.com> References: <9435EDACD941174099E143BCA2BCD615F7A2457369@HE101452.emea1.cds.t-internal.com> In-Reply-To: <9435EDACD941174099E143BCA2BCD615F7A2457369@HE101452.emea1.cds.t-internal.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: multipart/alternative; boundary="_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7INOAVREX11p_" MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 07:21:11 -0000 --_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7INOAVREX11p_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQuDQoNClJlZ2FyZHMsDQpSdWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbg0KU2VudDogVHVlc2RheSwgSnVseSAx MiwgMjAxMSA1OjMyIFBNDQpUbzogbXBsc0BpZXRmLm9yZw0KQ2M6IFJvc3MgQ2FsbG9uOyBkcmFm dC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDog W21wbHNdIFBvbGwgb24gZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDENCg0K V29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0byBzdGFydCBhIDEyIGRheSBwb2xsIG9uIG1ha2lu Zw0KDQpkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVycy0wMQ0KDQphbiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCklmIHlvdSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNv bWluZyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgcGxlYXNlDQpyZXNwb25kIHRvIHRoaXMgcG9s bCB3aXRoICJ5ZXMvc3VwcG9ydCINCg0KSWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVu dCBiZWNvbWluZyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCnBsZWFzZSByZXNwb25kIHRvIHRo aXMgcG9sbCB3aXRoICJuby9kbyBub3Qgc3VwcG9ydCIgYW5kIGF0IHRoZSBzYW1lIHRpbWUNCmdp dmUgdGhlIHRlY2huaWNhbCByZWFzb25zIHdoeSB5b3UgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBk b2N1bWVudC4NCg0KSWYgeW91IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIG9yIGluIGFueSBvdGhl ciB3YXkgd2FudCB0byBkaXNjdXNzIHRoZQ0KZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNv bW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZw0KbGlzdCwgYnV0IHdpdGgg YW5vdGhlciBzdWJqZWN0IHRoYW4gd2hhdCBpcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRl IHRoZQ0Kc3RyaW5nIOKAnGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJz4oCdIGlu IHRoZSBzdWJqZWN0IGxpbmUuDQoNClRoZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4gIFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBpcyB0aGUgU3VuZGF5IGJlZm9yZSB0aGUNCklFVEYuIEFsc28gbm90ZSB0 aGF0IHRoZSBsZW5ndGggb2YgdGhlIHBvbGwgaGFzICBiZWVuIHNob3J0ZW5lZCBieSB0d28gZGF5 cw0Kc28gdGhhdCB0aGUgcG9sbCBjYW4gYmUgY29tcGxldGVkIHByaW9yIHRvIG91ciBmaXJzdCBX RyBtZWV0aW5nIGluIFF1ZWJlYyBDaXR5Lg0KDQpSb3NzDQoNCg== --_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7INOAVREX11p_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrl rovkvZM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiM2MDY0MjA7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRpdi5l bWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEuOXB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1QVCBsaW5rPWJsdWUgdmxp bms9IiM2MDY0MjAiPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5ZZXMvc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+UmVnYXJkcyzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SdWk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgY2xh c3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFu IGxhbmc9REU+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Sb3NzIENhbGxvbjxicj48Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSnVseSAxMiwgMjAxMSA1OjMyIFBNPGJyPjxiPlRvOjwvYj4gbXBsc0BpZXRm Lm9yZzxicj48Yj5DYzo8L2I+IFJvc3MgQ2FsbG9uOyBkcmFmdC13aW4tbXBscy10cC1pdHUtdC1p ZGVudGlmaWVyc0B0b29scy5pZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW21wbHNdIFBvbGwg b24gZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDE8L3NwYW4+PHNwYW4gbGFu Zz1ERT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9REU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+V29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiJz50aGlzIGlzIHRvIHN0YXJ0IGEgMTIgZGF5IHBvbGwgb24gbWFraW5nPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMt MDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5hbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SWYgeW91IHN1cHBvcnQgdGhlIGRv Y3VtZW50IGJlY29taW5nIGEgd29ya2luZyBncm91cCBkb2N1bWVudCBwbGVhc2UgPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+cmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAmcXVvdDt5ZXMvc3VwcG9ydCZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPklmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1l bnQgYmVjb21pbmcgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPnBsZWFzZSBy ZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRoICZxdW90O25vL2RvIG5vdCBzdXBwb3J0JnF1b3Q7IGFu ZCBhdCB0aGUgc2FtZSB0aW1lIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPmdpdmUgdGhlIHRlY2huaWNhbCByZWFzb25z IHdoeSB5b3UgYXJlIG5vdCBzdXBwb3J0aW5nIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiJz5JZiB5b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55IG90 aGVyIHdheSB3YW50IHRvIGRpc2N1c3MgdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPmRvY3VtZW50LCBwbGVhc2Ug c2VuZCB0aGVzZSBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+bGlzdCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0IHRoYW4gd2hhdCBpcyBvbiB0 aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5zdHJpbmcg4oCcZHJhZnQt d2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnPigJ0gaW4gdGhlIHN1YmplY3QgbGluZS4gPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhlIHBvbGwgZW5kcyAyMDExLTA3LTI0LiZuYnNw OyBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgdGhlIFN1bmRheSBiZWZvcmUgdGhlIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURF IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPklFVEYuIEFsc28gbm90ZSB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIHBvbGwgaGFzJm5ic3A7 IGJlZW4gc2hvcnRlbmVkIGJ5IHR3byBkYXlzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPnNvIHRoYXQgdGhlIHBvbGwg Y2FuIGJlIGNvbXBsZXRlZCBwcmlvciB0byBvdXIgZmlyc3QgV0cgbWVldGluZyBpbiBRdWViZWMg Q2l0eS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Um9zczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPURFIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9o dG1sPg== --_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7INOAVREX11p_-- From Feng.f.Huang@alcatel-sbell.com.cn Fri Jul 22 01:07:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C68421F8658 for ; Fri, 22 Jul 2011 01:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.605 X-Spam-Level: * X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnOIldNKELUK for ; Fri, 22 Jul 2011 01:07:39 -0700 (PDT) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8321F869D for ; Fri, 22 Jul 2011 01:07:37 -0700 (PDT) X-AuditID: ac189297-b7bfdae000006c3f-2f-4e292fc5205a Received: from CNSHJCASHUB04.ad4.ad.alcatel.com (Unknown_Domain [135.251.50.74]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 82.17.27711.5CF292E4; Fri, 22 Jul 2011 16:07:33 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com (172.24.146.171) by CNSHJCASHUB04.ad4.ad.alcatel.com (135.251.50.74) with Microsoft SMTP Server id 14.1.323.0; Fri, 22 Jul 2011 16:07:32 +0800 Received: from 172.24.146.181 ([172.24.146.181]) by CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.181]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jul 2011 08:07:32 +0000 References: <9435EDACD941174099E143BCA2BCD615F7A2457369@HE101452.emea1.cds.t-internal.com> <52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7@INOAVREX11.ptin.corpPT.com> Content-Transfer-Encoding: 7bit From: HUANG Feng F Content-Type: multipart/alternative; boundary="Apple-Mail-3-154808311"; charset="gb2312" In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D53C1B7@INOAVREX11.ptin.corpPT.com> Message-ID: <38810816-E7B1-4ADC-9FC8-9AB481CF753F@alcatel-sbell.com.cn> Date: Fri, 22 Jul 2011 16:05:53 +0800 Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxIRmizfKpDWbnMS4C/ZZVodoX5vQ== To: Rui Costa MIME-Version: 1.0 (iPhone Mail 8C148) X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: rcallon@juniper.net, mpls@ietf.org, draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:07:40 -0000 --Apple-Mail-3-154808311 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="GB2312" KzENCg0K1NogMjAxMS03LTIyo6wxNToyMaOsIlJ1aSBDb3N0YSIgPFJDb3N0YUBwdGlub3ZhY2Fv LnB0PiDQtLXAo7oNCg0KPiBZZXMvc3VwcG9ydC4NCj4gDQo+ICANCj4gDQo+IFJlZ2FyZHMsICAg ICAgICAgICAgIA0KPiANCj4gUnVpDQo+IA0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NzIENhbGxvbg0K PiBTZW50OiBUdWVzZGF5LCBKdWx5IDEyLCAyMDExIDU6MzIgUE0NCj4gVG86IG1wbHNAaWV0Zi5v cmcNCj4gQ2M6IFJvc3MgQ2FsbG9uOyBkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVy c0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10gUG9sbCBvbiBkcmFmdC13aW4tbXBs cy10cC1pdHUtdC1pZGVudGlmaWVycy0wMQ0KPiANCj4gIA0KPiANCj4gV29ya2luZyBHcm91cCwN Cj4gDQo+ICANCj4gDQo+IHRoaXMgaXMgdG8gc3RhcnQgYSAxMiBkYXkgcG9sbCBvbiBtYWtpbmcN Cj4gDQo+ICANCj4gDQo+IGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzLTAxDQo+ IA0KPiAgDQo+IA0KPiBhbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+IA0KPiAgDQo+ IA0KPiBJZiB5b3Ugc3VwcG9ydCB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSB3b3JraW5nIGdyb3Vw IGRvY3VtZW50IHBsZWFzZQ0KPiANCj4gcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAieWVzL3N1 cHBvcnQiDQo+IA0KPiAgDQo+IA0KPiBJZiB5b3UgZG8gbm90IHN1cHBvcnQgdGhlIGRvY3VtZW50 IGJlY29taW5nIGEgd29ya2luZyBncm91cCBkb2N1bWVudA0KPiANCj4gcGxlYXNlIHJlc3BvbmQg dG8gdGhpcyBwb2xsIHdpdGggIm5vL2RvIG5vdCBzdXBwb3J0IiBhbmQgYXQgdGhlIHNhbWUgdGlt ZQ0KPiANCj4gZ2l2ZSB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgd2h5IHlvdSBhcmUgbm90IHN1cHBv cnRpbmcgdGhlIGRvY3VtZW50Lg0KPiANCj4gIA0KPiANCj4gSWYgeW91IGhhdmUgdGVjaG5pY2Fs IGNvbW1lbnRzIG9yIGluIGFueSBvdGhlciB3YXkgd2FudCB0byBkaXNjdXNzIHRoZQ0KPiANCj4g ZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcg Z3JvdXAgbWFpbGluZw0KPiANCj4gbGlzdCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0IHRoYW4g d2hhdCBpcyBvbiB0aGlzIG1haWwuIFBsZWFzZSBpbmNsdWRlIHRoZQ0KPiANCj4gc3RyaW5nIKGw ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnOhsSBpbiB0aGUgc3ViamVjdCBsaW5l Lg0KPiANCj4gIA0KPiANCj4gVGhlIHBvbGwgZW5kcyAyMDExLTA3LTI0LiAgUGxlYXNlIG5vdGUg dGhhdCB0aGlzIGlzIHRoZSBTdW5kYXkgYmVmb3JlIHRoZQ0KPiANCj4gSUVURi4gQWxzbyBub3Rl IHRoYXQgdGhlIGxlbmd0aCBvZiB0aGUgcG9sbCBoYXMgIGJlZW4gc2hvcnRlbmVkIGJ5IHR3byBk YXlzDQo+IA0KPiBzbyB0aGF0IHRoZSBwb2xsIGNhbiBiZSBjb21wbGV0ZWQgcHJpb3IgdG8gb3Vy IGZpcnN0IFdHIG1lZXRpbmcgaW4gUXVlYmVjIENpdHkuIA0KPiANCj4gIA0KPiANCj4gUm9zcw0K PiANCj4gIA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --Apple-Mail-3-154808311 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj4rMTwvZGl2PjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6 IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29s b3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZy YW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyI+PGJyPjwvc3Bhbj48L2Rp dj48ZGl2PuWcqCAyMDExLTctMjLvvIwxNToyMe+8jCJSdWkgQ29zdGEiICZsdDs8YSBocmVmPSJt YWlsdG86UkNvc3RhQHB0aW5vdmFjYW8ucHQiPlJDb3N0YUBwdGlub3ZhY2FvLnB0PC9hPiZndDsg 5YaZ6YGT77yaPGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWVzL3N1cHBvcnQuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZHMsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJ1aTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPjxkaXY+PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkRFIj48aHIgc2l6ZT0iMiIg d2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA8YSBocmVmPSJtYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvc3MgQ2FsbG9u PGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDEyLCAyMDExIDU6MzIgUE08YnI+PGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9hPjxicj48Yj5DYzo8L2I+IFJvc3MgQ2FsbG9u OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnNAdG9v bHMuaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVu dGlmaWVyc0B0b29scy5pZXRmLm9yZyI+ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmll cnNAdG9vbHMuaWV0Zi5vcmc8L2E+PC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gW21wbHNdIFBvbGwg b24gZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDE8L3NwYW4+PHNwYW4gbGFu Zz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V29ya2lu ZyBHcm91cCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50aGlzIGlzIHRvIHN0YXJ0IGEgMTIgZGF5IHBv bGwgb24gbWFraW5nPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQt aWRlbnRpZmllcnMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5hbiBtcGxzIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IHN1cHBvcnQgdGhlIGRvY3VtZW50 IGJlY29taW5nIGEgd29ya2luZyBncm91cCBkb2N1bWVudCBwbGVhc2UgPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+cmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAieWVzL3N1cHBv cnQiPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBkb2N1bWVu dCBiZWNvbWluZyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+cGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBwb2xsIHdpdGggIm5vL2RvIG5v dCBzdXBwb3J0IiBhbmQgYXQgdGhlIHNhbWUgdGltZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5naXZlIHRoZSB0ZWNobmljYWwgcmVhc29ucyB3aHkgeW91IGFyZSBub3Qgc3Vw cG9ydGluZyB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGhhdmUgdGVj aG5pY2FsIGNvbW1lbnRzIG9yIGluIGFueSBvdGhlciB3YXkgd2FudCB0byBkaXNjdXNzIHRoZSA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kb2N1bWVudCwgcGxlYXNlIHNlbmQg dGhlc2UgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmxpc3QsIGJ1dCB3aXRoIGFub3RoZXIgc3ViamVj dCB0aGFuIHdoYXQgaXMgb24gdGhpcyBtYWlsLiBQbGVhc2UgaW5jbHVkZSB0aGUgPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i REUiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c3RyaW5nIOKAnGRyYWZ0LXdpbi1tcGxzLXRwLWl0 dS10LWlkZW50aWZpZXJz4oCdIGluIHRoZSBzdWJqZWN0IGxpbmUuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRoZSBwb2xsIGVuZHMgMjAxMS0wNy0yNC4mbmJzcDsgUGxlYXNlIG5vdGUgdGhhdCB0aGlz IGlzIHRoZSBTdW5kYXkgYmVmb3JlIHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JRVRGLiBBbHNvIG5vdGUgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZSBwb2xsIGhhcyZuYnNw OyBiZWVuIHNob3J0ZW5lZCBieSB0d28gZGF5cyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5zbyB0aGF0IHRoZSBwb2xsIGNhbiBiZSBjb21wbGV0ZWQgcHJpb3IgdG8gb3VyIGZp cnN0IFdHIG1lZXRpbmcgaW4gUXVlYmVjIENpdHkuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlJvc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPm1wbHMgbWFpbGluZyBsaXN0PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwv YT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz PC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-3-154808311-- From Rolf.Winter@neclab.eu Fri Jul 22 01:29:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4DF21F85B8 for ; Fri, 22 Jul 2011 01:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st7jxw5REdFw for ; Fri, 22 Jul 2011 01:29:31 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2321D21F8504 for ; Fri, 22 Jul 2011 01:29:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C422828000331; Fri, 22 Jul 2011 10:29:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP9ssEDrudZn; Fri, 22 Jul 2011 10:29:29 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A8EB128000198; Fri, 22 Jul 2011 10:29:04 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.125]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 22 Jul 2011 10:29:04 +0200 From: Rolf Winter To: "curtis@occnc.com" , Ross Callon Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AQHMR9t7KdanyJkJU02NAiHKkVM81pT4AbBA Date: Fri, 22 Jul 2011 08:29:03 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> References: Your message of "Tue, 19 Jul 2011 16:27:23 EDT." <201107211920.p6LJKJlN001178@harbor.orleans.occnc.com> In-Reply-To: <201107211920.p6LJKJlN001178@harbor.orleans.occnc.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:29:31 -0000 Curtis, please see inline: > I think the objections are related to "and whether the document is a > reasonable start towards a working group document". >=20 > It covers only OAM identifiers and not tunnel, LSP, PW, etc and > therefor it is too incomplete to be a reasonable start. If either the > same author or another provided a more complete document, then it > would be a reasonable start. If the WG feels that it is acceptable to > specify use of ICC/CC restricted to no use of a control plane, then > that must be very agreed to by the WG and very clearly stated in the > draft. That is not quite accurate. I think you have missed this part of our docume= nt: "The same substitution procedure applies to all identifiers specified in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives mentioned in this document." In other words, _all_ IDs are already there and made globally unique with t= he ICC_Operator_ID defined in section 4.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 From Internet-Drafts@ietf.org Fri Jul 22 07:15:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A298221F8880; Fri, 22 Jul 2011 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHCpvMWiZ67f; Fri, 22 Jul 2011 07:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071F121F8A58; Fri, 22 Jul 2011 07:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110722141502.26136.41847.idtracker@ietfa.amsl.com> Date: Fri, 22 Jul 2011 07:15:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-identifiers-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:15:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Identifiers Author(s) : M. Bocci, et al Filename : draft-ietf-mpls-tp-identifiers-07.txt Pages : 17 Date : 2011-07-22 This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions compatible with IP/MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-identifiers-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-identifiers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-22070131.I-D@ietf.org> --NextPart-- From curtis@occnc.com Fri Jul 22 07:25:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16FD21F8ABB for ; Fri, 22 Jul 2011 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBe6CoSAQlvi for ; Fri, 22 Jul 2011 07:25:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5D521F8AAC for ; Fri, 22 Jul 2011 07:25:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6MENuBc024649; Fri, 22 Jul 2011 10:23:56 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107221423.p6MENuBc024649@harbor.orleans.occnc.com> To: Rolf Winter From: Curtis Villamizar In-reply-to: Your message of "Fri, 22 Jul 2011 08:29:03 -0000." <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> Date: Fri, 22 Jul 2011 10:23:56 -0400 Sender: curtis@occnc.com Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:25:18 -0000 In message <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> Rolf Winter writes: > > Curtis, > > please see inline: > > > > I think the objections are related to "and whether the document is a > > reasonable start towards a working group document". > > > > It covers only OAM identifiers and not tunnel, LSP, PW, etc and > > therefor it is too incomplete to be a reasonable start. If either the > > same author or another provided a more complete document, then it > > would be a reasonable start. If the WG feels that it is acceptable to > > specify use of ICC/CC restricted to no use of a control plane, then > > that must be very agreed to by the WG and very clearly stated in the > > draft. > > That is not quite accurate. I think you have missed this part of our > document: > > "The same substitution procedure applies to all identifiers specified > in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives > mentioned in this document." > > In other words, _all_ IDs are already there and made globally unique > with the ICC_Operator_ID defined in section 4. Perhaps I needed to provide more detail to expand on the perhaps too terse point that I made above. A key point in I-D.ietf-mpls-tp-identifiers is that all of the identifiers are consistent with existing routing and signaling extensions defined for MPLS (including GMPLS and MPLS-TP) and PW. The 4 byte global ID (based on AS number) is consistent with RFC 5003 "Attachment Individual Identifier (AII) Types for Aggregation". The unique Attachment Interface Identifier (AII) is a four byte quantity. 3.1. The Global ID RFC 5003 [3] defines a globally unique Attachment Interface Identifier (AII). That AII is composed of three parts, a Global ID which uniquely identifies a operator, a prefix, and finally and attachment circuit identifier. We have chosen to use that Global ID for MPLS-TP. Quoting from RFC 5003, section 3.2, "The global ID can contain the 2-octet or 4-octet value of the operator's Autonomous System Number (ASN). It is expected that the global ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. The presence of a global ID based on the operator's ASN ensures that the AII will be globally unique." The ITU Carrier Code does not have that property (fitting nicely into four bytes and uniquely identifying a provider). A quick search for SAII or TAII or RFC 5003 yields the following. The following documents either reference RFC 5003 or make use of AII. RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures RFC 4447 - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) RFC 4762 - Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling RFC 5287 - Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks RFC 5601 - Pseudowire (PW) Management Information Base (MIB) RFC 6073 - Segmented Pseudowire RFC 6074 - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) At the very least, RFC 5003 needs to be updated with a new document defining a new AII type. Then any implementation claiming compatibility needs to update all of the above protocol implementations to accommodate the new AII type. The list above may not be complete in that inclusion of RFC 4447 implies any use of PW with LDP signaling, therefore impacts the implementation of most documents from the PWE3 WG. The inclusion of RFC 4379 in the list means that any use of MPLS Ping, including MPLS use, PW use in VCCI, and MPLS-TP use is impacted. If I were to expand the search to find references to RFC 4379 and RFC 4447 there would be a very long list of RFC implementations affected. > Best, > > Rolf The reason I have called this work hopelessly incomplete is that you have specified a "wish" to use ICC/CC as the GLobal_ID, but have not specified or called for necessary protocol extensions, and nave not even touched on the impact of doing so and enumerated the changes to existing protocol implementations that would be required. In addition, I see zero gain in using ICC/CC rather than AS number and quite a bit of pain in doing so. Going from IPv4 to IPv6 has proven quite painful (and is still ongoing) but the pain was endured for a very good reason. Regards, Curtis From zhang.fei3@zte.com.cn Fri Jul 22 07:35:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA321F854D; Fri, 22 Jul 2011 07:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.776 X-Spam-Level: X-Spam-Status: No, score=-95.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH77cSkFwvhR; Fri, 22 Jul 2011 07:35:34 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 12DFF21F849F; Fri, 22 Jul 2011 07:35:33 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Fri, 22 Jul 2011 22:33:34 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2478792715; Fri, 22 Jul 2011 22:35:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6MEZJxd087253; Fri, 22 Jul 2011 22:35:19 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-KeepSent: 6F02273F:051695E6-482578D5:005014AD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 22 Jul 2011 22:35:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-22 22:35:21, Serialize complete at 2011-07-22 22:35:21 Content-Type: multipart/alternative; boundary="=_alternative 005023BA482578D5_=" X-MAIL: mse01.zte.com.cn p6MEZJxd087253 Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:35:35 -0000 This is a multipart message in MIME format. --=_alternative 005023BA482578D5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KRmVpDQoNCg0KDQpSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5l dD4gDQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDctMTIgMjM6MzENCg0K ytW8/sjLDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQqzrcvNDQpSb3NzIENhbGxv biA8cmNhbGxvbkBqdW5pcGVyLm5ldD4sIA0KImRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50 aWZpZXJzQHRvb2xzLmlldGYub3JnIiANCjxkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlm aWVyc0B0b29scy5pZXRmLm9yZz4NCtb3zOINClttcGxzXSBQb2xsIG9uIGRyYWZ0LXdpbi1tcGxz LXRwLWl0dS10LWlkZW50aWZpZXJzLTAxDQoNCg0KDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KIA0K dGhpcyBpcyB0byBzdGFydCBhIDEyIGRheSBwb2xsIG9uIG1ha2luZw0KIA0KZHJhZnQtd2luLW1w bHMtdHAtaXR1LXQtaWRlbnRpZmllcnMtMDENCiANCmFuIG1wbHMgd29ya2luZyBncm91cCBkb2N1 bWVudC4NCiANCklmIHlvdSBzdXBwb3J0IHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQgcGxlYXNlIA0KcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAieWVzL3N1 cHBvcnQiDQogDQpJZiB5b3UgZG8gbm90IHN1cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nIGEg d29ya2luZyBncm91cCBkb2N1bWVudCANCnBsZWFzZSByZXNwb25kIHRvIHRoaXMgcG9sbCB3aXRo ICJuby9kbyBub3Qgc3VwcG9ydCIgYW5kIGF0IHRoZSBzYW1lIHRpbWUgDQpnaXZlIHRoZSB0ZWNo bmljYWwgcmVhc29ucyB3aHkgeW91IGFyZSBub3Qgc3VwcG9ydGluZyB0aGUgZG9jdW1lbnQuDQog DQpJZiB5b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55IG90aGVyIHdheSB3YW50 IHRvIGRpc2N1c3MgdGhlIA0KZG9jdW1lbnQsIHBsZWFzZSBzZW5kIHRoZXNlIGNvbW1lbnRzIHRv IHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyANCmxpc3QsIGJ1dCB3aXRoIGFub3RoZXIg c3ViamVjdCB0aGFuIHdoYXQgaXMgb24gdGhpcyBtYWlsLiBQbGVhc2UgaW5jbHVkZSANCnRoZSAN CnN0cmluZyChsGRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlkZW50aWZpZXJzobEgaW4gdGhlIHN1 YmplY3QgbGluZS4gDQogDQpUaGUgcG9sbCBlbmRzIDIwMTEtMDctMjQuICBQbGVhc2Ugbm90ZSB0 aGF0IHRoaXMgaXMgdGhlIFN1bmRheSBiZWZvcmUgdGhlIA0KSUVURi4gQWxzbyBub3RlIHRoYXQg dGhlIGxlbmd0aCBvZiB0aGUgcG9sbCBoYXMgIGJlZW4gc2hvcnRlbmVkIGJ5IHR3byANCmRheXMg DQpzbyB0aGF0IHRoZSBwb2xsIGNhbiBiZSBjb21wbGV0ZWQgcHJpb3IgdG8gb3VyIGZpcnN0IFdH IG1lZXRpbmcgaW4gUXVlYmVjIA0KQ2l0eS4gDQogDQpSb3NzDQogX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQo= --=_alternative 005023BA482578D5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9zdXBwb3J0PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Um9zcyBDYWxsb24gJmx0 O3JjYWxsb25AanVuaXBlci5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3LTEyIDIzOjMxPC9m b250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5Sb3NzIENhbGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDssDQomcXVvdDtk cmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc0B0b29scy5pZXRmLm9yZyZxdW90OyAm bHQ7ZHJhZnQtd2luLW1wbHMtdHAtaXR1LXQtaWRlbnRpZmllcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBsc10gUG9sbCBvbiBkcmFmdC13aW4tbXBscy10cC1pdHUt dC1pZGVudGlmaWVycy0wMTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Xb3JraW5nIEdyb3VwLDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj50aGlzIGlzIHRvIHN0YXJ0IGEgMTIgZGF5IHBvbGwgb24gbWFraW5n PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPmRyYWZ0LXdpbi1tcGxzLXRwLWl0dS10LWlk ZW50aWZpZXJzLTAxPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPmFuIG1wbHMgd29ya2lu ZyBncm91cCBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SWYgeW91IHN1 cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nIGENCndvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgcGxl YXNlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+cmVzcG9uZCB0byB0 aGlzIHBvbGwgd2l0aCAmcXVvdDt5ZXMvc3VwcG9ydCZxdW90OzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5JZiB5b3UgZG8gbm90IHN1cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nDQph IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5wbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0aCAmcXVvdDtuby9kbw0Kbm90 IHN1cHBvcnQmcXVvdDsgYW5kIGF0IHRoZSBzYW1lIHRpbWUgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5naXZlIHRoZSB0ZWNobmljYWwgcmVhc29ucyB3aHkgeW91IGFy ZQ0Kbm90IHN1cHBvcnRpbmcgdGhlIGRvY3VtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5JZiB5b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4gYW55DQpvdGhlciB3YXkg d2FudCB0byBkaXNjdXNzIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPmRvY3VtZW50LCBwbGVhc2Ugc2VuZCB0aGVzZSBjb21tZW50cyB0bw0KdGhlIG1wbHMgd29y a2luZyBncm91cCBtYWlsaW5nIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+bGlzdCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0IHRoYW4gd2hhdA0KaXMgb24gdGhpcyBt YWlsLiBQbGVhc2UgaW5jbHVkZSB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5zdHJpbmcgobBkcmFmdC13aW4tbXBscy10cC1pdHUtdC1pZGVudGlmaWVyc6GxDQpp biB0aGUgc3ViamVjdCBsaW5lLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIHBv bGwgZW5kcyAyMDExLTA3LTI0LiAmbmJzcDtQbGVhc2UNCm5vdGUgdGhhdCB0aGlzIGlzIHRoZSBT dW5kYXkgYmVmb3JlIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PklFVEYuIEFsc28gbm90ZSB0aGF0IHRoZSBsZW5ndGggb2YgdGhlDQpwb2xsIGhhcyAmbmJzcDti ZWVuIHNob3J0ZW5lZCBieSB0d28gZGF5cyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPnNvIHRoYXQgdGhlIHBvbGwgY2FuIGJlIGNvbXBsZXRlZCBwcmlvcg0KdG8gb3Vy IGZpcnN0IFdHIG1lZXRpbmcgaW4gUXVlYmVjIENpdHkuICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5Sb3NzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0Bp ZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 005023BA482578D5_=-- From jdrake@juniper.net Fri Jul 22 07:40:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7C21F8B04 for ; Fri, 22 Jul 2011 07:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+d2ytxL3jGn for ; Fri, 22 Jul 2011 07:40:26 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3DF21F8B07 for ; Fri, 22 Jul 2011 07:40:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTimLzcjQW29/cdgasp3spPTQyDSepm5T@postini.com; Fri, 22 Jul 2011 07:40:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 22 Jul 2011 07:38:56 -0700 From: John E Drake To: "curtis@occnc.com" , Rolf Winter Date: Fri, 22 Jul 2011 07:38:54 -0700 Thread-Topic: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxIe02iw1TApZKVRtK5ti5LBYCeiwAAZE9A Message-ID: <5E893DB832F57341992548CDBB333163A0A99A7F8B@EMBX01-HQ.jnpr.net> References: Your message of "Fri, 22 Jul 2011 08:29:03 -0000." <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> <201107221423.p6MENuBc024649@harbor.orleans.occnc.com> In-Reply-To: <201107221423.p6MENuBc024649@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:40:27 -0000 Curtis, It sounds like the authors have a lot or work to do. Thanks, John Sent from my iPhone > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Friday, July 22, 2011 7:24 AM > To: Rolf Winter > Cc: curtis@occnc.com; Ross Callon; John E Drake; mpls@ietf.org; draft- > win-mpls-tp-itu-t-identifiers@tools.ietf.org > Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 >=20 >=20 > In message > <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> > Rolf Winter writes: > > > > Curtis, > > > > please see inline: > > > > > > > I think the objections are related to "and whether the document is > a > > > reasonable start towards a working group document". > > > > > > It covers only OAM identifiers and not tunnel, LSP, PW, etc and > > > therefor it is too incomplete to be a reasonable start. If either > the > > > same author or another provided a more complete document, then it > > > would be a reasonable start. If the WG feels that it is acceptable > to > > > specify use of ICC/CC restricted to no use of a control plane, then > > > that must be very agreed to by the WG and very clearly stated in > the > > > draft. > > > > That is not quite accurate. I think you have missed this part of our > > document: > > > > "The same substitution procedure applies to all identifiers specified > > in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives > > mentioned in this document." > > > > In other words, _all_ IDs are already there and made globally unique > > with the ICC_Operator_ID defined in section 4. >=20 > Perhaps I needed to provide more detail to expand on the perhaps too > terse point that I made above. >=20 > A key point in I-D.ietf-mpls-tp-identifiers is that all of the > identifiers are consistent with existing routing and signaling > extensions defined for MPLS (including GMPLS and MPLS-TP) and PW. >=20 > The 4 byte global ID (based on AS number) is consistent with RFC 5003 > "Attachment Individual Identifier (AII) Types for Aggregation". The > unique Attachment Interface Identifier (AII) is a four byte quantity. >=20 > 3.1. The Global ID >=20 > RFC 5003 [3] defines a globally unique Attachment Interface > Identifier (AII). That AII is composed of three parts, a Global ID > which uniquely identifies a operator, a prefix, and finally and > attachment circuit identifier. We have chosen to use that Global > ID for MPLS-TP. Quoting from RFC 5003, section 3.2, "The global ID > can > contain the 2-octet or 4-octet value of the operator's Autonomous > System Number (ASN). It is expected that the global ID will be > derived from the globally unique ASN of the autonomous system > hosting > the PEs containing the actual AIIs. The presence of a global ID > based on the operator's ASN ensures that the AII will be globally > unique." >=20 > The ITU Carrier Code does not have that property (fitting nicely into > four bytes and uniquely identifying a provider). >=20 > A quick search for SAII or TAII or RFC 5003 yields the following. The > following documents either reference RFC 5003 or make use of AII. >=20 > RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS) > Data Plane Failures >=20 > RFC 4447 - Pseudowire Setup and Maintenance > Using the Label Distribution Protocol (LDP) >=20 > RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions > for Layer 2 Tunneling Protocol (L2TP) >=20 > RFC 4762 - Virtual Private LAN Service (VPLS) Using > Label Distribution Protocol (LDP) Signaling >=20 > RFC 5287 - Control Protocol Extensions for the Setup of > Time-Division Multiplexing (TDM) Pseudowires in MPLS > Networks >=20 > RFC 5601 - Pseudowire (PW) Management Information Base (MIB) >=20 > RFC 6073 - Segmented Pseudowire >=20 > RFC 6074 - Provisioning, Auto-Discovery, and Signaling > in Layer 2 Virtual Private Networks (L2VPNs) >=20 > At the very least, RFC 5003 needs to be updated with a new document > defining a new AII type. >=20 > Then any implementation claiming compatibility needs to update all of > the above protocol implementations to accommodate the new AII type. > The list above may not be complete in that inclusion of RFC 4447 > implies any use of PW with LDP signaling, therefore impacts the > implementation of most documents from the PWE3 WG. The inclusion of > RFC 4379 in the list means that any use of MPLS Ping, including MPLS > use, PW use in VCCI, and MPLS-TP use is impacted. >=20 > If I were to expand the search to find references to RFC 4379 and RFC > 4447 there would be a very long list of RFC implementations affected. >=20 > > Best, > > > > Rolf >=20 > The reason I have called this work hopelessly incomplete is that you > have specified a "wish" to use ICC/CC as the GLobal_ID, but have not > specified or called for necessary protocol extensions, and nave not > even touched on the impact of doing so and enumerated the changes to > existing protocol implementations that would be required. >=20 > In addition, I see zero gain in using ICC/CC rather than AS number and > quite a bit of pain in doing so. Going from IPv4 to IPv6 has proven > quite painful (and is still ongoing) but the pain was endured for a > very good reason. >=20 > Regards, >=20 > Curtis From malcolm.betts@zte.com.cn Fri Jul 22 08:37:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E649521F8786 for ; Fri, 22 Jul 2011 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdnF25E4ChXF for ; Fri, 22 Jul 2011 08:37:32 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D172F21F8B26 for ; Fri, 22 Jul 2011 08:37:23 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 4864806486374; Fri, 22 Jul 2011 23:34:28 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 44186.4833539970; Fri, 22 Jul 2011 23:37:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6MFbBTm013978; Fri, 22 Jul 2011 23:37:11 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <201107221423.p6MENuBc024649@harbor.orleans.occnc.com> References: Your message of "Fri, 22 Jul 2011 08:29:03 -0000." <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> <201107221423.p6MENuBc024649@harbor.orleans.occnc.com> To: curtis@occnc.com MIME-Version: 1.0 X-KeepSent: 6721406F:0211B5BB-852578D5:0054B118; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Fri, 22 Jul 2011 11:36:43 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-22 23:37:13, Serialize complete at 2011-07-22 23:37:13 Content-Type: multipart/alternative; boundary="=_alternative 0055CBF1852578D5_=" X-MAIL: mse01.zte.com.cn p6MFbBTm013978 Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , Ross Callon Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:37:34 -0000 This is a multipart message in MIME format. --=_alternative 0055CBF1852578D5_= Content-Type: text/plain; charset="US-ASCII" Curtis, The introduction of draft-ietf-mpls-tp-identifiers states: 1. Introduction This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) [7] require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions suitable to IP/MPLS conventions. The identifiers have been chosen to be compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. The mapping to control plane identifiers is only mentioned in section 5.3: 5.3. Mapping to RSVP Signaling This section is informative and exists to help understand the structure of the LSP IDs. GMPLS [5] is based on RSVP-TE [2]. This section defines the mapping from an MPLS-TP LSP_ID to RSVP-TE. At this time, RSVP-TE has yet to be extended to accommodate Global_IDs. Thus a mapping is only made for the network unique form of the LSP_ID. As Rolf stated in his reply, win-mpls-tp-itu-t-identifiers describes the substitution of the global ID with an ICC based identifier. On this basis I am have trouble understanding how your comments are relevant. Regards, Malcolm Curtis Villamizar Sent by: curtis@occnc.com 22/07/2011 10:23 AM Please respond to curtis@occnc.com To Rolf Winter cc "curtis@occnc.com" , Ross Callon , John E Drake , "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 In message <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> Rolf Winter writes: > > Curtis, > > please see inline: > > > > I think the objections are related to "and whether the document is a > > reasonable start towards a working group document". > > > > It covers only OAM identifiers and not tunnel, LSP, PW, etc and > > therefor it is too incomplete to be a reasonable start. If either the > > same author or another provided a more complete document, then it > > would be a reasonable start. If the WG feels that it is acceptable to > > specify use of ICC/CC restricted to no use of a control plane, then > > that must be very agreed to by the WG and very clearly stated in the > > draft. > > That is not quite accurate. I think you have missed this part of our > document: > > "The same substitution procedure applies to all identifiers specified > in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives > mentioned in this document." > > In other words, _all_ IDs are already there and made globally unique > with the ICC_Operator_ID defined in section 4. Perhaps I needed to provide more detail to expand on the perhaps too terse point that I made above. A key point in I-D.ietf-mpls-tp-identifiers is that all of the identifiers are consistent with existing routing and signaling extensions defined for MPLS (including GMPLS and MPLS-TP) and PW. The 4 byte global ID (based on AS number) is consistent with RFC 5003 "Attachment Individual Identifier (AII) Types for Aggregation". The unique Attachment Interface Identifier (AII) is a four byte quantity. 3.1. The Global ID RFC 5003 [3] defines a globally unique Attachment Interface Identifier (AII). That AII is composed of three parts, a Global ID which uniquely identifies a operator, a prefix, and finally and attachment circuit identifier. We have chosen to use that Global ID for MPLS-TP. Quoting from RFC 5003, section 3.2, "The global ID can contain the 2-octet or 4-octet value of the operator's Autonomous System Number (ASN). It is expected that the global ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. The presence of a global ID based on the operator's ASN ensures that the AII will be globally unique." The ITU Carrier Code does not have that property (fitting nicely into four bytes and uniquely identifying a provider). A quick search for SAII or TAII or RFC 5003 yields the following. The following documents either reference RFC 5003 or make use of AII. RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures RFC 4447 - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) RFC 4762 - Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling RFC 5287 - Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks RFC 5601 - Pseudowire (PW) Management Information Base (MIB) RFC 6073 - Segmented Pseudowire RFC 6074 - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) At the very least, RFC 5003 needs to be updated with a new document defining a new AII type. Then any implementation claiming compatibility needs to update all of the above protocol implementations to accommodate the new AII type. The list above may not be complete in that inclusion of RFC 4447 implies any use of PW with LDP signaling, therefore impacts the implementation of most documents from the PWE3 WG. The inclusion of RFC 4379 in the list means that any use of MPLS Ping, including MPLS use, PW use in VCCI, and MPLS-TP use is impacted. If I were to expand the search to find references to RFC 4379 and RFC 4447 there would be a very long list of RFC implementations affected. > Best, > > Rolf The reason I have called this work hopelessly incomplete is that you have specified a "wish" to use ICC/CC as the GLobal_ID, but have not specified or called for necessary protocol extensions, and nave not even touched on the impact of doing so and enumerated the changes to existing protocol implementations that would be required. In addition, I see zero gain in using ICC/CC rather than AS number and quite a bit of pain in doing so. Going from IPv4 to IPv6 has proven quite painful (and is still ongoing) but the pain was endured for a very good reason. Regards, Curtis --=_alternative 0055CBF1852578D5_= Content-Type: text/html; charset="US-ASCII" Curtis,

The introduction of draft-ietf-mpls-tp-identifiers states:

1.  Introduction

   This document specifies an initial set of identifiers to be used in
   the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
   The MPLS-TP requirements (RFC 5654) [7] require that the elements and
   objects in an MPLS-TP environment are able to be configured and
   managed without a control plane.  In such an environment many
   conventions for defining identifiers are possible.  This document
   defines identifiers for MPLS-TP management and OAM functions suitable
   to IP/MPLS conventions.  The identifiers have been chosen to be
   compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions.

The mapping to control plane identifiers is only mentioned in section 5.3:

5.3.  Mapping to RSVP Signaling

   This section is informative and exists to help understand the
   structure of the LSP IDs.
   GMPLS [5] is based on RSVP-TE [2].  This section defines the mapping
   from an MPLS-TP LSP_ID to RSVP-TE.  At this time, RSVP-TE has yet to
   be extended to accommodate Global_IDs.  Thus a mapping is only made
   for the network unique form of the LSP_ID.

As Rolf stated in his reply, win-mpls-tp-itu-t-identifiers describes the substitution of the global ID with an ICC based identifier.

On this basis I am have trouble understanding how your comments are relevant.

Regards,

Malcolm





Curtis Villamizar <curtis@occnc.com>
Sent by: curtis@occnc.com

22/07/2011 10:23 AM
Please respond to
curtis@occnc.com
To
Rolf Winter <Rolf.Winter@neclab.eu>
cc
"curtis@occnc.com" <curtis@occnc.com>, Ross Callon <rcallon@juniper.net>, John E Drake <jdrake@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" <draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org>
Subject
Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01






In message <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd>
Rolf Winter writes:
>  
> Curtis,
>  
> please see inline:
>  
>  
> > I think the objections are related to "and whether the document is a
> > reasonable start towards a working group document".
> >
> > It covers only OAM identifiers and not tunnel, LSP, PW, etc and
> > therefor it is too incomplete to be a reasonable start.  If either the
> > same author or another provided a more complete document, then it
> > would be a reasonable start.  If the WG feels that it is acceptable to
> > specify use of ICC/CC restricted to no use of a control plane, then
> > that must be very agreed to by the WG and very clearly stated in the
> > draft.
>  
> That is not quite accurate. I think you have missed this part of our
> document:
>  
> "The same substitution procedure applies to all identifiers specified
> in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives
> mentioned in this document."
>  
> In other words, _all_ IDs are already there and made globally unique
> with the ICC_Operator_ID defined in section 4.

Perhaps I needed to provide more detail to expand on the perhaps too
terse point that I made above.

A key point in I-D.ietf-mpls-tp-identifiers is that all of the
identifiers are consistent with existing routing and signaling
extensions defined for MPLS (including GMPLS and MPLS-TP) and PW.

The 4 byte global ID (based on AS number) is consistent with RFC 5003
"Attachment Individual Identifier (AII) Types for Aggregation".  The
unique Attachment Interface Identifier (AII) is a four byte quantity.

 3.1.  The Global ID

  RFC 5003 [3] defines a globally unique Attachment Interface
  Identifier (AII).  That AII is composed of three parts, a Global ID
  which uniquely identifies a operator, a prefix, and finally and
  attachment circuit identifier.  We have chosen to use that Global
  ID for MPLS-TP.  Quoting from RFC 5003, section 3.2, "The global ID can
  contain the 2-octet or 4-octet value of the operator's Autonomous
  System Number (ASN).  It is expected that the global ID will be
  derived from the globally unique ASN of the autonomous system hosting
  the PEs containing the actual AIIs.  The presence of a global ID
  based on the operator's ASN ensures that the AII will be globally
  unique."

The ITU Carrier Code does not have that property (fitting nicely into
four bytes and uniquely identifying a provider).

A quick search for SAII or TAII or RFC 5003 yields the following.  The
following documents either reference RFC 5003 or make use of AII.

 RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS)
                     Data Plane Failures

 RFC 4447 - Pseudowire Setup and Maintenance
            Using the Label Distribution Protocol (LDP)

 RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions
            for Layer 2 Tunneling Protocol (L2TP)

 RFC 4762 - Virtual Private LAN Service (VPLS) Using
            Label Distribution Protocol (LDP) Signaling

 RFC 5287 - Control Protocol Extensions for the Setup of
            Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks

 RFC 5601 - Pseudowire (PW) Management Information Base (MIB)

 RFC 6073 - Segmented Pseudowire

 RFC 6074 - Provisioning, Auto-Discovery, and Signaling
            in Layer 2 Virtual Private Networks (L2VPNs)

At the very least, RFC 5003 needs to be updated with a new document
defining a new AII type.

Then any implementation claiming compatibility needs to update all of
the above protocol implementations to accommodate the new AII type.
The list above may not be complete in that inclusion of RFC 4447
implies any use of PW with LDP signaling, therefore impacts the
implementation of most documents from the PWE3 WG.  The inclusion of
RFC 4379 in the list means that any use of MPLS Ping, including MPLS
use, PW use in VCCI, and MPLS-TP use is impacted.

If I were to expand the search to find references to RFC 4379 and RFC
4447 there would be a very long list of RFC implementations affected.

> Best,
>  
> Rolf

The reason I have called this work hopelessly incomplete is that you
have specified a "wish" to use ICC/CC as the GLobal_ID, but have not
specified or called for necessary protocol extensions, and nave not
even touched on the impact of doing so and enumerated the changes to
existing protocol implementations that would be required.

In addition, I see zero gain in using ICC/CC rather than AS number and
quite a bit of pain in doing so.  Going from IPv4 to IPv6 has proven
quite painful (and is still ongoing) but the pain was endured for a
very good reason.

Regards,

Curtis
--=_alternative 0055CBF1852578D5_=-- From swallow@cisco.com Fri Jul 22 10:44:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5575B21F8B1C; Fri, 22 Jul 2011 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-1.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi+Fye3A2O6d; Fri, 22 Jul 2011 10:44:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3621F8B1B; Fri, 22 Jul 2011 10:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=1660; q=dns/txt; s=iport; t=1311356649; x=1312566249; h=date:subject:from:to:cc:message-id:mime-version; bh=55Twyg/8FXUAfGl+6Hv2f5ptMiSDUelUECdG/Bamy74=; b=hZqr9A/HyMhujVNPE3bg8YZYHIevMzCbEudRee2WSjJqGnERUMy4sR05 ffvQ8nitWOvM5ti8H6Cmdy4Xx5zctnBSI/PL3BeyEQ87lGe4YyOaaiBNY aNasu1cJS1vXrfA4wRnFOOLcGZWYT+mmwe4InW7oFN0Tww0f050f9fUgp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIbAAm2KU6tJXG8/2dsb2JhbABTG4I4lWiHBhyGeHJ3iQCcJJ4whj8Egk+EV4tIhRCLaw X-IronPort-AV: E=Sophos;i="4.67,248,1309737600"; d="scan'208,217";a="5569662" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2011 17:44:08 +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 p6MHi8tn028413; Fri, 22 Jul 2011 17:44:08 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 12:44:08 -0500 Received: from 10.86.250.202 ([10.86.250.202]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jul 2011 17:44:08 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 22 Jul 2011 13:44:07 -0400 From: George Swallow To: Message-ID: Thread-Topic: Last call comments on draft-mpls-tp-identifiers-06.txt Thread-Index: AcxIlvRt+K9VKNK6SEijlPUe3r2GTw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394187047_5167292" X-OriginalArrivalTime: 22 Jul 2011 17:44:08.0048 (UTC) FILETIME=[F50D3700:01CC4896] Cc: mpls@ietf.org Subject: [mpls] Last call comments on draft-mpls-tp-identifiers-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:44:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3394187047_5167292 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I=B9ve addressed the last call comments received on the list as well as some comments on =AD05.txt that were received after the WG LC completed. The response to specific comments are in a spreadsheet which can be found at http://www.pi.nu/~loa/MPLS-TP-Identifiers_IETF_LC_Comments.xls I=B9ve also addressed some of the discuss issues raised by IESG members. The new =AD07 version has been posted. ...George --B_3394187047_5167292 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Last call comments on draft-mpls-tp-identifiers-06.txt I’ve addressed the last call comments received on the list as well a= s some comments on –05.txt that were received after the WG LC complete= d.  The response to specific comments are in a spreadsheet which can be= found at
http://www.pi.nu/~loa/MPLS-TP-Identifiers_IETF_LC_Com= ments.xls

I’ve also addressed some of the discuss issues raised by IESG members= .

The new –07 version has been posted.

...George --B_3394187047_5167292-- From curtis@occnc.com Fri Jul 22 12:27:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BFB21F8AF1 for ; Fri, 22 Jul 2011 12:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvbb3OXFZVwU for ; Fri, 22 Jul 2011 12:26:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9321F86BE for ; Fri, 22 Jul 2011 12:26:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6MJPS3N030021; Fri, 22 Jul 2011 15:25:29 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107221925.p6MJPS3N030021@harbor.orleans.occnc.com> To: Malcolm.BETTS@zte.com.cn From: Curtis Villamizar In-reply-to: Your message of "Fri, 22 Jul 2011 11:36:43 EDT." Date: Fri, 22 Jul 2011 15:25:28 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" , Ross Callon Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:27:00 -0000 Malcolm, The text you cite has nothing to do with the issues related to AII in PW. The AII does specificy a globally unique identifier which can be used if PW T-PE are using IPv4 private address space and a lot of protocol definitions and implementations rely on the PW AII. Curtis In message Malcolm.BETTS@zte.com.cn writes: > > Curtis, > > The introduction of draft-ietf-mpls-tp-identifiers states: > > 1. Introduction > > This document specifies an initial set of identifiers to be used in > the Transport Profile of Multiprotocol Label Switching (MPLS-TP). > The MPLS-TP requirements (RFC 5654) [7] require that the elements and > objects in an MPLS-TP environment are able to be configured and > managed without a control plane. In such an environment many > conventions for defining identifiers are possible. This document > defines identifiers for MPLS-TP management and OAM functions suitable > to IP/MPLS conventions. The identifiers have been chosen to be > compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. > > The mapping to control plane identifiers is only mentioned in section 5.3: > > 5.3. Mapping to RSVP Signaling > > This section is informative and exists to help understand the > structure of the LSP IDs. > GMPLS [5] is based on RSVP-TE [2]. This section defines the mapping > from an MPLS-TP LSP_ID to RSVP-TE. At this time, RSVP-TE has yet to > be extended to accommodate Global_IDs. Thus a mapping is only made > for the network unique form of the LSP_ID. > > As Rolf stated in his reply, win-mpls-tp-itu-t-identifiers describes the > substitution of the global ID with an ICC based identifier. > > On this basis I am have trouble understanding how your comments are > relevant. > > Regards, > > Malcolm > > > Curtis Villamizar > Sent by: curtis@occnc.com > 22/07/2011 10:23 AM > Please respond to > curtis@occnc.com > > > To > Rolf Winter > cc > "curtis@occnc.com" , Ross Callon , > John E Drake , "mpls@ietf.org" , > "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" > > Subject > Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 > > > > > > > > In message <791AD3077F94194BB2BDD13565B6295D1D009C33@Polydeuces.office.hd> > Rolf Winter writes: > > > > Curtis, > > > > please see inline: > > > > > > > I think the objections are related to "and whether the document is a > > > reasonable start towards a working group document". > > > > > > It covers only OAM identifiers and not tunnel, LSP, PW, etc and > > > therefor it is too incomplete to be a reasonable start. If either the > > > same author or another provided a more complete document, then it > > > would be a reasonable start. If the WG feels that it is acceptable to > > > specify use of ICC/CC restricted to no use of a control plane, then > > > that must be very agreed to by the WG and very clearly stated in the > > > draft. > > > > That is not quite accurate. I think you have missed this part of our > > document: > > > > "The same substitution procedure applies to all identifiers specified > > in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives > > mentioned in this document." > > > > In other words, _all_ IDs are already there and made globally unique > > with the ICC_Operator_ID defined in section 4. > > Perhaps I needed to provide more detail to expand on the perhaps too > terse point that I made above. > > A key point in I-D.ietf-mpls-tp-identifiers is that all of the > identifiers are consistent with existing routing and signaling > extensions defined for MPLS (including GMPLS and MPLS-TP) and PW. > > The 4 byte global ID (based on AS number) is consistent with RFC 5003 > "Attachment Individual Identifier (AII) Types for Aggregation". The > unique Attachment Interface Identifier (AII) is a four byte quantity. > > 3.1. The Global ID > > RFC 5003 [3] defines a globally unique Attachment Interface > Identifier (AII). That AII is composed of three parts, a Global ID > which uniquely identifies a operator, a prefix, and finally and > attachment circuit identifier. We have chosen to use that Global > ID for MPLS-TP. Quoting from RFC 5003, section 3.2, "The global ID can > contain the 2-octet or 4-octet value of the operator's Autonomous > System Number (ASN). It is expected that the global ID will be > derived from the globally unique ASN of the autonomous system hosting > the PEs containing the actual AIIs. The presence of a global ID > based on the operator's ASN ensures that the AII will be globally > unique." > > The ITU Carrier Code does not have that property (fitting nicely into > four bytes and uniquely identifying a provider). > > A quick search for SAII or TAII or RFC 5003 yields the following. The > following documents either reference RFC 5003 or make use of AII. > > RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS) > Data Plane Failures > > RFC 4447 - Pseudowire Setup and Maintenance > Using the Label Distribution Protocol (LDP) > > RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions > for Layer 2 Tunneling Protocol (L2TP) > > RFC 4762 - Virtual Private LAN Service (VPLS) Using > Label Distribution Protocol (LDP) Signaling > > RFC 5287 - Control Protocol Extensions for the Setup of > Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks > > RFC 5601 - Pseudowire (PW) Management Information Base (MIB) > > RFC 6073 - Segmented Pseudowire > > RFC 6074 - Provisioning, Auto-Discovery, and Signaling > in Layer 2 Virtual Private Networks (L2VPNs) > > At the very least, RFC 5003 needs to be updated with a new document > defining a new AII type. > > Then any implementation claiming compatibility needs to update all of > the above protocol implementations to accommodate the new AII type. > The list above may not be complete in that inclusion of RFC 4447 > implies any use of PW with LDP signaling, therefore impacts the > implementation of most documents from the PWE3 WG. The inclusion of > RFC 4379 in the list means that any use of MPLS Ping, including MPLS > use, PW use in VCCI, and MPLS-TP use is impacted. > > If I were to expand the search to find references to RFC 4379 and RFC > 4447 there would be a very long list of RFC implementations affected. > > > Best, > > > > Rolf > > The reason I have called this work hopelessly incomplete is that you > have specified a "wish" to use ICC/CC as the GLobal_ID, but have not > specified or called for necessary protocol extensions, and nave not > even touched on the impact of doing so and enumerated the changes to > existing protocol implementations that would be required. > > In addition, I see zero gain in using ICC/CC rather than AS number and > quite a bit of pain in doing so. Going from IPv4 to IPv6 has proven > quite painful (and is still ongoing) but the pain was endured for a > very good reason. > > Regards, > > Curtis From iesg-secretary@ietf.org Sat Jul 23 05:38:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A535321F899F; Sat, 23 Jul 2011 05:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1skXInwISb1; Sat, 23 Jul 2011 05:38:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4221F88A6; Sat, 23 Jul 2011 05:38:44 -0700 (PDT) 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.55 Message-ID: <20110723123844.20334.61725.idtracker@ietfa.amsl.com> Date: Sat, 23 Jul 2011 05:38:44 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 12:38:44 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP- TE Label Switched Paths' 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 2011-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-no-php-oob-mapping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-te-no-php-oob-mapping/ No IPR declarations have been submitted directly on this I-D. This document makes a DownRef in the form of a Normative reference to an Informational RFC: RFC 5920 From martin.vigoureux@alcatel-lucent.com Sun Jul 24 07:19:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41B521F8AC3 for ; Sun, 24 Jul 2011 07:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1icp56zgAba for ; Sun, 24 Jul 2011 07:19:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6F721F8A97 for ; Sun, 24 Jul 2011 07:19:31 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6OEJQW3006597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2011 09:19:27 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6OEJPmD030690 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 24 Jul 2011 09:19:26 -0500 Received: from [135.244.34.0] (135.3.63.243) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 24 Jul 2011 09:19:25 -0500 Message-ID: <4E2C29EC.3000802@alcatel-lucent.com> Date: Sun, 24 Jul 2011 16:19:24 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "MPLS @ IETF" References: <4E248BA2.8060903@alcatel-lucent.com> In-Reply-To: <4E248BA2.8060903@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Updated agenda of MPLS Sessions at IETF81 uploaded X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 14:19:32 -0000 heads-up, the agenda has been updated. martin Le 18/07/2011 21:38, Martin Vigoureux a crit : > all, > > the agenda is uploaded: > http://www.ietf.org/proceedings/81/agenda/mpls.txt > > As you'll notice we are packed so please respect your slot duration. > Please consider that the slot duration accounts for both your > presentation and the potential questions that it might trigger. > > martin > > > ps: if you are not on the agenda this is most surely because you did not > send me any request ... > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From martin.vigoureux@alcatel-lucent.com Sun Jul 24 08:23:48 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69821F869E for ; Sun, 24 Jul 2011 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.49 X-Spam-Level: X-Spam-Status: No, score=-105.49 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBEbF4IUZN8m for ; Sun, 24 Jul 2011 08:23:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E077B21F869D for ; Sun, 24 Jul 2011 08:23:47 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6OFNlZL007338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 24 Jul 2011 10:23:47 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6OFNkMN012434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 24 Jul 2011 10:23:46 -0500 Received: from [135.244.34.0] (135.3.63.243) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 24 Jul 2011 10:23:46 -0500 Message-ID: <4E2C3901.5030503@alcatel-lucent.com> Date: Sun, 24 Jul 2011 17:23:45 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [mpls] Information concerning MPLS Sessions @IETF81 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 15:23:48 -0000 Session I; Monday, 09:00-11:30 On site participation: Room 206-B http://tools.ietf.org/agenda/81/venue/?room=206-b Remote participation: Webex link: https://workgreen.webex.com/workgreen/j.php?ED=180772312&UID=1245061107&RT=MiM0 Webex Meeting Number: 969 714 432 Audio stream: http://ietf81streaming.dnsalias.net/ietf/ietf805.m3u Chat room: mpls@jabber.ietf.org Session II; Wednesday, 13:00-15:00 On site participation: Room 206-B http://tools.ietf.org/agenda/81/venue/?room=206-b Remote participation: Webex link: https://workgreen.webex.com/workgreen/j.php?ED=180773172&UID=1245064322&RT=MiM0 Webex Meeting Number: 967 822 368 Audio stream: http://ietf81streaming.dnsalias.net/ietf/ietf805.m3u Chat room: mpls@jabber.ietf.org Agenda, presentations and minutes: http://tools.ietf.org/wg/mpls/agenda?item=agenda81.html https://datatracker.ietf.org/meeting/81/materials.html From gregimirsky@gmail.com Sun Jul 24 12:50:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C611321F899D for ; Sun, 24 Jul 2011 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oatjZ8Af+vXJ for ; Sun, 24 Jul 2011 12:50:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66621F88B7 for ; Sun, 24 Jul 2011 12:50:19 -0700 (PDT) Received: by vxi40 with SMTP id 40so3235986vxi.31 for ; Sun, 24 Jul 2011 12:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NsXnEuW8pvxP+/sx8iadfrR1Gd2fS/cQukoUMxkh3r8=; b=a8SeXnJOU+Uqg5hiUVA+8nO9Q6LQVRo6BrgA47oejVcdmdv1eGGTySThJ4Z2AQZ1gS VRTw6kD5C+PgGmeYWEPv8iePTFu+CWWwg5fH3TNgO4FxOb5rYR1gMQydsbqwqXi3EUbf a8iPD55UObF7mzRxbMqB07faobo/54MngxXsk= MIME-Version: 1.0 Received: by 10.52.156.3 with SMTP id wa3mr3858052vdb.24.1311537018271; Sun, 24 Jul 2011 12:50:18 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Sun, 24 Jul 2011 12:50:18 -0700 (PDT) Date: Sun, 24 Jul 2011 12:50:18 -0700 Message-ID: From: Greg Mirsky To: Sami Boutros Content-Type: multipart/alternative; boundary=bcaec53aee24157a1c04a8d6021a Cc: BUSI ITALO , "wu.bo@zte.com.cn" , "Bitar, Nabil N" , "Siva Sivabalan\(msiva\)" , David Ward , "mpls@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 19:50:21 -0000 --bcaec53aee24157a1c04a8d6021a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Authors and All, please find my comments to the latest version: - Introduction Is LI/LB mechanism applicable to MPLS-TP Sections? - Introduction RE: LI/LB signaling methods in-band and LSP Ping are discussed as opposites. Isn=92t LSP Ping an in-band methods too? - Section 3.5 Each individual LI/LB Request can carry or not to carry Authentication TLV? LSP Ping MPLS-TP OAM Configuration does not control whether LI/LB session Authenticated or not. - Section 4. What is the rationale to allow use of different methods to do LI/LB in one session? I think that model of LI/LB session with predef= ined parameters, e.g. Authentication, might be even duration, and etc. will b= e useful and beneficial. - Section 4.3 Control over the Loopback mode is done entirely based on the TTL value. I think this is too weak and can be strengthen by combini= ng with match to a destination MIP ID. I suggest to make use of destination= MIP ID mandatory for LB request. Then we can use Cause code 1 =93Fail to mat= ch target MIP/MEP ID=94 in NACK. Thus Section 6.1 General Procedures will b= e modified too. - Sections 6.3 and further logically are based on Section 6.2 and should be enumerated 6.2.1, 6.2.2, =85 - Section 6.3 bullet 2 refers to source MEP ID but none of presented formats or previous descriptions mentions use of Source MEP ID in Lock Request in-band encapsulation. - Same issue with 6.3.b =96 Target MEP ID. - MEP-ID and MEP-A might be confusing. Suggest to use =93MEP ID=94 and =93MEP-A=94 to differentiate type of identifier and node specified. - Section 6.3 refers to an example =93the OAM traffic, e.g. cv and cc packets=94 I think that more likely that DM and LM packets will be sent = under LI/LB. - Section 7 I think that order in which Authentication is used is not adequate for procedures like LI/LB that can severely affect services. Your feedback is greatly appreciated. Regards, Greg On Sun, Jun 19, 2011 at 11:19 PM, Sami Boutros wrote: > Hi Greg, > > > At 04:52 PM 6/7/2011, Gregory Mirsky wrote: > > Hi Sami, > thank you for your response. Please find my notes below and in-lined with > tag GIM>>: > > second paragraph of Introduction refers to use of LSP-Ping "either ove= r > GACh or using native IP addressing". I think that this is in reference= to > different encapsulations of LSP-Ping and the text might benefit from t= he > clarification and note that with either type of encapsulation an LSP-P= ing is > always transported in-band over MPLS-TP network. Considering that > characterizing G-ACh encapsulation as exclusively "in-band option" for= LI-LB > transport might be misleading. Perhaps it can be referred as "G-ACh op= tion". > > > Sami: Agreed, will clarify the text to align more with the on-demand-cv > draft that allows LSP Ping to be G-ACH encaped with or without IP address= . > > > > Section 3.3 What is application of Informational Return Code? > > > Sami: No application so far. > > > > Section 3.5 Which Operation and Return Code values should be used when > negotiating CHAP Authentication? > > > Sami: We will use Request and Response messages with the same operation > being authenticated, return codes will reflect authentication > success/failures in case we get one. > > > > section 3.6.2 states that "only LI-LB response TLV might be present in > LSP Ping Echo request message". I think it is a typo and this clarific= ation > is in regard to LSP Ping Echo reply message, not request. > > > Sami: Will address. > > > > - In 6.3.g it might be "back to MEP-A' in place of "back to A" to be > consistent with terminology used. > > > Sami: Will address. > > > > I find draft-ietf-mpls-tp-ach-tlv-02 expired and IANA's ACH TLV > Registry is empty. The document doesn't request IANA allocation of ACH= TLV > types for Source MEP-ID, Destination MEP-ID, Destination MIP-ID, and > Authentication. How these ACH TLV types will be defined? > > > Sami: Will get rid of the MEP-IDs and use source/tgt identifiers defined = in > the on-demand-cv draft. > > > > Reference 9 is missing mention of RFC 1334. > > > Sami: Will add. > > Thanks, > > Sami > > > Regards, > Greg > > ------------------------------ > *From:* mpls-bounces@ietf.org [ mailto:mpls-bounces@ietf.org] > *On Behalf Of *Sami Boutros > *Sent:* Monday, June 06, 2011 10:16 PM > *To:* Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; > martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > swallow@cisco.com; David Ward; stbryant@cisco.com; cpignata@cisco.com; > Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN); > laurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.cn; > yang_jian@zte.com.cn; mpls@ietf.org > *Subject:* Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 > > Hi Greg, > > Here are responses to your comments please let us know if you are OK with > the Responses. > > > - section 3.2 I think that there are mandatory TLVs for LI-LB and > optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP= -ID, > while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication T= LV. > > > Response-1: Correct. > GIM>> I don't find Source and Destination MEP-ID, MIP-ID TLVs being > discussed or referenced even though section 6.3 refers to validation of > Source and Destination/target MEP-IDs. > > > - section 3.3.5 describes Return Code in Return TLV for LSP-ping optio= n > of LI-LB signaling. For in-band option Return Code has different value= s and > values listed in this section are for field Cause Code. I think it wou= ld be > beneficial to have some uniformity across LI-LB signalling options and= in > Return TLV have both Return Code and Cause Code fields with values ide= ntical > for in-band and LSP-Ping options. > > > Response-2: Addressed in latest version -02 where we made this section > shared by both in-Band and LSP-Ping, we as well limited the # of TLVs use= d > by LSP Ping. > GIM>> Great > > > - section 3.3.6 defines Authentication TLV for LSP-Ping option. > Authentication of LB request but in-band option doesn't have provision= to > indicate that Authentication is in use. I propose to allocate MSB of > Reserved field as Authentication flag. > > > Response-3: Addressed in latest version -02 by making authentication TLV > common to both in-band and LSP Ping. > GIM>> Agree > > > - section 6.3 mentions that Authentication may be used both in Lock > request and Lock response. I think that if Authentication was present = in > Lock request and accepted by remote MEP, then Lock response must have > Authentication. Similar is applicable to use of Authentication in Unlo= ck > request/response, and Setting/Removing LB . > > > Response-4: We described authentication procedures in more details in > section 3.5 of latest draft version, please have a look to see if it > addresses your concern. > GIM>> I was thinking of allocating an Authnetication (A) flag from > Reserved field to indicate whether Authentication is in use for given LB = and > LI. Note, that setting of A flag on LI Lock request or LB Set request > defines use of Authentication not only in corresponding replies but in > Unlock/Unset as well. > > > - section 6.5.b I think that there's no guarantee that sender of LI > request will not generate false positive after remote MEP locks the LS= P. > Perhaps, if proactive OAM is enabled, the remote MEP should send LI re= ply > but it might stop sending OAM messages after 3*TxPeriod interval. > > > Response-5: Addressed in section 6.3 last paragraph > > MEP-D will lock the LSP, resulting in that all traffic from D to A, > including all OAM traffic, stops. > > a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc > packets, but since it has been informed that the LSP will be locked it wi= ll > take no action(s). > b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM > traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is = in > Locked state it will take no action. > GIM>> Thank you. > > Thanks, > > Sami > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec53aee24157a1c04a8d6021a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
please find my comments to the latest version:
  • Introduction Is LI/LB mechanism applicable to MPLS-TP Sections?
  • Introduction RE: LI/LB signaling methods in-band and LSP Ping are discussed as oppo= sites. Isn=92t LSP Ping an in-band methods too?
  • Section 3.5 Each individual LI/LB Request can carry or not to carry Authentica= tion TLV? LSP Ping MPLS-TP OAM Configuration does not control whether LI/LB session Authenticated or not.
  • Section 4. What is the rationale to allow use of different methods to do LI/LB= in one session? I think that model of LI/LB session with predefined param= eters, e.g. Authentication, might be even duration, and etc. will be useful= and beneficial.
  • Section 4.3 Control over the Loopback mode is done entirely based on the TTL value. I think this is too weak and can be strengthen by combining wit= h match to a destination MIP ID. I suggest to make use of destination MI= P ID mandatory for LB request. Then we can use Cause code 1 =93Fail to matc= h target MIP/MEP ID=94 in NACK. Thus Section 6.1 General Procedures will= be modified too.
  • Sections 6.3 and further logically are based on Section 6.2 and should be enumerated 6.2.1, 6.2.2, =85
  • Section 6.3 bullet 2 refers to source MEP ID but none of presented formats or previous descriptions mentions use of Source MEP ID in Lock Request in-band encapsulation.
  • Same issue with 6.3.b =96 Target MEP ID.
  • MEP-ID and MEP-A might be confusing. Suggest to use =93MEP ID=94 and =93MEP-A= =94 to differentiate type of identifier and node specified.
  • Section 6.3 refers to an example =93the OAM traffic, e.g. cv and cc packets=94= I think that more likely that DM and LM packets will be sent under LI/LB.
    • =
  • Section 7 I think that order in which Authentication is used is not adequate f= or procedures like LI/LB that can severely affect services.
=A0 Your feedback is greatly appreciated.

Regards,
Greg


On Sun, Jun 19, 2011 at 11:19 PM, Sami Boutros <sboutros@cisco.com= > wrote:
Hi Greg,


At 04:52 PM 6/7/2011, Gregory Mirsky wrote:
Hi Sami,
thank you for your response. Please find my notes below and in-lined with tag GIM>>:
    second paragraph of Introduction refers to use of LSP-Ping "either over GACh or using native IP addressing". I think that this is in reference to different encapsulations of LSP-Ping and the text might benefit from the clarification and note that with either type of encapsulation an LSP-Ping is always transported in-band over MPLS-TP network. Considering that characterizing G-ACh encapsulation as exclusively "in-band option" for LI-LB transport might be misleading. Perhaps it can be referred as "G-ACh option".

Sami: Agreed, will clarify the text to align more with the on-demand-cv draft that allows LSP Ping to be G-ACH encaped with or without IP address.


    Section 3.3 What is application of Informational Return Code?

Sami: No application so far.


    Section 3.5 Which Operation and Return C= ode values should be used when negotiating CHAP Authentication?

Sami: We will use Request and Response messages with the same operation being authenticated, return codes will reflect authentication success/failures in case we get one.


    section 3.6.2 states that "only LI-= LB response TLV might be present in LSP Ping Echo request message". I think it is a typo and this clarification is in regard to LSP Ping Echo reply message, not request.

Sami: Will address.


  • In 6.3.g it might be "back to MEP-A' in place of "back to A" to be consistent with terminology used.

Sami: Will address.


    I find draft-ietf-mpls-tp-ach-tlv-02 exp= ired and IANA's ACH TLV Registry is empty. The document doesn't request = IANA allocation of ACH TLV types for Source MEP-ID, Destination MEP-ID, Destination MIP-ID, and Authentication. How these ACH TLV types will be defined?

Sami: Will get rid of the MEP-IDs and use source/tgt identifiers defined in the on-demand-cv draft.


    Reference 9 is missing mention of RFC 1334.

Sami: Will add.

Thanks,

Sami


=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0 Greg

From: mpls-bounces@ietf.org [ mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros
Sent: Monday, June 06, 2011 10:16 PM
To: Greg Mirsky; Siva Sivabalan(msiva); Rahul Aggarwal; ma= rtin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; swallow@cisco.com; David Ward; stbr= yant@cisco.com; cpignata@cisco.com; Bitar, Nabil N; BUSI ITALO; LEVRAU, LIEVEN (LIEVEN); l= aurent.ciavaglia@alcatel-lucent.com; wu.bo@zte.com.= cn; yang_jian@zte.com= .cn; mpls@ietf.org
Subject: Re: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01

Hi Greg,

Here are responses to your comments please let us know if you are OK with the Responses.

  • section 3.2 I think that there are mandatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV.

Response-1: Correct.
=A0GIM>> I don't find Source a= nd Destination MEP-ID, MIP-ID TLVs being discussed or referenced even though section 6.3 refers to validation of Source and Destination/target MEP-IDs.
  • section 3.3.5 describes Return Code in Return TLV for LSP-ping option of LI-LB signaling. For in-band option Return Code has different values and values listed in this section are for field Cause Code. I think it would be beneficial to have some uniformity across LI-LB signalling options and in Return TLV have both Return Code and Cause Code fields with values identical for in-band and LSP-Ping options.

Response-2: Addressed in latest version -02 where we made this section shared by both in-Band and LSP-Ping, we as well limited the # of TLVs used by LSP Ping.
=A0GIM>> Great
  • section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentication of LB request but in-band option doesn't have provision = to indicate that Authentication is in use. I propose to allocate MSB of Reserved field as Authentication flag.

Response-3: Addressed in latest version -02 by making authentication TLV common to both in-band and LSP Ping.
=A0GIM>> Agree
  • section 6.3 mentions that Authentication may be used both in Lock request and Lock response. I think that if Authentication was present in Lock request and accepted by remote MEP, then Lock response must have Authentication. Similar is applicable to use of Authentication in Unlock request/response, and Setting/Removing LB .

Response-4: We described authentication procedures in more details in section 3.5 of latest draft version, please have a look to see if it addresses your concern.
GIM>> I was thinking of allocating an Authnetication (A) flag from Reserved field to indicate whether Authentication is in use for given LB and LI. Note, that setting of A flag on LI Lock request or LB Set request defines use of Authentication not only in corresponding replies but in Unlock/Unset as well.
  • section 6.5.b I think that there's no guarantee that sender of LI request will not generate false positive after remote MEP locks the LSP. Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply but it might stop sending OAM messages after 3*TxPeriod interval.

Response-5:=A0 Addressed in section 6.3 last paragraph

MEP-D will lock the LSP, resulting in that all traffic from D to A, including all OAM traffic, stops.

a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv and cc packets, but since it has been informed that the LSP will be locked it will take no action(s).
b. When MEP-A receives the LI ACK, MEP-A discontinues sending other OAM traffic, e.g. cv and cc packets. MEP-D will detect this, but since it is in Locked state it will take no action.
GIM>> Thank you.

Thanks,

Sami


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


--bcaec53aee24157a1c04a8d6021a-- From rcallon@juniper.net Sun Jul 24 18:51:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26D321F8588 for ; Sun, 24 Jul 2011 18:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTx5XIIErs+S for ; Sun, 24 Jul 2011 18:51:36 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0A21F8520 for ; Sun, 24 Jul 2011 18:51:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTizMHpdbFU2E60Dk2YOB8O6AhFgOrUG4@postini.com; Sun, 24 Jul 2011 18:51:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 24 Jul 2011 18:48:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 24 Jul 2011 21:48:44 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Sun, 24 Jul 2011 21:48:41 -0400 Thread-Topic: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Thread-Index: AcxAqM9vEc2v19hHRiSCyP0N/Fu42gJwwqQg 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_DF7F294AF4153D498141CBEFADB17704C2A03FE4D9EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org" Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 01:51:38 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C2A03FE4D9EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This poll has now ended, and the document has been accepted as a working gr= oup document. Authors, please re-submit this document as draft-ietf-mpls-tp-itu-t-identif= iers-00. (Also note that the window for submitting internet drafts is currently clos= ed, but will re-open sometime tomorrow). Thanks, Ross _____________________________________________ From: Ross Callon Sent: Tuesday, July 12, 2011 11:32 AM To: mpls@ietf.org Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org; Ross Callon; Loa An= dersson; George Swallow; Martin Vigoureux Subject: Poll on draft-win-mpls-tp-itu-t-identifiers-01 Working Group, this is to start a 12 day poll on making draft-win-mpls-tp-itu-t-identifiers-01 an mpls working group document. If you support the document becoming a working group document please respond to this poll with "yes/support" If you do not support the document becoming a working group document please respond to this poll with "no/do not support" and at the same time give the technical reasons why you are not supporting the document. If you have technical comments or in any other way want to discuss the document, please send these comments to the mpls working group mailing list, but with another subject than what is on this mail. Please include th= e string "draft-win-mpls-tp-itu-t-identifiers" in the subject line. The poll ends 2011-07-24. Please note that this is the Sunday before the IETF. Also note that the length of the poll has been shortened by two days so that the poll can be completed prior to our first WG meeting in Quebec C= ity. Ross --_000_DF7F294AF4153D498141CBEFADB17704C2A03FE4D9EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This poll has now ended, and the document has = been accepted as a working group document.
 
Authors, please re-submit this document as dra= ft-ietf-mpls-tp-itu-t-identifiers-00. 
 
(Also note that the window for submitting inte= rnet drafts is currently closed, but will re-open sometime tomorrow).
 
Thanks, Ross
 
_________________________= ____________________
From: Ross Callon
Sent: Tuesday, July 12, 2011 11:32 AM
To: mpls@ietf.org
Cc: draft-win-mpls-tp-itu-t-identifiers@tools.ietf.org; Ross Callon;= Loa Andersson; George Swallow; Martin Vigoureux
Subject: Poll on draft-win-mpls-tp-itu-t-identifiers-01
 
 
Working Group,
 
this is to start a 12 day poll on m= aking
 
draft-win-mpls-tp-itu-t-identifiers= -01
 
an mpls working group document.
 
If you support the document becomin= g a working group document please
respond to this poll with "yes= /support"
 
If you do not support the document = becoming a working group document
please respond to this poll with &q= uot;no/do not support" and at the same time
give the technical reasons why you = are not supporting the document.
 
If you have technical comments or i= n any other way want to discuss the
document, please send these comment= s to the mpls working group mailing
list, but with another subject than= what is on this mail. Please include the
string “draft-win-mpls-tp-itu= -t-identifiers” in the subject line.
 
The poll ends 2011-07-24.  Ple= ase note that this is the Sunday before the
IETF. Also note that the length of = the poll has  been shortened by two days
so that the poll can be completed p= rior to our first WG meeting in Quebec City. 
 
Ross
 
 --_000_DF7F294AF4153D498141CBEFADB17704C2A03FE4D9EMBX01WFjnprn_-- From internet-drafts@ietf.org Mon Jul 25 06:07:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D90421F8A91; Mon, 25 Jul 2011 06:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+w-KVsPVpUJ; Mon, 25 Jul 2011 06:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B166321F8A23; Mon, 25 Jul 2011 06:07:35 -0700 (PDT) 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.56 Message-ID: <20110725130735.22805.60026.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 06:07:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:07:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Linear Protection Author(s) : Stewart Bryant Eric Osborne Nurit Sprecher Annamaria Fulignoli Yaacov Weingarten Filename : draft-ietf-mpls-tp-linear-protection-08.txt Pages : 42 Date : 2011-07-25 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-08= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-08.= txt From gregimirsky@gmail.com Mon Jul 25 09:11:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E259421F8BFB for ; Mon, 25 Jul 2011 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMAvqehMYtIL for ; Mon, 25 Jul 2011 09:11:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6121F8C01 for ; Mon, 25 Jul 2011 07:28:15 -0700 (PDT) Received: by vxi40 with SMTP id 40so3753955vxi.31 for ; Mon, 25 Jul 2011 07:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=fJRkWG+zY6f3qR/5JTYs2iQEtMJwBJPoM8OwDUhCNkw=; b=FAEwbtQj8QGx+6lg20dyCNbrl6abWUaEs9QfFDYNCFR8NedK6JyA8J9ySf0kKFKfN/ RMM0CklPRgw3BspyOaoZSwuZHhKsYmYKuEuR2OkQBAVd4/Ek5KPxIYRo9XaHeenMwOb6 7F5Dhos6vxprqqIFfMVSyLPwrWFrS5lYflZAM= MIME-Version: 1.0 Received: by 10.52.172.244 with SMTP id bf20mr4294941vdc.292.1311604094723; Mon, 25 Jul 2011 07:28:14 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Mon, 25 Jul 2011 07:28:14 -0700 (PDT) Date: Mon, 25 Jul 2011 07:28:14 -0700 Message-ID: From: Greg Mirsky To: lufang@cisco.com, Ben Niven-Jenkins , scott.mansfield@ericsson.com, raymond.zhang@bt.com, "Bitar, Nabil N" , ms-daikoku@kddi.com, lei.wang@telenor.com, henry.yu@twtelecom.com, mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec51ba21726e58504a8e5a0c8 Subject: [mpls] Comments to draft-ietf-mpls-tp-security-framework-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:11:05 -0000 --bcaec51ba21726e58504a8e5a0c8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Authors and All, below are more detailed comments to the document that I've promised at the mike: - Section 1.4 GAL is =93Generic Associated Channel Label=94 not =93Gener= ic Alert Label=94 - Section 1.4 Generic Associated Channel usually is G-Ach, not G-ACH. - MEP =96 Maintenance Entity Group End Point - MIP =96 Maintenance Entity Group Intermediate Point - Section 2.1 SP (Service Provider) not listed, expanded in Section 1.4 Terminology - Enumerate models 1(a), 1(b), =85 - Security Reference Model 2(b) I don=92t think that trusted zone can be limited to a single S-PE. I=92d think that in this scenario a SS-PW or p= erhaps consecutive SS_PWs between S-PE1 and S-PE2 are the trusted zone and the = rest of MS-PW segments, i.e. CE1-T-PE1 to S-PE1 and S-PE2 to T-PE2-CE2 are untrusted zones. - How Security Model 1(a) is different from the Reference Model 3? If Ref.Model 3 is multi-provider case, then there' should be S-PE(s) and P router depicted might be not that significant to the model. Then how Ref.Model 3 is different from Ref.Model 1(b)? Only because one is multi-= SP whereas another case is single SP? If that is the case, explicit text wo= uld be helpful. - Section 4.2 Can unauthorized Lock on MSPL-TP bi-directional connection be considered as =93Unauthorized Deletion of Data Traffic=94? Your consideration and feedback greatly appreciated. Regards, Greg --bcaec51ba21726e58504a8e5a0c8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
below are more detailed comments to the document t= hat I've promised at the mike:
  • Section 1.4 GAL is =93Generic Associated Channel Label=94 not =93Generic Alert= Label=94
  • Section 1.4 Generic Associated Channel usually is G-Ach, not G-ACH.
  • MEP= =96 Maintenance Entity Group End Point
  • MIP =96 Maintenance Entity Group Intermediate Point
  • Section 2.1 SP (Service Provider) not listed, expanded in Section 1.4 Terminol= ogy
  • Enumerate models 1(a), 1(b), =85
  • Security Reference Model 2(b) I don=92t think that trusted zone can be limited = to a single S-PE. I=92d think that in this scenario a SS-PW or perhaps consecutive SS_PWs between S-PE1 and S-PE2 are the trusted zone and th= e rest of MS-PW segments, i.e. CE1-T-PE1 to S-PE1 and S-PE2 to T-PE2-CE2= are untrusted zones.
  • How Security Model 1(a) is different from the Reference Model 3? If Ref.Mo= del 3 is multi-provider case, then there' should be S-PE(s) and P route= r depicted might be not that significant to the model. Then how Ref.Model 3= is different from Ref.Model 1(b)? Only because one is multi-SP whereas ano= ther case is single SP? If that is the case, explicit text would be helpful= .
  • Section 4.2 Can unauthorized Lock on MSPL-TP bi-directional connection be considered as =93Unauthorized Deletion of Data Traffic=94?
Yo= ur consideration and feedback greatly appreciated.

Regards,
Greg<= br>
--bcaec51ba21726e58504a8e5a0c8-- From prvs=0187b53dc5=hshah@ciena.com Mon Jul 25 09:13:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E8111E820D for ; Mon, 25 Jul 2011 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.717 X-Spam-Level: * X-Spam-Status: No, score=1.717 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8h1xopu3sor for ; Mon, 25 Jul 2011 09:13:10 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 39D5A21F8D95 for ; Mon, 25 Jul 2011 08:07:50 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p6PF5n6F026965 for ; Mon, 25 Jul 2011 11:07:50 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id xs9u0r83c-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 25 Jul 2011 11:07:50 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Mon, 25 Jul 2011 11:07:50 -0400 From: "Shah, Himanshu" To: "mpls@ietf.org" Content-Class: urn:content-classes:message Date: Mon, 25 Jul 2011 11:07:46 -0400 Thread-Topic: question on draft-fuxh-ccamp-delay-loss-te-framework-00 Thread-Index: AcxK3JxZxsWzcLeZTG69bChCMPg/4w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18284.000 x-tm-as-result: No--36.458300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-25_04:2011-07-25, 2011-07-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107250109 Subject: [mpls] question on draft-fuxh-ccamp-delay-loss-te-framework-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:13:11 -0000 --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_ Content-Type: multipart/alternative; boundary="_000_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_" --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors - While this work is interesting, what is your opinion on transitivity of the Delay and Loss to be used as an attribute for RSVP-TE L= SP? In rapidly changing network, measured Delay and Loss snapshot value could = very well have changed before LSP has completed the establishment. Is that a concern? Thanks, himanshu [cid:image904aa2.gif@8c026e44.eb7940be] --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= meta content=3D"Microsoft Word 12 (filtered medium)" name=3DGenerator>
Authors –

=  

While this work is interesting, what i= s your opinion on

transitivity of the D= elay and Loss to be used as an attribute for RSVP-TE LSP?

In rapidly changing network, measured Delay and Loss &nbs= p;snapshot value could very well have changed before

LSP has completed the establishment. Is that a concern?

 

Than= ks,

himanshu




= --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_-- --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_ Content-Type: image/gif; name="image904aa2.gif@8c026e44.eb7940be" Content-Description: image904aa2.gif@8c026e44.eb7940be Content-Disposition: inline; filename="image904aa2.gif@8c026e44.eb7940be"; size=3410; creation-date="Mon, 25 Jul 2011 11:07:50 GMT"; modification-date="Mon, 25 Jul 2011 11:07:50 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E287690MDWEXGMB02ciena_-- From sboutros@cisco.com Mon Jul 25 09:13:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418611E8228 for ; Mon, 25 Jul 2011 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKJutDVv2CiD for ; Mon, 25 Jul 2011 09:13:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F54C21F8DA3 for ; Mon, 25 Jul 2011 08:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=2755; q=dns/txt; s=iport; t=1311606552; x=1312816152; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=pdUSH/mq1sEgYZSSDBP2P0Ecys3UZ6FEBjyY8wCxW8g=; b=QGT9uVyHQg5h2fYzjalYI5wA/MkWH89FP44uF71rC1irB+J0g0m1muhb CjCv/D1DOdLhRLuPv5WW46hpjgFw4aDHCW9mP8Wgcow5Nf2lERxh5OPgI ZS3Wwbjfck3kKzF/yLeWXWfy2h3IgfWQTF9j/y07pMBaMwXI0BYJqVhNN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEiGLU6rRDoJ/2dsb2JhbAA0AQEBAQMBAQERASkCOgsRCAQYKhAUBhI5BwEWIAeHQp9vd4kAog+dfoY/BIdVkCuLcA X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6143143" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jul 2011 15:09:11 +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 p6PF9BQi006381; Mon, 25 Jul 2011 15:09:11 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 08:09:11 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.168.229]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2011 08:09:10 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jul 2011 08:09:08 -0700 To: Maciek Konstantynowicz , From: Sami Boutros In-Reply-To: <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> References: <23532.1309359379@erosen-linux> <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2011 15:09:10.0481 (UTC) FILETIME=[CE825410:01CC4ADC] Cc: mpls@ietf.org Subject: Re: [mpls] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:13:19 -0000 Maciek, Will the 2 mins back off be acceptable? or will you address this aspect in your draft? and if so how? Thanks, Sami At 06:16 AM 7/12/2011, Maciek Konstantynowicz wrote: >Eric, > >Regarding your question about handling unreachable FEC becoming >reachable again:- > >We wrote a separate draft with a detailed description of LDP DoD >behaviours in the context of Seamless MPLS >http://tools.ietf.org/html/draft-beckhaus-ldp-dod-00 > >In this draft, #section-4.4.3 describes the behaviour in case >specific requested FEC is unreachable: > >4.4.3. Label Request Retry Procedure > > If AN or AGN receives a "No route" Notification in response to its > label request message, it should retry with exponential backoff > algorithm similar to the backoff algoritm mentioned in the LDP > session negotiation section 4.3. >... > AN should follow the exponential backoff algorithm as specified in > the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays > grow to a maximum delay of 2 minutes. > >Maciek > > > > >On 29 Jun 2011, at 15:56, Eric Rosen wrote: > > > > >> For a more long term approach we are in favour of a change to RFC5036 by > >> defining a new TLV which denotes the DU/DoD mode per FEC type. > > > > Does that mean you expect every FEC type to be able to work in both modes? > > If you only anticipate needing DoD for address prefix FECs, a more > > conservative solution might be to just clarify that the negotiated session > > mode applies only to address prefix FECs. > > > > While on the topic, I do have a question about the use of DoD for address > > prefix FECs. > > > > From draft-leymann-mpls-seamless-mpls-03: > > > > the AN will use LDP DoD to only request the label bindings > > for the FECs corresponding to the loopback addresses of those egress > > nodes to which it has services configured. > > > > Suppose one of the configured egress nodes is down or otherwise unreachable > > at the time the AN asks for a label binding. How does the AN get the label > > binding when the egress node becomes reachable? Is the AN expected to ask > > periodically for the binding? Is the periodic interval expected to be > > configurable? The draft should say something about this. > > > > I don't think RFC 5036 requires the AGN to remember what the AN has asked > > for, so that it can reply when and if the egress becomes reachable. > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From adrian@olddog.co.uk Mon Jul 25 09:13:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EF911E825D for ; Mon, 25 Jul 2011 09:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmKHnwOb5AZX for ; Mon, 25 Jul 2011 09:13:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8245121F8DDF for ; Mon, 25 Jul 2011 08:15:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6PFFgms020253; Mon, 25 Jul 2011 16:15:42 +0100 Received: from 950129200 ([130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6PFFe5F020169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 16:15:41 +0100 From: "Adrian Farrel" To: Date: Mon, 25 Jul 2011 11:15:29 +0100 Message-ID: <030401cc4ab3$cbcf1790$636d46b0$@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: AcxKs4x+wPuvGU8GTa6Vp8FeFGi6Xg== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Second AD review of draft-ietf-mpls-explicit-resource-control-bundle X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:13:59 -0000 Hi, I have performed a further AD review of this document because my first review was quite substantial and it has been a while since then. idnits throws up a large number of issues. A substantial number are caused by formatting problems with the document as submitted. It would be wise to fix these to allow you to uncover the real problems that are lurking. I do not appear to have received a direct response to my previous review (sorry if I lost it) and so I am piecing together your responses from the changes you have made. A number of issues remain to be addressed. I have interleaved these with a few new comments. > I have a meta-question about this draft. Given RFC 4990 Section 6.2, > why is this extension needed? I can see it would work, but what is the > benefit of creating a second way to signal a component link in an ERO > or RRO? I still think this question needs to be answered in the document. I would expect a direct reference to 4990, a statement of the limitation of 4990, and a summary of how this proposal resolves the limitation. The Abstract makes a forceful assertion on the need for this work, but the document seems to completely ignore the solution set out in 4990. > I think you need to rewrite the Abstract. Consider that you should be > able to read the Abstract in a fair degree of isolation, so it should > give context. > > At the moment you jump straight into Record Route without any hints > that you are dealing with GMPLS! > > You also need to remove citations from the Abstract (you are allowed > to name the documents). I don't see any changes for these points. > Section 1 needs to include a definition of "Component Interface" I don't see a change for this. > Can you go through the document and expand all of the acronyms where > they are first used. LSP is expanded but some time after first use SRLG is expanded but not quite in the right place LSR isn't expanded --- Section 4.1 s/oPTIoNAL/OPTIONAL/ > Section 4.1 > > The following SHOULD result in "Bad EXPLICIT_ROUTE object" error > being sent upstream by a node processing an ERO that contains the > Component Interface ID sub-object: > > o) The first component interface identifier subobject is not > preceded by a sub-object containing an IPv4 or IPv6 address, or > an interface identifier [RFC3477], associated with a TE link. > > and later... > > Inferred from above, the interface subobject should never be the > first subobject in a newly received message. If the component > interface subobject is the first subobject in a received ERO, then it > SHOULD be treated as a "Bad strict node" error. > > These seem to contradict each other. Doesn't appear to have been resolved. --- Section 7 There seems to be a discrepancy about the codepoint requests. This is marked as an Experimental document (for publication as an Experimental RFC). Yet it is making requests for codepoints from "Standard Actions" registries. My understanding is IANA will not allow this. So either the status of the I-D needs to change, or the allocations need to change. Thanks, Adrian From RCosta@ptinovacao.pt Mon Jul 25 10:37:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE73421F8BF7 for ; Mon, 25 Jul 2011 10:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmoH7K4WY20o for ; Mon, 25 Jul 2011 10:37:07 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id E4BE821F8BDC for ; Mon, 25 Jul 2011 10:37:03 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Mon, 25 Jul 2011 18:37:02 +0100 From: Rui Costa To: Thomas Nadeau Date: Mon, 25 Jul 2011 18:37:01 +0100 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxDB0TdNFHQrYoiS3+ba5ZEeJ8t7gBpVyZw Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051@INOAVREX11.ptin.corpPT.com> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com>, <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> <1310745013.23819.YahooMailRC@web88407.mail.re1.yahoo.com> <97E700BD-DBB4-4841-B550-A1E151E99F9B@lucidvision.com> In-Reply-To: <97E700BD-DBB4-4841-B550-A1E151E99F9B@lucidvision.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: multipart/alternative; boundary="_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051INOAVREX11p_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:37:12 -0000 --_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051INOAVREX11p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Tom. "The mix of CC and CV makes any implementation complex. I don't see any sig= nificant benefit in it" Agreed. We create a tool for checking the connection. That tool carries an = instance identifier in the packet. That instance identifier is all we need = to detect misconnections using just one type of packet. i"f they are run together they should be 2 separate independent BFD flow" Disagree. The problem is, we actually need a 2 way connection to run BFD's = FSM, even when one just needs/can have unidireccional check (P2P unidir, P2= MP...). So, what we need is a PDU integrating instance identifier sent @ co= nstant provisioned pace, without any articulation with the opposite path ot= her than RDI (when relevant). If we don't consider not using BFD, then at least let's not complicate it m= ore unnecessarily: we need a single type of packet for both CC and CV. The frame loss draft, f.i., doesn't put it on BFD. Do we really need that? If it's marketing we're talking about, wouldn't it be possible to set a PDU= primitive protocol, integrating instance identifier, 3 counters for FL (or= 4, as per draft-ietf-mpls-tp-loss-delay), timestamp, sent @ constant provi= sioned pace, without any articulation with the opposite path other than RDI= (when relevant) and give it a cool name? BFD_NG, UFD, xFD, BFD_reloaded...= ) "It is also a relatively less scaleable one as well as compared to doing in= HW" Agreed. Kind Regards, Rui From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Tho= mas Nadeau Sent: sexta-feira, 15 de Julho de 2011 16:52 To: S. Davari Cc: mpls@ietf.org; stbryant@cisco.com Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) While I personally agree, I'd leave how it is actually run up t= o the operators. They might know a thing or two about running their network= s. *) --Tom Robert, Forget about HW and SW. The mix of CC and CV makes any implementation compl= ex. I don't see any significant benefit in it. I suggest either running CC = or CV and of they are run together they should be 2 separate independent BF= D flow. -Shahram ________________________________ From: Robert Rennison > To: S. Davari >; Thomas Nadea= u >; "stbryant@cisc= o.com" > Cc: "mpls@ietf.org" > Sent: Fri, July 15, 2011 8:41:59 AM Subject: RE: [mpls] Last Call:(Proacti= ve Connectivity) Se we're in agreement that there's no duplication of effort required; good. I'll agree at a general level with a part of Tom's overall statement that > It is also a relatively less scaleable >one as well as compared to doing= in HW. A HW implementation of a protocol can be made to be more scaleable than a S= W only one, ok that's agreed. >From implementation experience with shipping scaleable and interoperable = BFD and has also been pointed out by Mahesh, many vendors implement a comb= ined approach, one needs software to manage the HW assist and the overall s= tate machines, so a blended approach is usually done using HW for heavy lif= ting, and distributing SW functions where necessary / desirable. The division of this work and the decision of what to accelerate with HW as= sist. is a function of where in the network the equipment is situated and t= he anticipated scale on it, these are descions made by vendors and born fro= m experiences with implementations. However one can if, desired accelerate aspects of CV with "HW" assist to= o, it's a cos/ scale tradeoff that an implementation will make. One could h= ave HW assist to send the one per second CV messages, and one could add a = "HW" function to match the CV messages if desired. Would the RX match portion be more efficient with no TLVs for the various = identifiers ? Yes. Would the extra efficiency make a substantial difference to the HW cost, I = doubt it. Is this a hard requirement ? Not that I've seen. Note: all of this talk of HW vs SW is also not precise enough, vendors have= so called Fast-path logic to play with too. so HW and SW are not necessari= ly sharp boundaries. But this is the stuff of a more general exposition and= not germane to last call comments on the specific draft on the table. Cheers Rob ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of S. Davari [davarish@yahoo= .com] Sent: Friday, July 15, 2011 8:24 AM To: Thomas Nadeau; stbryant@cisco.com Cc: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Tom is is correct. I meant to say not scalable. Shahram ________________________________ From: Thomas Nadeau > To: stbryant@cisco.com Cc: "ietf@ietf.or" >= ; "mpls@ietf.org" > Sent: Fri, July 15, 2011 4:56:13 AM Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) It is less efficient not really due to the duplication, but because the= SW path is a relatively very slow path for processing CV packets. It is also a relativ= ely less scaleable one as well as compared to doing in HW. So the a number of lines of process= ing or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >> >> 3) Process CC in HW and CV in SW, which is not efficient since we are du= plicating the HW logic in SW as well. >> > Now I know that it depends on your implementation, but just how many line= s of code are we talking about here? > The elements of this function that you would put in h/w do not seem compl= ex. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls 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_52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051INOAVREX11p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Tom. &nbs= p;

“The mix of CC and CV makes any impl= ementation complex. I don't see any significant benefit in it”

Agreed. We create a tool for checking the connection. That tool c= arries an instance identifier in the packet. That instance identifier is al= l we need to detect misconnections using just one type of packet. &nbs= p;          =

 

i“f they are run together they should be 2 separate = independent BFD flow”   &nb= sp;     

Disagree. The problem is, we actually need a 2 way co= nnection to run BFD’s FSM, even when one just needs/can have unidirec= cional check (P2P unidir, P2MP…). So, what we need is a PDU integrati= ng instance identifier sent @ constant provisioned pace, without any articu= lation with the opposite path other than RDI (when relevant).  &n= bsp; 

I= f we don’t consider not using BFD, then at least let’s not comp= licate it more unnecessarily: we need a single type of packet for both CC a= nd CV.

The = frame loss draft, f.i., doesn’t put it on BFD. Do we really need that= ?             <= o:p>

If it’s= marketing we’re talking about, wouldn’t it be possible to set = a PDU primitive protocol, integrating instance identifier, 3 counters for F= L (or 4, as per draft-ietf-mpls-tp-loss-delay), timestamp, sent @ constant = provisioned pace, without any articulation with the opposite path other tha= n RDI (when relevant) and give it a cool name? BFD_NG, UFD, xFD, BFD_reload= ed…)           = ;    

 

“It is also a relatively less scaleable one as well as compa= red to doing in HW”      <= /p>

Agreed.    &= nbsp;      <= /span>

 =

Kind Regards,   = ;

Rui

 

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of <= /b>Thomas Nadeau
Sent: sexta-feira, 15 de Julho de 2011 16:52
= To: S. Davari
Cc: mpls@ietf.org; stbryant@cisco.com
= Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt&g= t;(Proactive Connectivity)

 

<= span lang=3DEN-US> 

    &= nbsp;       = While I personally agree, I'd leave how it is actually run up to the operat= ors. They might know a thing or two about running their networks. *)

&nbs= p;

        &nb= sp;   --Tom

 

 

<= div>

Robert,

Forget about HW and SW. The mix of CC and CV makes any impl= ementation complex. I don't see any significant benefit in it. I suggest ei= ther running CC or CV and of they are run together they should be 2 separat= e independent BFD flow.

-Sha= hram

 

 

From: Robert Rennison <Robert.Rennison@ecitele.com>
To: S. Dav= ari <davarish@ya= hoo.com>; Thomas Nadeau <tnadeau@lucidvision.com<= /span>>; "stbryant@cisco.com" <stbryant@cisco.com<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>>
Cc: &quo= t;mpls@ietf.org" <mpls@ietf.org>
Sent: Fri, July 15, 2011 8:41:59 AM
Subject:=  RE: [mpls] Last Call:&= lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Se we're in agreement that there's no duplication of effort requi= red; good.

I'll agree at a general level with a part of  Tom's = overall statement that

>  It is also a relatively less scale= able >one as well as compared to doing in HW.

A HW implementation= of a protocol can be made to be more scaleable than a SW only one, ok that= 's agreed.


From  implementation experience with shipping sc= aleable and interoperable  BFD and has also  been pointed out by = Mahesh, many vendors implement a combined approach, one needs software to m= anage the HW assist and the overall state machines, so a blended approach i= s usually done using HW for heavy lifting,  and distributing SW functi= ons where necessary / desirable.

The division of this work and the d= ecision of what to accelerate with HW assist. is a function of where in the= network the equipment is situated and the anticipated scale on it, these a= re descions made by vendors and born from experiences with implementations.=

However one can if,  desired  accelerate aspects of CV&nb= sp; with "HW" assist too, it's a cos/ scale tradeoff that an impl= ementation will make. One could have HW assist to send the one per second C= V messages, and one could  add a "HW"  function to = ; match the CV messages if desired.

Would  the RX match portion= be more efficient with no TLVs for the various identifiers  ? Yes.Would the extra efficiency make a substantial difference to the HW cost, I= doubt it.
Is this a hard requirement ? Not that I've seen.

Note:= all of this talk of HW vs SW is also not precise enough, vendors have so c= alled Fast-path logic to play with too. so HW and SW are not necessarily sh= arp boundaries. But this is the stuff of a more general exposition and not = germane to last call comments on the specific draft on the table.


Cheers

Rob

________________________________________
= From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of S. Davari [davarish@yahoo.com]
Sent: F= riday, July 15, 2011 8:24 AM
To: Thomas Nadeau; stbryant@cisco.com
Cc: i= etf@ietf.or; = ;mpls@ietf.org
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-= cc-cv-rdi-05.txt>(Proactive  Connectivity)

Tom is is correct= . I meant to say not scalable.

Shahram


__________________= ______________
From: Thomas Nadeau <tnadeau@lucidvision.com>= ;
To: stbryant@cisco.com
Cc: "ietf@ietf.= or" <ietf@ietf.or>; "mpls@ietf.org"= <mpls@ietf.org= >
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: = [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Conn= ectivity)


    It is less efficient not really due to t= he duplication, but because the SW path is
a relatively very slow path f= or processing CV packets. It is also a relatively less scaleable
one as = well as compared to doing in HW. So the a number of lines of processing or = duplication
of code therein is a bit of a red herring if you ask me.
=
    --Tom



On Jul 15, 2011, at 4:12 AM, Stewart= Bryant wrote:

> On 15/07/2011 01:03, Shahram Davari wrote:
&g= t;>
>> 3) Process CC in HW and CV in SW, which is not efficient= since we are duplicating the HW logic in SW as well.
>>
> N= ow I know that it depends on your implementation, but just how many lines o= f code are we talking about here?
> The elements of this function tha= t you would put in h/w do not seem complex.
>
> - Stewart
&g= t;
>
> _______________________________________________
> = mpls mailing list
> <= /span>mpls@ietf.org<mailto:mpls@= ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls
>

_______________________________________= ________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>= https://www.ietf.org/mailman/listinfo/mpls


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

 

= --_000_52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051INOAVREX11p_-- From DanielC@orckit.com Mon Jul 25 10:44:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4C21F8770 for ; Mon, 25 Jul 2011 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4BgoIu57Y48 for ; Mon, 25 Jul 2011 10:44:39 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2065321F8781 for ; Mon, 25 Jul 2011 10:44:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4AF2.C59D1779" Date: Mon, 25 Jul 2011 20:44:35 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Thread-Index: AcxK8oSkLo44K9pDSQm7KNh1oNi2Qw== From: "Daniel Cohn" To: Cc: mpls@ietf.org Subject: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:44:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4AF2.C59D1779 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, =20 Wrt the "Two-phase without lock" option which you presented today - if the side detecting the failure does not wait for acknowledgment before switching traffic to the protection path, in which sense is this still "two phase"? =20 Regards, =20 Daniel =20 PS: I also don't see a scenario where the "lock" is required ------_=_NextPart_001_01CC4AF2.C59D1779 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Eric,

 

Wrt the “Two-phase without lock” option = which you presented today – if the side detecting the failure does = not wait for acknowledgment before switching traffic to the protection = path, in which sense is this still “two = phase”?

 

Regards,

 

Daniel

 

PS: I also = don’t see a scenario where the “lock” is = required

------_=_NextPart_001_01CC4AF2.C59D1779-- From neil.2.harrison@bt.com Mon Jul 25 11:21:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8841421F8B84 for ; Mon, 25 Jul 2011 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVHsgNj-5eqz for ; Mon, 25 Jul 2011 11:20:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4921F8B77 for ; Mon, 25 Jul 2011 11:20:54 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 25 Jul 2011 19:20:53 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.132]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 25 Jul 2011 19:20:53 +0100 From: To: , Date: Mon, 25 Jul 2011 19:20:49 +0100 Thread-Topic: [mpls] Last Call:(Proactive Connectivity) Thread-Index: AcxDB0TdNFHQrYoiS3+ba5ZEeJ8t7gBpVyZwAZI/bZA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405C52D54B@EMV62-UKRD.domain1.systemhost.net> References: <20110630134642.1281.3095.idtracker@ietfa.amsl.com>, <1310649062.45643.YahooMailRC@web88402.mail.re1.yahoo.com><786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB871@USPITMAIL01.ecitele.com>, <1466780933-1310676233-cardhu_decombobulator_blackberry.rim.net-1477022216-@b4.c27.bise6.blackberry> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB873@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9322B535A@SJEXCHCCR02.corp.ad.broadcom.com> <4E1FF655.8090005@cisco.com> <835D7FB3-6DFF-4D31-9ABF-037AB74639CD@lucidvision.com>, <1310732661.58009.YahooMailRC@web88406.mail.re1.yahoo.com> <786AD2EC3D80A1428B921CDC9BE9EE546BB7CDB876@USPITMAIL01.ecitele.com> <1310745013.23819.YahooMailRC@web88407.mail.re1.yahoo.com> <97E700BD-DBB4-4841-B550-A1E151E99F9B@lucidvision.com> <52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED4D5A2051@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E4405C52D54BEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call:(Proactive Connectivity) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:21:00 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E4405C52D54BEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rui..I agree...but also see in-line: From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rui= Costa Sent: 25 July 2011 18:37 To: Thomas Nadeau Cc: mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Thanks, Tom. "The mix of CC and CV makes any implementation complex. I don't see any sig= nificant benefit in it" Agreed. We create a tool for checking the connection. That tool carries an = instance identifier in the packet. That instance identifier is all we need = to detect misconnections using just one type of packet. NH=3D> CC is next to useless. This is the same as I.610 ATM OAM. i"f they are run together they should be 2 separate independent BFD flow" Disagree. The problem is, we actually need a 2 way connection to run BFD's = FSM, even when one just needs/can have unidireccional check (P2P unidir, P2= MP...). So, what we need is a PDU integrating instance identifier sent @ co= nstant provisioned pace, without any articulation with the opposite path ot= her than RDI (when relevant). NH=3D> It's actually quite vital that one runs defect detection OAM in a un= idirectional sense for a very simple reason: Under defect free conditions = one assumes a connection is a constraining construct to both DP traffic and= DP OAM....this (along with a single source assumption) is why one can take= short-cuts on the labelling of co-ps mode traffic units that are not allow= ed on cl-ps traffic units, ie remove SA and restrict DA to link unique only= , ie label swapping. Neither is great idea but they are doable. However, we can have instances of traffic/OAM that leaks unidirectionally o= ut of a connection/LSP, ie there simply is no return path. This is also wh= y request/response OAM must not be used to detect misconnectivity or to try= and trace out such leaks...this was another mistake of ATM I.610 OAM (mult= iple loopback technique). And, as you also note above, one can of course have asymmetrical p2mp conne= ctions...which by definition are unidirectional. Finally, one should run exactly the same type/rate of CV on all connections= both in the same layer network and all nested instances of XoverX. This i= s so that wherever misconnectivity defects occur (ie both intra and inter l= ayer network...the latter being the new case that MPLS-TP introduces) the r= eceiving trail termination point is easily able to make sense of parsing th= e received CV OAM flow. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 If we don't consider not using BFD, then at least let's not complicate it m= ore unnecessarily: we need a single type of packet for both CC and CV. The frame loss draft, f.i., doesn't put it on BFD. Do we really need that? If it's marketing we're talking about, wouldn't it be possible to set a PDU= primitive protocol, integrating instance identifier, 3 counters for FL (or= 4, as per draft-ietf-mpls-tp-loss-delay), timestamp, sent @ constant provi= sioned pace, without any articulation with the opposite path other than RDI= (when relevant) and give it a cool name? BFD_NG, UFD, xFD, BFD_reloaded...= ) "It is also a relatively less scaleable one as well as compared to doing in= HW" Agreed. Kind Regards, Rui From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Tho= mas Nadeau Sent: sexta-feira, 15 de Julho de 2011 16:52 To: S. Davari Cc: mpls@ietf.org; stbryant@cisco.com Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) While I personally agree, I'd leave how it is actually run up t= o the operators. They might know a thing or two about running their network= s. *) --Tom Robert, Forget about HW and SW. The mix of CC and CV makes any implementation compl= ex. I don't see any significant benefit in it. I suggest either running CC = or CV and of they are run together they should be 2 separate independent BF= D flow. -Shahram ________________________________ From: Robert Rennison > To: S. Davari >; Thomas Nadea= u >; "stbryant@cisc= o.com" > Cc: "mpls@ietf.org" > Sent: Fri, July 15, 2011 8:41:59 AM Subject: RE: [mpls] Last Call:(Proacti= ve Connectivity) Se we're in agreement that there's no duplication of effort required; good. I'll agree at a general level with a part of Tom's overall statement that > It is also a relatively less scaleable >one as well as compared to doing= in HW. A HW implementation of a protocol can be made to be more scaleable than a S= W only one, ok that's agreed. >From implementation experience with shipping scaleable and interoperable = BFD and has also been pointed out by Mahesh, many vendors implement a comb= ined approach, one needs software to manage the HW assist and the overall s= tate machines, so a blended approach is usually done using HW for heavy lif= ting, and distributing SW functions where necessary / desirable. The division of this work and the decision of what to accelerate with HW as= sist. is a function of where in the network the equipment is situated and t= he anticipated scale on it, these are descions made by vendors and born fro= m experiences with implementations. However one can if, desired accelerate aspects of CV with "HW" assist to= o, it's a cos/ scale tradeoff that an implementation will make. One could h= ave HW assist to send the one per second CV messages, and one could add a = "HW" function to match the CV messages if desired. Would the RX match portion be more efficient with no TLVs for the various = identifiers ? Yes. Would the extra efficiency make a substantial difference to the HW cost, I = doubt it. Is this a hard requirement ? Not that I've seen. Note: all of this talk of HW vs SW is also not precise enough, vendors have= so called Fast-path logic to play with too. so HW and SW are not necessari= ly sharp boundaries. But this is the stuff of a more general exposition and= not germane to last call comments on the specific draft on the table. Cheers Rob ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of S. Davari [davarish@yahoo= .com] Sent: Friday, July 15, 2011 8:24 AM To: Thomas Nadeau; stbryant@cisco.com Cc: ietf@ietf.or; mpls@ietf.org Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) Tom is is correct. I meant to say not scalable. Shahram ________________________________ From: Thomas Nadeau > To: stbryant@cisco.com Cc: "ietf@ietf.or" >= ; "mpls@ietf.org" > Sent: Fri, July 15, 2011 4:56:13 AM Subject: Re: [mpls] Last Call:(Proacti= ve Connectivity) It is less efficient not really due to the duplication, but because the= SW path is a relatively very slow path for processing CV packets. It is also a relativ= ely less scaleable one as well as compared to doing in HW. So the a number of lines of process= ing or duplication of code therein is a bit of a red herring if you ask me. --Tom On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote: > On 15/07/2011 01:03, Shahram Davari wrote: >> >> 3) Process CC in HW and CV in SW, which is not efficient since we are du= plicating the HW logic in SW as well. >> > Now I know that it depends on your implementation, but just how many line= s of code are we talking about here? > The elements of this function that you would put in h/w do not seem compl= ex. > > - Stewart > > > _______________________________________________ > mpls mailing list > mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls 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_6D3D47CB84BDE349BC23BF1C94E316E4405C52D54BEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rui..I agree...but also see in-line:

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rui Costa
Sent: 25 July 2011 18:37
To: Thomas Nadeau
Cc: mpls@ietf.org
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

 

Thanks, Tom.  

 

“= The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it”

Agreed. We create a tool for checking the connection. That t= ool carries an instance identifier in the packet. That instance identifier is a= ll we need to detect misconnections using just one type of packet.        

NH=3D> CC is next to useless.  This is the same as I= .610 ATM OAM.

   

 

i“f they are run together they should be 2 separate independent BFD flow”         = ;

Disagree. The problem is, we actually need a 2 way connectio= n to run BFD’s FSM, even when one just needs/can have unidireccional check (P2P unidir, P2MP…). So, what we need is a PDU integrating instance identifier sent @ constant provisioned pace, without any articulation with = the opposite path other than RDI (when relevant).     =

 

NH=3D> It’s actually quite vital that one runs defe= ct detection OAM in a unidirectional sense for a very simple reason:  Under defect = free conditions one assumes a connection is a constraining construct to both DP traffic and DP OAM....this (along with a single source assumption) is why o= ne can take short-cuts on the labelling of co-ps mode traffic units that are not allowed on cl-ps traffic units, ie remove SA and restrict DA to link unique only, ie label swapping.  Neither is great idea but they are doable.

 

However, we can have instances of traffic/OAM that leaks uni= directionally out of a connection/LSP, ie there simply is no return path.  This is a= lso why request/response OAM must not be used to detect misconnectivity or to t= ry and trace out such leaks...this was another mistake of ATM I.610 OAM (multi= ple loopback technique).

 

And, as you also note above, one can of course have asymmetr= ical p2mp connections...which by definition are unidirectional.

 

Finally, one should run exactly the same type/rate of CV on = all connections both in the same layer network and all nested instances of Xove= rX.  This is so that wherever misconnectivity defects occur (ie both intra and i= nter layer network...the latter being the new case that MPLS-TP introduces) the receiving trail termination point is easily able to make sense of parsing t= he received CV OAM flow. 

 

regards, Neil

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

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

 

If we don’t consider not using BFD, then at least let’s not complicate it more unnecessarily: we need a single type of packet for both CC and CV.

The frame loss draft, f.i., doesn’t put it on BFD. Do = we really need that?           &nbs= p;

If it’s marketing we’re talking about, wouldn’t it be possible to set a PDU primitive protocol, integrating instance identifier, 3 counters for FL (or 4, as per draft-ietf-mpls-tp-loss-delay), timestamp, sent @ constant provisioned pace= , without any articulation with the opposite path other than RDI (when releva= nt) and give it a cool name? BFD_NG, UFD, xFD, BFD_reloaded…)         &= nbsp;     

 

“It is also a relatively less scaleable one as well as compared to doing in HW”     

Agreed.    &nbs= p;     

 

Kind Regards,   

Rui

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Thomas Nadeau
Sent: sexta-feira, 15 de Julho de 2011 16:52
To: S. Davari
Cc: mpls@ietf.org; stbryant@cisco.com
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

 

 

 =            While I personally agree, I'd leave how it= is actually run up to the operators. They might know a thing or two about runn= ing their networks. *)

 

 =            --Tom

 

 

Robert,<= br>
Forget about HW and SW. The mix of CC and CV makes any implementation compl= ex. I don't see any significant benefit in it. I suggest either running CC or C= V and of they are run together they should be 2 separate independent BFD flow= .

-Shahram

 =

 =

From: Robert Renniso= n <Robert.Renni= son@ecitele.com&= gt;
To: S. Davari <davarish@yahoo.com&= gt;; Thomas Nadeau <tnadeau@lucidvision.com>; "stbryant@cisco.com&= quot; <stbryant@cisco.com&= gt;
Cc: "mpls@ietf.org&= quot; <mpls@ietf.org&= gt;
Sent: Fri, July 15, = 2011 8:41:59 AM
Subject: RE: [mpls] = Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)
Se we're in agreement that there's no duplication of effort required; good.=

I'll agree at a general level with a part of  Tom's overall statement = that

>  It is also a relatively less scaleable >one as well as compar= ed to doing in HW.

A HW implementation of a protocol can be made to be more scaleable than a S= W only one, ok that's agreed.


From  implementation experience with shipping scaleable and interopera= ble  BFD and has also  been pointed out by Mahesh, many vendors implement a combined approach, one needs software to manage the HW assist and the overa= ll state machines, so a blended approach is usually done using HW for heavy lifting,  and distributing SW functions where necessary / desirable.
The division of this work and the decision of what to accelerate with HW assist. is a function of where in the network the equipment is situated and= the anticipated scale on it, these are descions made by vendors and born from experiences with implementations.

However one can if,  desired  accelerate aspects of CV  with "HW" assist too, it's a cos/ scale tradeoff that an implementatio= n will make. One could have HW assist to send the one per second CV messages,= and one could  add a "HW"  function to  match the CV messages if desired.

Would  the RX match portion be more efficient with no TLVs for the var= ious identifiers  ? Yes.
Would the extra efficiency make a substantial difference to the HW cost, I doubt it.
Is this a hard requirement ? Not that I've seen.

Note: all of this talk of HW vs SW is also not precise enough, vendors have= so called Fast-path logic to play with too. so HW and SW are not necessarily s= harp boundaries. But this is the stuff of a more general exposition and not germ= ane to last call comments on the specific draft on the table.



Cheers

Rob

________________________________________
From: mpls-bounces@ietf.= org [mpls-bounces@ietf.= org] = On Behalf Of S. Davari [davarish@yahoo.com]<= br> Sent: Friday, July 15, 2011 8:24 AM
To: Thomas Nadeau; <= span lang=3DPT style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>stbryant@cisco.com Cc: ietf@ietf.or;<= span class=3Dapple-converted-space> <= span lang=3DEN-US>mpls@ietf.org
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive  Connectivi= ty)

Tom is is correct. I meant to say not scalable.

Shahram


________________________________
From: Thomas Nadeau <tnadeau@lucidvision.com>
To: stbryant@cisco.com Cc: "ietf@ietf.or&q= uot; <ietf@ietf.or&g= t;; "mpls@ietf.org&q= uot; <mpls@ietf.org&g= t;
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

    It is less efficient not really due to the duplication, but because the SW path is
a relatively very slow path for processing CV packets. It is also a relativ= ely less scaleable
one as well as compared to doing in HW. So the a number of lines of process= ing or duplication
of code therein is a bit of a red herring if you ask me.

    --Tom



On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> On 15/07/2011 01:03, Shahram Davari wrote:
>>
>> 3) Process CC in HW and CV in SW, which is not efficient since we = are duplicating the HW logic in SW as well.
>>
> Now I know that it depends on your implementation, but just how many l= ines of code are we talking about here?
> The elements of this function that you would put in h/w do not seem complex.
>
> - Stewart
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org&l= t;mailto:mpls@ietf.org&g= t;
> https://www.ietf.org/mailman/listinfo/mpls >

_______________________________________________
mpls mailing list
mpls@ietf.org&l= t;mailto:mpls@ietf.org&g= t;
https://www.ietf.org/mailman/listinfo/mpls

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 h= ave received this transmission in error, please inform us by e-mail, phone or f= ax, and then delete the original and all copies thereof.

 

--_000_6D3D47CB84BDE349BC23BF1C94E316E4405C52D54BEMV62UKRDdoma_-- From eosborne@cisco.com Mon Jul 25 11:34:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF8221F8C24 for ; Mon, 25 Jul 2011 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IrbjdCD9Ehl for ; Mon, 25 Jul 2011 11:34:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D144021F8AE6 for ; Mon, 25 Jul 2011 11:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1630; q=dns/txt; s=iport; t=1311618850; x=1312828450; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=76B/ZA0MJoUrpUfvyRFNBIu0YzppSnYJoUNK5O2RMZ0=; b=T0vkUANzzYTD4r63gHML/A/M6YNPO2fxx9VOgkVsb9RWmxJ+NByq/8/J njkq+2wUj7kK88tA/z7ZFK+5sLNS7+u9VMWdt9QRFdspI/nhVpkT68eP8 uoUTNJUziTIq6iDFSYSxxTfgUiaQ6MmCRKQkXk3utvodgQS+DfepPgejX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAIy2LU6tJV2a/2dsb2JhbAA0AQEBAQMUASEKRQwFAgEJEQQBAQsGIwEGARM7DggBAQUXDBuXW49Xd6piniGFYF8Eh1WQK4tu X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6217101" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2011 18:34:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6PIY9NZ017645; Mon, 25 Jul 2011 18:34:09 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 13:34:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 13:34:08 -0500 Message-ID: In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Thread-Index: AcxK8oSkLo44K9pDSQm7KNh1oNi2QwABnB7g References: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> From: "Eric Osborne (eosborne)" To: "Daniel Cohn" X-OriginalArrivalTime: 25 Jul 2011 18:34:08.0834 (UTC) FILETIME=[70E61220:01CC4AF9] Cc: mpls@ietf.org Subject: Re: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:34:10 -0000 Hi Daniel- That is indeed a good question. To me, it's two-phase in that there are two phases to the message (protection notification, and the ACK in reply). All we're doing with my proposed behavior is sending the traffic that we would have converged on anyways, without waiting unnecessarily. As I noted in my slides, we need this so that after all the dust settles, both ends of the protection domain can agree on what they're protecting. This is really only necessary in the case of an oddball unidirectional failure. =20 You could argue that all unidir failures should be caught by CC/Cv and that we should not have to worry about anything in PSC other than bidirectional failures. And if you did argue that I'd be in vehement agreement that it'd be nice to ignore unidir failures. But we can't, and so we need to be able to handle them in PSC, which makes several things trickier than they would be otherwise. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, July 25, 2011 1:45 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg question?) >=20 > Hi Eric, >=20 >=20 >=20 > Wrt the "Two-phase without lock" option which you presented today - if the > side detecting the failure does not wait for acknowledgment before > switching traffic to the protection path, in which sense is this still > "two phase"? >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Daniel >=20 >=20 >=20 > PS: I also don't see a scenario where the "lock" is required From DanielC@orckit.com Mon Jul 25 12:19:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24011E8096 for ; Mon, 25 Jul 2011 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK+59h3PIa69 for ; Mon, 25 Jul 2011 12:19:31 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1921F8726 for ; Mon, 25 Jul 2011 12:19:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 22:19:25 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306E584B2@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Thread-Index: AcxK8oSkLo44K9pDSQm7KNh1oNi2QwABnB7gAAGacRA= References: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> From: "Daniel Cohn" To: "Eric Osborne (eosborne)" Cc: mpls@ietf.org Subject: Re: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:19:32 -0000 Eric, "Classic" PSC or APS, which is explicitly 1-phase, also has an implicit ACK when the far end reports which signal is being bridge to the protection path in the PSC/APS messages. And this doesn't make it two-phase. So I believe that your suggested behavior should be called 1-phase. I'm not suggesting we ignore unidirectional failures, as I believe the PSC mechanisms should work regardless of the underlying specific SF/SD detection mechanism. I'm just splitting hairs on terminology ;-) DC -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Monday, July 25, 2011 2:34 PM To: Daniel Cohn Cc: mpls@ietf.org Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Hi Daniel- That is indeed a good question. To me, it's two-phase in that there are two phases to the message (protection notification, and the ACK in reply). All we're doing with my proposed behavior is sending the traffic that we would have converged on anyways, without waiting unnecessarily. As I noted in my slides, we need this so that after all the dust settles, both ends of the protection domain can agree on what they're protecting. This is really only necessary in the case of an oddball unidirectional failure. =20 You could argue that all unidir failures should be caught by CC/Cv and that we should not have to worry about anything in PSC other than bidirectional failures. And if you did argue that I'd be in vehement agreement that it'd be nice to ignore unidir failures. But we can't, and so we need to be able to handle them in PSC, which makes several things trickier than they would be otherwise. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, July 25, 2011 1:45 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg question?) >=20 > Hi Eric, >=20 >=20 >=20 > Wrt the "Two-phase without lock" option which you presented today - if the > side detecting the failure does not wait for acknowledgment before > switching traffic to the protection path, in which sense is this still > "two phase"? >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Daniel >=20 >=20 >=20 > PS: I also don't see a scenario where the "lock" is required From vishwas.ietf@gmail.com Mon Jul 25 13:56:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF24511E80C2 for ; Mon, 25 Jul 2011 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvHRzKojFdSv for ; Mon, 25 Jul 2011 13:56:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1300311E80C0 for ; Mon, 25 Jul 2011 13:56:58 -0700 (PDT) Received: by vxi40 with SMTP id 40so4080441vxi.31 for ; Mon, 25 Jul 2011 13:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dot+YOCURLgoQ+OB9QcpQaimOehcFOQ38nbIYCbpQEQ=; b=YS1jPZLxgMYV1UEO3RHLbtRwQvJvr8uIGgwR5wzMeeoflF0dzObK+6SbGuw51/vrNG NzTVaDaOx6Id+Pde1PaDe0aGe10U6ib810im6Z+vGvYoQp/BaZK2PK85b3DIk6/5zg3A 6UyTSoatAwtQ0LqgozmVlZhItsI+MQt2IHcxk= MIME-Version: 1.0 Received: by 10.52.110.103 with SMTP id hz7mr4192123vdb.313.1311627418416; Mon, 25 Jul 2011 13:56:58 -0700 (PDT) Received: by 10.52.165.37 with HTTP; Mon, 25 Jul 2011 13:56:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jul 2011 13:56:58 -0700 Message-ID: From: Vishwas Manral To: "Shah, Himanshu" Content-Type: multipart/related; boundary=bcaec548a5d55a34fa04a8eb0ec6 Cc: "mpls@ietf.org" Subject: Re: [mpls] question on draft-fuxh-ccamp-delay-loss-te-framework-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:56:59 -0000 --bcaec548a5d55a34fa04a8eb0ec6 Content-Type: multipart/alternative; boundary=bcaec548a5d55a34f704a8eb0ec5 --bcaec548a5d55a34f704a8eb0ec5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Himanshu, Delay is generally bimodal, which means that its mails A or B, and does not randomly spread the entire spectrum. With that mentioned, the thing to note is that the values may change, and every change in value should not result in the LSP being rerouted (tere has to be a lot of damping and heuristics that will be involved for the same). BTW, here is a draft I put up which looks at details a bit more http://www.ietf.org/internet-drafts/draft-manral-mpls-service-00.txt Thanks, Vishwas On Mon, Jul 25, 2011 at 8:07 AM, Shah, Himanshu wrote: > Authors =96**** > > ** ** > > While this work is interesting, what is your opinion on **** > > transitivity of the Delay and Loss to be used as an attribute for RSVP-TE > LSP?**** > > In rapidly changing network, measured Delay and Loss snapshot value coul= d > very well have changed before**** > > LSP has completed the establishment. Is that a concern?**** > > ** ** > > Thanks,**** > > himanshu **** > > [image: ciena logo] > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec548a5d55a34f704a8eb0ec5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Himanshu,
=A0
Delay is generally bimodal, which means that its mails=A0A or B, and d= oes not randomly spread the entire spectrum. With that mentioned, the thing= to note is that the values may change, and every change in value should no= t result in the LSP being rerouted (tere has to be a lot of damping and heu= ristics that will be involved for the same).
=A0
=A0
BTW, here is a draft I put up which looks at details a bit more
Thanks,
Vishwas
On Mon, Jul 25, 2011 at 8:07 AM, Shah, Himanshu = <= hshah@ciena.com> wrote:

Authors =96

=A0

While this work is interesting, what is your opinion= on

transitivity of the Delay and Loss to be used as an = attribute for RSVP-TE LSP?

In rapidly changing network, measured Delay and Loss= =A0snapshot value could very well have changed before

LSP has completed the establishment. Is that a conce= rn?

=A0

Thanks,

himanshu


3D"cie=


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


--bcaec548a5d55a34f704a8eb0ec5-- --bcaec548a5d55a34fa04a8eb0ec6 Content-Type: image/gif; name="image904aa2.gif@8c026e44.eb7940be" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 322afdcb7e67909a_0.0.1 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --bcaec548a5d55a34fa04a8eb0ec6-- From internet-drafts@ietf.org Mon Jul 25 17:46:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8321F87C9; Mon, 25 Jul 2011 17:46:55 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPImxrML2ekQ; Mon, 25 Jul 2011 17:46:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32E221F8794; Mon, 25 Jul 2011 17:46:54 -0700 (PDT) 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.56 Message-ID: <20110726004654.17166.34803.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 17:46:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-recurs-fec-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 00:46:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Using Multipoint LDP when the Backbone has no Route to t= he Root Author(s) : IJsbrand Wijnands Eric C. Rosen Maria Napierala Nicolai Leymann Filename : draft-ietf-mpls-mldp-recurs-fec-04.txt Pages : 12 Date : 2011-07-25 The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") cont= ains a field that identifies the address of a "root node". Intermedi= ate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-recurs-fec-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-mldp-recurs-fec-04.txt From internet-drafts@ietf.org Tue Jul 26 05:13:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B5121F8C52; Tue, 26 Jul 2011 05:13:58 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9WE9qHxf7ZR; Tue, 26 Jul 2011 05:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3C21F8C3B; Tue, 26 Jul 2011 05:13:57 -0700 (PDT) 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.56 Message-ID: <20110726121357.20350.77645.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2011 05:13:57 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:13:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-00.txt Pages : 13 Date : 2011-07-26 This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-00= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-00.= txt From eosborne@cisco.com Tue Jul 26 07:31:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31F21F8B68 for ; Tue, 26 Jul 2011 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8rqgViaKU-4 for ; Tue, 26 Jul 2011 07:31:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4869321F889F for ; Tue, 26 Jul 2011 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=3356; q=dns/txt; s=iport; t=1311690661; x=1312900261; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zXWajg8CgeTCDuVYis6Ei7LM3jxau1gdd30ZOA5REz8=; b=Xz83Rub/E5XvK4TLQZbvGJrOHbd40+7PRV+UPEw4DrCCdsEQxAmhmfQp eV0TCjReKC2GykSh7MXdpOw0v6Q9Qj0O23KsmgXLSozrUTDlWxs5PtSIb 7yjoEf5tUaHFIad7PoC03MivcWYjlPmU8mpPLT0eGT3wgO4hAAKNQqnPJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAP3OLk6tJV2a/2dsb2JhbAA2AQEBAQMUASEKRQwFAgEJEQQBAQsGIwEGARM7DggBAQUXDBuXXI9ad6wDnmKFYV8Eh1eQK4tu X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6502934" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 14:31:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QEV0KA029797; Tue, 26 Jul 2011 14:31:00 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 09:31:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 09:30:59 -0500 Message-ID: In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306E584B2@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Thread-Index: AcxK8oSkLo44K9pDSQm7KNh1oNi2QwABnB7gAAGacRAAKDR5oA== References: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306E584B2@tlvmail1> From: "Eric Osborne (eosborne)" To: "Daniel Cohn" X-OriginalArrivalTime: 26 Jul 2011 14:31:00.0745 (UTC) FILETIME=[A4221790:01CC4BA0] Cc: mpls@ietf.org Subject: Re: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:31:02 -0000 Hi Daniel- 1:1 PSC is 1-phase, no argument there. I'm not sure I follow your point that APS is also explicitly 1-phase. I'm looking at GR-253 issue 5. Table 5-8 lists what I'd call a two-phase procedure: - C detects failure, requests bridge - A bridges, sends reverse request - C selects and bridges True, it's not exactly the same as PSC, but the idea as I read it is that C needs an ACK (RR) from A in order to complete the protection. If that's one-phase then yeah, I think our terminologies are at odds with each other. Right? eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, July 25, 2011 3:19 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) >=20 > Eric, >=20 > "Classic" PSC or APS, which is explicitly 1-phase, also has an implicit > ACK when the far end reports which signal is being bridge to the > protection path in the PSC/APS messages. And this doesn't make it two- > phase. So I believe that your suggested behavior should be called 1-phase. > I'm not suggesting we ignore unidirectional failures, as I believe the PSC > mechanisms should work regardless of the underlying specific SF/SD > detection mechanism. I'm just splitting hairs on terminology ;-) >=20 > DC >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Monday, July 25, 2011 2:34 PM > To: Daniel Cohn > Cc: mpls@ietf.org > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) >=20 > Hi Daniel- >=20 > That is indeed a good question. To me, it's two-phase in that there are > two phases to the message (protection notification, and the ACK in reply). > All we're doing with my proposed behavior is sending the traffic that we > would have converged on anyways, without waiting unnecessarily. >=20 > As I noted in my slides, we need this so that after all the dust > settles, both ends of the protection domain can agree on what they're > protecting. This is really only necessary in the case of an oddball > unidirectional failure. >=20 > You could argue that all unidir failures should be caught by CC/Cv and > that we should not have to worry about anything in PSC other than > bidirectional failures. And if you did argue that I'd be in vehement > agreement that it'd be nice to ignore unidir failures. But we can't, and > so we need to be able to handle them in PSC, which makes several things > trickier than they would be otherwise. >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, July 25, 2011 1:45 PM > > To: Eric Osborne (eosborne) > > Cc: mpls@ietf.org > > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) > > > > Hi Eric, > > > > > > > > Wrt the "Two-phase without lock" option which you presented today - if > the > > side detecting the failure does not wait for acknowledgment before > > switching traffic to the protection path, in which sense is this still > > "two phase"? > > > > > > > > Regards, > > > > > > > > Daniel > > > > > > > > PS: I also don't see a scenario where the "lock" is required From DanielC@orckit.com Tue Jul 26 07:54:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA211E807E for ; Tue, 26 Jul 2011 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO2OUhdoelAH for ; Tue, 26 Jul 2011 07:54:09 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5238521F8AE9 for ; Tue, 26 Jul 2011 07:54:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 17:54:05 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED7FA8@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Thread-Index: AcxK8oSkLo44K9pDSQm7KNh1oNi2QwABnB7gAAGacRAAKDR5oAAAyxaA References: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306E584B2@tlvmail1> From: "Daniel Cohn" To: "Eric Osborne (eosborne)" Cc: mpls@ietf.org Subject: Re: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:54:10 -0000 Right, GR-253 APS is 2-phase. G.8031 APS for example is 1-phase. Regardless of examples, my point is that if you bridge the signal to the protection path before waiting for the ACK, then this is a 1-phase protocol, despite the ACK being eventually received. DC -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Tuesday, July 26, 2011 10:31 AM To: Daniel Cohn Cc: mpls@ietf.org Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg question?) Hi Daniel- 1:1 PSC is 1-phase, no argument there. I'm not sure I follow your point that APS is also explicitly 1-phase. I'm looking at GR-253 issue 5. Table 5-8 lists what I'd call a two-phase procedure: - C detects failure, requests bridge - A bridges, sends reverse request - C selects and bridges True, it's not exactly the same as PSC, but the idea as I read it is that C needs an ACK (RR) from A in order to complete the protection. If that's one-phase then yeah, I think our terminologies are at odds with each other. Right? eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, July 25, 2011 3:19 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) >=20 > Eric, >=20 > "Classic" PSC or APS, which is explicitly 1-phase, also has an implicit > ACK when the far end reports which signal is being bridge to the > protection path in the PSC/APS messages. And this doesn't make it two- > phase. So I believe that your suggested behavior should be called 1-phase. > I'm not suggesting we ignore unidirectional failures, as I believe the PSC > mechanisms should work regardless of the underlying specific SF/SD > detection mechanism. I'm just splitting hairs on terminology ;-) >=20 > DC >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Monday, July 25, 2011 2:34 PM > To: Daniel Cohn > Cc: mpls@ietf.org > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) >=20 > Hi Daniel- >=20 > That is indeed a good question. To me, it's two-phase in that there are > two phases to the message (protection notification, and the ACK in reply). > All we're doing with my proposed behavior is sending the traffic that we > would have converged on anyways, without waiting unnecessarily. >=20 > As I noted in my slides, we need this so that after all the dust > settles, both ends of the protection domain can agree on what they're > protecting. This is really only necessary in the case of an oddball > unidirectional failure. >=20 > You could argue that all unidir failures should be caught by CC/Cv and > that we should not have to worry about anything in PSC other than > bidirectional failures. And if you did argue that I'd be in vehement > agreement that it'd be nice to ignore unidir failures. But we can't, and > so we need to be able to handle them in PSC, which makes several things > trickier than they would be otherwise. >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, July 25, 2011 1:45 PM > > To: Eric Osborne (eosborne) > > Cc: mpls@ietf.org > > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) > > > > Hi Eric, > > > > > > > > Wrt the "Two-phase without lock" option which you presented today - if > the > > side detecting the failure does not wait for acknowledgment before > > switching traffic to the protection path, in which sense is this still > > "two phase"? > > > > > > > > Regards, > > > > > > > > Daniel > > > > > > > > PS: I also don't see a scenario where the "lock" is required From iesg-secretary@ietf.org Tue Jul 26 07:55:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5990E11E80FC; Tue, 26 Jul 2011 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPR-E2BAaqxj; Tue, 26 Jul 2011 07:55:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541AF11E80ED; Tue, 26 Jul 2011 07:55:04 -0700 (PDT) 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.56 Message-ID: <20110726145504.13834.33560.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2011 07:55:04 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS-TP Identifiers' to Proposed Standard (draft-ietf-mpls-tp-identifiers-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:55:05 -0000 The IESG has approved the following document: - 'MPLS-TP Identifiers' (draft-ietf-mpls-tp-identifiers-07.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/ Technical Summary This document specifies identifiers for MPLS-TP objects. Included are identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. The identifiers apply to the ends of Label Switched Paths (LSPs) and the ends of Pseudowires. They also apply to the identifiable objects within Operations, Administration, and Maintenance (OAM) Maintenance Entities. Working Group Summary This document defines a format for MPLS-TP LSP Identifiers based on global node IDs (ie, IP addresses). A previous version of this draft included MPLS-TP identifiers based on ICCs (ITU Carrier Codes). However, late in the process, technical problems with the global uniqueness of the ICC format were discovered. Due to the anticipated delay in getting these issues resolved, the ICC based identifiers have been removed from the document. It is anticipated that a further document handling ICC based identifiers will be developed once the issues have been resolved by the ITU-T. There was a request from a few people to allow use of a global node ID for one end of an LSP and an ICC based ID for the other end of the same LSP. After extensive discussion on the MPLS WG email list, there was a clear consensus to progress the document without support for mixed use. Clearly this could not be done in any case until the issues with the ICC based identifier have been resolved. Future work on "mixed mode" identifiers was not ruled out. Other than these issues there was little controversy, and the document is needed for important ongoing work on MPLS-TP. Document Quality The document has been extensively reviewed and is an important basis for ongoing work on MPLS-TP. Many of the identifiers using standard IETF addressing fields are already implemented by default in MPLS and pseudowire systems. A number of vendors are building MPLS-TP solutions and will include identifier formats described in this document. Personnel Ross Callon (rcallon@juniper.net) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From eric.gray@ericsson.com Tue Jul 26 08:55:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E636311E80A3 for ; Tue, 26 Jul 2011 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66zgX3kaQ79e for ; Tue, 26 Jul 2011 08:55:51 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DE74B11E808E for ; Tue, 26 Jul 2011 08:55:50 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6QFtj4s003739; Tue, 26 Jul 2011 10:55:47 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 26 Jul 2011 11:55:41 -0400 From: Eric Gray To: Zhenlong Cui Date: Tue, 26 Jul 2011 11:55:39 -0400 Thread-Topic: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZCAF28eAIAWWg2g Message-ID: References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:55:52 -0000 Zhenlong, Q-1: See RFC 4379, where these regitry entries are derived from. RFC 4379 sets up a number of registries - including the TLV registry - and defines explicitly how to handle unknown TLV types in section 3, in two very obscure paragraphs on page 10, just before section 3.1.=20 Q-2: "ingress port" is not correct - thanks for spotting this=20 cut-and-paste duplication error. -- Eric -----Original Message----- From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com]=20 Sent: Tuesday, July 12, 2011 5:20 AM To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Dear Authors, Two questions regarding the idenfifiers TLV and DSMAP TLV. Question 1: > > > Which return code to send when identifiers are wrong (Malformed echo > > > request received?) or drop the packet. > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > EG > screaming into the night. What does one do when one gets > > > EG > something either not recognizably intended for one, or not > > > EG > from a source that one recognizes? From a security point > > > EG > of view, we cannot require an implementation to reply to > > > EG > the requester in this case (this is an attack vector for > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > If the "type" of identifier TLV is incorrect, then should this request fram= e be dropped? Should we reply to the requestor(One or more of the TLVs was not understood)? Can this way two answers be generated= ? Question 2: In section 2.1.1, Is below("ingress port") correct? Egress IF_Num identifies the ingress port on the target node. A value of 0 indicates that the port is not part of the identifier. Best, zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of R= olf Winter > Sent: Monday, June 27, 2011 8:04 PM > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.= org > Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv >=20 > I think that's OK, since the value is not beyond but within the TLV. Take= n from 4379: >=20 > Types are defined below; Length is the length of the Value field in > octets. The Value field depends on the Type; it is zero padded to > align to a 4-octet boundary. >=20 > That means the length is the length of the actual value (excluding the pa= dding). So the beginning of the next TLV is determined > by the length plus a value that makes it align on a 4-octet boundary (whi= ch of course can be 0). I cannot follow your argument > why this is not correct. I am sure I am missing something trivial, so sor= ry for spamming the list. But all information is > encoded in the packet (plus the simple rule quoted above). Otherwise, a n= ode needs to understand the internal structure of > each TLV to extract the value instead of applying the simple rule above. >=20 >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Montag, 27. Juni 2011 12:42 > > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > cv@tools.ietf.org > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > > > IMO, that would be a problem with RFC 4379. Perhaps there is > > an errata? > > > > TLVs are meant to follow each other, where the beginning of the > > next TLV is determined by the length of the current TLV - hence > > it is not correct to specify any content as having any value at > > all if it is beyond the end of the TLV. > > > > -----Original Message----- > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > Sent: Monday, June 27, 2011 5:06 AM > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > cv@tools.ietf.org > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > Importance: High > > > > Hi Eric, > > > > just one more to follow up. You say: > > > > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > EG > even if the last two octets "Must be Zero"). The length of > > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > EG > longer by the addition of the 2-word AGI. Nice catch! > > > > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > included in the length of the sub-TLVs. Why are they included here? > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > EG > Apparently. > > > > > > Which return code to send when identifiers are wrong (Malformed echo > > > request received?) or drop the packet. > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > EG > screaming into the night. What does one do when one gets > > > EG > something either not recognizably intended for one, or not > > > EG > from a source that one recognizes? From a security point > > > EG > of view, we cannot require an implementation to reply to > > > EG > the requester in this case (this is an attack vector for > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > > Using the per-interface model and say the DSMAP TLV did not match the > > > ingress IF identifier, then should this request frame be dropped? > > > Should we reply to the requestor? Can this way two answers be > > > generated? > > > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > > > EG > Thanks. > > > > > > > > > Best, > > > > > > > > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > Of > > > > Loa Andersson > > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > > Ross > > > > Callon; George Swallow; MPLS-TP ad hoc team > > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > cv > > > > > > > > Working Group. > > > > > > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > > > after wg last call and published version -04 of the document. > > > > > > > > A document detailing how the comments have been addressed will be > > > > found at: > > > > http://www.pi.nu/~loa/comments-on-03.xls > > > > > > > > This is to start a working group call to verify that all comments > > > > been adequately addressed. Please send your comments to the > > > > mpls working group mailing list before June 24th. > > > > > > > > Loa > > > > on behalf of the MPLS wg co-chairs > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From DanielC@orckit.com Tue Jul 26 10:55:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B905E8002 for ; Tue, 26 Jul 2011 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0G2cNE68lKu for ; Tue, 26 Jul 2011 10:55:27 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE2321F87C7 for ; Tue, 26 Jul 2011 10:55:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BBD.6F319F7C" Date: Tue, 26 Jul 2011 20:55:19 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxLvS75Zfu9lTb8QDyzg3B9ZzuI9g== From: "Daniel Cohn" To: Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:55:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4BBD.6F319F7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly stated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data link). =20 See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack"=20 "An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent..." =20 However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.=20 =20 If my understanding is correct, the section OAM requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.=20 =20 Comments? =20 Regards, =20 Daniel =20 =20 ------_=_NextPart_001_01CC4BBD.6F319F7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In several = places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and = sometimes explicitly stated that an MPLS-TP section is equivalent to a = non-MPLS-TP link (aka data link).

 

See for = example (there’s more):

“MPLS-TP Section: As defined in [8], it is a = link that can be  traversed by one or more MPLS-TP = LSPs.”

“in case of an = MPLS-TP section, the MEG is inferred from the port on which an OAM = packet was received with the GAL at the top of the label stack” =

“An SMEG is intended to be = deployed for applications where it is preferable to monitor the link = between topologically adjacent…”

 

However, as = per RFC 5654 and especially RFC5960 (http://tools.ietf= .org/html/rfc5960#section-3.2), an MPLS-TP section can also be an = LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a = PW.

 

If my understanding is correct, the section OAM = requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant = for data-link sections (n=3D0 following RFC 5960 terminology). In this = case, this should be clarified in the draft.

 

Comments?

 

Regards,

 

Daniel

 

 

------_=_NextPart_001_01CC4BBD.6F319F7C-- From david.i.allan@ericsson.com Tue Jul 26 12:53:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C048F11E809B for ; Tue, 26 Jul 2011 12:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiP98BT-fPCs for ; Tue, 26 Jul 2011 12:53:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CD1BB11E8088 for ; Tue, 26 Jul 2011 12:53:01 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6QJqrhw022569; Tue, 26 Jul 2011 14:53:01 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 26 Jul 2011 15:52:51 -0400 From: David Allan I To: Daniel Cohn , "mpls@ietf.org" Date: Tue, 26 Jul 2011 15:52:50 -0400 Thread-Topic: draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxLvS75Zfu9lTb8QDyzg3B9ZzuI9gADoBUA Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> 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_60C093A41B5E45409A19D42CF7786DFD52215D4FACEUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 19:53:04 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D4FACEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Daniel: We have a bit of an inconsistency creeping in in numerous places.... By the definition of a section as any (sub) layer "minus one" path componen= t, then a section can be a physical link for an SPME or LSP, an SPME for a = LSP, an LSP for a PW etc. So to invent terms to facilitate this discussion we have a physical section= (non-MPLS link) and a logical section (some MPLS path construct) Which means we have established procedures for configuring OAM for any logi= cal section, but as Greg Mirsky noted today, not for a physical section, at= least not ones we'd necessarily want to use. We have MEP identifiers speci= fic to a physical section in the identifiers draft what we would not use fo= r logical sections as we really do not need multiple identities for mainten= ance entity components. I'm sure we have a few other places where this smal= l dichotomy raises its head. Nor do we want to confuse physical sections with logical sections.... Hence if we are to resolve some of this without revisiting established RFCs= we need to introduce some distinction to further define section "types" al= ong the lines I've suggested above (physcial and logical)... and apply it a= cross the current document set. WDYT? Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dan= iel Cohn Sent: Tuesday, July 26, 2011 1:55 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section= definitions? Hi, In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and= sometimes explicitly stated that an MPLS-TP section is equivalent to a non= -MPLS-TP link (aka data link). See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by= one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which = an OAM packet was received with the GAL at the top of the label stack" "An SMEG is intended to be deployed for applications where it is preferable= to monitor the link between topologically adjacent..." However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html= /rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying anoth= er LSP (SPME or generic H-LSP), or an LSP carrying a PW. If my understanding is correct, the section OAM requirements in draft-ietf-= mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 fo= llowing RFC 5960 terminology). In this case, this should be clarified in th= e draft. Comments? Regards, Daniel --_000_60C093A41B5E45409A19D42CF7786DFD52215D4FACEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI Daniel:
 
We have a bit of an inconsistency creeping in in nume= rous=20 places....
 
By the definition of a section as any (sub) laye= r "minus=20 one" path component, then a section can be a physical link for an SPME or L= SP,=20 an SPME for a LSP, an LSP for a PW etc.
 
So to invent terms to facilitate this discussion we h= ave a=20 physical section (non-MPLS link) and a logical section (some MPLS path=20 construct)
 
Which means we have established procedures for config= uring OAM=20 for any logical section, but as Greg Mirsky noted today, not for a physical= =20 section, at least not ones we'd necessarily want to use. We have MEP identi= fiers=20 specific to a physical section in the identifiers draft what we would not u= se=20 for logical sections as we really do not need multiple identities=20 for maintenance entity components. I'm sure we have a few other places= =20 where this small dichotomy raises its head.
 
Nor do we want to confuse physical sections with logi= cal=20 sections....
 
Hence if we are to resolve some of this without revis= iting=20 established RFCs we need to introduce some distinction to further define se= ction=20 "types" along the lines I've suggested above (physcial and logical)... and = apply=20 it across the current document set.
 
WDYT?
Dave
 
 

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn
Sent:<= /B>=20 Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject:=20 [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section=20 definitions?

Hi,

 

In several places in draft-ietf-mpls-tp-oam-framework-= 10, it=20 is assumed and sometimes explicitly stated that an MPLS-TP section is equiv= alent=20 to a non-MPLS-TP link (aka data link).

 

See for example (there’s more):

“MPLS-TP Section: As defined in [8], it is a lin= k that can=20 be  traversed by one or more MPLS-TP LSPs.”

“in case of an MPLS-TP section, the MEG is infer= red from the=20 port on which an OAM packet was received with the GAL at the top of the lab= el=20 stack”

“An SMEG is intended to be deployed for applicat= ions where it=20 is preferable to monitor the link between topologically=20 adjacent…”

 

However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.o= rg/html/rfc5960#section-3.2),=20 an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic= =20 H-LSP), or an LSP carrying a PW.

 

If my understanding is correct, the section OAM requir= ements=20 in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sect= ions=20 (n=3D0 following RFC 5960 terminology). In this case, this should be clarif= ied in=20 the draft.

 

Comments?

 

Regards,

 

Daniel

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D4FACEUSAACMS0703e_-- From fu.xihua@zte.com.cn Tue Jul 26 13:18:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C221621F863A for ; Tue, 26 Jul 2011 13:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLPg2iGiipy8 for ; Tue, 26 Jul 2011 13:18:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB4821F85DE for ; Tue, 26 Jul 2011 13:18:16 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 4864806486374; Wed, 27 Jul 2011 04:16:12 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1202975933; Wed, 27 Jul 2011 04:18:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6QKI4nX024228; Wed, 27 Jul 2011 04:18:04 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: To: "Shah, Himanshu" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Wed, 27 Jul 2011 04:18:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-27 04:18:04, Serialize complete at 2011-07-27 04:18:04 Content-Type: multipart/related; boundary="=_related 006F84B9482578D9_=" X-MAIL: mse01.zte.com.cn p6QKI4nX024228 Cc: "mpls@ietf.org" Subject: Re: [mpls] question on draft-fuxh-mpls-delay-loss-te-framework-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:18:18 -0000 This is a multipart message in MIME format. --=_related 006F84B9482578D9_= Content-Type: multipart/alternative; boundary="=_alternative 006F84B9482578D9_=" --=_alternative 006F84B9482578D9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSGltYW5zaHUsDQoNCk9uZSBvZiBhdXRob3JzIGhlcmUuIFRoYW5rIHlvdSBmb3IgeW91ciBj b21tZW50cy4NCkkgY2hhbmdlIHRoZSBlbWFpbCB0aXRsZSB3aXRoICJNUExTIiBiZWNhdXNlIEkg aGF2ZSB1cGxvYWRlZCB0aGUgZHJhZnQgdG8gDQpNUExTIFdHLiBUaGVycyBpcyBubyBhbnkgY2hh bmdlIG9mIHRoZSBjb250ZW50Lg0KV2hlbiB5b3UgbWVudGlvbiB1c2luZyBkZWxheSBhbmQgbG9z cyBhcyBhbiBhdHRyaWJ1dGUgZm9yIFJTVlAtVEUgTFNQLCANCnN1cHBvc2UgSSB1bmRlcnN0YW5k IHdoYXQgeW91IGFyZSBzYXlpbmcuDQpUaGVyZSBhcmUgc29tZSByZXF1aXJlbWVudCByZWxhdGVk IHRvIFJTVlAtVEUuDQoxLiBEZWxheSBBY2N1bXVsYXRpb24gYW5kIFZlcmlmaWNhdGlvbg0KZS5n LiwgU29tZSBBUyBtYXkgbm90IHN1cHBvcnQgY29tbXVuaWNhdGlvbiBkZWxheSBhbmQgbG9zcyBp biBJR1Agb3IgUENFIA0KYXJjaGl0ZWN0dXJlIGlzbid0IGFwcGxpZWQuDQp8LS0tLS0tLS1BUzEt LS0tLS0tfCAgICAgICAgICAgICAgfC0tLS0tLS1BUzItLS0tLS0tfA0KMC0tLS0tLS0tLTAtLS0t LS0tLS0wLS0tLS0tLS0tMC0tLS0tLS0tLTAtLS0tLS0tLTANCkEgICAgICAgICAgICAgIEIgICAg ICAgICAgICAgICBDICAgICAgICAgICAgICBEICAgICAgICAgICAgICAgRSAgIEYNClRoZSBpZGVh IGlzIHRvIGFjY3VtdWxhdGUgdGhlIGRlbGF5IHBlcmZvcm1hbmNlIGFsb25nIHRoZSANCm11bHRp LWRvbWFpbi9tdWx0aS1sYXllciBwYXRoIGluIFJTVlAtVEUuDQpJIHRoaW5rIHRoaXMgcmVxdWly ZW1lbnQgaXMgcmVsYXRlZCB0byB5b3VyIHF1ZXN0aW9uLg0KVGhlIGRlbGF5IHBlcmZvcm1hbmNl IGFjY3VtdWxhdGVkIHNob3VsZCBiZSBhIGF2ZXJhZ2UgdmFsdWUuDQpTdXBwb3NlIENQIHNpZ25h bCBlMmUgTFNQIGFjcm9zcyBtdWx0aS1kb21haW4sIGFjY3VtdWxhdGUgZGVsYXkgDQpwZXJmb3Jt YW5jZSBhbmQgdmVyaWZ5IGl0IG1lZXQgU0xBLg0KWW91IG1heSBtZW50aW9uIGFmdGVyIHRoZSBj cmVhdGlvbiwgZGVsYXkgb2Ygc29tZSBzZWdtZW50IHJvdXRpbmcgbWF5IA0KY2hhbmdlIChlLmcu LCBkZWxheSBpbmNyZWFzZSApLg0KSWYgdGhlIGRlbGF5IG9mIG9uZSBzZWdtZW50IChlLmcuLCBi ZXR3ZWVuIEQgYW5kIEYpIGRvZXNuJ3QgZXhjZWVkIHRoZSANCnRocmVzaG9sZCwgaW5ncmVzcyBk b2Vzbid0IG5lZWQgdG8gY2FyZSBhYm91dCBpdC4NCklmIGl0IGV4Y2VlZCB0aGUgdGhyZXNob2xk LCBEIG1heSBub3RpZnkgaXQgdG8gaW5ncmVzcyBBLiBTbyBBIG1heSByZWZyZXNoIA0KKGUuZy4s IGFjY3VtdWxhdGUgaXQgYWdhaW4pIHRoZSBlMmUgZGVsYXkgYnkgdXNpbmcgcGF0aCBtZXNzYWdl Lg0KV2UgbWF5IGZvY3VzIG9uIHJlcXVpcmVtZW50IGZpcnN0bHkuIFRoZSBzb2x1dGlvbiBzaG91 bGQgYmUgbmV4dCBzdGVwLiANCg0KMi4gQ29udmV5aW5nIERlbGF5IGFuZCBMb3NzIGluIFJTVlAt VEUuDQplLmcuLCBUaGVyZSBpcyBhIENvbXBvc2l0ZSBMaW5rIGJldHdlZW4gQiBhbmQgQyBpbmNs dWRpbmcgdGhyZWUgY29tcG9uZW50IA0KbGlua3MgKGkuZS4sICMxLCAjMiBhbmQgIzMpDQpBICAg ICAgICAgIEIgICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAgICBEDQpvLS0tLS0tbyAgICAg ICAgICAgICAgICAgICAgICBvLS0tLS0tbw0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAj MQ0KICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAjMg0KICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLSAjMw0KSW5ncmVzcyBub2RlIEEgc2hvdWxkIGluZm9ybSBub2RlIEIgaW4gc2lnbmFs aW5nIG1lc3NhZ2UgdGhlIGRlbGF5IGFuZCANCmxvc3MgY29uc3RyYWludCB0byBpbmRpY2F0ZSBo b3cgdG8gc2VsZWN0IGEgY29tcG9uZW50IGxpbmsuDQpTbyBJIHRoaW5rIHRoaXMgaXNuJ3QgcmVs YXRlZCB0byB5b3VyIHF1ZXN0aW9uLiANCg0KZS5nLiwgU3VwcG9zZSBhIExTUCBpcyBvdmVyIGEg SC1MU1AgKEItQy1ELUUpLiBUaGVyZSBtYXkgYmUgYSBkZWxheSBhbmQgDQpsb3NzIGNvbnN0cmFp bnQgZm9yIHRoZSBMU1Agc2VnbWVudCAoZS5nLCBiZXR3ZWVuIEIgYW5kIEUpLiANClNvIGluZ3Jl c3MgYWxzbyBtYXkgY29udmV5IGRlbGF5IGFuZCBsb3NzIGNvbnN0cmFpbnQgaW4gUlNWUC1URSB0 byBCLiBTbyBCIA0Kc2hvdWxkIHRyaWdnZXIgSC1MU1Agd2hpY2ggbXVzdCBtZWV0IHRoZSBjb25z dHJhaW50Lg0KQSAgICAgICAgICBCICAgICAgICAgICAgICAgICAgICAgIEUgICAgICAgICAgRg0K by0tLS0tLW8gICAgICAgICAgICAgICAgICAgICAgby0tLS0tLW8NCiAgICAgICAgICAgICAgXCAg ICAgICAgICAgICAgICAgICAgLw0KICAgICAgICAgICAgICAgIG8tLS0tLS0tLS1vDQogICAgICAg ICAgICAgICAgQyAgICAgICAgICAgICAgIEQNCkkgYWxzbyB0aGluayB0aGlzIGlzbid0IHJlbGF0 ZWQgdG8geW91ciBxdWVzdGlvbi4gDQoNClRoYW5rcywNCg0KWGlodWENCg0KDQoNCg0KIlNoYWgs IEhpbWFuc2h1IiA8aHNoYWhAY2llbmEuY29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRm Lm9yZw0KMjAxMS0wNy0yNSDPws7nIDExOjA3DQoNCsrVvP7Iyw0KIm1wbHNAaWV0Zi5vcmciIDxt cGxzQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbbXBsc10gcXVlc3Rpb24gIG9uIGRyYWZ0LWZ1 eGgtY2NhbXAtZGVsYXktbG9zcy10ZS1mcmFtZXdvcmstMDANCg0KDQoNCg0KDQoNCkF1dGhvcnMg qEMNCiANCldoaWxlIHRoaXMgd29yayBpcyBpbnRlcmVzdGluZywgd2hhdCBpcyB5b3VyIG9waW5p b24gb24gDQp0cmFuc2l0aXZpdHkgb2YgdGhlIERlbGF5IGFuZCBMb3NzIHRvIGJlIHVzZWQgYXMg YW4gYXR0cmlidXRlIGZvciBSU1ZQLVRFIA0KTFNQPw0KSW4gcmFwaWRseSBjaGFuZ2luZyBuZXR3 b3JrLCBtZWFzdXJlZCBEZWxheSBhbmQgTG9zcyAgc25hcHNob3QgdmFsdWUgY291bGQgDQp2ZXJ5 IHdlbGwgaGF2ZSBjaGFuZ2VkIGJlZm9yZQ0KTFNQIGhhcyBjb21wbGV0ZWQgdGhlIGVzdGFibGlz aG1lbnQuIElzIHRoYXQgYSBjb25jZXJuPw0KIA0KVGhhbmtzLA0KaGltYW5zaHUgDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg0KDQo= --=_alternative 006F84B9482578D9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkhpIEhpbWFuc2h1LDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+T25lIG9mIGF1dGhvcnMgaGVyZS4g VGhhbmsgeW91IGZvciB5b3VyDQpjb21tZW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPkkgY2hhbmdlIHRoZSBlbWFpbCB0aXRsZSB3aXRoICZxdW90O01QTFMmcXVv dDsNCmJlY2F1c2UgSSBoYXZlIHVwbG9hZGVkIHRoZSBkcmFmdCB0byBNUExTIFdHLiBUaGVycyBp cyBubyBhbnkgY2hhbmdlIG9mDQp0aGUgY29udGVudC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPldoZW4geW91IG1lbnRpb24gdXNpbmcgZGVsYXkgYW5kIGxvc3MgYXMN CmFuIGF0dHJpYnV0ZSBmb3IgUlNWUC1URSBMU1AsIHN1cHBvc2UgSSB1bmRlcnN0YW5kIHdoYXQg eW91IGFyZSBzYXlpbmcuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5U aGVyZSBhcmUgc29tZSByZXF1aXJlbWVudCByZWxhdGVkIHRvIFJTVlAtVEUuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4xLiBEZWxheSBBY2N1bXVsYXRpb24gYW5kIFZl cmlmaWNhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ZS5nLiwg U29tZSBBUyBtYXkgbm90IHN1cHBvcnQgY29tbXVuaWNhdGlvbg0KZGVsYXkgYW5kIGxvc3MgaW4g SUdQIG9yIFBDRSBhcmNoaXRlY3R1cmUgaXNuJ3QgYXBwbGllZC48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPnwtLS0tLS0tLUFTMS0tLS0tLS18ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLUFTMi0tLS0tLS18PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4wLS0tLS0tLS0tMC0tLS0tLS0t LTAtLS0tLS0tLS0wLS0tLS0tLS0tMC0tLS0tLS0tMDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+QSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7QiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IEUgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIGlkZWEgaXMgdG8gYWNjdW11bGF0ZSB0aGUg ZGVsYXkgcGVyZm9ybWFuY2UNCmFsb25nIHRoZSBtdWx0aS1kb21haW4vbXVsdGktbGF5ZXIgcGF0 aCBpbiBSU1ZQLVRFLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SSB0 aGluayB0aGlzIHJlcXVpcmVtZW50IGlzIHJlbGF0ZWQgdG8NCnlvdXIgcXVlc3Rpb24uPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUgZGVsYXkgcGVyZm9ybWFuY2Ug YWNjdW11bGF0ZWQgc2hvdWxkDQpiZSBhIGF2ZXJhZ2UgdmFsdWUuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TdXBwb3NlIENQIHNpZ25hbCBlMmUgTFNQIGFjcm9zcyBt dWx0aS1kb21haW4sDQphY2N1bXVsYXRlIGRlbGF5IHBlcmZvcm1hbmNlIGFuZCB2ZXJpZnkgaXQg bWVldCBTTEEuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Zb3UgbWF5 IG1lbnRpb24gYWZ0ZXIgdGhlIGNyZWF0aW9uLCBkZWxheQ0Kb2Ygc29tZSBzZWdtZW50IHJvdXRp bmcgbWF5IGNoYW5nZSAoZS5nLiwgZGVsYXkgaW5jcmVhc2UgKS48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPklmIHRoZSBkZWxheSBvZiBvbmUgc2VnbWVudCAoZS5nLiwg YmV0d2Vlbg0KRCBhbmQgRikgZG9lc24ndCBleGNlZWQgdGhlIHRocmVzaG9sZCwgaW5ncmVzcyBk b2Vzbid0IG5lZWQgdG8gY2FyZSBhYm91dA0KaXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5JZiBpdCBleGNlZWQgdGhlIHRocmVzaG9sZCwgRCBtYXkgbm90aWZ5DQpp dCB0byBpbmdyZXNzIEEuIFNvIEEgbWF5IHJlZnJlc2ggKGUuZy4sIGFjY3VtdWxhdGUgaXQgYWdh aW4pIHRoZSBlMmUgZGVsYXkNCmJ5IHVzaW5nIHBhdGggbWVzc2FnZS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPldlIG1heSBmb2N1cyBvbiByZXF1aXJlbWVudCBmaXJz dGx5LiBUaGUNCnNvbHV0aW9uIHNob3VsZCBiZSBuZXh0IHN0ZXAuIDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Mi4gQ29udmV5aW5nIERlbGF5IGFuZCBMb3Nz IGluIFJTVlAtVEUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5lLmcu LCBUaGVyZSBpcyBhIENvbXBvc2l0ZSBMaW5rIGJldHdlZW4NCkIgYW5kIEMgaW5jbHVkaW5nIHRo cmVlIGNvbXBvbmVudCBsaW5rcyAoaS5lLiwgIzEsICMyIGFuZCAjMyk8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0IgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7RDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+by0tLS0tLW8g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtvLS0tLS0tbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAtLS0tLS0tLS0tLS0tLSAjMTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAt LS0tLS0tLS0tLS0tLSAjMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAtLS0tLS0t LS0tLS0tLSAjMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SW5ncmVz cyBub2RlIEEgc2hvdWxkIGluZm9ybSBub2RlIEIgaW4NCnNpZ25hbGluZyBtZXNzYWdlIHRoZSBk ZWxheSBhbmQgbG9zcyBjb25zdHJhaW50IHRvIGluZGljYXRlIGhvdyB0byBzZWxlY3QNCmEgY29t cG9uZW50IGxpbmsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TbyBJ IHRoaW5rIHRoaXMgaXNuJ3QgcmVsYXRlZCB0byB5b3VyIHF1ZXN0aW9uLg0KPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5lLmcuLCBTdXBwb3NlIGEgTFNQIGlz IG92ZXIgYSBILUxTUCAoQi1DLUQtRSkuDQpUaGVyZSBtYXkgYmUgYSBkZWxheSBhbmQgbG9zcyBj b25zdHJhaW50IGZvciB0aGUgTFNQIHNlZ21lbnQgKGUuZywgYmV0d2Vlbg0KQiBhbmQgRSkuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U28gaW5ncmVzcyBhbHNvIG1h eSBjb252ZXkgZGVsYXkgYW5kIGxvc3MNCmNvbnN0cmFpbnQgaW4gUlNWUC1URSB0byBCLiBTbyBC IHNob3VsZCB0cmlnZ2VyIEgtTFNQIHdoaWNoIG11c3QgbWVldCB0aGUNCmNvbnN0cmFpbnQuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5BICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtCICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RQ0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0Y8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPm8tLS0tLS1vICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7by0tLS0tLW88L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgXCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7LzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgby0tLS0tLS0tLW88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7IEMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkkgYWxzbyB0 aGluayB0aGlzIGlzbid0IHJlbGF0ZWQgdG8geW91cg0KcXVlc3Rpb24uIDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+WGlodWE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7U2hhaCwgSGltYW5z aHUmcXVvdDsNCiZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYu b3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDctMjUg z8LO5yAxMTowNzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+W21wbHNdIHF1ZXN0aW9uICZuYnNwO29uIGRyYWZ0LWZ1eGgtY2NhbXAtZGVsYXktbG9zcy10 ZS1mcmFtZXdvcmstMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QXV0aG9ycyCoQzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5XaGlsZSB0aGlzIHdvcmsgaXMgaW50ZXJlc3RpbmcsIHdoYXQgaXMNCnlvdXIg b3BpbmlvbiBvbiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPnRyYW5z aXRpdml0eSBvZiB0aGUgRGVsYXkgYW5kIExvc3MgdG8gYmUNCnVzZWQgYXMgYW4gYXR0cmlidXRl IGZvciBSU1ZQLVRFIExTUD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PkluIHJhcGlkbHkgY2hhbmdpbmcgbmV0d29yaywgbWVhc3VyZWQgRGVsYXkNCmFuZCBMb3NzICZu YnNwO3NuYXBzaG90IHZhbHVlIGNvdWxkIHZlcnkgd2VsbCBoYXZlIGNoYW5nZWQgYmVmb3JlPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5MU1AgaGFzIGNvbXBsZXRlZCB0 aGUgZXN0YWJsaXNobWVudC4gSXMNCnRoYXQgYSBjb25jZXJuPzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5oaW1hbnNodSA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250PjxpbWcgc3Jj PWNpZDpfMV8wNzJCMkFCODA3MkIyNkI4MDA2Rjg0Qjk0ODI1NzhEOSBhbHQ9ImNpZW5hIGxvZ28i Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBsczxicj4NCjwvdHQ+PC9mb250Pg0KPHA+DQo= --=_alternative 006F84B9482578D9_=-- --=_related 006F84B9482578D9_= Content-Type: image/gif Content-ID: <_1_072B2AB8072B26B8006F84B9482578D9> Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --=_related 006F84B9482578D9_=-- From gregimirsky@gmail.com Tue Jul 26 13:33:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E562521F87C9 for ; Tue, 26 Jul 2011 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opEJYWd8iUqD for ; Tue, 26 Jul 2011 13:33:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C86E421F87C7 for ; Tue, 26 Jul 2011 13:33:41 -0700 (PDT) Received: by vxi40 with SMTP id 40so806236vxi.31 for ; Tue, 26 Jul 2011 13:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iCXgCajZxjiqxWWeqcDJWHzJ9fTNGjHNI+lYKvQTFJE=; b=B80LLq8JWqj+EkfWhoYnAQ75A35YM8QEOD5OlX9oDfId2mQfxBNP41W4MUPHuM0EMl JwC0zu2n8YZ9YuozV3pGsYMz+W123o5H+Oj/7bVeeXmsAscrBY0iUFIohyroBXwvoK/+ jvkt5oD0usjHdTBo8tznu7YYF9UK+IqjzYU/0= MIME-Version: 1.0 Received: by 10.52.172.244 with SMTP id bf20mr6037030vdc.292.1311712420191; Tue, 26 Jul 2011 13:33:40 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Tue, 26 Jul 2011 13:33:40 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 26 Jul 2011 13:33:40 -0700 Message-ID: From: Greg Mirsky To: David Allan I Content-Type: multipart/alternative; boundary=bcaec51ba217da5dc204a8fed87d Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:33:45 -0000 --bcaec51ba217da5dc204a8fed87d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dave, Daniel, and All, I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP). I think that making MEP ID of Logical Section identical to MEP ID of Server layer LSP MEP ID creates issues with properly executing PM OAM on Section layer and Server layer LSP. Regards, Greg On Tue, Jul 26, 2011 at 12:52 PM, David Allan I wrote: > ** > HI Daniel: > > We have a bit of an inconsistency creeping in in numerous places.... > > By the definition of a section as any (sub) layer "minus one" path > component, then a section can be a physical link for an SPME or LSP, an S= PME > for a LSP, an LSP for a PW etc. > > So to invent terms to facilitate this discussion we have a physical secti= on > (non-MPLS link) and a logical section (some MPLS path construct) > > Which means we have established procedures for configuring OAM for any > logical section, but as Greg Mirsky noted today, not for a physical secti= on, > at least not ones we'd necessarily want to use. We have MEP identifiers > specific to a physical section in the identifiers draft what we would not > use for logical sections as we really do not need multiple identities > for maintenance entity components. I'm sure we have a few other places wh= ere > this small dichotomy raises its head. > > Nor do we want to confuse physical sections with logical sections.... > > Hence if we are to resolve some of this without revisiting established RF= Cs > we need to introduce some distinction to further define section "types" > along the lines I've suggested above (physcial and logical)... and apply = it > across the current document set. > > WDYT? > Dave > > > > ------------------------------ > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Daniel Cohn > *Sent:* Tuesday, July 26, 2011 1:55 PM > *To:* mpls@ietf.org > *Subject:* [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions? > > Hi,**** > > ** ** > > In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed a= nd > sometimes explicitly stated that an MPLS-TP section is equivalent to a > non-MPLS-TP link (aka data link).**** > > ** ** > > See for example (there=92s more):**** > > =93MPLS-TP Section: As defined in [8], it is a link that can be traverse= d by > one or more MPLS-TP LSPs.=94**** > > =93in case of an MPLS-TP section, the MEG is inferred from the port on wh= ich > an OAM packet was received with the GAL at the top of the label stack=94 = *** > * > > =93An SMEG is intended to be deployed for applications where it is prefer= able > to monitor the link between topologically adjacent=85=94**** > > ** ** > > However, as per RFC 5654 and especially RFC5960 ( > http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can > also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP > carrying a PW. **** > > ** ** > > If my understanding is correct, the section OAM requirements in > draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link secti= ons > (n=3D0 following RFC 5960 terminology). In this case, this should be clar= ified > in the draft. **** > > ** ** > > Comments?**** > > ** ** > > Regards,**** > > ** ** > > Daniel**** > > ** ** > > ** ** > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec51ba217da5dc204a8fed87d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dave, Daniel, and All,
I'd like to start from Section MEP ID as defined in MPLS-TP ID=20 document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP).=A0 I think that making MEP ID of Logical Section=20 identical to MEP ID of Server layer LSP MEP ID creates issues with=20 properly executing PM OAM on Section layer and Server layer LSP.

Regards,
Greg

On Tue, Jul 26, 2011 at 12:52 PM, Da= vid Allan I <david.i.allan@ericsson.com> wrote:
HI Daniel:
=A0
We have a bit of an inconsistency creeping in in numerous=20 places....
=A0
By the definition of=A0a section as any (sub) layer "minu= s=20 one" path component, then a section can be a physical link for an SPME= or LSP,=20 an SPME for a LSP, an LSP for a PW=A0etc.
=A0
So to invent terms to facilitate this discussion we have a=20 physical section (non-MPLS link) and a logical section (some MPLS path=20 construct)
=A0
Which means we have established procedures for configuring OAM= =20 for any logical section, but as Greg Mirsky noted today, not for a physical= =20 section, at least not ones we'd necessarily want to use. We have MEP id= entifiers=20 specific to a physical section in the identifiers draft what we would not u= se=20 for logical sections as we really do not need multiple identities=20 for=A0maintenance entity components. I'm sure we have a few other place= s=20 where this small dichotomy raises its head.
=A0
Nor do we want to confuse physical sections with logical=20 sections....
=A0
Hence if we are to resolve some of this without revisiting=20 established RFCs we need to introduce some distinction to further define se= ction=20 "types" along the lines I've suggested above (physcial and lo= gical)... and apply=20 it across the current document set.
=A0
WDYT?
Dave
=A0
=A0

From: mpls-bounces@ietf.org=20 [mailto:mpls-bou= nces@ietf.org] On Behalf Of Daniel Cohn
Sent:=20 Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject:=20 [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section=20 definitions?

Hi,

=A0

In several places in draft-ietf-mpls-tp-oam-framewor= k-10, it=20 is assumed and sometimes explicitly stated that an MPLS-TP section is equiv= alent=20 to a non-MPLS-TP link (aka data link).

=A0

See for example (there=92s more):

=93MPLS-TP Section: As defined in [8], it is a link = that can=20 be=A0 traversed by one or more MPLS-TP LSPs.=94

=93in case of an MPLS-TP section, the MEG is inferre= d from the=20 port on which an OAM packet was received with the GAL at the top of the lab= el=20 stack=94

=93An SMEG is intended to be deployed for applicatio= ns where it=20 is preferable to monitor the link between topologically=20 adjacent=85=94

=A0

However, as per RFC 5654 and especially RFC5960 (h= ttp://tools.ietf.org/html/rfc5960#section-3.2),=20 an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic= =20 H-LSP), or an LSP carrying a PW.

=A0

If my understanding is correct, the section OAM requ= irements=20 in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sect= ions=20 (n=3D0 following RFC 5960 terminology). In this case, this should be clarif= ied in=20 the draft.

=A0

Comments?

=A0

Regards,

=A0

Daniel

=A0

=A0


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


--bcaec51ba217da5dc204a8fed87d-- From wim.henderickx@alcatel-lucent.com Tue Jul 26 13:48:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E131D11E80B7; Tue, 26 Jul 2011 13:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwhZxsJ8MKBD; Tue, 26 Jul 2011 13:48:11 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBEA11E80A1; Tue, 26 Jul 2011 13:48:06 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6QKm4KT008907 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Jul 2011 22:48:04 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 26 Jul 2011 22:48:04 +0200 From: "Henderickx, Wim (Wim)" To: "yshen@juniper.net" , Rahul Aggarwal Date: Tue, 26 Jul 2011 22:48:01 +0200 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL1U7fI2okDnOnToe4ryNlXmqCWg== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: [mpls] draft-shen-pwe3-endpoint-fast-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:48:12 -0000 Regarding the draft I have following remarks/questions/suggestions since we= had no discussion on the mike today. 1. Will this solution support revertive as well as non-revertive behavior a= fter failure recovery. How will it work? 2. Is the goal to make this solution applicable to MS-PW as well as dynamic= MS-PW FEC129. 3. In general we should add some applicability in the draft. In certain cas= es and depending on the applicability you could have un-optimized traffic f= lows. 5. We should discuss the RSVP procedures in this draft in the MPLS WG. Cheers, Wim From neil.2.harrison@bt.com Tue Jul 26 13:54:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A2521F8A56 for ; Tue, 26 Jul 2011 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhNfP75NzV1M for ; Tue, 26 Jul 2011 13:54:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0421F880C for ; Tue, 26 Jul 2011 13:54:17 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 21:54:15 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 26 Jul 2011 21:54:16 +0100 From: To: , Date: Tue, 26 Jul 2011 21:54:11 +0100 Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxL01WCAHuEjjUhRfSPv7SRFQWdrQAAPKNg Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCC@EMV62-UKRD.domain1.systemhost.net> References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCCEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:54:23 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCCEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg/Dave/Daniel, The fundamental problem here is that we simply don't have a proper BOS sect= ion layer in MPLS (any spin of). More generally, in all networking scenarios there MUST be two things presen= t: - a true TOS layer network that interfaces (via suitable adaptations)= with the suite of external message/file/stream applications out there - a true BOS layer network that modulates an EM wave on either metall= ic/radio/fibre media...else we can't sent information (from the ultimate al= ways-present TOS external message/file/stream applications noted above) ove= r geographic distance. So here we must have a binary<=3D>q'ary symbol lexi= con mapping (which itself is a client/server relationship BTW). MPLS in any guise is neither of these things...it sits between them. It is= for sure not a transport network, as this must be able to perform a true B= OS role. MPLS always requires a real transport network under that can perf= orm this role. So the whole discussion about an MPLS 'section layer' is somewhat moot/mean= ingless IMO. MPLS (any spin) simply has a lowest LSP level...below that co= me the real transport layer networks. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= g Mirsky Sent: 26 July 2011 21:34 To: David Allan I Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in sec= tion definitions? Hi Dave, Daniel, and All, I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I = think that there should not be distinction in Section MEP ID whether it is = Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP). = I think that making MEP ID of Logical Section identical to MEP ID of Serve= r layer LSP MEP ID creates issues with properly executing PM OAM on Section= layer and Server layer LSP. Regards, Greg On Tue, Jul 26, 2011 at 12:52 PM, David Allan I > wrote: HI Daniel: We have a bit of an inconsistency creeping in in numerous places.... By the definition of a section as any (sub) layer "minus one" path componen= t, then a section can be a physical link for an SPME or LSP, an SPME for a = LSP, an LSP for a PW etc. So to invent terms to facilitate this discussion we have a physical section= (non-MPLS link) and a logical section (some MPLS path construct) Which means we have established procedures for configuring OAM for any logi= cal section, but as Greg Mirsky noted today, not for a physical section, at= least not ones we'd necessarily want to use. We have MEP identifiers speci= fic to a physical section in the identifiers draft what we would not use fo= r logical sections as we really do not need multiple identities for mainten= ance entity components. I'm sure we have a few other places where this smal= l dichotomy raises its head. Nor do we want to confuse physical sections with logical sections.... Hence if we are to resolve some of this without revisiting established RFCs= we need to introduce some distinction to further define section "types" al= ong the lines I've suggested above (physcial and logical)... and apply it a= cross the current document set. WDYT? Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, July 26, 2011 1:55 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section= definitions? Hi, In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and= sometimes explicitly stated that an MPLS-TP section is equivalent to a non= -MPLS-TP link (aka data link). See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by= one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which = an OAM packet was received with the GAL at the top of the label stack" "An SMEG is intended to be deployed for applications where it is preferable= to monitor the link between topologically adjacent..." However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html= /rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying anoth= er LSP (SPME or generic H-LSP), or an LSP carrying a PW. If my understanding is correct, the section OAM requirements in draft-ietf-= mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 fo= llowing RFC 5960 terminology). In this case, this should be clarified in th= e draft. Comments? Regards, Daniel _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCCEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg/Dave/Daniel,

 

The fundamental problem here is that we simply don’t have a proper BOS se= ction layer in MPLS (any spin of).

 

More generally, in all networking scenarios there MUST be two things present:

-       a true TOS layer network that interfaces (via suitable adaptations) with the suite of external message/file/stream applications out there

-       a true BOS layer network that modulates an EM wave on either metallic/radio/f= ibre media...else we can’t sent information (from the ultimate always-pres= ent TOS external message/file/stream applications noted above) over geographic dist= ance.  So here we must have a binary<=3D>q’ary symbol lexicon mapping = (which itself is a client/server relationship BTW).

 

MPLS in any guise is neither of these things...it sits between them.  It is= for sure not a transport network, as this must be able to perform a true BOS role.&n= bsp; MPLS always requires a real transport network under that can perform this role.<= o:p>

 

So the whole discussion about an MPLS ‘section layer’ is somewhat = moot/meaningless IMO.  MPLS (any spin) simply has a lowest LSP level...below that come = the real transport layer networks.

 

regards, Neil

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

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: 26 July 2011 21:34
To: David Allan I
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency= in section definitions?

 

Hi Dave, Daniel, and Al= l,
I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP).  I think that making MEP ID of Logical Section identical to MEP = ID of Server layer LSP MEP ID creates issues with properly executing PM OAM on Section layer and Server layer LSP.

Regards,
Greg

On Tue, Jul 26, 2011 at 12:52 PM, David Allan I <david.i.allan@ericsson.com&g= t; wrote:

HI Daniel:

 

We have a bit of an inconsistency creeping in in numerous places....

 

By the definition of a section as any (sub) layer "mi= nus one" path component, then a section can be a physical link for an SPME= or LSP, an SPME for a LSP, an LSP for a PW etc.=

 

So to invent terms to facilitate this discussion we have a phys= ical section (non-MPLS link) and a logical section (some MPLS path construct)

 

Which means we have established procedures for configuring OAM = for any logical section, but as Greg Mirsky noted today, not for a physical section, at least not ones we'd necessarily want to use. We have MEP identifiers specific to a physical section in the identifiers draft what we would not use for logical sections as we really do not need multiple identi= ties for maintenance entity components. I'm sure we have a few other places where this small dichotomy raises its head.<= /o:p>

 

Nor do we want to confuse physical sections with logical sections....

 

Hence if we are to resolve some of this without revisiting established RFCs we need to introduce some distinction to further define section "types" along the lines I've suggested above (physcial an= d logical)... and apply it across the current document set.

 

WDYT?

Dave

 

 

 

From: = mpls-bounces@ietf.o= rg [mailto:mpls-bou= nces@ietf.org] On Behalf Of Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org=
Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

Hi,

 

In several places in draft-ietf-mpls-tp-oam-framework-10, it i= s assumed and sometimes explicitly stated that an MPLS-TP section is equivale= nt to a non-MPLS-TP link (aka data link).

 

See for example (there’s more):

“MPLS-TP Section: As defined in [8], it is a link that c= an be  traversed by one or more MPLS-TP LSPs.”

“in case of an MPLS-TP section, the MEG is inferred from= the port on which an OAM packet was received with the GAL at the top of the label stack= ”

“An SMEG is intended to be deployed for applications whe= re it is preferable to monitor the link between topologically adjacent…”=

 

However, as per RFC 5654 and especially RFC5960 (h= ttp://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.

 

If my understanding is correct, the section OAM requirements i= n draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link section= s (n=3D0 following RFC 5960 terminology). In this case, this should be clarif= ied in the draft.

 

Comments?

 

Regards,

 

Daniel

 

 


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

 

--_000_6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCCEMV62UKRDdoma_-- From ilya@nobulus.com Tue Jul 26 14:00:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2D121F880C for ; Tue, 26 Jul 2011 14:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59jlHv7Pxxlj for ; Tue, 26 Jul 2011 14:00:20 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 600AF5E800F for ; Tue, 26 Jul 2011 14:00:20 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 9DFB01746B for ; Tue, 26 Jul 2011 23:00:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RROCjN-tpi6E for ; Tue, 26 Jul 2011 23:00:15 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 9C5C51744E for ; Tue, 26 Jul 2011 23:00:15 +0200 (CEST) From: Ilya Varlashkin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 23:00:14 +0200 Message-Id: <73460629-CAAC-4C2E-9ECA-7FEC8570480A@nobulus.com> To: IETF MPLS Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mpls] terminology in draft-pkwok-pwe3-pw-communities X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:00:21 -0000 Hi, sooner or later most of control-plane information makes its way into = BGP. Some day somebody will want to carry PW communities in BGP. That's = going to be confusing as BGP already has community attribute. = Presentation at the PWE3 meeting mentioned "coloring". Couldn't then "PW = color" be adopted instead of "PW community"? /iLya From c-sai@bx.jp.nec.com Tue Jul 26 14:04:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223BB21F861E for ; Tue, 26 Jul 2011 14:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRRhb3bqijkR for ; Tue, 26 Jul 2011 14:04:35 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id B33AB11E8097 for ; Tue, 26 Jul 2011 14:04:34 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6QL4SRR028494; Wed, 27 Jul 2011 06:04:28 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6QL4Si04065; Wed, 27 Jul 2011 06:04:28 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6QL4R75021304; Wed, 27 Jul 2011 06:04:27 +0900 (JST) Received: from kaishu.jp.nec.com ([10.26.220.5] [10.26.220.5]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-51822; Wed, 27 Jul 2011 06:03:45 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTP; Wed, 27 Jul 2011 06:03:43 +0900 From: "Zhenlong Cui" To: "'Eric Gray'" References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> Date: Wed, 27 Jul 2011 06:03:43 +0900 Message-ID: <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZCAF28eAIAWWg2ggABTzkA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:04:36 -0000 Hi Eric, I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem with responding. On the other hand, you say that you should send a reply when the request includes an unknown TLV. I think if the responder receives a request it checks the type of the TLV before it checks the identifiers. So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does the responder have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it? Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. 1) Which return code to send when source/destination identifiers are wrong or drop the request. 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. Best, Zhenlong > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Wednesday, July 27, 2011 12:56 AM > To: Zhenlong Cui > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Zhenlong, > > Q-1: See RFC 4379, where these regitry entries are derived from. > RFC 4379 sets up a number of registries - including the TLV > registry - and defines explicitly how to handle unknown TLV > types in section 3, in two very obscure paragraphs on page > 10, just before section 3.1. > > Q-2: "ingress port" is not correct - thanks for spotting this > cut-and-paste duplication error. > > -- > Eric > > -----Original Message----- > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > Sent: Tuesday, July 12, 2011 5:20 AM > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Dear Authors, > > Two questions regarding the idenfifiers TLV and DSMAP TLV. > > Question 1: > > > > Which return code to send when identifiers are wrong (Malformed echo > > > > request received?) or drop the packet. > > > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > > EG > screaming into the night. What does one do when one gets > > > > EG > something either not recognizably intended for one, or not > > > > EG > from a source that one recognizes? From a security point > > > > EG > of view, we cannot require an implementation to reply to > > > > EG > the requester in this case (this is an attack vector for > > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One > or > more of the TLVs was not understood)? Can this way two answers be generated? > > > Question 2: > In section 2.1.1, Is below("ingress port") correct? > > Egress IF_Num identifies the ingress port on the target node. A > value of 0 indicates that the port is not part of the identifier. > > > Best, > zhenlong > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > > Sent: Monday, June 27, 2011 8:04 PM > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > > > I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > > > > Types are defined below; Length is the length of the Value field in > > octets. The Value field depends on the Type; it is zero padded to > > align to a 4-octet boundary. > > > > That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is determined > > by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your argument > > why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information > is > > encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure > of > > each TLV to extract the value instead of applying the simple rule above. > > > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > > Sent: Montag, 27. Juni 2011 12:42 > > > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > cv@tools.ietf.org > > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > cv > > > > > > IMO, that would be a problem with RFC 4379. Perhaps there is > > > an errata? > > > > > > TLVs are meant to follow each other, where the beginning of the > > > next TLV is determined by the length of the current TLV - hence > > > it is not correct to specify any content as having any value at > > > all if it is beyond the end of the TLV. > > > > > > -----Original Message----- > > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > > Sent: Monday, June 27, 2011 5:06 AM > > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > cv@tools.ietf.org > > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > cv > > > Importance: High > > > > > > Hi Eric, > > > > > > just one more to follow up. You say: > > > > > > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > > EG > even if the last two octets "Must be Zero"). The length of > > > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > > EG > longer by the addition of the 2-word AGI. Nice catch! > > > > > > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > > included in the length of the sub-TLVs. Why are they included here? > > > > > > Best, > > > > > > Rolf > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > EG > Apparently. > > > > > > > > Which return code to send when identifiers are wrong (Malformed echo > > > > request received?) or drop the packet. > > > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > > EG > screaming into the night. What does one do when one gets > > > > EG > something either not recognizably intended for one, or not > > > > EG > from a source that one recognizes? From a security point > > > > EG > of view, we cannot require an implementation to reply to > > > > EG > the requester in this case (this is an attack vector for > > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > > > > Using the per-interface model and say the DSMAP TLV did not match the > > > > ingress IF identifier, then should this request frame be dropped? > > > > Should we reply to the requestor? Can this way two answers be > > > > generated? > > > > > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > > > > > EG > Thanks. > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > Behalf > > > > Of > > > > > Loa Andersson > > > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > > > Ross > > > > > Callon; George Swallow; MPLS-TP ad hoc team > > > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > cv > > > > > > > > > > Working Group. > > > > > > > > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > > > > after wg last call and published version -04 of the document. > > > > > > > > > > A document detailing how the comments have been addressed will be > > > > > found at: > > > > > http://www.pi.nu/~loa/comments-on-03.xls > > > > > > > > > > This is to start a working group call to verify that all comments > > > > > been adequately addressed. Please send your comments to the > > > > > mpls working group mailing list before June 24th. > > > > > > > > > > Loa > > > > > on behalf of the MPLS wg co-chairs > > > > > > > > > > -- > > > > > > > > > > > > > > > Loa Andersson email: > > > > loa.andersson@ericsson.com > > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > > +46 767 72 92 13 > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From giles.heron@gmail.com Tue Jul 26 14:09:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE321F87AF for ; Tue, 26 Jul 2011 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgTmCoqGPT7s for ; Tue, 26 Jul 2011 14:09:15 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 373BC21F8797 for ; Tue, 26 Jul 2011 14:09:15 -0700 (PDT) Received: by yie30 with SMTP id 30so721576yie.31 for ; Tue, 26 Jul 2011 14:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=UtulXL4zl/LmT72H4f9dYGNQSWcx5QKzCG7k3IowjfY=; b=oIRVSahRbNXkLqBZPe5y6NtBsnsYoYhcLeZFZ+IPJWVbf9VNDf0w7BbvpaYBQPKAsv cgoqhw+g56BUMiDyFIzdXUZFTW+D1aGOeosj2WMF6S3vEDFcNdlqVzN97byf2+EjKG5A 0PLx5c+MFatpXCHwgfd3z9UyPPw8aOaIMbKOk= Received: by 10.142.194.9 with SMTP id r9mr3921616wff.183.1311714552787; Tue, 26 Jul 2011 14:09:12 -0700 (PDT) Received: from [10.21.127.101] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id v1sm873273pbg.31.2011.07.26.14.09.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 14:09:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 26 Jul 2011 22:10:59 +0100 From: Giles Heron To: , , Message-ID: Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxL01WCAHuEjjUhRfSPv7SRFQWdrQAAPKNgAAEPCaU= In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCC@EMV62-UKRD.domain1.systemhost.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:09:16 -0000 On 26/07/2011 21:54, "neil.2.harrison@bt.com" wrote: > Greg/Dave/Daniel, > > The fundamental problem here is that we simply don't have a proper BOS section > layer in MPLS (any spin of). Agreed. > More generally, in all networking scenarios there MUST be two things present: > - a true TOS layer network that interfaces (via suitable adaptations) > with the suite of external message/file/stream applications out there > - a true BOS layer network that modulates an EM wave on either > metallic/radio/fibre media...else we can't sent information (from the ultimate > always-present TOS external message/file/stream applications noted above) over > geographic distance. So here we must have a binary<=>q'ary symbol lexicon > mapping (which itself is a client/server relationship BTW). Agreed > MPLS in any guise is neither of these things...it sits between them. It is > for sure not a transport network, as this must be able to perform a true BOS > role. MPLS always requires a real transport network under that can perform > this role. Agreed. But the "real transport network" MPLS sits on may be (and typically is) just a link. It doesn't have to be a network (in the sense of being something with more than two nodes and with some form of switching capability). > So the whole discussion about an MPLS 'section layer' is somewhat > moot/meaningless IMO. MPLS (any spin) simply has a lowest LSP level...below > that come the real transport layer networks. Agreed. Giles > regards, Neil > This email contains BT information, which may be privileged or confidential. > It's meant only for the individual(s) or entity named above. If you're not the > intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me know > immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg > Mirsky > Sent: 26 July 2011 21:34 > To: David Allan I > Cc: mpls@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions? > > Hi Dave, Daniel, and All, > I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I > think that there should not be distinction in Section MEP ID whether it is > Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP). I > think that making MEP ID of Logical Section identical to MEP ID of Server > layer LSP MEP ID creates issues with properly executing PM OAM on Section > layer and Server layer LSP. > > Regards, > Greg > On Tue, Jul 26, 2011 at 12:52 PM, David Allan I > > wrote: > HI Daniel: > > We have a bit of an inconsistency creeping in in numerous places.... > > By the definition of a section as any (sub) layer "minus one" path component, > then a section can be a physical link for an SPME or LSP, an SPME for a LSP, > an LSP for a PW etc. > > So to invent terms to facilitate this discussion we have a physical section > (non-MPLS link) and a logical section (some MPLS path construct) > > Which means we have established procedures for configuring OAM for any logical > section, but as Greg Mirsky noted today, not for a physical section, at least > not ones we'd necessarily want to use. We have MEP identifiers specific to a > physical section in the identifiers draft what we would not use for logical > sections as we really do not need multiple identities for maintenance entity > components. I'm sure we have a few other places where this small dichotomy > raises its head. > > Nor do we want to confuse physical sections with logical sections.... > > Hence if we are to resolve some of this without revisiting established RFCs we > need to introduce some distinction to further define section "types" along the > lines I've suggested above (physcial and logical)... and apply it across the > current document set. > > WDYT? > Dave > > > > ________________________________ > From: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] On Behalf Of > Daniel Cohn > Sent: Tuesday, July 26, 2011 1:55 PM > To: mpls@ietf.org > Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section > definitions? > Hi, > > In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and > sometimes explicitly stated that an MPLS-TP section is equivalent to a > non-MPLS-TP link (aka data link). > > See for example (there's more): > "MPLS-TP Section: As defined in [8], it is a link that can be traversed by > one or more MPLS-TP LSPs." > "in case of an MPLS-TP section, the MEG is inferred from the port on which an > OAM packet was received with the GAL at the top of the label stack" > "An SMEG is intended to be deployed for applications where it is preferable to > monitor the link between topologically adjacent..." > > However, as per RFC 5654 and especially RFC5960 > (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also > be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a > PW. > > If my understanding is correct, the section OAM requirements in > draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections > (n=0 following RFC 5960 terminology). In this case, this should be clarified > in the draft. > > Comments? > > Regards, > > Daniel > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Tue Jul 26 14:27:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8811E80A7 for ; Tue, 26 Jul 2011 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFpy63h5vxtv for ; Tue, 26 Jul 2011 14:27:12 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BE7D821F8A66 for ; Tue, 26 Jul 2011 14:27:12 -0700 (PDT) Received: by pzk6 with SMTP id 6so1396619pzk.26 for ; Tue, 26 Jul 2011 14:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=juPJ3M13+d9Kph94VTtMwq4M+swCiqZgRvNuhehlhwg=; b=HMpgN7547KceZAk9gi2Y7v+E651wgW7LMomcn7hfZETKY2C2sIjCxY9BsoODo7Ck34 poybAJnYA/9uwvFc3Dfz4LwEanRTxDzhganMc8BoI2v74ibq01CUPpbWBj9sNjIx2atR 6ArPXsIpeBmziJPcjabBxIGWzN1+fAu3wto7k= Received: by 10.68.13.105 with SMTP id g9mr11407469pbc.135.1311715631408; Tue, 26 Jul 2011 14:27:11 -0700 (PDT) Received: from [130.129.23.104] (dhcp-1768.meeting.ietf.org [130.129.23.104]) by mx.google.com with ESMTPS id d1sm936616pbj.72.2011.07.26.14.27.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 14:27:10 -0700 (PDT) References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> In-Reply-To: <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com> X-Mailer: iPad Mail (8J2) From: Sam Aldrin Date: Tue, 26 Jul 2011 14:29:00 -0700 To: Zhenlong Cui Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:27:13 -0000 As Eric said in earlier email, these questions are more related to RFC4379 a= nd not just this draft. Having said that, please find responses inline. Sam Sent from my iPad On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: > Hi Eric, >=20 > I remember you said earlier that you should drop the packet from unknown s= ource nodes, because there is a security problem with > responding. > On the other hand, you say that you should send a reply when the request i= ncludes an unknown TLV. >=20 Unknown source is not same as receiving malformed Tlv or unsupported tlv. > I think if the responder receives a request it checks the type of the TLV b= efore it checks the identifiers. >=20 > So, my question is "if the responder receives a request from an unknown so= urce node that includes an unknown TLV, does the responder > have to reply to the unknown source node?". If yes, this has the security p= roblem you mentioned earlier, doesn't it? If received from unknown source, most vendors drop the packet. >=20 >=20 > Lastly, I suggest that add some mention to this draft regarding responder'= s behavior for new TLV. > 1) Which return code to send when source/destination identifiers are wrong= or drop the request. As said above, it should be dropped, if the source is unknown. > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TL= V are wrong or drop the request. Return code 5, dsmap mismatch. This is already defined in rfc4379. >=20 >=20 > Best, > Zhenlong >=20 >> -----Original Message----- >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> Sent: Wednesday, July 27, 2011 12:56 AM >> To: Zhenlong Cui >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 >>=20 >> Zhenlong, >>=20 >> Q-1: See RFC 4379, where these regitry entries are derived from. >> RFC 4379 sets up a number of registries - including the TLV >> registry - and defines explicitly how to handle unknown TLV >> types in section 3, in two very obscure paragraphs on page >> 10, just before section 3.1. >>=20 >> Q-2: "ingress port" is not correct - thanks for spotting this >> cut-and-paste duplication error. >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] >> Sent: Tuesday, July 12, 2011 5:20 AM >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 >>=20 >> Dear Authors, >>=20 >> Two questions regarding the idenfifiers TLV and DSMAP TLV. >>=20 >> Question 1: >>>>> Which return code to send when identifiers are wrong (Malformed echo >>>>> request received?) or drop the packet. >>>>>=20 >>>>> EG > Drop the packet, probably log the error, possibly run off >>>>> EG > screaming into the night. What does one do when one gets >>>>> EG > something either not recognizably intended for one, or not >>>>> EG > from a source that one recognizes? =46rom a security point >>>>> EG > of view, we cannot require an implementation to reply to >>>>> EG > the requester in this case (this is an attack vector for >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. >>>>>=20 >> If the "type" of identifier TLV is incorrect, then should this request fr= ame be dropped? Should we reply to the requestor(One >> or >> more of the TLVs was not understood)? Can this way two answers be generat= ed? >>=20 >>=20 >> Question 2: >> In section 2.1.1, Is below("ingress port") correct? >>=20 >> Egress IF_Num identifies the ingress port on the target node. A >> value of 0 indicates that the port is not part of the identifier. >>=20 >>=20 >> Best, >> zhenlong >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of R= olf Winter >>> Sent: Monday, June 27, 2011 8:04 PM >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf= .org >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv= >>>=20 >>> I think that's OK, since the value is not beyond but within the TLV. Tak= en from 4379: >>>=20 >>> Types are defined below; Length is the length of the Value field in >>> octets. The Value field depends on the Type; it is zero padded to >>> align to a 4-octet boundary. >>>=20 >>> That means the length is the length of the actual value (excluding the p= adding). So the beginning of the next TLV is determined >>> by the length plus a value that makes it align on a 4-octet boundary (wh= ich of course can be 0). I cannot follow your argument >>> why this is not correct. I am sure I am missing something trivial, so so= rry for spamming the list. But all information >> is >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a n= ode needs to understand the internal structure >> of >>> each TLV to extract the value instead of applying the simple rule above.= >>>=20 >>>=20 >>> Best, >>>=20 >>> Rolf >>>=20 >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on W3 6BL | Registered in England 2832014 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>> Sent: Montag, 27. Juni 2011 12:42 >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- >>>> cv@tools.ietf.org >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- >>>> cv >>>>=20 >>>> IMO, that would be a problem with RFC 4379. Perhaps there is >>>> an errata? >>>>=20 >>>> TLVs are meant to follow each other, where the beginning of the >>>> next TLV is determined by the length of the current TLV - hence >>>> it is not correct to specify any content as having any value at >>>> all if it is beyond the end of the TLV. >>>>=20 >>>> -----Original Message----- >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>> Sent: Monday, June 27, 2011 5:06 AM >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- >>>> cv@tools.ietf.org >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- >>>> cv >>>> Importance: High >>>>=20 >>>> Hi Eric, >>>>=20 >>>> just one more to follow up. You say: >>>>=20 >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, >>>>> EG > even if the last two octets "Must be Zero"). The length of >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! >>>>=20 >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be >>>> included in the length of the sub-TLVs. Why are they included here? >>>>=20 >>>> Best, >>>>=20 >>>> Rolf >>>>=20 >>>>=20 >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>> London W3 6BL | Registered in England 2832014 >>>>=20 >>>>=20 >>>>>=20 >>>>> EG > Apparently. >>>>>=20 >>>>> Which return code to send when identifiers are wrong (Malformed echo >>>>> request received?) or drop the packet. >>>>>=20 >>>>> EG > Drop the packet, probably log the error, possibly run off >>>>> EG > screaming into the night. What does one do when one gets >>>>> EG > something either not recognizably intended for one, or not >>>>> EG > from a source that one recognizes? =46rom a security point >>>>> EG > of view, we cannot require an implementation to reply to >>>>> EG > the requester in this case (this is an attack vector for >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. >>>>>=20 >>>>> Using the per-interface model and say the DSMAP TLV did not match the >>>>> ingress IF identifier, then should this request frame be dropped? >>>>> Should we reply to the requestor? Can this way two answers be >>>>> generated? >>>>>=20 >>>>> Nit (section 2.1): s/mpls/MPLS/ >>>>>=20 >>>>> EG > Thanks. >>>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Rolf >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>> Behalf >>>>> Of >>>>>> Loa Andersson >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; >>>>> Ross >>>>>> Callon; George Swallow; MPLS-TP ad hoc team >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- >>>> cv >>>>>>=20 >>>>>> Working Group. >>>>>>=20 >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID >>>>>> after wg last call and published version -04 of the document. >>>>>>=20 >>>>>> A document detailing how the comments have been addressed will be >>>>>> found at: >>>>>> http://www.pi.nu/~loa/comments-on-03.xls >>>>>>=20 >>>>>> This is to start a working group call to verify that all comments >>>>>> been adequately addressed. Please send your comments to the >>>>>> mpls working group mailing list before June 24th. >>>>>>=20 >>>>>> Loa >>>>>> on behalf of the MPLS wg co-chairs >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email: >>>>> loa.andersson@ericsson.com >>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>> +46 767 72 92 13 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From DanielC@orckit.com Tue Jul 26 16:22:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720D711E80BE for ; Tue, 26 Jul 2011 16:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcMh9157HnRy for ; Tue, 26 Jul 2011 16:22:21 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1046711E809E for ; Tue, 26 Jul 2011 16:22:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BEB.1AF124C4" Date: Wed, 27 Jul 2011 02:24:02 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxL048ZvZgqRmrjTQ27QKYbUcvs0QAFmxSA References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1><60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> From: "Daniel Cohn" To: "Greg Mirsky" , "David Allan I" Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:22:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4BEB.1AF124C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 I'm afraid I don't follow you. A logical section *is* an LSP. So why wouldn't we use the identifiers we defined for LSP? Can you ellaborate on the PM OAM problems you mention? =20 Thanks, =20 Daniel =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Tuesday, July 26, 2011 4:34 PM To: David Allan I Cc: Daniel Cohn; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? =20 Hi Dave, Daniel, and All, I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP). I think that making MEP ID of Logical Section identical to MEP ID of Server layer LSP MEP ID creates issues with properly executing PM OAM on Section layer and Server layer LSP. Regards, Greg On Tue, Jul 26, 2011 at 12:52 PM, David Allan I wrote: HI Daniel: =20 We have a bit of an inconsistency creeping in in numerous places.... =20 By the definition of a section as any (sub) layer "minus one" path component, then a section can be a physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW etc. =20 So to invent terms to facilitate this discussion we have a physical section (non-MPLS link) and a logical section (some MPLS path construct) =20 Which means we have established procedures for configuring OAM for any logical section, but as Greg Mirsky noted today, not for a physical section, at least not ones we'd necessarily want to use. We have MEP identifiers specific to a physical section in the identifiers draft what we would not use for logical sections as we really do not need multiple identities for maintenance entity components. I'm sure we have a few other places where this small dichotomy raises its head. =20 Nor do we want to confuse physical sections with logical sections.... =20 Hence if we are to resolve some of this without revisiting established RFCs we need to introduce some distinction to further define section "types" along the lines I've suggested above (physcial and logical)... and apply it across the current document set. =20 WDYT? Dave =20 =20 =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, July 26, 2011 1:55 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Hi, =20 In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly stated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data link). =20 See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack"=20 "An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent..." =20 However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.=20 =20 If my understanding is correct, the section OAM requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.=20 =20 Comments? =20 Regards, =20 Daniel =20 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------_=_NextPart_001_01CC4BEB.1AF124C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

I’m afraid I don’t follow you. A logical section *is* an = LSP. So why wouldn’t we use the identifiers we defined for LSP? = Can you ellaborate on the PM OAM problems you = mention?

 

Thanks,

 

Daniel

 

From:= = Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, = July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel = Cohn; mpls@ietf.org
Subject: Re: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

 

Hi Dave, Daniel, and All,
I'd like to = start from Section MEP ID as defined in MPLS-TP ID document. I think = that there should not be distinction in Section MEP ID whether it is = Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 = LSP).  I think that making MEP ID of Logical Section identical to = MEP ID of Server layer LSP MEP ID creates issues with properly executing = PM OAM on Section layer and Server layer = LSP.

Regards,
Greg

On = Tue, Jul 26, 2011 at 12:52 PM, David Allan I <david.i.allan@ericsson.com= > wrote:

HI= Daniel:

 

We= have a bit of an inconsistency creeping in in numerous = places....

 

By= the definition of a section as any (sub) layer "minus = one" path component, then a section can be a physical link for an = SPME or LSP, an SPME for a LSP, an LSP for a = PW etc.

 

So= to invent terms to facilitate this discussion we have a physical = section (non-MPLS link) and a logical section (some MPLS path = construct)

 

Wh= ich means we have established procedures for configuring OAM for any = logical section, but as Greg Mirsky noted today, not for a physical = section, at least not ones we'd necessarily want to use. We have MEP = identifiers specific to a physical section in the identifiers draft what = we would not use for logical sections as we really do not need multiple = identities for maintenance entity components. I'm sure we have a = few other places where this small dichotomy raises its = head.

 

No= r do we want to confuse physical sections with logical = sections....

 

He= nce if we are to resolve some of this without revisiting established = RFCs we need to introduce some distinction to further define section = "types" along the lines I've suggested above (physcial and = logical)... and apply it across the current document = set.

 

WD= YT?

Da= ve

 

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel = Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

Hi,

 <= /o:p>

In several = places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and = sometimes explicitly stated that an MPLS-TP section is equivalent to a = non-MPLS-TP link (aka data link).

 <= /o:p>

See for = example (there’s more):

“MPLS-= TP Section: As defined in [8], it is a link that can be  traversed = by one or more MPLS-TP LSPs.”

“in = case of an MPLS-TP section, the MEG is inferred from the port on which = an OAM packet was received with the GAL at the top of the label = stack”

“An = SMEG is intended to be deployed for applications where it is preferable = to monitor the link between topologically = adjacent…”

 <= /o:p>

However, as = per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), = an MPLS-TP section can also be an LSP carrying another LSP (SPME or = generic H-LSP), or an LSP carrying a PW.

 <= /o:p>

If my = understanding is correct, the section OAM requirements in = draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link = sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.

 <= /o:p>

Comments?

 <= /o:p>

Regards,

 <= /o:p>

Daniel<= /o:p>

 <= /o:p>

 <= /o:p>


______________________________________= _________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 

------_=_NextPart_001_01CC4BEB.1AF124C4-- From DanielC@orckit.com Tue Jul 26 16:23:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FFE11E80C0 for ; Tue, 26 Jul 2011 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcQhV+mmfvAM for ; Tue, 26 Jul 2011 16:23:45 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id C12DC11E809E for ; Tue, 26 Jul 2011 16:23:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BEB.4ED0CDB2" Date: Wed, 27 Jul 2011 02:23:41 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED7FCC@tlvmail1> In-reply-to: <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-tp-oam-framework - inconsistency in sectiondefinitions? Thread-Index: AcxLvS75Zfu9lTb8QDyzg3B9ZzuI9gADoBUAAAc8CVA= References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> From: "Daniel Cohn" To: "David Allan I" , Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in sectiondefinitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:23:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4BEB.4ED0CDB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, =20 I agree with your proposal. Only I wouldn't call the non-MPLS-TP link a physical section, since it's not necessarily so - consider e.g. MPLS running over an SDH VC or OTN ODU. I'd prefer calling it a layer 0 section, following draft-ietf-mpls-tp-identifiers terminology, and clarify it's aka data link. =20 I don't think we need to define again OAM for nonzero layer sections as this is identical to already defined LSP OAM. =20 Let me know what you think. =20 DC =20 From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Tuesday, July 26, 2011 3:53 PM To: Daniel Cohn; mpls@ietf.org Subject: RE: draft-ietf-mpls-tp-oam-framework - inconsistency in sectiondefinitions? =20 HI Daniel: =20 We have a bit of an inconsistency creeping in in numerous places.... =20 By the definition of a section as any (sub) layer "minus one" path component, then a section can be a physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW etc. =20 So to invent terms to facilitate this discussion we have a physical section (non-MPLS link) and a logical section (some MPLS path construct) =20 Which means we have established procedures for configuring OAM for any logical section, but as Greg Mirsky noted today, not for a physical section, at least not ones we'd necessarily want to use. We have MEP identifiers specific to a physical section in the identifiers draft what we would not use for logical sections as we really do not need multiple identities for maintenance entity components. I'm sure we have a few other places where this small dichotomy raises its head. =20 Nor do we want to confuse physical sections with logical sections.... =20 Hence if we are to resolve some of this without revisiting established RFCs we need to introduce some distinction to further define section "types" along the lines I've suggested above (physcial and logical)... and apply it across the current document set. =20 WDYT? Dave =20 =20 =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, July 26, 2011 1:55 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Hi, =20 In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly stated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data link). =20 See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack"=20 "An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent..." =20 However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.=20 =20 If my understanding is correct, the section OAM requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.=20 =20 Comments? =20 Regards, =20 Daniel =20 =20 ------_=_NextPart_001_01CC4BEB.4ED0CDB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

I agree with your = proposal. Only I wouldn’t call the non-MPLS-TP link a physical = section, since it’s not necessarily so – consider e.g. MPLS = running over an SDH VC or OTN ODU. I’d prefer calling it a layer 0 = section, following draft-ietf-mpls-tp-identifiers terminology, and = clarify it’s aka data link.

 

I don’t think we = need to define again OAM for nonzero layer sections as this is identical = to already defined LSP OAM.

 

Let me know what you = think.

 

DC

 

From:= = David Allan I [mailto:david.i.allan@ericsson.com]
Sent: = Tuesday, July 26, 2011 3:53 PM
To: Daniel Cohn; = mpls@ietf.org
Subject: RE: draft-ietf-mpls-tp-oam-framework - = inconsistency in sectiondefinitions?

 

HI= Daniel:

 

We= have a bit of an inconsistency creeping in in numerous = places....

 

By= the definition of a section as any (sub) layer "minus = one" path component, then a section can be a physical link for an = SPME or LSP, an SPME for a LSP, an LSP for a PW etc.

 

So= to invent terms to facilitate this discussion we have a physical = section (non-MPLS link) and a logical section (some MPLS path = construct)

 

Wh= ich means we have established procedures for configuring OAM for any = logical section, but as Greg Mirsky noted today, not for a physical = section, at least not ones we'd necessarily want to use. We have MEP = identifiers specific to a physical section in the identifiers draft what = we would not use for logical sections as we really do not need multiple = identities for maintenance entity components. I'm sure we have a = few other places where this small dichotomy raises its head.

 

No= r do we want to confuse physical sections with logical = sections....

 

He= nce if we are to resolve some of this without revisiting established = RFCs we need to introduce some distinction to further define section = "types" along the lines I've suggested above (physcial and = logical)... and apply it across the current document set.

 

WD= YT?

Da= ve

 

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 = PM
To: mpls@ietf.org
Subject: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

Hi,

 

In several = places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and = sometimes explicitly stated that an MPLS-TP section is equivalent to a = non-MPLS-TP link (aka data link).

 

See for = example (there’s more):

“MPLS-TP Section: As defined in [8], it is a = link that can be  traversed by one or more MPLS-TP = LSPs.”

“in case of an = MPLS-TP section, the MEG is inferred from the port on which an OAM = packet was received with the GAL at the top of the label stack” =

“An SMEG is intended to be = deployed for applications where it is preferable to monitor the link = between topologically adjacent…”

 

However, as = per RFC 5654 and especially RFC5960 (http://tools.ietf= .org/html/rfc5960#section-3.2), an MPLS-TP section can also be an = LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a = PW.

 

If my understanding is correct, the section OAM = requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant = for data-link sections (n=3D0 following RFC 5960 terminology). In this = case, this should be clarified in the draft.

 

Comments?

 

Regards,

 

Daniel

 

 

------_=_NextPart_001_01CC4BEB.4ED0CDB2-- From pabloisnot@gmail.com Tue Jul 26 19:04:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F214911E8090 for ; Tue, 26 Jul 2011 19:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7KglfUzjFhR for ; Tue, 26 Jul 2011 19:04:06 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7ED911E8093 for ; Tue, 26 Jul 2011 19:04:05 -0700 (PDT) Received: by qyk9 with SMTP id 9so2129527qyk.10 for ; Tue, 26 Jul 2011 19:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H41Dz9BFsOy8rXD+Mh/g0PnJRobEGhyZViHPZ7SdPRY=; b=iYTCnyMQ1r4xi3ZcEeNnOKJ1f2BtPTPCT/WvfohSpcxsHq/QZ30zxn22AxGVsqe/03 Jz2FJCpasscjckhkINXtBQn3PbQ8fPueZ1WVEjcBUa8hRw1Kg5gi4RLgvvK//QYBmHC2 iFqPkgenO4YRQAnN6L8dW61l5YJAFuAjD2uVI= MIME-Version: 1.0 Received: by 10.224.192.202 with SMTP id dr10mr4600694qab.131.1311732244994; Tue, 26 Jul 2011 19:04:04 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Tue, 26 Jul 2011 19:04:04 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED7FA8@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306E584AC@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306E584B2@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED7FA8@tlvmail1> Date: Tue, 26 Jul 2011 22:04:04 -0400 Message-ID: From: Pablo Frank To: Daniel Cohn Content-Type: multipart/alternative; boundary=20cf300fb1f180d8b204a90376db Cc: mpls@ietf.org Subject: Re: [mpls] 1:n protection for MPLS-TP open question (the 1000 Kg question?) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:04:07 -0000 --20cf300fb1f180d8b204a90376db Content-Type: text/plain; charset=ISO-8859-1 I think this is true. The only thing that makes it "2-phase-ish" is the way the sender goes into a Wait-for-ack (Wfa) state while it waits for the other side to acknowledge the state change. However, the more I think about it, the more I'm unsure why we even need the Wfa state, and thus why the PSC protocol has to be modified to be 2-phase-ish in the first place. It seems like the only reason the Wfa state exists is so that it can raise an alarm if the other side never acknowledges the change. But is that really necessary? The current PSC will send 3 PSC messages in quick succession following a state change and then will continue to send periodic PSC messages indefinitely until the next change. It seems to me that as long as the senders continue to report on what they think the highest priority failed path is, both sides will converge to protecting the same path. Am I missing something here? regards, Pablo p.s. given the spelling, it's actually the 1016.04691 Kg question. : ) On Tue, Jul 26, 2011 at 10:54 AM, Daniel Cohn wrote: > Right, GR-253 APS is 2-phase. G.8031 APS for example is 1-phase. > Regardless of examples, my point is that if you bridge the signal to the > protection path before waiting for the ACK, then this is a 1-phase > protocol, despite the ACK being eventually received. > > DC > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Tuesday, July 26, 2011 10:31 AM > To: Daniel Cohn > Cc: mpls@ietf.org > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > question?) > > Hi Daniel- > > 1:1 PSC is 1-phase, no argument there. I'm not sure I follow your > point that APS is also explicitly 1-phase. I'm looking at GR-253 issue > 5. Table 5-8 lists what I'd call a two-phase procedure: > > - C detects failure, requests bridge > - A bridges, sends reverse request > - C selects and bridges > > True, it's not exactly the same as PSC, but the idea as I read it is > that C needs an ACK (RR) from A in order to complete the protection. If > that's one-phase then yeah, I think our terminologies are at odds with > each other. Right? > > > > > eric > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Monday, July 25, 2011 3:19 PM > > To: Eric Osborne (eosborne) > > Cc: mpls@ietf.org > > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > > question?) > > > > Eric, > > > > "Classic" PSC or APS, which is explicitly 1-phase, also has an > implicit > > ACK when the far end reports which signal is being bridge to the > > protection path in the PSC/APS messages. And this doesn't make it two- > > phase. So I believe that your suggested behavior should be called > 1-phase. > > I'm not suggesting we ignore unidirectional failures, as I believe the > PSC > > mechanisms should work regardless of the underlying specific SF/SD > > detection mechanism. I'm just splitting hairs on terminology ;-) > > > > DC > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Monday, July 25, 2011 2:34 PM > > To: Daniel Cohn > > Cc: mpls@ietf.org > > Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg > > question?) > > > > Hi Daniel- > > > > That is indeed a good question. To me, it's two-phase in that there > are > > two phases to the message (protection notification, and the ACK in > reply). > > All we're doing with my proposed behavior is sending the traffic that > we > > would have converged on anyways, without waiting unnecessarily. > > > > As I noted in my slides, we need this so that after all the dust > > settles, both ends of the protection domain can agree on what they're > > protecting. This is really only necessary in the case of an oddball > > unidirectional failure. > > > > You could argue that all unidir failures should be caught by CC/Cv > and > > that we should not have to worry about anything in PSC other than > > bidirectional failures. And if you did argue that I'd be in vehement > > agreement that it'd be nice to ignore unidir failures. But we can't, > and > > so we need to be able to handle them in PSC, which makes several > things > > trickier than they would be otherwise. > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > > Sent: Monday, July 25, 2011 1:45 PM > > > To: Eric Osborne (eosborne) > > > Cc: mpls@ietf.org > > > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg > > question?) > > > > > > Hi Eric, > > > > > > > > > > > > Wrt the "Two-phase without lock" option which you presented today - > if > > the > > > side detecting the failure does not wait for acknowledgment before > > > switching traffic to the protection path, in which sense is this > still > > > "two phase"? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Daniel > > > > > > > > > > > > PS: I also don't see a scenario where the "lock" is required > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf300fb1f180d8b204a90376db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this is true. =A0The only thing that makes it "2-phase-ish&quo= t; is the way the sender goes into a Wait-for-ack (Wfa) state while it wait= s for the other side to acknowledge the state change. =A0

However, the more I think about it, the more I'm unsure why we even nee= d the Wfa state, and thus why the PSC protocol has to be modified to be 2-p= hase-ish in the first place. =A0It seems like the only reason the Wfa state= exists is so that it can raise an alarm if the other side never acknowledg= es the change. =A0But is that really necessary? =A0The current PSC will sen= d 3 PSC messages in quick succession following a state change and then will= continue to send periodic PSC messages indefinitely until the next change.= =A0It seems to me that as long as the senders continue to report on what t= hey think the highest priority failed path is, both sides will converge to = protecting the same path. =A0Am I missing something here?=A0

regards,
Pablo

p.s. = given the spelling, it's actually the 1016.04691 Kg question. =A0: )

On Tue, Jul 26, 2011 at 10:54 AM, Da= niel Cohn <Danie= lC@orckit.com> wrote:
Right, GR-253 APS is 2-phase. G.8031 APS fo= r example is 1-phase.
Regardless of examples, my point is that if you bridge the signal to the protection path before waiting for the ACK, then this is a 1-phase
protocol, despite the ACK being eventually received.

DC

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
Sent: Tuesday, July 26, 2011 10:31 AM
To: Daniel Cohn
Cc: mpls@ietf.org
Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg
question?)

Hi Daniel-

=A01:1 PSC is 1-phase, no argument there. =A0I'm not sure I follow you= r
point that APS is also explicitly 1-phase. =A0I'm looking at GR-253 iss= ue
5. =A0Table 5-8 lists what I'd call a two-phase procedure:

- C detects failure, requests bridge
- A bridges, sends reverse request
- C selects and bridges

True, it's not exactly the same as PSC, but the idea as I read it is that C needs an ACK (RR) from A in order to complete the protection. =A0If<= br> that's one-phase then yeah, I think our terminologies are at odds with<= br> each other. Right?




eric

> -----Original Message-----
> From: Daniel Cohn [mailto:Daniel= C@orckit.com]
> Sent: Monday, July 25, 2011 3:19 PM
> To: Eric Osborne (eosborne)
> Cc: mpls@ietf.org
> Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg
> question?)
>
> Eric,
>
> "Classic" PSC or APS, which is explicitly 1-phase, also has = an
implicit
> ACK when the far end reports which signal is being bridge to the
> protection path in the PSC/APS messages. And this doesn't make it = two-
> phase. So I believe that your suggested behavior should be called
1-phase.
> I'm not suggesting we ignore unidirectional failures, as I believe= the
PSC
> mechanisms should work regardless of the underlying specific SF/SD
> detection mechanism. I'm just splitting hairs on terminology ;-) >
> DC
>
> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> Sent: Monday, July 25, 2011 2:34 PM
> To: Daniel Cohn
> Cc: mpls@ietf.org
> Subject: RE: 1:n protection for MPLS-TP open question (the 1000 Kg
> question?)
>
> Hi Daniel-
>
> =A0 That is indeed a good question. =A0To me, it's two-phase in th= at there
are
> two phases to the message (protection notification, and the ACK in
reply).
> All we're doing with my proposed behavior is sending the traffic t= hat
we
> would have converged on anyways, without waiting unnecessarily.
>
> =A0 As I noted in my slides, we need this so that after all the dust > settles, both ends of the protection domain can agree on what they'= ;re
> protecting. =A0This is really only necessary in the case of an oddball=
> unidirectional failure.
>
> =A0 You could argue that all unidir failures should be caught by CC/Cv=
and
> that we should not have to worry about anything in PSC other than
> bidirectional failures. =A0And if you did argue that I'd be in veh= ement
> agreement that it'd be nice to ignore unidir failures. =A0But we c= an't,
and
> so we need to be able to handle them in PSC, which makes several
things
> trickier than they would be otherwise.
>
>
>
>
> eric
>
>
> > -----Original Message-----
> > From: Daniel Cohn [mailto:D= anielC@orckit.com]
> > Sent: Monday, July 25, 2011 1:45 PM
> > To: Eric Osborne (eosborne)
> > Cc: mpls@ietf.org
> > Subject: 1:n protection for MPLS-TP open question (the 1000 Kg > question?)
> >
> > Hi Eric,
> >
> >
> >
> > Wrt the "Two-phase without lock" option which you prese= nted today -
if
> the
> > side detecting the failure does not wait for acknowledgment befor= e
> > switching traffic to the protection path, in which sense is this<= br> still
> > "two phase"?
> >
> >
> >
> > Regards,
> >
> >
> >
> > Daniel
> >
> >
> >
> > PS: I also don't see a scenario where the "lock" is= required

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

--20cf300fb1f180d8b204a90376db-- From gregimirsky@gmail.com Tue Jul 26 20:21:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86811E80A5 for ; Tue, 26 Jul 2011 20:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxRvSDn66SL4 for ; Tue, 26 Jul 2011 20:21:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C77315E8018 for ; Tue, 26 Jul 2011 20:21:18 -0700 (PDT) Received: by vws12 with SMTP id 12so1015165vws.31 for ; Tue, 26 Jul 2011 20:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PTtGkF2P7GQhmOFoEVpz5wepG5RloH6S9zaryh0d1v0=; b=v6pkhosyuwH8nrk3MuTMHZOseOj1EjaW3yeesMMBqvgPx0vl18DvDYutqJqgDKQSmp +RaKGiVo54IuvUqf04O7z6TEHxserhOnLKjkUY9RM/zBCA4d1H7mpkvZTTk1O1StgNb5 zNfCPmdu9MzhR3SRsdCH7xp2FUv7ps13tVmvc= MIME-Version: 1.0 Received: by 10.52.156.3 with SMTP id wa3mr6929091vdb.24.1311736878051; Tue, 26 Jul 2011 20:21:18 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Tue, 26 Jul 2011 20:21:17 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> Date: Tue, 26 Jul 2011 20:21:17 -0700 Message-ID: From: Greg Mirsky To: Daniel Cohn Content-Type: multipart/alternative; boundary=bcaec53aee24a7b14604a9048a1f Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 03:21:20 -0000 --bcaec53aee24a7b14604a9048a1f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, I feel that I need to use slideware as "a picture is worth a thousand words". But will give it a try nevertheless. I'm looking at layered networks a bit more in the way ITU-T decomposes functions. From that point, I think, Section OAM should not be aware of whether monitored construct is Layer 0 (physical) or Layer n-1 (logical) link. It is just a Section that is identified by Node ID and IF ID (note that IF ID itself is not necessarily ID of a physical port but of a logical circuit, e.g. VLAN). Thus, what we refer as Logical Section can be identified, I believe, through the same combination of Node and IF IDs. Regards, Greg PS. We can discuss it in person tomorrow morning. On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn wrote: > Hi Greg,**** > > ** ** > > I=92m afraid I don=92t follow you. A logical section *is* an LSP. So why > wouldn=92t we use the identifiers we defined for LSP? Can you ellaborate = on > the PM OAM problems you mention?**** > > ** ** > > Thanks,**** > > ** ** > > Daniel**** > > ** ** > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, July 26, 2011 4:34 PM > *To:* David Allan I > *Cc:* Daniel Cohn; mpls@ietf.org > *Subject:* Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions?**** > > ** ** > > Hi Dave, Daniel, and All, > I'd like to start from Section MEP ID as defined in MPLS-TP ID document. = I > think that there should not be distinction in Section MEP ID whether it i= s > Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP)= . > I think that making MEP ID of Logical Section identical to MEP ID of Serv= er > layer LSP MEP ID creates issues with properly executing PM OAM on Section > layer and Server layer LSP. > > Regards, > Greg**** > > On Tue, Jul 26, 2011 at 12:52 PM, David Allan I < > david.i.allan@ericsson.com> wrote:**** > > HI Daniel:**** > > **** > > We have a bit of an inconsistency creeping in in numerous places....**** > > **** > > By the definition of a section as any (sub) layer "minus one" path > component, then a section can be a physical link for an SPME or LSP, an S= PME > for a LSP, an LSP for a PW etc.**** > > **** > > So to invent terms to facilitate this discussion we have a physical secti= on > (non-MPLS link) and a logical section (some MPLS path construct)**** > > **** > > Which means we have established procedures for configuring OAM for any > logical section, but as Greg Mirsky noted today, not for a physical secti= on, > at least not ones we'd necessarily want to use. We have MEP identifiers > specific to a physical section in the identifiers draft what we would not > use for logical sections as we really do not need multiple identities > for maintenance entity components. I'm sure we have a few other places wh= ere > this small dichotomy raises its head.**** > > **** > > Nor do we want to confuse physical sections with logical sections....**** > > **** > > Hence if we are to resolve some of this without revisiting established RF= Cs > we need to introduce some distinction to further define section "types" > along the lines I've suggested above (physcial and logical)... and apply = it > across the current document set.**** > > **** > > WDYT?**** > > Dave**** > > **** > > **** > > ** ** > ------------------------------ > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Daniel Cohn > *Sent:* Tuesday, July 26, 2011 1:55 PM > *To:* mpls@ietf.org > *Subject:* [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions?**** > > Hi,**** > > **** > > In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed a= nd > sometimes explicitly stated that an MPLS-TP section is equivalent to a > non-MPLS-TP link (aka data link).**** > > **** > > See for example (there=92s more):**** > > =93MPLS-TP Section: As defined in [8], it is a link that can be traverse= d by > one or more MPLS-TP LSPs.=94**** > > =93in case of an MPLS-TP section, the MEG is inferred from the port on wh= ich > an OAM packet was received with the GAL at the top of the label stack=94 = *** > * > > =93An SMEG is intended to be deployed for applications where it is prefer= able > to monitor the link between topologically adjacent=85=94**** > > **** > > However, as per RFC 5654 and especially RFC5960 ( > http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can > also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP > carrying a PW. **** > > **** > > If my understanding is correct, the section OAM requirements in > draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link secti= ons > (n=3D0 following RFC 5960 terminology). In this case, this should be clar= ified > in the draft. **** > > **** > > Comments?**** > > **** > > Regards,**** > > **** > > Daniel**** > > **** > > **** > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --bcaec53aee24a7b14604a9048a1f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel,
I feel that I need to use slideware as "a picture is wor= th a thousand words". But will give it a try nevertheless.
I'm = looking at layered networks a bit more in the way ITU-T decomposes function= s. From that point, I think, Section OAM should not be aware of whether mon= itored construct is Layer 0 (physical) or Layer n-1 (logical) link. It is j= ust a Section that is identified by Node ID and IF ID (note that IF ID itse= lf is not necessarily ID of a physical port but of a logical circuit, e.g. = VLAN). Thus, what we refer as Logical Section can be identified, I believe,= through the same combination of Node and IF IDs.

Regards,
Greg

PS. We can discuss it in person tomorrow mornin= g.

On Tue, Jul 26, 2011 at 4:24 PM, Danie= l Cohn <DanielC@= orckit.com> wrote:

Hi Greg,

=A0

I=92m afraid I don=92t follow you. A logical section *is*= an LSP. So why wouldn=92t we use the identifiers we defined for LSP? Can y= ou ellaborate on the PM OAM problems you mention?

=A0

Thanks,

=A0

Danie= l

=A0

From:= Greg Mirsky [mailto:gregimirsky@gmail.com]
Sen= t: Tuesday, July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel Cohn; mpls@ietf.org
Subject: Re: [mpls]= draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

=A0

Hi Dave, Dan= iel, and All,
I'd like to start from Section MEP ID as defined in MP= LS-TP ID document. I think that there should not be distinction in Section = MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Sect= ion (Layer n-1 LSP).=A0 I think that making MEP ID of Logical Section ident= ical to MEP ID of Server layer LSP MEP ID creates issues with properly exec= uting PM OAM on Section layer and Server layer LSP.

Regards,
Greg

On Tue, J= ul 26, 2011 at 12:52 PM, David Allan I <david.i.allan@ericsson.com> wrote:

HI = Daniel:

=A0

We have= a bit of an inconsistency creeping in in numerous places....=

=A0

By the definition of=A0a section as any= (sub) layer "minus one" path component, then a section can be a = physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW=A0etc.=

=A0

So to invent terms to facilitate this d= iscussion we have a physical section (non-MPLS link) and a logical section = (some MPLS path construct)

=A0

Which means we have established procedu= res for configuring OAM for any logical section, but as Greg Mirsky noted t= oday, not for a physical section, at least not ones we'd necessarily wa= nt to use. We have MEP identifiers specific to a physical section in the id= entifiers draft what we would not use for logical sections as we really do = not need multiple identities for=A0maintenance entity components. I'm s= ure we have a few other places where this small dichotomy raises its head.<= /span>

=A0

Nor do we want to confuse physical sect= ions with logical sections....

=A0

Hence if= we are to resolve some of this without revisiting established RFCs we need= to introduce some distinction to further define section "types" = along the lines I've suggested above (physcial and logical)... and appl= y it across the current document set.

=A0

WDYT?

Dave

=A0

=A0

=A0

From: mpls-bounces@ietf.o= rg [mailto:m= pls-bounces@ietf.org] On Behalf Of Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject: [mpl= s] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?=

Hi,

=A0

In several places in dra= ft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly st= ated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data = link).

=A0

See for = example (there=92s more):

=93MPLS-T= P Section: As defined in [8], it is a link that can be=A0 traversed by one = or more MPLS-TP LSPs.=94

=93in case of an MPLS-TP section, the MEG is inferre= d from the port on which an OAM packet was received with the GAL at the top= of the label stack=94

=93An SMEG = is intended to be deployed for applications where it is preferable to monit= or the link between topologically adjacent=85=94

=A0

However,= as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc59= 60#section-3.2), an MPLS-TP section can also be an LSP carrying another= LSP (SPME or generic H-LSP), or an LSP carrying a PW.

=A0

If my un= derstanding is correct, the section OAM requirements in draft-ietf-mpls-tp-= oam-framework-10 are only relevant for data-link sections (n=3D0 following = RFC 5960 terminology). In this case, this should be clarified in the draft.=

=A0

Comments= ?

=A0

Regards,

=A0

Daniel

=A0

=A0


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

=A0

<= /blockquote>

--bcaec53aee24a7b14604a9048a1f-- From gregimirsky@gmail.com Tue Jul 26 20:26:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133D45E801B for ; Tue, 26 Jul 2011 20:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DMeRR6VsWrG for ; Tue, 26 Jul 2011 20:26:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C255C5E8015 for ; Tue, 26 Jul 2011 20:26:45 -0700 (PDT) Received: by vws12 with SMTP id 12so1017670vws.31 for ; Tue, 26 Jul 2011 20:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGESbj/pRcxqiEXxGScI9ysTm2F7y60vSgrttybWvtg=; b=gteorGn9JUr4Jqtedu7tBXLIxy+9w33wrNORHrDKPwHc6PA1vTc5JoMOETdF1JuKsA f4FYBVtdm1XPJ4W9YyLNhHbVaunfKZAxCiGuO4aE8lsuTDF6LvNAjfH3gc2810uRvGTt Or1EuXFgPkStoL8CoKbZq9GJX33IHDL6lzYH0= MIME-Version: 1.0 Received: by 10.52.172.244 with SMTP id bf20mr6343727vdc.292.1311737205194; Tue, 26 Jul 2011 20:26:45 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Tue, 26 Jul 2011 20:26:45 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> Date: Tue, 26 Jul 2011 20:26:45 -0700 Message-ID: From: Greg Mirsky To: Daniel Cohn Content-Type: multipart/alternative; boundary=bcaec51ba217277fdb04a9049e3a Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 03:26:47 -0000 --bcaec51ba217277fdb04a9049e3a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, I feel that I need to use slideware as "a picture is worth a thousand words". But will give it a try nevertheless. I'm looking at layered networks a bit more in the way ITU-T decomposes functions. From that point, I think, Section OAM should not be aware of whether monitored construct is physical or logical link. It is a Section that is identified by Node ID and IF ID (note that IF ID itself is not necessarily ID of a physical port but of a logical circuit, e.g. VLAN). Thus, what we refer as Logical Section can be characterized, I beli On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn wrote: > Hi Greg,**** > > ** ** > > I=92m afraid I don=92t follow you. A logical section *is* an LSP. So why > wouldn=92t we use the identifiers we defined for LSP? Can you ellaborate = on > the PM OAM problems you mention?**** > > ** ** > > Thanks,**** > > ** ** > > Daniel**** > > ** ** > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, July 26, 2011 4:34 PM > *To:* David Allan I > *Cc:* Daniel Cohn; mpls@ietf.org > *Subject:* Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions?**** > > ** ** > > Hi Dave, Daniel, and All, > I'd like to start from Section MEP ID as defined in MPLS-TP ID document. = I > think that there should not be distinction in Section MEP ID whether it i= s > Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP)= . > I think that making MEP ID of Logical Section identical to MEP ID of Serv= er > layer LSP MEP ID creates issues with properly executing PM OAM on Section > layer and Server layer LSP. > > Regards, > Greg**** > > On Tue, Jul 26, 2011 at 12:52 PM, David Allan I < > david.i.allan@ericsson.com> wrote:**** > > HI Daniel:**** > > **** > > We have a bit of an inconsistency creeping in in numerous places....**** > > **** > > By the definition of a section as any (sub) layer "minus one" path > component, then a section can be a physical link for an SPME or LSP, an S= PME > for a LSP, an LSP for a PW etc.**** > > **** > > So to invent terms to facilitate this discussion we have a physical secti= on > (non-MPLS link) and a logical section (some MPLS path construct)**** > > **** > > Which means we have established procedures for configuring OAM for any > logical section, but as Greg Mirsky noted today, not for a physical secti= on, > at least not ones we'd necessarily want to use. We have MEP identifiers > specific to a physical section in the identifiers draft what we would not > use for logical sections as we really do not need multiple identities > for maintenance entity components. I'm sure we have a few other places wh= ere > this small dichotomy raises its head.**** > > **** > > Nor do we want to confuse physical sections with logical sections....**** > > **** > > Hence if we are to resolve some of this without revisiting established RF= Cs > we need to introduce some distinction to further define section "types" > along the lines I've suggested above (physcial and logical)... and apply = it > across the current document set.**** > > **** > > WDYT?**** > > Dave**** > > **** > > **** > > ** ** > ------------------------------ > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Daniel Cohn > *Sent:* Tuesday, July 26, 2011 1:55 PM > *To:* mpls@ietf.org > *Subject:* [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section definitions?**** > > Hi,**** > > **** > > In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed a= nd > sometimes explicitly stated that an MPLS-TP section is equivalent to a > non-MPLS-TP link (aka data link).**** > > **** > > See for example (there=92s more):**** > > =93MPLS-TP Section: As defined in [8], it is a link that can be traverse= d by > one or more MPLS-TP LSPs.=94**** > > =93in case of an MPLS-TP section, the MEG is inferred from the port on wh= ich > an OAM packet was received with the GAL at the top of the label stack=94 = *** > * > > =93An SMEG is intended to be deployed for applications where it is prefer= able > to monitor the link between topologically adjacent=85=94**** > > **** > > However, as per RFC 5654 and especially RFC5960 ( > http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can > also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP > carrying a PW. **** > > **** > > If my understanding is correct, the section OAM requirements in > draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link secti= ons > (n=3D0 following RFC 5960 terminology). In this case, this should be clar= ified > in the draft. **** > > **** > > Comments?**** > > **** > > Regards,**** > > **** > > Daniel**** > > **** > > **** > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --bcaec51ba217277fdb04a9049e3a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel,
I feel that I need to use slideware as "a picture is wor= th a thousand words". But will give it a try nevertheless.
I'm = looking at layered networks a bit more in the way ITU-T decomposes function= s. From that point, I think, Section OAM should not be aware of whether mon= itored construct is physical or logical link. It is a Section that is ident= ified by Node ID and IF ID (note that IF ID itself is not necessarily ID of= a physical port but of a logical circuit, e.g. VLAN). Thus, what we refer = as Logical Section can be characterized, I beli

On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn= <DanielC@orckit.com> wrote:

Hi Greg,

=A0

I=92m= afraid I don=92t follow you. A logical section *is* an LSP. So why wouldn= =92t we use the identifiers we defined for LSP? Can you ellaborate on the P= M OAM problems you mention?

=A0

Thanks,

=A0

Danie= l

=A0

From:= Greg Mirsky [mailto:gregimirsky@gmail.com]
Sen= t: Tuesday, July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel Cohn; mpls@ietf.org
Subject: Re: [mpls]= draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?

=A0

Hi Dave, Daniel, and All,=
I'd like to start from Section MEP ID as defined in MPLS-TP ID docu= ment. I think that there should not be distinction in Section MEP ID whethe= r it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-= 1 LSP).=A0 I think that making MEP ID of Logical Section identical to MEP I= D of Server layer LSP MEP ID creates issues with properly executing PM OAM = on Section layer and Server layer LSP.

Regards,
Greg

On Tue, J= ul 26, 2011 at 12:52 PM, David Allan I <david.i.allan@ericsson.com> wrote:

HI = Daniel:

=A0

We have= a bit of an inconsistency creeping in in numerous places....=

=A0

By the definition of=A0a section as any= (sub) layer "minus one" path component, then a section can be a = physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW=A0etc.=

=A0

So to invent terms to facilitate this d= iscussion we have a physical section (non-MPLS link) and a logical section = (some MPLS path construct)

=A0

Which means we have established procedu= res for configuring OAM for any logical section, but as Greg Mirsky noted t= oday, not for a physical section, at least not ones we'd necessarily wa= nt to use. We have MEP identifiers specific to a physical section in the id= entifiers draft what we would not use for logical sections as we really do = not need multiple identities for=A0maintenance entity components. I'm s= ure we have a few other places where this small dichotomy raises its head.<= /span>

=A0

Nor do we want to confuse physical sect= ions with logical sections....

=A0

Hence if= we are to resolve some of this without revisiting established RFCs we need= to introduce some distinction to further define section "types" = along the lines I've suggested above (physcial and logical)... and appl= y it across the current document set.

=A0

WDYT?

Dave

=A0

=A0

=A0

From: mpls-bounces@ietf.o= rg [mailto:m= pls-bounces@ietf.org] On Behalf Of Daniel Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject: [mpl= s] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions?=

Hi,

=A0

In several places in dra= ft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly st= ated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data = link).

=A0

See for = example (there=92s more):

=93MPLS-T= P Section: As defined in [8], it is a link that can be=A0 traversed by one = or more MPLS-TP LSPs.=94

=93in case of an MPLS-TP section, the MEG is inferre= d from the port on which an OAM packet was received with the GAL at the top= of the label stack=94

=93An SMEG = is intended to be deployed for applications where it is preferable to monit= or the link between topologically adjacent=85=94

=A0

However,= as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc59= 60#section-3.2), an MPLS-TP section can also be an LSP carrying another= LSP (SPME or generic H-LSP), or an LSP carrying a PW.

=A0

If my un= derstanding is correct, the section OAM requirements in draft-ietf-mpls-tp-= oam-framework-10 are only relevant for data-link sections (n=3D0 following = RFC 5960 terminology). In this case, this should be clarified in the draft.=

=A0

Comments= ?

=A0

Regards,

=A0

Daniel

=A0

=A0


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

=A0

<= /blockquote>

--bcaec51ba217277fdb04a9049e3a-- From eric.gray@ericsson.com Tue Jul 26 22:17:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A9421F8B82 for ; Tue, 26 Jul 2011 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YakEdB0dtIQ for ; Tue, 26 Jul 2011 22:17:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7095F21F8B83 for ; Tue, 26 Jul 2011 22:17:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6R5Hdqm024218; Wed, 27 Jul 2011 00:17:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 27 Jul 2011 01:17:35 -0400 From: Eric Gray To: Zhenlong Cui Date: Wed, 27 Jul 2011 01:17:33 -0400 Thread-Topic: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: AQHMLGAfW26yQHHsSES4MoXuuvjsuJTLNK7QgAHHkYCAA/0dQIAAGryggAAC3ZCAF28eAIAWWg2ggABTzkCAACpC4A== Message-ID: References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> In-Reply-To: <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 05:17:50 -0000 Zhenlong, A few observations: 1) Even if you can respond to the sender - as expected for the unknown TLV case - you should exercise implementation caution to avoid banging the network with these responses if you keep getting the offending TLVs. That turns some other vendor's problems into your problem. This approach reduces security risks associated with a known sender that is behaving badly. 2) If you are relying on the TLV to give you the identity of the sender, how can you not know the TLV type? On the other hand, if you know how to get a reply to the sender by some means, and you get one or more TLVs that you don't understand, then you should probably send an error code at least once, and you may determine from your own experience that you need to send additional replies periodically if it continues. 3) Specifying this sort of implementation detail is not part of what the IETF is not paying me to do. :-) 4) Since this document refers to RFC 4379 extensively, it isn't necessary for this document to repeat the content of RFC 4379. 5) What we can do is point to the specific location in RFC 4379, since it is not easy to find. That we will do. -- Eric -----Original Message----- From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com]=20 Sent: Tuesday, July 26, 2011 5:04 PM To: Eric Gray Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Importance: High Hi Eric, I remember you said earlier that you should drop the packet from unknown so= urce nodes, because there is a security problem with responding. On the other hand, you say that you should send a reply when the request in= cludes an unknown TLV. I think if the responder receives a request it checks the type of the TLV b= efore it checks the identifiers. So, my question is "if the responder receives a request from an unknown sou= rce node that includes an unknown TLV, does the responder have to reply to the unknown source node?". If yes, this has the security p= roblem you mentioned earlier, doesn't it? Lastly, I suggest that add some mention to this draft regarding responder's= behavior for new TLV. 1) Which return code to send when source/destination identifiers are wrong = or drop the request. 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV= are wrong or drop the request. Best, Zhenlong > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Wednesday, July 27, 2011 12:56 AM > To: Zhenlong Cui > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 >=20 > Zhenlong, >=20 > Q-1: See RFC 4379, where these registry entries are derived from. > RFC 4379 sets up a number of registries - including the TLV > registry - and defines explicitly how to handle unknown TLV > types in section 3, in two very obscure paragraphs on page > 10, just before section 3.1. >=20 > Q-2: "ingress port" is not correct - thanks for spotting this > cut-and-paste duplication error. >=20 > -- > Eric >=20 > -----Original Message----- > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > Sent: Tuesday, July 12, 2011 5:20 AM > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 >=20 > Dear Authors, >=20 > Two questions regarding the idenfifiers TLV and DSMAP TLV. >=20 > Question 1: > > > > Which return code to send when identifiers are wrong (Malformed ech= o > > > > request received?) or drop the packet. > > > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > > EG > screaming into the night. What does one do when one gets > > > > EG > something either not recognizably intended for one, or not > > > > EG > from a source that one recognizes? From a security point > > > > EG > of view, we cannot require an implementation to reply to > > > > EG > the requester in this case (this is an attack vector for > > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > If the "type" of identifier TLV is incorrect, then should this request fr= ame be dropped? Should we reply to the requestor(One > or > more of the TLVs was not understood)? Can this way two answers be generat= ed? >=20 >=20 > Question 2: > In section 2.1.1, Is below("ingress port") correct? >=20 > Egress IF_Num identifies the ingress port on the target node. A > value of 0 indicates that the port is not part of the identifier. >=20 >=20 > Best, > zhenlong >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= Rolf Winter > > Sent: Monday, June 27, 2011 8:04 PM > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.iet= f.org > > Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-c= v > > > > I think that's OK, since the value is not beyond but within the TLV. Ta= ken from 4379: > > > > Types are defined below; Length is the length of the Value field in > > octets. The Value field depends on the Type; it is zero padded to > > align to a 4-octet boundary. > > > > That means the length is the length of the actual value (excluding the = padding). So the beginning of the next TLV is determined > > by the length plus a value that makes it align on a 4-octet boundary (w= hich of course can be 0). I cannot follow your argument > > why this is not correct. I am sure I am missing something trivial, so s= orry for spamming the list. But all information > is > > encoded in the packet (plus the simple rule quoted above). Otherwise, a= node needs to understand the internal structure > of > > each TLV to extract the value instead of applying the simple rule above= . > > > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > > Sent: Montag, 27. Juni 2011 12:42 > > > To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > cv@tools.ietf.org > > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand= - > > > cv > > > > > > IMO, that would be a problem with RFC 4379. Perhaps there is > > > an errata? > > > > > > TLVs are meant to follow each other, where the beginning of the > > > next TLV is determined by the length of the current TLV - hence > > > it is not correct to specify any content as having any value at > > > all if it is beyond the end of the TLV. > > > > > > -----Original Message----- > > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > > Sent: Monday, June 27, 2011 5:06 AM > > > To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > cv@tools.ietf.org > > > Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand= - > > > cv > > > Importance: High > > > > > > Hi Eric, > > > > > > just one more to follow up. You say: > > > > > > > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > > EG > even if the last two octets "Must be Zero"). The length of > > > > EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > > EG > longer by the addition of the 2-word AGI. Nice catch! > > > > > > In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > > included in the length of the sub-TLVs. Why are they included here? > > > > > > Best, > > > > > > Rolf > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > EG > Apparently. > > > > > > > > Which return code to send when identifiers are wrong (Malformed ech= o > > > > request received?) or drop the packet. > > > > > > > > EG > Drop the packet, probably log the error, possibly run off > > > > EG > screaming into the night. What does one do when one gets > > > > EG > something either not recognizably intended for one, or not > > > > EG > from a source that one recognizes? From a security point > > > > EG > of view, we cannot require an implementation to reply to > > > > EG > the requester in this case (this is an attack vector for > > > > EG > all kinds of hate and discontent). Nor can we forbid it. > > > > > > > > Using the per-interface model and say the DSMAP TLV did not match t= he > > > > ingress IF identifier, then should this request frame be dropped? > > > > Should we reply to the requestor? Can this way two answers be > > > > generated? > > > > > > > > Nit (section 2.1): s/mpls/MPLS/ > > > > > > > > EG > Thanks. > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > Behalf > > > > Of > > > > > Loa Andersson > > > > > Sent: Donnerstag, 16. Juni 2011 22:01 > > > > > To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org= ; > > > > Ross > > > > > Callon; George Swallow; MPLS-TP ad hoc team > > > > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand= - > > > cv > > > > > > > > > > Working Group. > > > > > > > > > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the I= D > > > > > after wg last call and published version -04 of the document. > > > > > > > > > > A document detailing how the comments have been addressed will be > > > > > found at: > > > > > http://www.pi.nu/~loa/comments-on-03.xls > > > > > > > > > > This is to start a working group call to verify that all comments > > > > > been adequately addressed. Please send your comments to the > > > > > mpls working group mailing list before June 24th. > > > > > > > > > > Loa > > > > > on behalf of the MPLS wg co-chairs > > > > > > > > > > -- > > > > > > > > > > > > > > > Loa Andersson email: > > > > loa.andersson@ericsson.com > > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > > +46 767 72 92 13 > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Tue Jul 26 23:27:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39C05E8023 for ; Tue, 26 Jul 2011 23:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp8pk-xUFR5T for ; Tue, 26 Jul 2011 23:27:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id B4B495E801E for ; Tue, 26 Jul 2011 23:27:29 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 07:27:28 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 27 Jul 2011 07:27:28 +0100 From: To: , , Date: Wed, 27 Jul 2011 07:27:23 +0100 Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxL01WCAHuEjjUhRfSPv7SRFQWdrQAAPKNgAAEPCaUAEobp8A== Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BFB@EMV62-UKRD.domain1.systemhost.net> References: <6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BCC@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:27:31 -0000 Hi Giles...thanks....just one point in-line: who said 26 July 2011 22:11 =20 > On 26/07/2011 21:54, "neil.2.harrison@bt.com" > wrote: >=20 > > Greg/Dave/Daniel, > > > > The fundamental problem here is that we simply don't have a proper > BOS section > > layer in MPLS (any spin of). >=20 > Agreed. >=20 > > More generally, in all networking scenarios there MUST be two things > present: > > - a true TOS layer network that interfaces (via suitable > adaptations) > > with the suite of external message/file/stream applications out there > > - a true BOS layer network that modulates an EM wave on either > > metallic/radio/fibre media...else we can't sent information (from the > ultimate > > always-present TOS external message/file/stream applications noted > above) over > > geographic distance. So here we must have a binary<=3D>q'ary symbol > lexicon > > mapping (which itself is a client/server relationship BTW). >=20 > Agreed >=20 > > MPLS in any guise is neither of these things...it sits between them. > It is > > for sure not a transport network, as this must be able to perform a > true BOS > > role. MPLS always requires a real transport network under that can > perform > > this role. >=20 > Agreed. >=20 > But the "real transport network" MPLS sits on may be (and typically is) > just > a link. It doesn't have to be a network (in the sense of being > something > with more than two nodes and with some form of switching capability). NH=3D> This may or may not be true. We should not make a statement that it= is usually not networked....indeed it is often more efficient to 'switch' = at the lower layer in large traffic aggregates of the client in the core of= the network(s). A link (1-hop) in layer N is created by an E2E path (>=3D= 1hop) in layer N+1 (ie towards the duct layer network direction). That low= er layer network may or may not be owned by the same party as the higher la= yer network. It often won't have the same geographic span. It may or may = not be the same network mode as the client.....there is always a space reso= urce layer network at the very BOS. A couple of observations one can make here are these: - one needs to minimise the number of layer networks from true TOS to true = BOS...this obviously affects cost/complexity/reliability/perf/etc...so we s= hould remove all unnecessary layer networks. Aside=3D> MS PWs should not e= xist in MPLS-TP....PWs are of course an artefact of the loss of source info= rmation created by merging in LDP, but making them *MS* just generates an u= nnecessary layer network that really should have no place in MPLS-TP. - ...however the answer is for sure not one do-it-all layer network...that = view leads to increasing diseconomies of scale/scope. - similarly, one cannot have a do-it-all common CP (or indeed any DP/CP fun= ctional component) running TOS to BOS.=20 regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 >=20 > > So the whole discussion about an MPLS 'section layer' is somewhat > > moot/meaningless IMO. MPLS (any spin) simply has a lowest LSP > level...below > > that come the real transport layer networks. >=20 > Agreed. >=20 > Giles >=20 > > regards, Neil > > This email contains BT information, which may be privileged or > confidential. > > It's meant only for the individual(s) or entity named above. If > you're not the > > intended > > recipient, note that disclosing, copying, distributing or using this > > information > > is prohibited. If you've received this email in error, please let me > know > > immediately > > on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Greg > > Mirsky > > Sent: 26 July 2011 21:34 > > To: David Allan I > > Cc: mpls@ietf.org > > Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency > in > > section definitions? > > > > Hi Dave, Daniel, and All, > > I'd like to start from Section MEP ID as defined in MPLS-TP ID > document. I > > think that there should not be distinction in Section MEP ID whether > it is > > Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 > LSP). I > > think that making MEP ID of Logical Section identical to MEP ID of > Server > > layer LSP MEP ID creates issues with properly executing PM OAM on > Section > > layer and Server layer LSP. > > > > Regards, > > Greg > > On Tue, Jul 26, 2011 at 12:52 PM, David Allan I > > > > wrote: > > HI Daniel: > > > > We have a bit of an inconsistency creeping in in numerous places.... > > > > By the definition of a section as any (sub) layer "minus one" path > component, > > then a section can be a physical link for an SPME or LSP, an SPME for > a LSP, > > an LSP for a PW etc. > > > > So to invent terms to facilitate this discussion we have a physical > section > > (non-MPLS link) and a logical section (some MPLS path construct) > > > > Which means we have established procedures for configuring OAM for > any logical > > section, but as Greg Mirsky noted today, not for a physical section, > at least > > not ones we'd necessarily want to use. We have MEP identifiers > specific to a > > physical section in the identifiers draft what we would not use for > logical > > sections as we really do not need multiple identities for maintenance > entity > > components. I'm sure we have a few other places where this small > dichotomy > > raises its head. > > > > Nor do we want to confuse physical sections with logical sections.... > > > > Hence if we are to resolve some of this without revisiting > established RFCs we > > need to introduce some distinction to further define section "types" > along the > > lines I've suggested above (physcial and logical)... and apply it > across the > > current document set. > > > > WDYT? > > Dave > > > > > > > > ________________________________ > > From: mpls-bounces@ietf.org > > [mailto:mpls-bounces@ietf.org] On > Behalf Of > > Daniel Cohn > > Sent: Tuesday, July 26, 2011 1:55 PM > > To: mpls@ietf.org > > Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in > section > > definitions? > > Hi, > > > > In several places in draft-ietf-mpls-tp-oam-framework-10, it is > assumed and > > sometimes explicitly stated that an MPLS-TP section is equivalent to > a > > non-MPLS-TP link (aka data link). > > > > See for example (there's more): > > "MPLS-TP Section: As defined in [8], it is a link that can be > traversed by > > one or more MPLS-TP LSPs." > > "in case of an MPLS-TP section, the MEG is inferred from the port on > which an > > OAM packet was received with the GAL at the top of the label stack" > > "An SMEG is intended to be deployed for applications where it is > preferable to > > monitor the link between topologically adjacent..." > > > > However, as per RFC 5654 and especially RFC5960 > > (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section > can also > > be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP > carrying a > > PW. > > > > If my understanding is correct, the section OAM requirements in > > draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link > sections > > (n=3D0 following RFC 5960 terminology). In this case, this should be > clarified > > in the draft. > > > > Comments? > > > > Regards, > > > > Daniel > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 From DanielC@orckit.com Wed Jul 27 05:04:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0484621F8B8D for ; Wed, 27 Jul 2011 05:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAlL5PAvHxZt for ; Wed, 27 Jul 2011 05:04:28 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id E71A321F8B8C for ; Wed, 27 Jul 2011 05:04:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C55.B4C014A2" Date: Wed, 27 Jul 2011 15:04:19 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED80E5@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxMDUM7r5Ge1GD2RuWpfw85JEO7ZQARvmBw References: <44F4E579A764584EA9BDFD07D0CA081306ED7FC4@tlvmail1><60C093A41B5E45409A19D42CF7786DFD52215D4FAC@EUSAACMS0703.eamcs.ericsson.se><44F4E579A764584EA9BDFD07D0CA081306ED7FCB@tlvmail1> From: "Daniel Cohn" To: "Greg Mirsky" Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:04:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C55.B4C014A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I agree with your first sentence, why don't we meet face to face and talk it over, assisted by paper and ink? How about today right after MPLS session (15:00), right outside the MPLS room (206B)? =20 Daniel =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Tuesday, July 26, 2011 11:27 PM To: Daniel Cohn Cc: David Allan I; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? =20 Hi Daniel, I feel that I need to use slideware as "a picture is worth a thousand words". But will give it a try nevertheless. I'm looking at layered networks a bit more in the way ITU-T decomposes functions. From that point, I think, Section OAM should not be aware of whether monitored construct is physical or logical link. It is a Section that is identified by Node ID and IF ID (note that IF ID itself is not necessarily ID of a physical port but of a logical circuit, e.g. VLAN). Thus, what we refer as Logical Section can be characterized, I beli On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn wrote: Hi Greg, =20 I'm afraid I don't follow you. A logical section *is* an LSP. So why wouldn't we use the identifiers we defined for LSP? Can you ellaborate on the PM OAM problems you mention? =20 Thanks, =20 Daniel =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Tuesday, July 26, 2011 4:34 PM To: David Allan I Cc: Daniel Cohn; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? =20 Hi Dave, Daniel, and All, I'd like to start from Section MEP ID as defined in MPLS-TP ID document. I think that there should not be distinction in Section MEP ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 LSP). I think that making MEP ID of Logical Section identical to MEP ID of Server layer LSP MEP ID creates issues with properly executing PM OAM on Section layer and Server layer LSP. Regards, Greg On Tue, Jul 26, 2011 at 12:52 PM, David Allan I wrote: HI Daniel: =20 We have a bit of an inconsistency creeping in in numerous places.... =20 By the definition of a section as any (sub) layer "minus one" path component, then a section can be a physical link for an SPME or LSP, an SPME for a LSP, an LSP for a PW etc. =20 So to invent terms to facilitate this discussion we have a physical section (non-MPLS link) and a logical section (some MPLS path construct) =20 Which means we have established procedures for configuring OAM for any logical section, but as Greg Mirsky noted today, not for a physical section, at least not ones we'd necessarily want to use. We have MEP identifiers specific to a physical section in the identifiers draft what we would not use for logical sections as we really do not need multiple identities for maintenance entity components. I'm sure we have a few other places where this small dichotomy raises its head. =20 Nor do we want to confuse physical sections with logical sections.... =20 Hence if we are to resolve some of this without revisiting established RFCs we need to introduce some distinction to further define section "types" along the lines I've suggested above (physcial and logical)... and apply it across the current document set. =20 WDYT? Dave =20 =20 =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, July 26, 2011 1:55 PM To: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Hi, =20 In several places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and sometimes explicitly stated that an MPLS-TP section is equivalent to a non-MPLS-TP link (aka data link). =20 See for example (there's more): "MPLS-TP Section: As defined in [8], it is a link that can be traversed by one or more MPLS-TP LSPs." "in case of an MPLS-TP section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack"=20 "An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent..." =20 However, as per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section can also be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP carrying a PW.=20 =20 If my understanding is correct, the section OAM requirements in draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.=20 =20 Comments? =20 Regards, =20 Daniel =20 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 =20 ------_=_NextPart_001_01CC4C55.B4C014A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I agree with your first sentence, why don’t we meet face to = face and talk it over, assisted by paper and = ink?

How about today right after MPLS session (15:00), right outside the = MPLS room (206B)?

 

Daniel

 

From:= = Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, = July 26, 2011 11:27 PM
To: Daniel Cohn
Cc: David = Allan I; mpls@ietf.org
Subject: Re: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

 

Hi Daniel,
I feel that I need to use = slideware as "a picture is worth a thousand words". But will = give it a try nevertheless.
I'm looking at layered networks a bit = more in the way ITU-T decomposes functions. From that point, I think, = Section OAM should not be aware of whether monitored construct is = physical or logical link. It is a Section that is identified by Node ID = and IF ID (note that IF ID itself is not necessarily ID of a physical = port but of a logical circuit, e.g. VLAN). Thus, what we refer as = Logical Section can be characterized, I beli

On Tue, Jul 26, 2011 at 4:24 PM, Daniel Cohn <DanielC@orckit.com> = wrote:

Hi = Greg,

 

I’m afraid I don’t = follow you. A logical section *is* an LSP. So why wouldn’t we use = the identifiers we defined for LSP? Can you ellaborate on the PM OAM = problems you mention?

 

Thanks,

 

Daniel

 

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, = July 26, 2011 4:34 PM
To: David Allan I
Cc: Daniel = Cohn; mpls@ietf.org
Subject: Re: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

 <= /o:p>

Hi Dave, Daniel, = and All,
I'd like to start from Section MEP ID as defined in MPLS-TP = ID document. I think that there should not be distinction in Section MEP = ID whether it is Physical Section (Layer 0 for MPLS-TP) or Logical = Section (Layer n-1 LSP).  I think that making MEP ID of Logical = Section identical to MEP ID of Server layer LSP MEP ID creates issues = with properly executing PM OAM on Section layer and Server layer = LSP.

Regards,
Greg

On Tue, Jul = 26, 2011 at 12:52 PM, David Allan I <david.i.allan@ericsson.com> = wrote:

HI Daniel:

 <= /o:p>

We have a bit of an inconsistency = creeping in in numerous places....

 <= /o:p>

By the definition of a = section as any (sub) layer "minus one" path component, then a = section can be a physical link for an SPME or LSP, an SPME for a LSP, an = LSP for a PW etc.

 <= /o:p>

So to invent terms to facilitate = this discussion we have a physical section (non-MPLS link) and a logical = section (some MPLS path construct)

 <= /o:p>

Which means we have established = procedures for configuring OAM for any logical section, but as Greg = Mirsky noted today, not for a physical section, at least not ones we'd = necessarily want to use. We have MEP identifiers specific to a physical = section in the identifiers draft what we would not use for logical = sections as we really do not need multiple identities = for maintenance entity components. I'm sure we have a few other = places where this small dichotomy raises its = head.

 <= /o:p>

Nor do we want to confuse physical = sections with logical sections....

 <= /o:p>

Hence if we are to resolve some of = this without revisiting established RFCs we need to introduce some = distinction to further define section "types" along the lines = I've suggested above (physcial and logical)... and apply it across the = current document set.

 <= /o:p>

WDYT?

Dave

 <= /o:p>

 <= /o:p>

 <= /o:p>

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel = Cohn
Sent: Tuesday, July 26, 2011 1:55 PM
To: mpls@ietf.org
Subject: [mpls] = draft-ietf-mpls-tp-oam-framework - inconsistency in section = definitions?

Hi,

 <= /o:p>

In several = places in draft-ietf-mpls-tp-oam-framework-10, it is assumed and = sometimes explicitly stated that an MPLS-TP section is equivalent to a = non-MPLS-TP link (aka data link).

 <= /o:p>

See for = example (there’s more):

“MPLS-= TP Section: As defined in [8], it is a link that can be  traversed = by one or more MPLS-TP LSPs.”

“in = case of an MPLS-TP section, the MEG is inferred from the port on which = an OAM packet was received with the GAL at the top of the label = stack”

“An = SMEG is intended to be deployed for applications where it is preferable = to monitor the link between topologically = adjacent…”

 <= /o:p>

However, as = per RFC 5654 and especially RFC5960 (http://tools.ietf.org/html/rfc5960#section-3.2), = an MPLS-TP section can also be an LSP carrying another LSP (SPME or = generic H-LSP), or an LSP carrying a PW.

 <= /o:p>

If my = understanding is correct, the section OAM requirements in = draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link = sections (n=3D0 following RFC 5960 terminology). In this case, this = should be clarified in the draft.

 <= /o:p>

Comments?

 <= /o:p>

Regards,

 <= /o:p>

Daniel<= /o:p>

 <= /o:p>

 <= /o:p>


______________= _________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 <= /o:p>

 

------_=_NextPart_001_01CC4C55.B4C014A2-- From pabloisnot@gmail.com Wed Jul 27 06:36:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46E021F8678 for ; Wed, 27 Jul 2011 06:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ullMWeCJF5X for ; Wed, 27 Jul 2011 06:36:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A56521F863E for ; Wed, 27 Jul 2011 06:36:25 -0700 (PDT) Received: by qwc23 with SMTP id 23so1062999qwc.31 for ; Wed, 27 Jul 2011 06:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=SsKSWa+RU27Sd4YxzCY3YHu3+Qf5r8O1gArh7clpxMA=; b=FaXO3McU22n22F7LqzwffDkofRfnjFshjzA4FshkdTjRq8RwUFk0JVsQyiNVkySG6h 3kKwxToEsxOLQpB9jbY6c/9r6SRYOl1CTH5ondxRon46Q0nOFChrqkSG8SIqS5GeH3o9 SB3duu3bHMc4eLt41PrO4tnWzZZXcBOo3wU8k= MIME-Version: 1.0 Received: by 10.224.203.131 with SMTP id fi3mr17766qab.381.1311773784977; Wed, 27 Jul 2011 06:36:24 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Wed, 27 Jul 2011 06:36:24 -0700 (PDT) Date: Wed, 27 Jul 2011 09:36:24 -0400 Message-ID: From: Pablo Frank To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf300512c27ab1f604a90d2245 Subject: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:36:26 -0000 --20cf300512c27ab1f604a90d2245 Content-Type: text/plain; charset=ISO-8859-1 There was a question raised in monday's WG meeting as to whether there was a strong use-case for m:n protection. A related question was whether m:n has been standardized in the OTN / SONET world. After we consulted our OTN experts back at the ranch, the general consensus is that while 1+1 and 1:n are well standardized by the ITU-T, m:n is typically left for further study. There are proprietary solutions, including our own, but they don't seem to be widely deployed. I didn't get a specific m:n use-case. I suspect that any m:n use-case is probably better handled with shared-mesh protection anyway. It seems that m:n shows up in all the standards, mainly for theoretical completeness, but never ends up being specified. Based on this, I don't think we should slow-down the current 1:n standardization effort by requiring the authors to embark on an m:n science project. Pablo Frank Ciena --20cf300512c27ab1f604a90d2245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There was a question raised in monday's WG meeting as to whether there = was a strong use-case for m:n protection. =A0A related question was whether= m:n has been standardized in the OTN / SONET world. =A0After we consulted = our OTN experts back at the ranch, the general consensus is that while 1+1 = and 1:n are well standardized by the ITU-T, m:n is typically left for furth= er study. =A0There are proprietary solutions, including our own, but they d= on't seem to be widely deployed. =A0I didn't get a specific m:n use= -case. =A0I suspect that any m:n use-case is probably better handled with s= hared-mesh protection anyway.

It seems that m:n shows up in all the standards, mainly for = theoretical completeness, but never ends up being specified.

=
Based on this, I don't think we should slow-down the current= 1:n standardization effort by requiring the authors to embark on an m:n sc= ience project.

Pablo Frank
Ciena=A0

--20cf300512c27ab1f604a90d2245-- From david.i.allan@ericsson.com Wed Jul 27 07:09:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5721F8B22; Wed, 27 Jul 2011 07:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-WgWkoxCdM; Wed, 27 Jul 2011 07:09:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8421F8B1D; Wed, 27 Jul 2011 07:09:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6RE8DIE017563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2011 09:09:01 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 10:08:44 -0400 From: David Allan I To: "pwe3@ietf.org" Date: Wed, 27 Jul 2011 10:08:43 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLw== Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:09:04 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI
 
During yesterday's PWE session the subject of GALs and PWs came up.
 
To reiterate my concern, it was that the use of the GAL for a PW in a = network that could employ ECMP rendered the OAM useless. For some strange r= eason this is permitted in RFC 5586, while use of the GAL for a PW in an MP= LS-TP network is not (where the explicit prohibition against ECMP means it COULD be safely used), huh!???
 
My belief is that permitting the use of the GAL for PWs in both domain= s will result in MS-PWs for which the OAM is useless. FM PM, and DM will re= turn false indications due to the lack of fate sharing… so different = latency, out of order delivery of PM loss measurement, and potential false positives, or negatives for FM.
 
My conclusion was that IF steps were being taken such that reserved la= bels (or at least the GAL) were explicitly excluded from ECMP processing TH= EN it would make sense to open Pandora's box. During the meeting it was sug= gested this was the case in work progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion to things continuing on their merry way.
 
So I went and read the current version of the entropy label draft and = unfortunately this is only true in a narrow sense. Fate sharing would only = be preserved for implementations that ONLY hashed the bottom label of a PW = using the entropy label. Not for any generic use of the GAL with PWs.
 
So not only do I now believe the problem not on it’s way to reso= lution, IMO the scenario is actually GETTING WORSE. We are now permitting t= he GAL to be other than bottom label to address a narrow case and only a sm= all portion of RFC 4928. I would now assert that allowing the GAL to be other than the bottom label is a worse and inco= mplete solution vs. excluding label 13 from ECMP processing and is perpetua= ting a bad situation.
 
So t'was my bad for rolling over yesterday without doing my homework, = but there you have it
 
Dave
 
BTW If I could make a suggestion, if we are XORing one or more labels = together prior to doing further processing, also XOR it with 13, and make t= he GAL the ONE label value that has no effect. It would do the world a huge= favor.
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_-- From c-sai@bx.jp.nec.com Wed Jul 27 07:46:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3221F8B0C for ; Wed, 27 Jul 2011 07:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1UlH-1nHJkW for ; Wed, 27 Jul 2011 07:46:29 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1C21F859C for ; Wed, 27 Jul 2011 07:46:25 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6REkG6B020981; Wed, 27 Jul 2011 23:46:16 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6REkGr22287; Wed, 27 Jul 2011 23:46:16 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6REkGkJ025634; Wed, 27 Jul 2011 23:46:16 +0900 (JST) Received: from kameyata.jp.nec.com ([10.26.220.29] [10.26.220.29]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-74793; Wed, 27 Jul 2011 23:45:40 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTPA id BT-MMP-71278; Wed, 27 Jul 2011 23:45:39 +0900 From: "Zhenlong Cui" To: "'Sam Aldrin'" , "'Eric Gray'" References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> <5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com> Date: Wed, 27 Jul 2011 23:45:38 +0900 Message-ID: <9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com> Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:46:30 -0000 Hi Sam and Eric, Ok, I understand that the issue of unknown TLVs is outside the scope of this document. > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > 1) Which return code to send when source/destination identifiersare wrong or drop the request. > As said above, it should be dropped, if the source is unknown. OK, I think this is clear now: - A responder will drop requests from an unknown source. - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.) > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > Return code 5, dsmap mismatch. This is already defined in rfc4379. Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below. The information collected MUST include identifiers related to the nodes and interfaces composing that route. I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity, therefore they should have the same behavior in the responder. So, my suggestions regarding these issues are as follows. 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV. Best, Zhenlong > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Wednesday, July 27, 2011 6:29 AM > To: Zhenlong Cui > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft. > Having said that, please find responses inline. > > Sam > > Sent from my iPad > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: > > > Hi Eric, > > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem > with > > responding. > > On the other hand, you say that you should send a reply when the request includes an unknown TLV. > > > Unknown source is not same as receiving malformed Tlv or unsupported tlv. > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers. > > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does > the responder > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it? > If received from unknown source, most vendors drop the packet. > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > 1) Which return code to send when source/destination identifiers are wrong or drop the request. > As said above, it should be dropped, if the source is unknown. > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > Best, > > Zhenlong > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Wednesday, July 27, 2011 12:56 AM > >> To: Zhenlong Cui > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > >> > >> Zhenlong, > >> > >> Q-1: See RFC 4379, where these regitry entries are derived from. > >> RFC 4379 sets up a number of registries - including the TLV > >> registry - and defines explicitly how to handle unknown TLV > >> types in section 3, in two very obscure paragraphs on page > >> 10, just before section 3.1. > >> > >> Q-2: "ingress port" is not correct - thanks for spotting this > >> cut-and-paste duplication error. > >> > >> -- > >> Eric > >> > >> -----Original Message----- > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > >> Sent: Tuesday, July 12, 2011 5:20 AM > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > >> > >> Dear Authors, > >> > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > >> > >> Question 1: > >>>>> Which return code to send when identifiers are wrong (Malformed echo > >>>>> request received?) or drop the packet. > >>>>> > >>>>> EG > Drop the packet, probably log the error, possibly run off > >>>>> EG > screaming into the night. What does one do when one gets > >>>>> EG > something either not recognizably intended for one, or not > >>>>> EG > from a source that one recognizes? From a security point > >>>>> EG > of view, we cannot require an implementation to reply to > >>>>> EG > the requester in this case (this is an attack vector for > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > >>>>> > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One > >> or > >> more of the TLVs was not understood)? Can this way two answers be generated? > >> > >> > >> Question 2: > >> In section 2.1.1, Is below("ingress port") correct? > >> > >> Egress IF_Num identifies the ingress port on the target node. A > >> value of 0 indicates that the port is not part of the identifier. > >> > >> > >> Best, > >> zhenlong > >> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > >>> Sent: Monday, June 27, 2011 8:04 PM > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > >>> > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > >>> > >>> Types are defined below; Length is the length of the Value field in > >>> octets. The Value field depends on the Type; it is zero padded to > >>> align to a 4-octet boundary. > >>> > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is > determined > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your > argument > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information > >> is > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure > >> of > >>> each TLV to extract the value instead of applying the simple rule above. > >>> > >>> > >>> Best, > >>> > >>> Rolf > >>> > >>> > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > >>> > >>> > >>>> -----Original Message----- > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> Sent: Montag, 27. Juni 2011 12:42 > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > >>>> cv@tools.ietf.org > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > >>>> cv > >>>> > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > >>>> an errata? > >>>> > >>>> TLVs are meant to follow each other, where the beginning of the > >>>> next TLV is determined by the length of the current TLV - hence > >>>> it is not correct to specify any content as having any value at > >>>> all if it is beyond the end of the TLV. > >>>> > >>>> -----Original Message----- > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> Sent: Monday, June 27, 2011 5:06 AM > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > >>>> cv@tools.ietf.org > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > >>>> cv > >>>> Importance: High > >>>> > >>>> Hi Eric, > >>>> > >>>> just one more to follow up. You say: > >>>> > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > >>>>> EG > even if the last two octets "Must be Zero"). The length of > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > >>>> > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > >>>> included in the length of the sub-TLVs. Why are they included here? > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>>> London W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>>> > >>>>> EG > Apparently. > >>>>> > >>>>> Which return code to send when identifiers are wrong (Malformed echo > >>>>> request received?) or drop the packet. > >>>>> > >>>>> EG > Drop the packet, probably log the error, possibly run off > >>>>> EG > screaming into the night. What does one do when one gets > >>>>> EG > something either not recognizably intended for one, or not > >>>>> EG > from a source that one recognizes? From a security point > >>>>> EG > of view, we cannot require an implementation to reply to > >>>>> EG > the requester in this case (this is an attack vector for > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > >>>>> > >>>>> Using the per-interface model and say the DSMAP TLV did not match the > >>>>> ingress IF identifier, then should this request frame be dropped? > >>>>> Should we reply to the requestor? Can this way two answers be > >>>>> generated? > >>>>> > >>>>> Nit (section 2.1): s/mpls/MPLS/ > >>>>> > >>>>> EG > Thanks. > >>>>> > >>>>> > >>>>> Best, > >>>>> > >>>>> > >>>>> > >>>>> Rolf > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>>>> London W3 6BL | Registered in England 2832014 > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>> Behalf > >>>>> Of > >>>>>> Loa Andersson > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > >>>>> Ross > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > >>>> cv > >>>>>> > >>>>>> Working Group. > >>>>>> > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > >>>>>> after wg last call and published version -04 of the document. > >>>>>> > >>>>>> A document detailing how the comments have been addressed will be > >>>>>> found at: > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > >>>>>> > >>>>>> This is to start a working group call to verify that all comments > >>>>>> been adequately addressed. Please send your comments to the > >>>>>> mpls working group mailing list before June 24th. > >>>>>> > >>>>>> Loa > >>>>>> on behalf of the MPLS wg co-chairs > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> Loa Andersson email: > >>>>> loa.andersson@ericsson.com > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>> +46 767 72 92 13 > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Wed Jul 27 08:45:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9288221F857E for ; Wed, 27 Jul 2011 08:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SULHY2b+GdRd for ; Wed, 27 Jul 2011 08:45:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31021F855A for ; Wed, 27 Jul 2011 08:45:32 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RFjKAc024608; Wed, 27 Jul 2011 10:45:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 11:45:22 -0400 From: Eric Gray To: Zhenlong Cui , "'Sam Aldrin'" Date: Wed, 27 Jul 2011 11:45:20 -0400 Thread-Topic: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQAAIYSLA= Message-ID: References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> <5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com> <9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> In-Reply-To: <9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:45:33 -0000 Not sure why you think the protocol redundancy is necessary, or even a good idea. The DSMAP TLV as defined allows specification of an interface. Asking for a potentially new TLV that will also provide this information in the event that one is unable to handle, read or interpret the DSMAP TLV is pointless. If one cannot use one TLV, the chances are very good that one cannot use a newer one either.=20 -----Original Message----- From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com]=20 Sent: Wednesday, July 27, 2011 10:46 AM To: 'Sam Aldrin'; Eric Gray Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Importance: High Hi Sam and Eric, Ok, I understand that the issue of unknown TLVs is outside the scope of thi= s document. > > Lastly, I suggest that add some mention to this draft regarding respond= er's behavior for new TLV. > > 1) Which return code to send when source/destination identifiersare wro= ng or drop the request. > As said above, it should be dropped, if the source is unknown. OK, I think this is clear now: - A responder will drop requests from an unknown source. - A responder will drop requests in case of destination identifier mismatch= . (as defined in section 4.2.3.) > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP= TLV are wrong or drop the request. > Return code 5, dsmap mismatch. This is already defined in rfc4379. Regarding the identifiers of nodes and interfaces for route trace which are= defined in RFC 5860 as below. The information collected MUST include identifiers related to the nodes and= interfaces composing that route. I think "destination node identifier" and "destination interface identifier= " are composed for one maintenance entity, therefore they should have the same behavior in the responder. So, my suggestions regarding these issues are as follows. 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. 2) If not, the "interface identifier" should be included in the Destination= identifier TLV, or one might define a new TLV. Best, Zhenlong > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Wednesday, July 27, 2011 6:29 AM > To: Zhenlong Cui > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.= org > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 >=20 > As Eric said in earlier email, these questions are more related to RFC437= 9 and not just this draft. > Having said that, please find responses inline. >=20 > Sam >=20 > Sent from my iPad >=20 > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: >=20 > > Hi Eric, > > > > I remember you said earlier that you should drop the packet from unknow= n source nodes, because there is a security problem > with > > responding. > > On the other hand, you say that you should send a reply when the reques= t includes an unknown TLV. > > > Unknown source is not same as receiving malformed Tlv or unsupported tlv. > > I think if the responder receives a request it checks the type of the T= LV before it checks the identifiers. > > > > So, my question is "if the responder receives a request from an unknown= source node that includes an unknown TLV, does > the responder > > have to reply to the unknown source node?". If yes, this has the securi= ty problem you mentioned earlier, doesn't it? > If received from unknown source, most vendors drop the packet. > > > > > > Lastly, I suggest that add some mention to this draft regarding respond= er's behavior for new TLV. > > 1) Which return code to send when source/destination identifiers are wr= ong or drop the request. > As said above, it should be dropped, if the source is unknown. > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP= TLV are wrong or drop the request. > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > Best, > > Zhenlong > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Wednesday, July 27, 2011 12:56 AM > >> To: Zhenlong Cui > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > >> > >> Zhenlong, > >> > >> Q-1: See RFC 4379, where these regitry entries are derived from. > >> RFC 4379 sets up a number of registries - including the TLV > >> registry - and defines explicitly how to handle unknown TLV > >> types in section 3, in two very obscure paragraphs on page > >> 10, just before section 3.1. > >> > >> Q-2: "ingress port" is not correct - thanks for spotting this > >> cut-and-paste duplication error. > >> > >> -- > >> Eric > >> > >> -----Original Message----- > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > >> Sent: Tuesday, July 12, 2011 5:20 AM > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > >> > >> Dear Authors, > >> > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > >> > >> Question 1: > >>>>> Which return code to send when identifiers are wrong (Malformed ech= o > >>>>> request received?) or drop the packet. > >>>>> > >>>>> EG > Drop the packet, probably log the error, possibly run off > >>>>> EG > screaming into the night. What does one do when one gets > >>>>> EG > something either not recognizably intended for one, or not > >>>>> EG > from a source that one recognizes? From a security point > >>>>> EG > of view, we cannot require an implementation to reply to > >>>>> EG > the requester in this case (this is an attack vector for > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > >>>>> > >> If the "type" of identifier TLV is incorrect, then should this request= frame be dropped? Should we reply to the requestor(One > >> or > >> more of the TLVs was not understood)? Can this way two answers be gene= rated? > >> > >> > >> Question 2: > >> In section 2.1.1, Is below("ingress port") correct? > >> > >> Egress IF_Num identifies the ingress port on the target node. A > >> value of 0 indicates that the port is not part of the identifier. > >> > >> > >> Best, > >> zhenlong > >> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Rolf Winter > >>> Sent: Monday, June 27, 2011 8:04 PM > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.i= etf.org > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand= -cv > >>> > >>> I think that's OK, since the value is not beyond but within the TLV. = Taken from 4379: > >>> > >>> Types are defined below; Length is the length of the Value field in > >>> octets. The Value field depends on the Type; it is zero padded to > >>> align to a 4-octet boundary. > >>> > >>> That means the length is the length of the actual value (excluding th= e padding). So the beginning of the next TLV is > determined > >>> by the length plus a value that makes it align on a 4-octet boundary = (which of course can be 0). I cannot follow your > argument > >>> why this is not correct. I am sure I am missing something trivial, so= sorry for spamming the list. But all information > >> is > >>> encoded in the packet (plus the simple rule quoted above). Otherwise,= a node needs to understand the internal structure > >> of > >>> each TLV to extract the value instead of applying the simple rule abo= ve. > >>> > >>> > >>> Best, > >>> > >>> Rolf > >>> > >>> > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, L= ondon W3 6BL | Registered in England 2832014 > >>> > >>> > >>>> -----Original Message----- > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> Sent: Montag, 27. Juni 2011 12:42 > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > >>>> cv@tools.ietf.org > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-deman= d- > >>>> cv > >>>> > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > >>>> an errata? > >>>> > >>>> TLVs are meant to follow each other, where the beginning of the > >>>> next TLV is determined by the length of the current TLV - hence > >>>> it is not correct to specify any content as having any value at > >>>> all if it is beyond the end of the TLV. > >>>> > >>>> -----Original Message----- > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> Sent: Monday, June 27, 2011 5:06 AM > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > >>>> cv@tools.ietf.org > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-deman= d- > >>>> cv > >>>> Importance: High > >>>> > >>>> Hi Eric, > >>>> > >>>> just one more to follow up. You say: > >>>> > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > >>>>> EG > even if the last two octets "Must be Zero"). The length of > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > >>>> > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > >>>> included in the length of the sub-TLVs. Why are they included here? > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>>> London W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>>> > >>>>> EG > Apparently. > >>>>> > >>>>> Which return code to send when identifiers are wrong (Malformed ech= o > >>>>> request received?) or drop the packet. > >>>>> > >>>>> EG > Drop the packet, probably log the error, possibly run off > >>>>> EG > screaming into the night. What does one do when one gets > >>>>> EG > something either not recognizably intended for one, or not > >>>>> EG > from a source that one recognizes? From a security point > >>>>> EG > of view, we cannot require an implementation to reply to > >>>>> EG > the requester in this case (this is an attack vector for > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > >>>>> > >>>>> Using the per-interface model and say the DSMAP TLV did not match t= he > >>>>> ingress IF identifier, then should this request frame be dropped? > >>>>> Should we reply to the requestor? Can this way two answers be > >>>>> generated? > >>>>> > >>>>> Nit (section 2.1): s/mpls/MPLS/ > >>>>> > >>>>> EG > Thanks. > >>>>> > >>>>> > >>>>> Best, > >>>>> > >>>>> > >>>>> > >>>>> Rolf > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>>>> London W3 6BL | Registered in England 2832014 > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>> Behalf > >>>>> Of > >>>>>> Loa Andersson > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > >>>>> Ross > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > >>>> cv > >>>>>> > >>>>>> Working Group. > >>>>>> > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > >>>>>> after wg last call and published version -04 of the document. > >>>>>> > >>>>>> A document detailing how the comments have been addressed will be > >>>>>> found at: > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > >>>>>> > >>>>>> This is to start a working group call to verify that all comments > >>>>>> been adequately addressed. Please send your comments to the > >>>>>> mpls working group mailing list before June 24th. > >>>>>> > >>>>>> Loa > >>>>>> on behalf of the MPLS wg co-chairs > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> Loa Andersson email: > >>>>> loa.andersson@ericsson.com > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>> +46 767 72 92 13 > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From bwijnen@ripe.net Tue Jul 12 07:34:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC721F86FA; Tue, 12 Jul 2011 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Hoy0GO1seU; Tue, 12 Jul 2011 07:34:59 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id E205721F86E6; Tue, 12 Jul 2011 07:34:58 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qge30-0002o0-Ov; Tue, 12 Jul 2011 16:34:51 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qge30-0000Hi-7X; Tue, 12 Jul 2011 16:34:50 +0200 Message-ID: <4E1C5B89.8070904@ripe.net> From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: stbryant@cisco.com, eosborne@cisco.com, nurit.sprecher@nsn.com, annamaria.fulignoli@ericsson.com, yaacov.weingarten@nsn.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ef351bc8f404fc29977233100005de3ce X-Mailman-Approved-At: Wed, 27 Jul 2011 08:50:35 -0700 Cc: mpls@ietf.org, ops-dir@ietf.org, Dan Romascanu Subject: [mpls] OPSDIR review of draft-ietf-mpls-tp-linear-protection-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 12 Jul 2011 14:35:00 -0000 X-Original-Date: Tue, 12 Jul 2011 16:34:49 +0200 X-List-Received-Date: Tue, 12 Jul 2011 14:35:00 -0000 [note that I am not on the MPLS WG mailing list, so cc me explicitly if you want me to see any reactions/responses. I am on the ops-dir list though). Hi, I was asked to do an ops-dir review of document draft-ietf-mpls-tp-linear-protection-07.txt. I think the document is in good shape. From an operations and management point of view I have these comments: There is one operational aspect mentioned in section 4.1, namely: The frequency of the three rapid messages and the separate frequency of the continual transmission SHOULD be configurable by the operator. For protection switching within 50ms, it is RECOMMENDED that the default interval of the first three PSC messages SHOULD be no larger than 3.3ms. The subsequent messages SHOULD be continuously transmitted with an interval of 5 seconds. It might be good to explain the rationale for the RECOMMENDED intervals. And maybe some explanation as to what considerations need to be taken into account when configuring these values. has the WG considered to standardize the configurability of these frequencies? Or is it left (intentionally?) to each implementation how this is done? Can an operator (or an NMS) easily see what the values are at the various LERs? Bert Wijnen From prvs=0176ad012b=medel@globetel.com.ph Wed Jul 13 20:28:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10B21F8BE9; Wed, 13 Jul 2011 20:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KUNsBCbvVob; Wed, 13 Jul 2011 20:28:04 -0700 (PDT) Received: from smtp02.globetel.com.ph (smtp02.globetel.com.ph [203.177.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0A43C21F8BE6; Wed, 13 Jul 2011 20:28:03 -0700 (PDT) Received: from exgtbh02.globetel.com ([10.225.208.154]) by smtp02.globetel.com.ph (8.14.4/8.14.4) with ESMTP id p6E3M2QU011163; Thu, 14 Jul 2011 11:22:02 +0800 Received: from EXVSGT02.globetel.com ([10.225.208.145]) by exgtbh02.globetel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 11:28:00 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC41D6.083C424B" Date: Thu, 14 Jul 2011 11:28:00 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard Thread-Index: AcxB0NKcS4oTg/PkTlS6nVs+/iJYxQABNEaw X-Priority: 1 Priority: Urgent Importance: high References: <24102355.3308421310589129962.JavaMail.defaultUser@defaultHost> From: "GT RAMIREZ, Medel G." To: X-OriginalArrivalTime: 14 Jul 2011 03:28:00.0998 (UTC) FILETIME=[08996860:01CC41D6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-14_02:2011-07-14, 2011-07-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107130233 X-Mailman-Approved-At: Wed, 27 Jul 2011 08:50:35 -0700 Cc: ietf@ietf.org, IETF-Announce , mpls@ietf.org Subject: Re: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 03:28:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC41D6.083C424B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Erminio Hi, I belong to an Operator, I strongly agree with Greg. =20 Regards Medel ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, July 14, 2011 10:50 AM To: erminio.ottone_69@libero.it Cc: mpls@ietf.org; IETF-Announce; ietf@ietf.org Subject: Re: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard =20 Dear Erminio, even though I'm not an operator but I think that you've went bit too far in your first generalization. "Every generalization is wrong, including this one" Regards, Greg On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone_69@libero.it wrote: The technical concern raised during the WG poll has not been resolved so the history definetely matters. Quoting RFC5921: There are thus two objectives for MPLS-TP: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. 2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks. Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1. The fact that the solution in this draft is not backward compatible with existing IP/MPLS BFD implementations means that this solution is also uselesee in case 2. Are there other undocumented use cases for MPLS-TP deployments? >----Messaggio originale---- >Da: nurit.sprecher@nsn.com >Data: 7-lug-2011 11.59 >A: , , , "IETF-Announce" >Cc: >Ogg: RE: [mpls] R: Re: LastCall: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard > >Erminio, >I do not think the history is relevant for this specific discussion... >Also I find it inappropriate to give statements with no justifications >behind. >You say: "the solution in this draft is useless for many MPLS-TP >deployments.". in order to seriously consider your comment, you have to >show why it is useless and which requirements are not satisfied. >Otherwise you cannot expect anyone to refer to your point. >Best regards, >Nurit > >P.s. did you mean that the document is useless to available non-standard >deployments, e.g. T-MPLS? > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately. ------_=_NextPart_001_01CC41D6.083C424B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

Erminio Hi,

I belong to an Operator, I strongly ag= ree with Greg.

 

Regards

Medel

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, July 14, 2011 10:50 AM
To: erminio.ottone_69@libero= .it
Cc: mpls@ietf.org; IETF-Anno= unce; ietf@ietf.org
Subject: Re: [mpls] R: RE: R= : Re: LastCall: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivi= ty Verification, Continuity Check and Remote Defect indicationfor MPLS Transpo= rt Profile) to Proposed Standard

 

Dear Erminio,
even though I'm not an operator but I think that you've went bit too far in your first generalization.
"Every generalization is wrong, including this one"

Regards,
Greg

On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone_69@libero.it= <erminio.ottone_69@libero.it= > wrote:

The technical concern raised during the WG poll has not been resolv= ed so the
history definetely matters.

Quoting RFC5921:

  There are thus two objectives for MPLS-TP:

  1.  To enable MPLS to be deployed in a transport network and operated
      in a similar manner to existing transport technologies= .

  2.  To enable MPLS to support packet transport services with a<= br>       similar degree of predictability to that found in exis= ting
      transport networks.

Based on the extensive comments provided by transport operators and ITU-T community, the solution in this draft is useless in case 1.

The fact that the solution in this draft is not backward compatible with
existing IP/MPLS BFD implementations means that this solution is also usele= see
in case 2.

Are there other undocumented use cases for MPLS-TP deployments?

>----Messaggio originale----
>Da: nurit.sprecher@nsn.com
>Data: 7-lug-2011 11.59
>A: <erminio.ottone_69= @libero.it>, <RCosta@ptinovacao.pt>, &= lt;ietf@ietf.org>,

"IETF-Announce"<ietf-announce@ietf.org>

>Cc: <mpls@ietf.org><= br> >Ogg: RE: [mpls] R: Re: LastCall:       &lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt&gt;

(Proactive      Connectivity    Verification,Continuity Check and Remote Defect

indicationfor   MPLS    Transport     &nbs= p; Profile) to Proposed Standard

>
>Erminio,
>I do not think the history is relevant for this specific discussion...<= br> >Also I find it inappropriate to give statements with no justifications<= br> >behind.
>You say: "the solution in this draft is useless for many MPLS-TP >deployments.".  in order to seriously consider your comment, = you have to
>show why it is useless and which requirements are not satisfied.
>Otherwise you cannot expect anyone to refer to your point.
>Best regards,
>Nurit
>
>P.s. did you mean that the document is useless to available non-standar= d
>deployments, e.g. T-MPLS?
>
>

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

 

This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately.
------_=_NextPart_001_01CC41D6.083C424B-- From tfl@psp.co.uk Thu Jul 14 08:45:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6CF21F8C19; Thu, 14 Jul 2011 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mae8MIibsuAr; Thu, 14 Jul 2011 08:45:01 -0700 (PDT) Received: from mail140.messagelabs.com (mail140.messagelabs.com [85.158.137.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F421F8C0D; Thu, 14 Jul 2011 08:45:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tfl@psp.co.uk X-Msg-Ref: server-13.tower-140.messagelabs.com!1310658281!32788904!44 X-StarScan-Version: 6.2.17; banners=psp.co.uk,-,- X-Originating-IP: [217.28.130.38] Received: (qmail 17214 invoked from network); 14 Jul 2011 15:44:58 -0000 Received: from hostedexchange.hostedservice.com (HELO outlook.hostedservice2.net) (217.28.130.38) by server-13.tower-140.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2011 15:44:58 -0000 Received: from THHS2E12BE2X.hostedservice2.net ([fe80:0000:0000:0000:e841:4ed5:117.193.90.34]) by thhs2e12ht02.hostedservice2.net ([192.168.16.112]) with mapi; Thu, 14 Jul 2011 16:45:07 +0100 From: Thomas Lee To: David Allan I , "erminio.ottone_69@libero.it" , "loa@pi.nu" , Rui Costa Date: Thu, 14 Jul 2011 16:44:55 +0100 Thread-Topic: RE: [mpls] R: Re: Last Call: and SPAM Thread-Index: AcxCPPpOu5rYNxG5SGG+fYF8Fkr+eg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 27 Jul 2011 08:50:35 -0700 Subject: Re: [mpls] R: Re: Last Call: and SPAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:45:02 -0000 guys - does EVERYONE need to see this - I've removed some of the list alia= ses to bcc - please be careful when you REPLY all -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.or= g] On Behalf Of David Allan I Sent: Wednesday, July 13, 2011 11:24 PM To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote De= fect indication for MPLS Transport Profile) to Proposed Standard HI Erminio: The comments that were raised during the day long discussion with the edit= ors at the SG15 plenary resulted in those comments appearing in the liasio= n IMO in an actionable form and resulted in a constructive outcome. I enjo= yed that level of cooperation. The comments that were punted over the wall with no discussion (depsite re= quests to allocate meeting time to do so) in some cases were sufficiently = vague as to have no constructive value or not have a recognizable issue to= be addressed. A request to have the commenters identified in the liaison so that comment= s that were unclear could be followed up upon by the editors was refused. = Apparently that is not done and I would go so far as to suggest that blank= et of anonymity diminished the quality of the liaison. The result of this= process was that the only recourse to go "what does this mean?" was a com= plete liaison cycle. For some comments, stomaching a multi-month delay to = clarify what the actual issue was that resulted in a comment like "describ= e the start-up procedure" was not reasonable, especially given SG15s conti= nual complaint on how slow the IETF was. Such comments had to be weighed a= gainst the nature of comments from the larger reviewing community that see= med to have no issue with the completeness of the document content and per= haps had actually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the li= aison was "clarify the raising/clearing of defects as well as any conseque= nt actions" which I can only interpret as section 3.7 of the document not = having been read. E.g. the TOC is: 3.7.1. Session initiation and Modification=0913 3.7.2. Defect entry criteria=09=09=09=0913 3.7.3. Defect entry consequent action=09=0914 3.7.4. Defect exit criteria=09=09=09=0915 3.7.5. State machines=09=09=09=09=0915 ...and if there was a deficiency in the descriptions it was not identified= , and we're not mind readers. So that is both the history and why some comments were rejected. If you ca= n suggest a constructive way to proceed that is not simply a waste of ever= yone's time, I'll listen.. Cheers Dave -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; loa@pi.nu; Rui Costa Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Def= ect indication for MPLS Transport Profile) to Proposed Standard Do you mean that ITU-T comments were discussed and resolution agreed durin= g the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agr= eed resolution? Why some ITU-T comments have been then rejected? >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 6-lug-2011 19.35 >A: "erminio.ottone_69@libero.it", "loa@pi.nu= " , "Rui Costa" >Cc: "mpls@ietf.org", "ietf@ietf.org", >"IETF- Announce" >Ogg: RE: [mpls] R: Re: Last Call:=09<draft-ietf-mpls-tp-cc-cv-rdi-05.t= xt>=09 (Proactive Connectivity=09Verification, Continuity Check and Remote Defect= =20 indication for=09MPLS=09Transport=09Profile) to Proposed Standard > >Hi Erminio: > >Two of the three document editors were present at SG15 plenary in=20 >February where the comments originated. The revised meeting schedule resulted in a = day spent going through the document with the editors. IMO there were lots= of discussion and legitimate issues with the document identified and corr= ected so it was a useful session. The liaison of same was in many ways *af= ter the fact*. > >Cheers >Dave > _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email _______= _______________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ From prvs=0182900c8f=medel@globetel.com.ph Tue Jul 19 18:11:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF411E8099 for ; Tue, 19 Jul 2011 18:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpNa4yy2VIKn for ; Tue, 19 Jul 2011 18:11:56 -0700 (PDT) Received: from smtp01.globetel.com.ph (smtp01.globetel.com.ph [203.177.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id F10E411E809B for ; Tue, 19 Jul 2011 18:11:54 -0700 (PDT) Received: from exgtbh02.globetel.com ([10.225.208.154]) by smtp01.globetel.com.ph (8.14.4/8.14.4) with ESMTP id p6K1BVJb027564; Wed, 20 Jul 2011 09:11:32 +0800 Received: from EXVSGT02.globetel.com ([10.225.208.145]) by exgtbh02.globetel.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 09:11:49 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4679.F67CEFF3" Date: Wed, 20 Jul 2011 09:11:32 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGcJlNrU73XoaQQuTuMMHqoR0wwAYCkFg X-Priority: 1 Priority: Urgent Importance: high References: From: "GT RAMIREZ, Medel G." To: "Bocci, Matthew (Matthew)" X-OriginalArrivalTime: 20 Jul 2011 01:11:49.0673 (UTC) FILETIME=[0096A990:01CC467A] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-19_05:2011-07-19, 2011-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107190235 X-Mailman-Approved-At: Wed, 27 Jul 2011 08:50:35 -0700 Cc: mpls@ietf.org Subject: Re: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 01:11:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4679.F67CEFF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Support ! =20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Tuesday, July 19, 2011 9:43 PM To: mpls@ietf.org Subject: [mpls] FW: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt =20 We have just started a poll of the PWE3 mailing list for PWE3 WG adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant to MPLS-TP. =20 Please send any comments to the PWE3 mailing list. =20 Best regards =20 Matthew =20 On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" wrote: =20 This email begins a poll of the list to see if there is consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group draft. =09=20 Please indicate whether or not you support adoption of this draft, and send any comments to the PWE3 list. =09=20 This poll ends on Tuesday 9th August. =09=20 Regards, =09=20 Matthew and Andy. This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately. ------_=_NextPart_001_01CC4679.F67CEFF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

Support !

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Tuesday, July 19, 2011= 9:43 PM
To: mpls@ietf.org
Subject: [mpls] FW: [PWE3] W= G Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt

 

We have just sta= rted a poll of the PWE3 mailing list for PWE3 WG adoption of draft-martini-pwe3-status-aggregation-protocol-03.txt, which is relevant to MPLS-TP.

 

Please send any comments to the PWE3 mailing list.

 

Best regards

 

Matthew

 

On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" <mat= thew.bocci@alcatel-lucent.com> wrote:

 

This email begin= s a poll of the list to see if there is consensus to adopt draft-martini-p= we3-status-aggregation-protocol-03.txt as a PWE3 working group draft.

 

Please indicate whether or not you support adoption of this draft, and send any comments to= the PWE3 list.

 

This poll ends on Tuesday 9th August.

 

Regards,

 

Matthew and Andy= .

This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately.
------_=_NextPart_001_01CC4679.F67CEFF3-- From joelja@bogus.com Thu Jul 14 13:15:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7911E8087; Thu, 14 Jul 2011 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHmGJeYrWyxY; Thu, 14 Jul 2011 13:15:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C0EDE11E8079; Thu, 14 Jul 2011 13:15:01 -0700 (PDT) Received: from [172.16.24.53] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6EKF0Wj039329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2011 20:15:00 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Joel Jaeggli In-Reply-To: <5E893DB832F57341992548CDBB333163A0A92C535B@EMBX01-HQ.jnpr.net> Date: Thu, 14 Jul 2011 13:14:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4323DAB4-3BCC-434F-98EF-515FCA9381DC@bogus.com> References: <29155895.3316791310591053994.JavaMail.defaultUser@defaultHost> <5E893DB832F57341992548CDBB333163A0A92C535B@EMBX01-HQ.jnpr.net> To: IETF discussion list , mpls@ietf.org X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Jul 2011 20:15:00 +0000 (UTC) X-Mailman-Approved-At: Wed, 27 Jul 2011 08:51:59 -0700 Subject: Re: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 20:15:02 -0000 To the extent that this particular debate (that of the nature scope and = success or failure of the liaison effort) has been going on for some = time: * it's not going to be resolved. * rehashing the history of how we came to this point it advances what = agenda? It would seems timely in the IETF last call to focus the line of = criticism on the merits or lack thereof of the draft as it stands, not = on how we arrived here. joel From kpfleming@digium.com Thu Jul 14 08:50:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8925821F8CA6; Thu, 14 Jul 2011 08:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44uzHDiCWYtd; Thu, 14 Jul 2011 08:49:59 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 80D3921F8C9B; Thu, 14 Jul 2011 08:49:59 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QhOAm-0000GR-4M; Thu, 14 Jul 2011 10:49:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 2409CD8024; Thu, 14 Jul 2011 10:49:56 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COmIhJibR-Wp; Thu, 14 Jul 2011 10:49:51 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 963B9D82A3; Thu, 14 Jul 2011 10:49:51 -0500 (CDT) Message-ID: <4E1F101E.5070007@digium.com> Date: Thu, 14 Jul 2011 10:49:50 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Greg Mirsky References: <947166.3310311310589521384.JavaMail.defaultUser@defaultHost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Jul 2011 08:52:42 -0700 Cc: "mpls@ietf.org" , "ietf@ietf.org" , IETF-Announce , Stewart Bryant Subject: Re: [mpls] R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:50:04 -0000 On 07/13/2011 09:57 PM, Greg Mirsky wrote: > Dear Erminio, > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is > even more narrow then of the document being discussed. The G.8113.1 > addresses only bi-directional co-routed LSP and has no model to handle > bi-directional associated LSP in independent mode. And unidirectional > p2p and p2mp LSPs are not addressed by the current revision of the G.8113.1. > Can all these out-of-scope constructs be used to conclude that G.8113.1 > is not capable to solve these issues? I don't think so. Solutions are > not readily available, that's all. Can you guys all drop the ietf-announce list from this thread, please? This list is not for technical discussions. Thanks. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From jdrake@juniper.net Wed Jul 27 08:59:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E085611E80BF; Wed, 27 Jul 2011 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMXMUEYMuK5P; Wed, 27 Jul 2011 08:59:22 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 485AD11E80E8; Wed, 27 Jul 2011 08:59:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTjA11i0KJ1n1dYs84A4Mwy9NJUocY7Yj@postini.com; Wed, 27 Jul 2011 08:59:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 27 Jul 2011 08:56:21 -0700 From: John E Drake To: David Allan I , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 08:56:19 -0700 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFg Message-ID: <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:59:25 -0000 --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

<= p class=3DMsoNormal>A previous version of the Entropy Label draft st= ipulated that reserved labels were not to be input to a transit node’= s load balancing function;  this was inadvertently dropped from the cu= rrent version but will be re-added to the next version.  I am thinking= that a bis version of Stewart’s ECMP considerations RFC that also sp= ecifies this behavior would be the appropriate place to codify this once an= d for all.

 

Thanks,

 

John

 

Sent from my iPhone=

 

From: pwe3-bounces@ietf.org [mailto:p= we3-bounces@ietf.org] On Behalf Of David Allan I
Sent: Wed= nesday, July 27, 2011 7:09 AM
To: pwe3@ietf.org
Cc: mpl= s@ietf.org
Subject: [PWE3] Entropy labels and the GAL....

 

HI

 =

During yesterday's PWE session the subjec= t of GALs and PWs came up.

&nbs= p;

To reiterate my concern, it = was that the use of the GAL for a PW in a network that could employ ECMP re= ndered the OAM useless. For some strange reason this is permitted in RFC 55= 86, while use of the GAL for a PW in an MPLS-TP network is not (where the e= xplicit prohibition against ECMP means it COULD be safely used), huh!???

 

My belief is that permitting the use of the GAL for PWs i= n both domains will result in MS-PWs for which the OAM is useless. FM PM, a= nd DM will return false indications due to the lack of fate sharing… = so different latency, out of order delivery of PM loss measurement, and pot= ential false positives, or negatives for FM.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>My conclus= ion was that IF steps were being taken such that reserved labels (or at lea= st the GAL) were explicitly excluded from ECMP processing THEN it would mak= e sense to open Pandora's box. During the meeting it was suggested this was= the case in work progressing in draft-ietf-mpls-entropy-label-00 and so I = withdrew my objection to things continuing on their merry way.

 

So I went and read the current version of the entropy label draft a= nd unfortunately this is only true in a narrow sense. Fate sharing would on= ly be preserved for implementations that ONLY hashed the bottom label of a = PW using the entropy label. Not for any generic use of the GAL with PWs.

 

So not only do I now believe the problem not on it’= s way to resolution, IMO the scenario is actually GETTING WORSE. We are now= permitting the GAL to be other than bottom label to address a narrow case = and only a small portion of RFC 4928. I would now assert that allowing the = GAL to be other than the bottom label is a worse and incomplete solution vs= . excluding label 13 from ECMP processing and is perpetuating a bad situati= on.

 

So t'was my bad for rolling over yesterday without = doing my homework, but there you have it

 

Dave

 

<= p class=3DMsoNormal>BTW If I could make a suggestion, if we are XORing one or more l= abels together prior to doing further processing, also XOR it with 13, and = make the GAL the ONE label value that has no effect. It would do the world = a huge favor.

 =

 

 

= --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_-- From eric.gray@ericsson.com Wed Jul 27 09:19:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECDE11E80AD for ; Wed, 27 Jul 2011 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFyOj59-DfnA for ; Wed, 27 Jul 2011 09:19:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9511E808E for ; Wed, 27 Jul 2011 09:19:12 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RGJA0a032014 for ; Wed, 27 Jul 2011 11:19:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 27 Jul 2011 12:19:05 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 27 Jul 2011 12:19:03 -0400 Thread-Topic: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 Thread-Index: AQI12X/8bGAt9w/aSv3piPWpQrmG1JP0TZwQgDjqQqA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:19:13 -0000 Forwarding in plain text, now with 'unmunging' (R)... ________________________________ From: Daniel King [mailto:daniel@olddog.co.uk] Sent: Tuesday, June 21, 2011 6:50 AM To: Eric Gray Cc: mpls@ietf.org; draft-ietf-mpls-tp-mib-management-overview@tools.ietf.or= g Subject: RE: Last Call review of draft-ietf-mpls-tp-mib-management-overview= -04 Hi Eric, Thanks for taking the time to review the draft thoroughly. As usual, a grea= t review. We will issue a new version of the draft at the end of the LC perio= d to address your, and any other, comments. We will then follow-up up with yo= u to make sure your points have been addressed. Br, Dan. From: Eric Gray [mailto:eric.gray@ericsson.com] Sent: 20 June 2011 19:12 To: draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org Cc: mpls@ietf.org Subject: Last Call review of draft-ietf-mpls-tp-mib-management-overview-04 This is my comments on this version for WG Last Call. This is generally a very useful piece of work. Most of my comments are related to front matter (prior to section 4 where most of the "meat" of the draft starts), or in other text which has probably not received recent revi= ew. This review is for the draft located at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mib-management-overview-04 Comments/Questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract: Why use "would be required" to describe additional MIB modules? Are they required, or does the requirement hinge on some other dependency? Introduction: Second paragraph: s/responsibility of the modules/responsibility for the mo= dules/ Third paragraph: Why do you explicitly refer to the GMPLS control plane, wh= en it is clearly the case that a transport path may be PW-based and PW signaling = is based on LDP? And, once the signaling context is expanded to include any f= orm of MPLS signaling, why limit the context of this paragraph to MPLS-TP? Any= LSP or PW can be statically provisioned. Fourth paragraph: instead of "architecture for MPLS-TP" we should say "arch= itecture for MPLS, as extended for MPLS-TP" - because there is not (AFAIK) intended = to be any restriction in the applicability of this management architecture to jus= t MPLS-TP. Also in the fourth paragraph, please break the first sentence into two part= s. And, we again say "would be required", implying in this specific context "if any= one, anywhere, ever even thinks they might use SNMP for the management interface= ." Does it seem likely that this will not be the case? Section 1.1: First paragraph: There is a problem with the two phrases "the MPLS-TP netw= orks" and "its client networks" (this can happen when using too many such phrases= in a sentence). As I understand the sentence (based on how it is now written), = it means to say: "MPLS-TP network management is inseparable from client network management s= o that the same management approach can be used regardless of the client." Once I think I have teased out the meaning of this sentence, I find that it= is wrong. Instead of being "inseparable", it should be "separable" or "independent" (= since the intent appears to be to allow MPLS-TP network to be managed independent of = the way that client networks are managed). Also in the first paragraph, "management functions ... includes" should be = either "management functions ... include", or "management function ... includes" (= given the opening of the next paragraph, I suspect the latter choice is more appr= opriate). Second paragraph: the first sentence in this paragraph needs work. Is the = purpose of the management function to provide control, monitoring and procedures (w= here control and monitoring applies to protocol mechanisms, and procedures appli= es to building blocks for ...) or is it to provide control and monitoring of both= protocol mechanisms and procedures? Also, assuming that a "profile" is supposed to = be a subset, why do we need "building blocks" for a transport profile of MPLS? Again, this is the problem with viewing MPLS-TP as separate from MPLS. We'= ve defined extensions to MPLS, such that we can define a transport profile. B= uilding blocks in this case are these extensions and apply to MPLS generally, even = though added to MPLS to allow definition of a transport profile. Section 2: PW terminology references are conspicuously missing from this se= ction. Minimally, the PWE3 architecture (RFC 3985) should be included here. Section 4.2.3: This section provides a doubtful description of a Label Edge= Router. Unfortunately, I am not aware of any RFC or other draft that defines this c= oncept. It is certainly not explicitly defined in any of the RFCs listed in section= 2 (where a list of RFCs is provided for terminology sources) - though it is used in = at least one of them. I suggest that you provide a definition "for the purposes of this document"= in the Terminology section. From a management perspective, your description is ve= ry convenient. In general, however, an LER typically provides either ingress = to, or egress from, an LSP. Since LSPs may be hierarchical, it is not even clear = that an LER will necessarily be mapping a network layer header (directly) to an = FTN (the mapping may be implied by any of a set of labels that each map to a su= bset of the intended FEC). >From a management perspective, the simple description you use is sufficient= , if not necessarily complete. It should be clear, however, that you are not de= fining the term LER to generally mean what you have in this section, since that wo= uld likely provoke some person - at some later time - to ask "well, what do we = call a device that is an egress to LSPs?" Section 4.2.5: This section provides a doubtful (if intuitive) description = of an Label Switched Path. Part of the problem is that "MPLS domain" is a bit ne= bulous. An LSP begins where a set of one or more labels is prepended to a previousl= y existing network layer or MPLS label header (thus forming, or adding to, a = label stack). The LSP continues through an arbitrary number of 0 or more LSRs wh= ere a top-of-stack label is swapped for the appropriate corresponding downstream = label. Finally, the LSP ends at the LSP egress (which will either be where the las= t label in the set is removed, or at the next LSR after this last label is removed = - if PHP is used and the LSR removing the label is the penultimate hop). At any LSR= along the LSP, the local view of an LSP comprises eitehr an FTN or an ILM (which = - for management purposes is represented by in-segment and out-segment mappings). The issue with the description you provide is that 1) it is more than just = the path taken (many LSPs may follow the same path) and 2) any LSP may be carri= ed in another LSP, which itself may not traverse the entire MPLS domain. Label Switched Path is defined in very explicit and precise detail in RFC 3= 031. Section 4.2.6: In the first paragraph, why is there a line break between "layered" and "mo= dular"? Section 4.2.8: First paragraph - This sentence/paragraph needs work. Possibly it should st= art "The purpose of MPLS resiliency is ..." Also, "no interruption" seems hard= ly to be likely - perhaps "minimal interruption"? Section 4.2.10: There are problems with the dependency chart in this section. First, it is= not too obvious how to resolve dependencies where lines intersect. After some = trouble, I realized that your use of arrows going into the intersection seems to mea= n that a dependency is one way. So - for example - that means - MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB etc. - but not the other way around (nor is there - for example - a direct depende= ncy between MPLS-FTN-STD-MIB and MPLS-LDP-GENERIC-STD-MIB). This notation is broken when it comes to the relationship between the follo= wing: MPLS-TE-STD-MIB and ... GMPLS-LSR-STD-MIB and ... GMPLS-TE-STD-MIB and ... PW-MPLS-STD-MIB and ... These look like they may all be dependent on both MPLS-LSR-STD-MIB and MPLS-FTN-STD-MIB - probably because of a missing arrow on the left side (pointing right) of an intersection where these all come together (although= you might argue that the absence of an arrow pointing left on the dashed-line g= oing left from this intersection means that the dependency doesn't go that way). I wonder if this chart might not be simplified somewhat by taking out indir= ect (or implicit) dependencies. For example (if I am reading this right), MPLS-LDP-GENERIC-STD-MIB ---> MPLS-LDP-STD-MIB, MPLS-FTN-STD-MIB ---> MPLS-TE-STD-MIB and MPLS-LDP-STD-MIB ---> MPLS-LSR-STD-MIB, MPLS-TE-STD-MIB ---> MPLS-LSR-STD-MIB and MPLS-LSR-STD-MIB ---> MPLS-TC-STD-MIB, means you could remove the dependencies: MPLS-FTN-STD-MIB ---> MPLS-LDP-STD-MIB (eliminating the above issue) MPLS-LDP-STD-MIB ---> MPLS-TC-STD-MIB MPLS-LDP-GENERIC-STD-MIB --> MPLS-TC-STD-MIB MPLS-FTN-STD-MIB ---> MPLS-TC-STD-MIB MPLS-TE-STD-MIB ---> MPLS-TC-STD-MIB These dependencies are implied by the dependencies above. Section 5: First paragraph, "sub sections" should probably be hyphenated. Also, there= 's something not-quite right about the sentence. Reading the section, it's th= e sub-sections of this section that focus on gaps in the current set of MPLS = MIB modules. Also, if "its" subsitutes for MPLS MIB modules, "its use" should b= e "their use." Lastly, restating an earlier comment, MPLS-TP is not an exten= sion of MPLS, it's a profile of MPLS as extended. I suggest re-wording the sent= ence as follows: "The below sub-sections of this section focus on possible gaps in existing = MPLS MIB modules in order to determine extensions or additional MIB modules that= are required to support MPLS-TP in MPLS networks." Second paragraph, why is there a line-break between "of" and "equipment"? Third paragraph, why is there a line-break between "for" and "MPLS-TP"? Fifth paragraph, either "Operations" should be "the Operations", or "functi= on" should be "functions" in the first sentence. Sixth paragraph, "seperate ..." should be "separate ..." section 5.1.1: The first sentence is actually two separate sentences joined by a comma. I= t should just be two separate sentences. Also, why is there a line-break bef= ore "for" in the second line of the first paragraph? The first sub-bullets under each of the two major bullets in this section s= hould include a reference to the identifiers draft (for Global_ID, Node_ID and t= unnel LSR identifier). I believe the intention is that "tunnel LSR identifier" s= hould be "Tunnel_ID"; if that is not correct, what does it mean? section 5.1.2: It is not obvious how the recommendations in this section address the issue of all missing identifiers mentioned in the preceding section. Which bulle= t is intended to address the missing tunnel identfier based on ICC? Section 5.2.1: Again there is a mssing reference to the identifiers draft. Rather than add= (or repeat) these references, perhaps it would be better if a general statement about identifiers was made in the lead-in text for section 5, along with cu= rrent references to various MIB documents, management and OAM requirements and framework documents, etc. Note that the first mention of the identifiers draft does not occur in this section until sub-section 5.6.1 (even though material from this draft is ne= eded earlier). Section 5.4.1: MIB-based management of exclusively on-demand OAM functions does not make as much sense as for other OAM functions. In particualr, Route Tracing does not seem to be an OAM function for which MIB-based management will make any sense. Some reasons why: 1) most MIBs today are essentially read-only. Thus it is unlikely that a R= oute trace would be invokable via a MIB . 2) the results of a route-trace would be difficult to represent in a MIB. 3) a Route-Trace is very unlikely to be an ongoing activity that would need= to be monitored over any significant period of time. As near as I can tell, this is the only listed OAM function which is extrem= ely unlikely to be used in proactive OAM and - therefore - does not make sense as a MIB function. Section 6: Second paragraph - "must be suppor in" should be "must be supported in" Also, same paragraph - "need tbe conformed to" should be "need to be complied with" Section 6: Either there is a convention being employed here that I am not aware of, or the phrase "New X" is being used in some way that is not transparent. At several points in this section phrases like "new textual convention mib module" and "New Identifiers" are used as if they are names of existing documents, that already accomplish some goal described in susequent text. If the intention is to refer to a task that is as yet to be accomplished by a new document, then the status of the task in question is not that it has been done already, and the phrase should be prefixed with "a" (or "A" if it occurs at the beginning of the sentence). If these are names of a set of documents, then these are very unfortunate names. Section 6.1.2: First paragraph - should "mib module" be "MIB module"? Second paragraph - is there already a "new textual convention mib [SIC] module" or are we getting ahead of ourselves in saying that a "textual convention representing the MEP identifier is defined in new textual convention mib [SIC] module"? Same paragraph - "... identify maintenance ... should be "... identify a maintenance ..." Section 6.1.3: I cannot be certain what this section says without understanding what the convention ("New X") means, if anything. Minimally, either the sentence should start "A New identifier identifies a new managed ...", "New identifiers identify new managed ...", or "New Identifiers describes managed ..." Section 6.1.4: Second paragraph - "corouted" should be "co-routed"... Section 6.1.5: Second paragraph - "much similar" should be "very similar", or just "simila= r"; Also, is this MIB (MPLS-TE-STD-MIB) already extended (as the text implies), or does it need to be extended? Same paragraph - "could be" should be "are either" (they MUST be one or the other, which is not what "could be X or Y" means). Section 7 (Management Options): Second paragraph - "refer" should be "refer to"... Section 9 (IANA Considerations): This is inconsistent with text earlier in the draft. For example, in secti= on 6.1.1, 6.2.1, 6.3.1 and 6.4.1, there is the statement that OIDs for MIB mod= ules are yet to be assigned and managed by IANA. I think this is intended as a general statement, as it does not seem that t= his document actually specifies any particular OIDs that would need to be assig= ned by IANA (or, if it does, I did not pick up on it). However, this document = seems to be making the point - possibly as a reminder - that the MIBs recommended= by this draft will require OID assignments from IANA. I suggest saying something to this effect in the IANA considerations sectio= n and adding that there is no IANA action required specifically by this document.= You might easily modify the first two paragraphs in section 8 (Security Considerations) for this purpose in Section 9. You must do something to remove the current ambiguity, as it is not clear t= hat you are not requesting specific OIDs for the - as yet to be specified - new objects in the OID trees in sections 6.1.1, 6.2.1, 6.3.1 and 6.4.1. From eric.gray@ericsson.com Wed Jul 27 09:21:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40CF11E8099 for ; Wed, 27 Jul 2011 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.064 X-Spam-Level: X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-2.268, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T8c7eP0xwf1 for ; Wed, 27 Jul 2011 09:21:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC811E80AD for ; Wed, 27 Jul 2011 09:21:13 -0700 (PDT) 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 p6RGLCFO032515 for ; Wed, 27 Jul 2011 11:21:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 12:21:07 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 27 Jul 2011 12:21:06 -0400 Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAAI39/AAoPt2UAaxh/Hg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:21:16 -0000 IEZvcndhcmRlZCBpbiBwbGFpbiB0ZXh0Li4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkZyb206IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gW21haWx0bzph bGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXRdDQpTZW50OiBUaHVyc2RheSwg SnVuZSAyMywgMjAxMSAxMToyMyBBTQ0KVG86IERhbmllbCBDb2huDQpDYzogbXBsc0BpZXRmLm9y ZzsgcHdlM0BpZXRmLm9yZzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0ZS5jb20u Y24NClN1YmplY3Q6IFI6IFtQV0UzXSBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtVFAgTGluZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQoNCkRl YXIgRGFuaWVsLA0KDQptYW55IHRoYW5rcyBmb3IgYnJpbmdpbmcgdG8gb3VyIGF0dGVudGlvbiB0 aGlzIGlzc3VlLg0KDQoNCg0KSXQgbWFrZXMgc2Vuc2UgZm9yIG1lIGhhdmluZyB0aGUgc2FtZSBs aW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGFwcGxpZWQgYXQgYm90aCBMU1AgYW5kIFBXIGxl dmVsIChpbiB0aGUgTVBMUy1UUCBmcmFtZXdvcmspLg0KDQoNCg0KSXQgaXMgb2J2aW91cyB0aGF0 IHRoZXJlIGFyZSBjaXJjdW1zdGFuY2VzIHdoZXJlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtcyBj YW4gYmUgZXhwbG9pdGVkIGJlY2F1c2UgdGhleSBjb3ZlciB0aGUgcmVxdWlyZW1lbnRzIG9mIGNl cnRhaW4gYXJjaGl0ZWN0dXJhbCBhcHByb2FjaGVzDQoNCmJ1dCBJIGRvIG5vdCBiZWxpZXZlIGl0 IGNhbiBiZSBjbGFpbWVkIHRoYXQgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc21zIGNvdmVyIHRoZSBz YW1lIHJlcXVpcmVtZW50cyAgY292ZXJlZCBieSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20u IFRoZXJlZm9yZSB0aGVyZSBpcyBhIGdhcCB0aGF0IG5lZWQgdG8gYmUgZmlsbGVkIGFuZCBleHRl bmRpbmcgdGhlIGFscmVhZHkgZGVmaW5lZCBsaW5lYXIgcHJvdGVjdGlvbiBmb3IgTFNQcyBzZWVt cyB0aGUgbW9zdCBhcHByb3ByaWF0ZSB3YXkgdG8gcHJvY2VlZC4NCg0KDQoNCkFjdHVhbGx5LCBJ IGRvIG5vdCBzZWUgYW55IGFyZ3VtZW50IGJlbG93IGNvbmZ1dGluZyB5b3VyIGh5cG90aGVzaXMg YW5kIHRoZXJlZm9yZSBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbC4NCg0KDQoNCkJlc3QgcmVnYXJk cywNCg0KQWxlc3NhbmRybw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbGVjb20gSXRhbGlhDQpBbGVzc2FuZHJv IEQnQWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24NClZpYSBSZWlzcyBSb21vbGksIDI3 NCAtIDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDExIDIyOCA1ODg3DQptb2JpbGU6ICszOSAz MzUgNzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2MzkgMDcNCg0KDQoNCkRhOiBwd2UzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBE YW5pZWwgQ29obg0KSW52aWF0bzogbHVuZWSorCAyMCBnaXVnbm8gMjAxMSAxMTo1MQ0KQTogQWxl eGFuZGVyIFZhaW5zaHRlaW47IG1hLnl1eGlhQHp0ZS5jb20uY24NCkNjOiBtcGxzQGlldGYub3Jn OyBwd2UzQGlldGYub3JnDQpPZ2dldHRvOiBSZTogW1BXRTNdIFttcGxzXSBTZWVraW5nIGZlZWRi YWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1T LVBXIg0KDQoNCg0KU2FzaGEsDQoNCg0KDQpJIHRoaW5rIHRoZSBtYWluIHF1ZXN0aW9uIGhlcmUg aXMgd2h5IGNhbGwgUFcgbGluZWFyIHByb3RlY3Rpb24gYW4gYWQtaG9jIG1lY2hhbmlzbSB3aGVu IGl0oa9zIHNpbXBseSBhbiBleHRlbnNpb24gb2YgTFNQIGxpbmVhciBwcm90ZWN0aW9uLiBGcm9t IGFuIGltcGxlbWVudGF0aW9uIHBvaW50IG9mIHZpZXcsIHRoZSBkaWZmZXJlbmNlcyBhcmUgbWlu aW1hbCCoQyB5b3UgY291bGQgZXZlbiBzYXkgc2VtYW50aWMuIEkgdGhpbmsgdGhpcyBpcyB3aGF0 IE1hIG1lYW5zIGJ5IHNpbXBsaWNpdHkgYW5kIEkgd2hvbGx5IGFncmVlIHdpdGggaGVyIKhDIHlv dSBoYXZlIGEgc2luZ2xlIG1lY2hhbmlzbSB0byBwcm90ZWN0IGFsbCB0cmFuc3BvcnQgcGF0aHMg qEMgYmUgdGhlbSBMU1Agb3IgUFcuDQoNCg0KDQpNeSB0d28gY2VudHMsDQoNCg0KDQpEQw0KDQoN Cg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAyMCwgMjAxMSAxMTo1MCBBTQ0KVG86 IG1hLnl1eGlhQHp0ZS5jb20uY24NCkNjOiBEYW5pZWwgQ29objsgbXBsc0BpZXRmLm9yZzsgU3By ZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBwd2UzQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMt VFAgTGluZWFyIFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQoNCkRlYXIg TWEsDQoNCkxvdHMgb2YgdGhhbmtzIGZvciBvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUgc29tZSBj b21tZW50cy9hbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KDQoNClJlZ2FyZHMsDQoNCiAgICAgU2Fz aGENCg0KDQoNCkZyb206IG1hLnl1eGlhQHp0ZS5jb20uY24gW21haWx0bzptYS55dXhpYUB6dGUu Y29tLmNuXQ0KU2VudDogTW9uZGF5LCBKdW5lIDIwLCAyMDExIDExOjMxIEFNDQpUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW4NCkNjOiBEYW5pZWwgQ29objsgbXBsc0BpZXRmLm9yZzsgU3ByZWNoZXIs IE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiC0 8Li0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUExp bmVhclByb3RlY3Rpb25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KDQoNCg0KDQpIaSBTYXNoYSwN Cg0KIkxpbmVhciBwcm90ZWN0aW9uIiBpcyBkaWZmZXJlbnQgZnJvbSAiTXVsdGktaG9tZWQgQ0Ug cmVkdW5kYW5jeSIgYW5kIGhhcyBubyByZWZlcmVuY2Ugd2l0aCBBQy4NCg0KW1tbU2FzaGFdXV0g QWJzb2x1dGVseS4NCg0KDQpXb3JraW5nIHBhdGgocykgYW5kIHByb3RlY3Rpb24gcGF0aChzKSBo YXZlIHNhbWUgc291cmNlIGFuZCBzaW5rIGVuZHBvaW50cyBpbiBsaW5lYXIgcHJvdGVjdGlvbiB0 eXBlLg0KDQpbW1tTYXNoYV1dXSBPZiBjb3Vyc2UuDQoNCg0KDQpJTUhPLCBXaGVuIFMtUEUgZmFp bHMsIGl0IGlzIG1vcmUgc2ltcGxlIHRvIHVzZSAiTGluZWFyIHByb3RlY3Rpb24iIHRvIHByb3Rl Y3QgaXQuDQoNCltbW1Nhc2hhXV1dIFdlbGwsIHNpbXBsaWNpdHkgLCBsaWtlIGJlYXV0eSwgaXMg aW4gdGhlIGV5ZSBvZiB0aGUgYmVob2xkZXJKLg0KDQpCdXQgSU1ITyAgaW50cm9kdWNpbmcgbXVs dGlwbGUgc2ltcGxlIGFkIGhvYyBzb2x1dGlvbnMgKGVhY2ggZm9yIGl0cyBzcGVjaWZpYyBjYXNl KSBhbmQgbWFpbnRhaW5pbmcgdGhlbSAgZXZlbnR1YWxseSBtYWtlIHlvdXIgbGlmZSBtb3JlICBj b21wbGljYXRlZCB3aGVuIGNvbXBhcmVkIHdpdGggb25lIGdlbmVyaWMgbWVjaGFuaXNtoa0NCg0K DQoNCkJlc3QgUmVnYXJkcywNCk1hDQoNCg0KQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiDQtNPaIDIwMTEtMDYtMTQgMjA6MDI6MTA6DQoNCj4g RGFuaWVsLA0KPiBQbGVhc2Ugc2VlIG1vcmUgaW5saW5lIChib2xkIHB1cnBsZSBpdGFsaWNzKS4g SaGvdmUgYWxzbyBzdHJpcHBlZCB0aGUNCj4gcG9ydGlvbnMgb2YgdGhlIHRleHQgdGhhdCBhcmUg bm90IHJlbGF0ZWQgdG8gdGhpcyByb3VuZCBvZiBjb21tZW50cy4NCj4NCj4gUmVnYXJkcywNCj4g ICAgICBTYXNoYQ0KPg0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0 LmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVuZSAxNCwgMjAxMSAyOjM0IFBNDQo+IFRvOiBBbGV4 YW5kZXIgVmFpbnNodGVpbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZzsgU3By ZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QNCj4gSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29t LmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1E ICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0K PiBIaSBTYXNoYSwgdGhhbmtzIGFnYWluIGFuZCBzZWUgaW5saW5lIHdpdGggW0RDXS4NCj4NCj4g RnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDY6MTEgUE0NCj4gVG86 IERhbmllbCBDb2huDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hl ciwgTnVyaXQgKE5TTiAtIElML0hvZA0KPiBIYVNoYXJvbik7IG1hLnl1eGlhQHp0ZS5jb20uY24N Cj4gU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IERh bmllbCBhbmQgYWxsLA0KPiBQbGVhc2Ugc2VlIHNvbWUgY29tbWVudHMgaW5saW5lIGJlbG93Lg0K Pg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+DQo+IEZyb206IERhbmllbCBDb2huIFttYWls dG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgNTo1 NSBQTQ0KPiBUbzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pOyBBbGV4 YW5kZXIgVmFpbnNodGVpbjsNCj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRm Lm9yZzsgcHdlM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5n IGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxp dHkgdG8gTVMtUFciDQo+DQo+IEhpLA0KPg0KPiBUaGFua3MgYWxsIGZvciB0aGUgZmVlZGJhY2su IEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgdGhhdCBQVw0KPiBwcm90ZWN0aW9uIGlzIG9ubHkgcmVx dWlyZWQgaW4gdGhlIGV2ZW50IG9mIFMtUEUgZmFpbHVyZSBhdCBhbiBNUy1QVw0KPiCoQyB0aGlz ICBpcyBjbGVhcmx5IHN0YXRlZCBpbiB0aGUgZHJhZnQuIE5vdywgYm90aCBTYXNoYSBhbmQgTnVy aXQNCj4gbWVudGlvbiB0aGF0IHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBjYW4gbWVldCB0 aGUgTVBMUy1UUCBQVw0KPiBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cy4NCj4gW1tbU2FzaGFdXV0g oa0gc25pcHBlZCChrQ0KPiBFLmcuLCB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc21zIHRha2Ug Y2FyZSBvZiBkdWFsLWhvbWVkIENFcyBpbg0KPiBTUy0gYW5kIE1TLVBXcyCoQyBzb21ldGhpbmcg dGhhdCBsaW5lciBwcm90ZWN0aW9uIG9mIFBXcyBjYW5ub3QgZG8uDQo+IFtEQ10gSaGvbSBhZnJh aWQgSSBkb26hr3QgZm9sbG93IHlvdSBoZXJlLiBXaGVyZSBkb2VzIFBXIHJlZHVuZGFuY3kNCj4g dGFrZSBjYXJlIG9mIGR1YWwtaG9tZWQgQ0U/IEFjdHVhbGx5IFBXIHJlZHVuZGFuY3kgZHJhZnQg ZXhwbGljaXRseQ0KPiBzdGF0ZXM6IKGwVGhlIG1ldGhvZCBmb3IgZHVhbC1ob21pbmcgb2YgQ0Ux IHRvIFBFMSBhbmQgdG8gUEUzIG5vZGVzLA0KPiBhbmQgdGhlIHByb3RvY29scyB1c2VkLCBhcmUg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudKGxLg0KPiBbW1tTYXNoYV1dXSBRdW90 aW5nIGZyb20gdGhlIGRyYWZ0Og0KPiAxNS4yLiBNdWx0aXBsZSBNdWx0aS1ob21lZCBDRXMgd2l0 aCBzaW5nbGUgU1MtUFcgcmVkdW5kYW5jeQ0KPg0KPiAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t LS0tLSBFbXVsYXRlZCBTZXJ2aWNlIC0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAg ICAgICAgICAgICAgfCAgICAgICAgICB8PC0tLS0tLS0gUHNldWRvIFdpcmUgLS0tLS0tPnwgICAg ICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgIHw8LS0g UFNOIFR1bm5lbHMtLT58ICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgfCAgICAgICAg ICBWICAgIFYgICAgKG5vdCBzaG93bikgICBWICAgIFYgICAgICAgICAgfA0KPiAgICAgICAgICAg ICAgViAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsgICAgIEFDICAgVg0K PiAgICAgICAgKy0tLS0tKyAgICB8ICAgICB8Li4uLnwuLi4uLi4uUFcxLi4uLi4uLi58Li4uLnwg ICAgIHwgICAgKy0tLS0tKw0KPiAgICAgICAgfCAgICAgfC0tLS0tLS0tLS18IFBFMXwuLi4uLi4g ICAuLi4uLi4uLi58IFBFM3wtLS0tLS0tLS0tfCAgICAgfA0KPiAgICAgICAgfCBDRTEgfCAgICAg ICAgICArLS0tLSsgICAgICBcIC8gIFBXMyAgICArLS0tLSsgICAgICAgICAgfCBDRTIgfA0KPiAg ICAgICAgfCAgICAgfCAgICAgICAgICArLS0tLSsgICAgICAgWCAgICAgICAgICArLS0tLSsgICAg ICAgICAgfCAgICAgfA0KPiAgICAgICAgfCAgICAgfCAgICAgICAgICB8ICAgIHwuLi4uLi4vIFwu LlBXNC4uLi58ICAgIHwgICAgICAgICAgfCAgICAgfA0KPiAgICAgICAgfCAgICAgfC0tLS0tLS0t LS18IFBFMnwgICAgICAgICAgICAgICAgICB8IFBFNHwtLS0tLS0tLS0gfCAgICAgfA0KPiAgICAg ICAgKy0tLS0tKyAgICB8ICAgICB8Li4uLnwuLi4uLlBXMi4uLi4uLi4uLi58Li4uLnwgICAgIHwg ICAgKy0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAg ICAgICArLS0tLSsgICAgQUMNCj4NCj4NCj4gICAgICBGaWd1cmUgMTUtMiBNdWx0aXBsZSBNdWx0 aS1ob21lZCBDRXMgd2l0aCBzaW5nbGUgU1MtUFcgcmVkdW5kYW5jeQ0KPg0KPiAgICBUaGUgYXBw bGljYXRpb24gaW4gRmlndXJlIDE1LTIgbWFrZXMgdXNlIG9mIHRoZSBJbmRlcGVuZGVudCBtb2Rl IG9mDQo+ICAgIG9wZXJhdGlvbi4NCj4NCj4gICAgQ0UxIGlzIGR1YWwtaG9tZWQgdG8gUEUxIGFu ZCBQRTIuIENFMiBpcyBkdWFsLWhvbWVkIFBFMyBhbmQgUEU0LiBUaGUNCj4gICAgbWV0aG9kIGZv ciBkdWFsLWhvbWluZyBhbmQgdGhlIHVzZWQgcHJvdG9jb2xzIGFyZSBvdXRzaWRlIHRoZSBzY29w ZQ0KPiAgICBvZiB0aGlzIGRvY3VtZW50LiAgTm90ZSB0aGF0IHRoZSBQU04gdHVubmVscyBhcmUg bm90IHNob3duIGluIHRoaXMNCj4gICAgZmlndXJlIGZvciBjbGFyaXR5LiBIb3dldmVyLCBpdCBj YW4gYmUgYXNzdW1lZCB0aGF0IGVhY2ggb2YgdGhlIFBXcw0KPiAgICBzaG93biBpcyBlbmNhcHN1 bGF0ZWQgaW4gYSBzZXBhcmF0ZSBQU04gdHVubmVsLg0KPg0KPiAgICBBc3N1bWUgdGhhdCB0aGUg QUMgZnJvbSBDRTEgdG8gUEUxIGlzIEFjdGl2ZSwgZnJvbSBDRTEgdG8gUEUyIGlzDQo+ICAgIFN0 YW5kYnk7IGZ1cnRoZXJtb3JlLCBhc3N1bWUgdGhhdCB0aGUgQUMgZnJvbSBDRTIgdG8gUEUzIGlz IFN0YW5kYnkNCj4gICAgYW5kIGZyb20gQ0UyIHRvIFBFNCBpcyBBY3RpdmUuIFRoZSBtZXRob2Qg b2YgZGVyaXZpbmcgQWN0aXZlL1N0YW5kYnkNCj4gICAgc3RhdHVzIG9mIHRoZSBBQyBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPg0KPiAgICBQRTEgYWR2ZXJ0aXNlcyB0 aGUgcHJlZmVyZW50aWFsIHN0YXR1cyAiQWN0aXZlIiBhbmQgb3BlcmF0aW9uYWwNCj4gICAgc3Rh dHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzEgYW5kIFBXNCBj b25uZWN0ZWQNCj4gICAgdG8gUEUzIGFuZCBQRTQuIFRoaXMgc3RhdHVzIHJlZmxlY3RzIHRoZSBm b3J3YXJkaW5nIHN0YXRlIG9mIHRoZSBBQw0KPiAgICBhdHRhY2hlZCB0byBQRTEuIFBFMiBhZHZl cnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMgIlN0YW5kYnkiIGFuZA0KPiAgICBvcGVyYXRpb25h bCBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMiBhbmQN Cj4gICAgUFczIHRvIFBFMyBhbmQgUEU0LiBQRTMgYWR2ZXJ0aXNlcyBwcmVmZXJlbnRpYWwgc3Rh dHVzICJTdGFuZGJ5IiBhbmQNCj4gICAgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZv cndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzEgYW5kDQo+ICAgIFBXMyB0byBQRTEgYW5kIFBF Mi4gUEU0IGFkdmVydGlzZSB0aGUgcHJlZmVyZW50aWFsIHN0YXR1cyAiQWN0aXZlIg0KPiAgICBh bmQgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93 aXJlcyBQVzINCj4gICAgYW5kIFBXNCB0byBQRTIgYW5kIFBFMSByZXNwZWN0aXZlbHkuIFRodXMg YnkgbWF0Y2hpbmcgdGhlIGxvY2FsIGFuZA0KPiAgICByZW1vdGUgcHJlZmVyZW50aWFsIGZvcndh cmRpbmcgc3RhdHVzIG9mICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAgICBzdGF0dXMgb2Yg IlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgb2YgcHNldWRvd2lyZXMsIHRoZSBQRSBub2Rlcw0KPiAg ICBkZXRlcm1pbmUgd2hpY2ggUFcgc2hvdWxkIGJlIGluIHRoZSBBY3RpdmUgc3RhdGUuIEluIHRo aXMgY2FzZSBpdCBpcw0KPiAgICBQVzQgdGhhdCB3aWxsIGJlIHNlbGVjdGVkLg0KPg0KPiAgICBP biBmYWlsdXJlIG9mIHRoZSBBQyBiZXR3ZWVuIENFMSBhbmQgUEUxLCB0aGUgZm9yd2FyZGluZyBz dGF0ZSBvZg0KPiAgICB0aGUgQUMgb24gUEUyIGlzIGNoYW5nZWQgdG8gQWN0aXZlLiBQRTIgdGhl biBhbm5vdW5jZXMgdGhlIG5ld2x5DQo+ICAgIGNoYW5nZWQgJ3ByZWZlcmVudGlhbCBmb3J3YXJk aW5nJyBzdGF0dXMgYml0IG9mICJhY3RpdmUiIHRvIFBFMyBhbmQNCj4gICAgUEU0LiBQRTEgd2ls bCBhZHZlcnRpc2UgYSBQVyBzdGF0dXMgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaW5kaWNhdGluZw0K PiAgICB0aGF0IHRoZSBBQyBiZXR3ZWVuIENFMSBhbmQgUEUxIGlzIG9wZXJhdGlvbmFsbHkgZG93 bi4gUEUyIGFuZCBQRTQNCj4gICAgbWF0Y2ggdGhlIGxvY2FsIGFuZCByZW1vdGUgcHJlZmVyZW50 aWFsIGZvcndhcmRpbmcgc3RhdHVzIG9mDQo+ICAgICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbCBz dGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgYW5kIHNlbGVjdA0KPiAgICBQVzIgYXMgdGhl IG5ldyBhY3RpdmUgcHNldWRvd2lyZSB0byBzZW5kIHRyYWZmaWMgdG8uDQo+DQo+ICAgIE9uIGZh aWx1cmUgb2YgUEUxIG5vZGUsIFBFMiB3aWxsIGRldGVjdCBpdCBhbmQgd2lsbCB0cmFuc2l0aW9u IHRoZQ0KPiAgICBmb3J3YXJkaW5nIHN0YXRlIG9mIGl0cyBBQyB0byBBY3RpdmUuIFRoZSBtZXRo b2QgYnkgd2hpY2ggUEUyDQo+ICAgIGRldGVjdHMgdGhhdCBQRTEgaXMgZG93biBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBQRTINCj4gICAgdGhlbiBhbm5vdW5jZXMgdGhl IG5ld2x5IGNoYW5nZWQgJ3ByZWZlcmVudGlhbCBmb3J3YXJkaW5nJyBzdGF0dXMNCj4gICAgYml0 IG9mICJBY3RpdmUiIHRvIFBFMyBhbmQgUEU0LiBQRTIgYW5kIFBFNCBtYXRjaCB0aGUgbG9jYWwg YW5kDQo+ICAgIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGluZyBzdGF0dXMgb2YgIkFjdGl2 ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBh bmQgc2VsZWN0IFBXMiBhcyB0aGUgbmV3IGFjdGl2ZQ0KPiAgICBwc2V1ZG93aXJlIHRvIHNlbmQg dHJhZmZpYyB0by4gTm90ZSB0aGF0IFBFMyBhbmQgUEU0IG1heSBoYXZlDQo+ICAgIGRldGVjdGVk IHRoYXQgdGhlIFBXIHRvIFBFMSB3ZW50IGRvd24gdmlhIFQtTERQIEhlbGxvIHRpbWVvdXQgb3Ig dmlhDQo+ICAgIG90aGVyIG1lYW5zLiBIb3dldmVyLCB0aGV5IHdpbGwgbm90IGJlIGFibGUgdG8g Zm9yd2FyZCB1c2VyIHRyYWZmaWMNCj4gICAgdW50aWwgdGhleSByZWNlaXZlZCB0aGUgdXBkYXRl ZCBzdGF0dXMgYml0IGZyb20gUEUyLg0KPg0KPiAgICBCZWNhdXNlIGVhY2ggZHVhbC1ob21pbmcg YWxnb3JpdGhtIHJ1bm5pbmcgb24gdGhlIHR3byBub2RlIHNldHMsDQo+ICAgIGkuZS4sIHtDRTEs IFBFMSwgUEUyfSBhbmQge0NFMiwgUEUzLCBQRTR9LCBzZWxlY3RzIHRoZSBhY3RpdmUgQUMNCj4g ICAgaW5kZXBlbmRlbnRseSwgdGhlcmUgaXMgYSBuZWVkIHRvIHNpZ25hbCB0aGUgYWN0aXZlIHN0 YXR1cyBvZiB0aGUgQUMNCj4gICAgc3VjaCB0aGF0IHRoZSBQRSBub2RlcyBjYW4gc2VsZWN0IGEg Y29tbW9uIGFjdGl2ZSBQVyBmb3IgZW5kLXRvLWVuZA0KPiAgICBmb3J3YXJkaW5nIGJldHdlZW4g Q0UxIGFuZCBDRTIgYXMgcGVyIHRoZSBwcm9jZWR1cmVzIGluIHRoZQ0KPiAgICBpbmRlcGVuZGVu dCBtb2RlLg0KPg0KPiAgICBOb3RlIHRoYXQgYW55IHByaW1hcnkvc2Vjb25kYXJ5IHByb2NlZHVy ZXMsIGFzIGRlZmluZWQgaW4gc2VjdGlvbnMNCj4gICAgNS4xLiAgYW5kIDUuMi4gLCBkbyBub3Qg YXBwbHkgaW4gdGhpcyB1c2UgY2FzZSBhcyB0aGUgQWN0aXZlL1N0YW5kYnkNCj4gICAgc3RhdHVz IGlzIGRyaXZlbiBieSB0aGUgQUMgZm9yd2FyZGluZyBzdGF0ZSBhcyBkZXRlcm1pbmVkIGJ5IHRo ZSBBQw0KPiAgICBkdWFsLWhvbWluZyBwcm90b2NvbCB1c2VkLg0KPg0KPg0KPiBJIGJlbGlldmUg eW91oa92ZSB0YWtlbiB5b3VyIKGwb3V0IG9mIHNjb3BlobEgcmVmZXJlbmNlIGZyb20gdGhpcyB0 ZXh0LA0KPiBidXQgSU1ITyB5b3UgbWlzaW50ZXJwcmV0ZWQgaXQuDQo+IFdoYXQgaXQgbWVhbnMg KG9yIHNvIEkgcmVhZCBpdCkgaXMgdGhhdCBzcGVjaWZpYyBkdWFsLWhvbWluZw0KPiBwcm90b2Nv bCBpcyBvdXQgb2Ygc2NvcGUgYXMgbG9uZyBhcyBpdCBtZWV0cyBjZXJ0YWluIGFzc3VtcHRpb25z Lg0KPiBBc2lkZTogSXQgd291bGQgYmUgZ29vZCBpZiB0aGUgYXV0aG9ycyBvZiB0aGUgUFcgcmVk dW5kYW5jeSBkcmFmdHMNCj4gY291bGQgZXhwbGljaXRseSBzcGVjaWZ5IHRoZXNlIGFzc3VtcHRp b25zLg0KPg0KPiBbW1tTYXNoYV1dXSChrSBzbmlwcGVkIKGtDQo+DQo+IE5vdyBsZXShr3MgdHVy biBvdXIgYXR0ZW50aW9uIGJhY2sgdG8gd2hldGhlciB0aGUgUFcgcmVkdW5kYW5jeQ0KPiBkcmFh ZnQgY2FuIGJlIHVzZWQgdG8gbWVldCBNUExTLVRQIFBXIHByb3RlY3Rpb24gcmVxdWlyZW1lbnRz LiBJIGNhbg0KPiBpZGVudGlmeSB0aGUgZm9sbG93aW5nIHJlYXNvbnMgd2h5IGluIGl0cyBjdXJy ZW50IGZvcm0gaXQgZG9lc26hr3Q6DQo+DQo+IC0gICAgICAgICAgSXQgZXhwbGljaXRseSAoobBv dXRzaWRlIHRoZSBzY29wZaGxKSBkb2VzIG5vdCBkZWZpbmUNCj4gcHJvdGVjdGlvbiB0cmlnZ2Vy cyBhbmQgaG93IHRvIGhhbmRsZSBjb2V4aXN0aW5nIHRyaWdnZXJzLCBhcw0KPiByZXF1ZXN0ZWQg aW4gUkZDIDU2NTQgKE1QTFMtVFAgUmVxdWlyZW1lbnRzKSwgcmVxcyAjNzUsICM3NiBhbmQgIzc5 DQo+IFtbW1Nhc2hhXV1dIFNvIHdoYXQ/IERlZmluaXRpb24gb2YgdHJpZ2dlcnMgaXMgb3J0aG9n b25hbCB0byBob3cNCj4gY29vcmRpbmF0ZWQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaGFwcGVucy4N Cj4gW0RDXSBJdCBpcy4gQnV0IHN0aWxsIGl0IG5lZWRzIHRvIGJlIGRlZmluZWQgYnkgdGhlIHJl Y292ZXJ5DQo+IGZyYW1ld29yaywgZS5nLiB3aGF0IHNob3VsZCB0aGUgZW5kcG9pbnQgZG8gd2hl biBvbmUgUFcgaXMgaW4gU0YgYW5kDQo+IHRoZSBvdGhlciBpcyBpbiBTRCwgb3Igd2hlbiBib3Ro IGFyZSBpbiBTRC4gT3BlcmF0b3JzIGV4cGVjdCB3ZWxsLQ0KPiBkZWZpbmVkIGJlaGF2aW9yIGlu IHRoZXNlIGFuZCBvdGhlciBzY2VuYXJpb3MsIGFuZCBQVyByZWR1bmRhbmN5DQo+IGRvZXMgbm90 IGRlZmluZSB0aGVtIChiZWNhdXNlIGl0IHdhcyBub3QgaW4gdGhlaXIgc2NvcGUpLg0KPiBbW1tT YXNoYV1dXSBJIHdvbmRlciBpZiB5b3UgaGF2ZSBmb2xsb3dlZCB0aGUgZGlzY3Vzc2lvbiByZWdh cmRpbmcNCj4gYWJpbGl0eSB0byBkZWZpbmUgU0QgY29uZGl0aW9uIGZvciBMU1BzIGFuZCBQV3Mg b24gdGhlIE1QTFMtVFAgbGlzdD8NCj4gSU1PIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkZWZpbmUg aXQgaW4gYSBtZWFuaW5nZnVsIHdheS4gSGVuY2UgSSBkbw0KPiBub3Qgc2VlIGEgcHJvcG9zYWwg dGhhdCBkb2VzIG5vdCBhZGRyZXNzIGEgc2NlbmFyaW8gdGhhdCBkb2VzIG5vdA0KPiBleGlzdCBp biByZWFsaXR5IGFzIGEgZmxhd2VkIG9uZS4NCj4NCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBz dXBwb3J0IHRoZSBhYmlsaXR5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4NCj4gZGlmZmVyZW50IHR5 cGVzIG9mIHRyaWdnZXJzIChpLmUuIG9uZSBlbmQgZG9lc26hr3Qga25vdyB3aHkgdGhlIG90aGVy DQo+IGVuZCB0cmlnZ2VyZWQgc3dpdGNoKSwgYXMgcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExT LVRQDQo+IFJlcXVpcmVtZW50cyksIHJlcSAjNzcNCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBk ZWZpbmUgcmV2ZXJ0aXZlL25vbnJldmVydGl2ZSBiZWhhdmlvciwgYXMNCj4gcmVxdWVzdGVkIGlu IFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjQNCj4gLSAgICAgICAgICBJ dCBkb2VzIG5vdCBkZWZpbmUgaG9sZG9mZiBzdXBwb3J0LCB3aGljaCBpcyBlc3BlY2lhbGx5DQo+ IGltcG9ydGFudCB0byBhdm9pZCByYWNlIGNvbmRpdGlvbnMgd2l0aCBMU1AgcHJvdGVjdGlvbiB3 aGVuIGl0IGV4aXN0cw0KPiAtICAgICAgICAgIEl0IGRvZXNuoa90IHN1cHBvcnQgMSsxIG1vZGUs IGFzIHJlcXVlc3RlZCBpbiBSRkMgNTY1NA0KPiAoTVBMUy1UUCBSZXF1aXJlbWVudHMpLCByZXEg IzY1DQo+IFtbW1Nhc2hhXV1dIEFsbCB0aGVzZSBjbGFpbXMgYXJlIGNvcnJlY3QgqEMgYW5kICB0 aGlzIHNob3VsZCBub3QgYmUgYQ0KPiBzdXJwcmlzZSwgYmVjYXVzZSBNUExTLVRQIHJlcXVpcmVt ZW50cyBoYXZlIGJlZW4gZGVmaW5lZCBtdWNoIGxhdGVyDQo+IHRoYW4gdGhlIFBXIHJlZHVuZGFu Y3kgbWVjaGFuaXNtLg0KPiBCdXQgSSBkbyBub3QgdGhpbmsgdGhhdCB0aGlzIGp1c3RpZmllcyBj by1leGlzdGVuY2Ugb2YgdHdvIGRpZmZlcmVudA0KPiBtZWNoYW5pc21zLg0KPiBbRENdIFNvIGhv dyBkbyB5b3UgcHJvcG9zZSB0byBtZWV0IHRoZSBQVyBwcm90ZWN0aW9uIHJlcXVpcmVtZW50Pw0K PiAtICAgICAgICAgIEl0oa9zIGEgdHdvLXBoYXNlIHByb3RvY29sLCB3aXRoIHRoZSBjb25zZXF1 ZW50IGltcGFjdCBvbiB0aW1pbmcNCj4gW1tbU2FzaGFdXV0gQ291bGQgeW91IHBsZWFzZSBlbGFi b3JhdGU/IFtEQ10gSW4gZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPiBsaW5lYXItcHJvdGVjdGlvbiwg ZWFjaCBlbmRwb2ludCB3aWxsIGltbWVkaWF0ZWx5IHN3aXRjaCB0cmFmZmljIHRvDQo+IHRoZSBv dGhlciBwYXRoIHVwb24gaWRlbnRpZnlpbmcgYW4gU0YgY29uZGl0aW9uIGluIGEgcGF0aCwgd2l0 aG91dA0KPiB3YWl0aW5nIGZvciB0aGUgZmFyIGVuZCB0byBhY2tub3dsZWRnZSB0aGUgc3dpdGNo ICgxLXBoYXNlKS4gSW4gUFcNCj4gcmVkdW5kYW5jeSwgYW4gZW5kcG9pbnQgZGV0ZWN0aW5nIGFu IFNGIGNvbmRpdGlvbiBpbiBhIHBhdGggd2lsbCBub3QNCj4gc3dpdGNoIHVudGlsIHRoZSBmYXIg ZW5kIGhhcyBhY2tub3dsZWRnZWQgdGhlIHN3aXRjaCAoMi1waGFzZSkuDQo+IE5lZWRsZXNzIHRv IHNheSwgcmVjb3ZlcnkgaXMgc2xvd2VyIGluIGEgMi1waGFzZSBwcm90b2NvbC4NCj4gW1tbU2Fz aGFdXV0gVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgMS1waGFzZSBwcm90ZWN0aW9u IGlzDQo+IG9ubHkgcG9zc2libGUgaW4gMSsxIHVuaWRpcmVjdGlvbmFsIGFyY2hpdGVjdHVyZXMu IEFuZCB5ZXMsIEkga25vdw0KPiB0aGF0IE1QTFMtVFAgcmVxdWlyZXMgYSAgbWVjaGFuaXNtIHRv IHN1cHBvcnQgdGhpczsgd2hldGhlciBhbnlib2R5DQo+IHdvdWxkIHJlYWxseSBkbyB0aGF0IGlu IHRoZSBwYWNrZXQtc3dpdGNoaW5nIG5ldHdvcmsgaXMgbm90IGNsZWFyIHRvDQo+IG1lLiBBbmQg SSBhY2tub3dsZWRnZSB0aGF0IHRoZSBQVyByZWR1bmRhbmN5IGRyYWZ0cyBkbyBub3Qgc3VwcG9y dA0KPiAxKzEgdW5pZGlyZWN0aW9uYWwgc2NoZW1lLg0KPg0KPiAtICAgICAgICAgIEl0IGRvZXNu oa90IGRlZmluZSByZXRyYW5zbWlzc2lvbiBvZiBwcm90ZWN0aW9uDQo+IGNvb3JkaW5hdGlvbiBt ZXNzYWdlcywgc28gbG9zcyBvZiBhIHNpbmdsZSBQRFUgY2FuIHJlc3VsdCBpbg0KPiBzd2l0Y2hv dmVyIG5vdCB0YWtpbmcgcGxhY2UsIHRodXMgbm90IHN1cHBvcnRpbmcgc3ViLTUwIG1zIHJlY292 ZXJ5DQo+IGluIHRoaXMgY2FzZQ0KPiBbW1tTYXNoYV1dXSBUaGUgUFcgcmVkdW5kYW5jeSBwcm90 b2NvbCBydW5zIGVpdGhlciBvbiB0b3Agb2YgTERQDQo+ICh3aGljaCBiZW5lZml0cyBmcm9tIFRD UCByZXRyYW5zbWlzc2lvbnMpIG9yIG9uIHRvcCBvZiBzdGF0aWMgUFcNCj4gc3RhdHVzIG1lc3Nh Z2VzICh3aGVyZSByZXRyYW5zbWlzc2lvbiBpcyBkZWZpbmVkKS4NCj4gW0RDXSBUcnVlIKhDIGJ1 dCBzdGF0aWMgUFcgc3RhdHVzIGRlZmluZXMgc2xvdyByZXRyYW5zbWlzc2lvbiAoobB3aWxsDQo+ IGJlIHRyYW5zbWl0dGVkIHR3aWNlIGF0IGFuIGluaXRpYWwgaW50ZXJ2YWwgb2Ygb25lIHNlY29u ZKGxKSB3aGlsZQ0KPiBkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24gc3BlY2lm aWVzIGZhc3QgcmV0cmFuc21pc3Npb24NCj4gd2hlbiByZXF1aXJlZCBmb3IgZmFzdCByZWNvdmVy eSAoc2VjdGlvbiAzLjEuNCkuDQo+DQo+IEluIHN1bW1hcnksIFBXIHJlZHVuZGFuY3kgd2FzIG5v dCBkZXNpZ25lZCB3aXRoIFRQIHJlcXVpcmVtZW50cyBpbg0KPiBtaW5kLCBhbmQgYXMgc3VjaCBk b2VzIG5vdCBtZWV0IHRoZSBUUCByZXF1aXJlbWVudHMuIE9mIGNvdXJzZQ0KPiBtb2RpZmljYXRp b25zIG1heSBiZSBpbnRyb2R1Y2VkLCBidXQgd2h5IHJlaW52ZW50IHRoZSB3aGVlbCB3aGVuDQo+ IHRoZXJlIGlzIGEgcHJvdG9jb2wgKGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlv bi0wNikgaW4gdGhlDQo+IHN0YW5kYXJkcyB0cmFjayB0aGF0IHN1cHBvcnRzIGFsbCB0aGUgYWJv dmUgcmVxdWlyZW1lbnRzIGFuZCBjYW4gYmUNCj4gYXBwbGllZCB0byBNUy1QVyBwcm90ZWN0aW9u IHdpdGggbWlub3IgbW9kaWZpY2F0aW9ucz8NCj4gW1tbU2FzaGFdXV0gQXMgSSBzYWlkLCBiZWNh dXNlIHRoZSBhcHBsaWNhYmlsaXR5IHNjb3BlIGlzIGJ5IGZhciB0b28NCj4gbmFycm93IHRvIGp1 c3RpZnkgYSBkZWRpY2F0ZWQgcHJvdG9jb2wuDQo+IFtEQ10gSWYgd2Ugd2VyZSBkaXNjdXNzaW5n IGRlc2lnbmluZyBhIG5ldyBwcm90b2NvbCwgSSBtaWdodCBhZ3JlZQ0KPiB3aXRoIHlvdS4gQnV0 IGZyb20gYSBwcmFjdGljYWwgc3RhbmRwb2ludCwgdGhlIFBXIHByb3RlY3Rpb24gZHJhZnQNCj4g aXMgbm90IGEgZGVkaWNhdGVkIHByb3RvY29sIKhDIGl0oa9zIGFuIGFwcGxpY2FiaWxpdHkgc3Rh dGVtZW50IHRvIGFuDQo+IGV4aXN0aW5nIHByb3RvY29sLiBCb3RoIGZyb20gdGhlIGltcGxlbWVu dGF0aW9uIGFuZCB0aGUgb3BlcmF0aW9uYWwNCj4gcG9pbnQgb2YgdmlldyBpdCBkZWZpbmVzIGEg bmV3IHVzZSBjYXNlIGZvciBhbiBleGlzdGluZyBwcm90b2NvbCBhbmQgY29uY2VwdC4NCj4NCj4N Cj4gUmVnYXJkcywNCj4NCj4gRGFuaWVsDQo+DQo+DQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFNwcmVj aGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKQ0KPiBTZW50OiBNb25kYXksIEp1bmUg MTMsIDIwMTEgNDowMiBQTQ0KPiBUbzogZXh0IEFsZXhhbmRlciBWYWluc2h0ZWluOyBtYS55dXhp YUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBU UExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGksDQo+IEkg d291bGQgbGlrZSB0byBzZWNvbmQgU2FzaGEuDQo+IEVuZC10by1lbmQgUFcgcHJvdGVjdGlvbiAo d2l0aCBkaXZlcnNlIHBhdGhzKSBkb2VzIG5vdCBzY2FsZSwgYW5kDQo+IHB1dCBoYXJkIHJlc3Ry aWN0aW9ucyBvbiB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIHJlc291cmNlcy4NCj4gTVBMUy1UUCBQ V3MgYXJlIGNhcnJpZWQgYWNyb3NzIHRoZSBuZXR3b3JrIGluc2lkZSBNUExTLVRQIExTUHMuDQo+ IFRoZXJlZm9yZSwgYW4gb2J2aW91cyB3YXkgdG8gcHJvdmlkZSBwcm90ZWN0aW9uIGZvciBhIFBX IGlzIHRvDQo+IHByb3RlY3QgdGhlIExTUCB0aGF0IGNhcnJpZXMgaXQuDQo+IElmIHRoZSBQVyBp cyBhIG11bHRpLXNlZ21lbnQgUFcsIHRoZW4gTFNQIHJlY292ZXJ5IGNhbiBvbmx5IHByb3RlY3QN Cj4gdGhlIFBXIGluIGluZGl2aWR1YWwgc2VnbWVudHMuICBUaGlzIG1lYW5zIHRoYXQgYSBzaW5n bGUgTFNQDQo+IHJlY292ZXJ5IGFjdGlvbiBjYW5ub3QgcHJvdGVjdCBhZ2FpbnN0IGEgZmFpbHVy ZSBvZiBhIFBXIHN3aXRjaGluZw0KPiBwb2ludCAoYW4gUy1QRSkuDQo+IFdoZW4gcHJvdGVjdGlu ZyBhZ2FpbnN0IGFuIEFDIG9yIFQvUy1QRSBmYWlsdXJlIGJ5IGR1YWwNCj4gY29ubmVjdGl2aXR5 LCBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgcHJvdmlkZSBtZWFucyBmb3IgdGhlIFBFcyB0bw0K PiBjb29yZGluYXRlIG92ZXIgd2hpY2ggTFNQIHRoZSB0cmFmZmljIG9mIHRoZSBQVyBpcyBjYXJy aWVkLg0KPiBJIGFsc28gZG91YnQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWRkaXRpb25hbCBt ZWNoYW5pc20uDQo+IEJlc3QgcmVnYXJkcywNCj4gTnVyaXQNCj4NCj4gRnJvbTogcHdlMy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj4gZXh0IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAx MSAzOjQzIFBNDQo+IFRvOiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3Jn OyBwd2UzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUFdFM10gW21wbHNdIFNlZWtpbmcgZmVl ZGJhY2sgb24gSS1EICJNUExTLVRQDQo+IExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0 byBNUy1QVyINCj4NCj4gRGVhciBNYSBhbmQgYWxsLA0KPiBBZGRpbmcgdGhlIFBXRTMgV0cgdG8g bXkgcmVzcG9uc2UuDQo+DQo+IFRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBzdXBwb3J0cyBs aW5lYXIgcHJvdGVjdGlvbiBvZiBNUy1QV3MgYXMNCj4gb25lIG9mIG1hbnkgYWRkaXRpb25hbCBh cHBsaWNhdGlvbiB1c2UgY2FzZXM6DQo+IEFwcGVuZGl4IEEgb2YgdGhlIFBXIHJlZHVuZGFuY3kg Qml0IGRyYWZ0IGRlc2NyaWJlcyA1IGFwcGxpY2F0aW9uDQo+IHVzZXMgY2FzZXMgaW4gYWRkaXRp b24gdG8gTVMtUFcgd2l0aCBzaW5nbGUtaG9tZWQgQ0VzICh3aGljaCBpcw0KPiBsaXN0ZWQgdGhl cmUgYXMgdXNlIGNhc2UgNSkuDQo+IEFuZCBpdCBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8gSVAv TVBMUyBhbmQgTVBMUyAtIHdpdGggdGhlIGhlbHAgb2YgIHRoZQ0KPiBTdGF0aWMgUFcgU3RhdHVz IE1lc3NhZ2VzIGRyYWZ0KCBpZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgeW91IGRvIG5vdA0KPiB3 YW50ICB0bywgb3IgY2Fubm90LCB1c2UgUkZDIDQ0NDcpLg0KPg0KPiBIZW5jZSBJIGRvdWJ0IHRo ZSBuZWVkIGZvciB5ZXQgYW5vdGhlciBQVyByZWR1bmRhbmN5ICBtZWNoYW5pc20gd2l0aA0KPiBu YXJyb3cgc2NvcGUgb2YgYXBwbGljYWJpbGl0eS4NCj4NCj4gUmVnYXJkcywNCj4gICAgICBTYXNo YQ0KPg0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFNlbnQ6IE1v bmRheSwgSnVuZSAxMywgMjAxMSAzOjI1IFBNDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAgTGluZWFyDQo+ IFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4gSGkgYWxsLA0KPg0KPiBU aGUgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGZvciBMU1AgYW5kIFBXKGluY2x1ZGluZyBN Uy1QVykNCj4gc2hvdWxkIGJlIHRoZSBzYW1lIGFuZCBpdCBpcyB2YWx1YWJsZSB0byBkZXNjcmli ZSBpdCBjbGVhcmx5Lg0KPg0KPiBCVFcsIHRoZXJlIGlzIGEgdHlwbywgaXQgaXMgIlQtUEUgWiIg aW5zdGVhZCBvZiAiVC1QRSBCIi4NCj4NCj4gICINCj4gICBGaWd1cmUgMSBpbGx1c3RyYXRlcyBz dWNoIGEgc2NlbmFyaW8sIHdoZXJlIHR3byBNUy1QV3MgYXJlDQo+ICAgZXN0YWJsaXNoZWQgYmV0 d2VlbiBULVBFIEEgYW5kIFQtUEUgQiwgb3ZlciBTLVBFcyAxLTIgYW5kIDMtNA0KPiAgIHJlc3Bl Y3RpdmVseS4gRWFjaCBQVyBzZWdtZW50IGlzIGVzdGFibGlzaGVkIG92ZXIgYW4gTFNQIChlLmcu IFBXLQ0KPiAgIHMxMiBvdmVyIExTUDEyKS4NCj4gICINCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogRGFuaWVsIENvaG4NCj4gU2VudDogVHVlc2RheSwgTWF5IDE3LCAyMDEx IDQ6MTQgUE0NCj4gVG86IG1wbHMNCj4gU3ViamVjdDogU2Vla2luZyBmZWVkYmFjayBvbiBJLUQg Ik1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24NCj4gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4g SW1wb3J0YW5jZTogSGlnaA0KPg0KPiBIaSBNUExTZXJzLA0KPg0KPiBJIHVwbG9hZGVkICJNUExT LVRQIExpbmVhciBQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciIEktRA0KPiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29obi1tcGxzLXRwLXB3LXByb3RlY3Rpb24t MDApDQo+DQo+IFRoZSBhYnN0cmFjdCBnb2VzOg0KPg0KPiBPbmUgb2YgdGhlIHJlcXVpcmVtZW50 cyBvZiB0aGUgTVBMUyB0cmFuc3BvcnQgcHJvZmlsZSBbUkZDIDU2NTRdIGlzDQo+IHRvIHByb3Zp ZGUgbGluZWFyIHByb3RlY3Rpb24gZm9yIHRyYW5zcG9ydCBwYXRocywgd2hpY2ggaW5jbHVkZSBi b3RoDQo+IExTUHMgYW5kIFBXcy4gVGhlIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGRlc2NyaWJl ZCBpbiBbU3Vydml2RndrXQ0KPiBpcyBhcHBsaWNhYmxlIHRvIGJvdGggTFNQIGFuZCBQV3MsIGhv d2V2ZXIgW0xpbmVhclByb3RdIGRvZXMgbm90DQo+IGV4cGxpY2l0bHkgZGVzY3JpYmUgbWVjaGFu aXNtcyBmb3IgUFcgcHJvdGVjdGlvbiBpbiBNUExTLVRQLg0KPg0KPiBUaGlzIGRvY3VtZW50IGV4 dGVuZHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGxpbmVhciBwcm90ZWN0aW9uDQo+IG1lY2hh bmlzbSBkZXNjcmliZWQgaW4gW0xpbmVhclByb3RdIHRvIE1QTFMtVFAgc2VnbWVudGVkIFBXcw0K PiAoTVMtUFdzKSBhcyBkZWZpbmVkIGluIFtSRkMgNjA3M10uDQo+DQo+IENvdWxkIHlvdSBwbGVh c2UgcmV2aWV3IGl0IGFuZCBzZW5kIGZlZWRiYWNrIHRvIHRoZSBtYWlsaW5nIGxpc3Qgb3INCj4g ZGlyZWN0bHkgdG8gdGhlIGF1dGhvcj8NCj4NCj4gTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgZmVl ZGJhY2ssDQo+DQo+IERhbmllbA0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZv ciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlz IENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxl Y29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLg0KPiBUaGlzIGUtbWFpbCBt ZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+ IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVy ZW9mLg0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBh bmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1 cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLiCpbXq52j8/YnI+DQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KDQpUaGlzIGUtbWFp bCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwg YW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KDQpR dWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVz aXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1 YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRl IHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUg cHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRp IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KcmlzcGV0dGEgbCdhbWJpZW50ZVJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0KDQo= From eric.gray@ericsson.com Wed Jul 27 09:32:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA1411E8108 for ; Wed, 27 Jul 2011 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRDFLFFjuFlE for ; Wed, 27 Jul 2011 09:32:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 33ACF11E80F6 for ; Wed, 27 Jul 2011 09:32:16 -0700 (PDT) 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 p6RGWEGx002846 for ; Wed, 27 Jul 2011 11:32:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 12:32:08 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Wed, 27 Jul 2011 12:32:07 -0400 Thread-Topic: [mpls] R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:32:20 -0000 Forwarding in plain text... ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, July 13, 2011 10:57 PM To: erminio.ottone_69@libero.it Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; ietf@ietf.org;= IETF-Announce Subject: Re: [mpls] R: RE: Last Call: = (Proactive Connectivity Verification, Continuity Check and Remote Defect i= ndication for MPLS Transport Profile) to Proposed Standard Dear Erminio, I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is eve= n more narrow then of the document being discussed. The G.8113.1 addresses = only bi-directional co-routed LSP and has no model to handle bi-directional= associated LSP in independent mode. And unidirectional p2p and p2mp LSPs a= re not addressed by the current revision of the G.8113.1. Can all these out-of-scope constructs be used to conclude that G.8113.1 is = not capable to solve these issues? I don't think so. Solutions are not read= ily available, that's all. Regards, Greg On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it wrote: >I would not go so far as to say "similar to 1731", there is actual= ly a lot of difference under the hood. As for uni-directional BFD, that is a BF= D WG problem at the moment. The fact that the BFD WG has not defined a solution for unidirectio= nal p2p and p2mp transport paths does not make BFD a suitable OAM protocol for = MPLS-TP nor does resolve the technical issue that have been raised. >----Messaggio originale---- >Da: david.i.allan@ericsson.com >Data: 8-lug-2011 18.13 >A: "Rui Costa", "Stewart Bryant" >Cc: "erminio.ottone_69@libero.it", "m= pls@ietf. org", "ietf@ietf.org", "IETF-Announce= " >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt= > (Proactive Connectivity Verification, Continuity Check and Rem= ote Defect indication for MPLS Transport Profile) to Proposed Standa= rd > >Rui: > >You wrote: > >>Reading something, keeping it on record, without effect in the dr= aft and "ignoring comments" have IMHO similar outcomes. As author of the dr= aft you are free to do it. These standards have a great impact >>in our work, so i'm also free to write what i did. > >Numerous comments did have effect on the draft and those that didn= 't were either simply not actionable, were rhetorical or not constructive, = and a few had to be balanced against comments coming from the MPLS & BFD WGs.= I would translate "ingored" or "without effect" to "did not get one'e way".= In the standards process it happens. > >Meanwhile as an editor of the document, I'll take the liberty of r= esponding to some of the points you raise... > >>My technical concerns regarding this draft were expressed... >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, = i believe); >>...in operators' meetings' that took place during ITU-T's Feb/201= 1 plenary meeting; > >I and the WG don't really have access to private grumblings. > >>...in a comparison session that took place during that same ITU-T= meeting. > >Lots of other opinions were expressed as well, and they did not al= l agree with you. > >>Some: >>CC/CV >>I don't understand the need for 2 types of packets: a single type= allows CC; mismatching identifiers in the same CC packets allow CV. >>Besides adding complexity, we whether always activate both or pot= entiate undetected mismerges. > >OK, lets walk through this. > >We want CV all the time so that any misconectivity can be detected= , but on the list it was expressed that the group did not want the overhead = of processing the source MEP TLV in every packet in order to achieve t= his. We could carry it in every packet and have the receiver simply ignore = most of them, but then that would make the defect entry criteria compeltely= random and the exit criteria unreliable as well, not really a good design. Hen= ce they are separated using different ACH code points and the receiver is oblig= ed to process every source MEP TLV it receives. I hope this is clear. > >>(BTW: can't understand how we propose one ACH codepoint to CC, an= other for CV, [counting other drafts, another for frame loss ...] but don't c= onsider assigning 1 single ACH protocol identifier codepoint >as requested = by ITU-T) > >Because that puts you into two protocol ID demultiplexing steps pe= r OAM PDU recevied to determine the intended function. Hence COSTS MORE. That= is pretty basic... > >> Uni P2P / P2MP >> I can't see how BFD will support unidir and hence P2MP other tha= n... >> ...eliminating the session "state variable" (down, init, up), ai= ming just the state variables we really need, bringing us to something simila= r to 1731, eventually with other bits on the wire or... >> ...using IP to create the reverse way, which we cannot assume pe= r requirements; >> Will we create a complete different tool for that? >> (BFD's B=3D"bidirectional") > >I would not go so far as to say "similar to 1731", there is actual= ly a lot of difference under the hood. As for uni-directional BFD, that is a BF= D WG problem at the moment. > >> Provisioning list >> This is an MPLS profile/subset (and i heard) achievable through = a particular configuration. So, i expect each draft-ietf-mpls-TP-* to= focus on that profile/configuration. However, i keep seeing >> references f.i. to IP encapsulations unexpected under TP's OAM. >> I don't thus understand what the aim is: do we expect this in TP= , are we talking about MPLS in general?... The TP profile is never quite del= imited. >> Does chapter 4 contain ALL the configurable parameters list agre= ed to provide in the comparison session? > >It should. As for encapsulations, unless TP is in a complete islan= d not connected to anything (which as a network is rather useless) it wil= l be expected to interoperate with the rest of the MPLS architecture, an= d the stated intention of tool development was that what resulted was applicable= to the broader MPLS architecture. Which means backwards compatiblity and p= rocedures for interoperation. > >> Backwards compatibility >> This was the main argument risen to ground MPLS-TP OAM on BFD. I= t's not a better argument than grounding MPLS-TP OAM on 1731 due to its ETH d= eployment plus coherence with SDH, OTN, as defended by ITU-T. >> For reasons like the above, however, MPLS-TP BFD won't be backwa= rds compatible with previous BFD (even considering just CC/CV). They do= n't even share the same codepoint. > >The issue is not code point, which is the trivial part. It is reus= e of the majority of the implementation. Again, pretty basic. > >>Simplicity >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC i= s simpler: in each flow, a standard defined nr of constant heartbeat signals (= with standard constant or provisioned period - no >>auto/negotiated -) means OK. A standard defined number of misses = means lost Rx connection. An RDI, the only articulation between Rx and Tx flow= s, meaningful in bidirectional applications, allows each >>pear to identify Tx problems. >>This OAM simplicity is the key for reliable fail finger pointing, performance reports and protection. Also to allow scaling, more imp= lementation opportunities/manufacturers, which is valuable for >>operators. > >Well IMO there was not a lot of interest in T-MPLS until the IETF = was going to re-define it and make it compatible with IP/MPLS. So there was a= n industry wide "design intent" implied here. > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and= more difficult to tell which is which. > >That is because MPLS-TP is not a new techology, it is an addition = to the entire MPLS protocol suite. > >Hope this helps >D > > > > > > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 19:25 >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; IETF-An= nounce >Cc: mpls@ietf.org >Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > > >>Several service providers regarded this draft as not meeting thei= r >>transport networks' needs. > >E> This is a true statement: the solution in this draft is useless= for many MPLS- TP deployments. > >The two statements do not necessarily follow. > >What we established during discussions at the SG15 plenary in Febr= uary was that the issue some service providers had was that the IETF BFD sol= ution exceeded their requirements in that there was additional functional= ity they did not see a need for, and that they considered any additional functio= nality parasitic. > >However this is a consequence of adapting an existing technology t= o a new application. I do not see any way around that. And the entire joint= project was based on the premise of engineering re-use not greenfield design. T= hat is what it said on the tin up front, and IMO why when the IETF started down= this path packet transport transitioned from being a minority sport to mainst= ream, so it is a bit late to cry foul.... > >My 2 cents >Dave > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 18:36 >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >Subject: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >Hi Erminio: > >Two of the three document editors were present at SG15 plenary in = February where the comments originated. The revised meeting schedule resulte= d in a day spent going through the document with the editors. IMO there were l= ots of discussion and legitimate issues with the document identified and c= orrected so it was a useful session. The liaison of same was in many ways *afte= r the fact*. > >Cheers >Dave > > > > >-----Original Message----- >From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero= .it] >Sent: quarta-feira, 6 de Julho de 2011 18:34 >To: Rui Costa; ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >The way this draft has been developed is a bit strange. > >The poll for its adoption as a WG document was halted by the MPLS = WG chair because "it is not possible to judge consensus": > >http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html > >The lack of consensus was motivated by serious technical concerns = raised by several transport experts during the poll. > >Nevertheless the MPLS WG chair decided to adopt the draft as a WG = document: > >http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html > >After several WG revisions and WG LCs, the technical issues have n= ot been resolved. > >>Several service providers regarded this draft as not meeting thei= r >>transport >networks' needs. > >This is a true statement: the solution in this draft is useless fo= r many MPLS- TP deployments. > > >-----Original Message----- >From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero= .it] >Sent: quarta-feira, 6 de Julho de 2011 18:26 >To: loa@pi.nu; Rui Costa >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >Subject: R: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >> Version -04 of the document was published June 28th. >> >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi was s= ent >> June 29th. >> > >So when the WG LC to confirm the LC comment resolution has been la= unched? > >The proto write-up says: > > It has also passed a working roup call to verify that = LC comments were correctly with minor comments. > >It also says: > > The comments has been > carefully discussed between the authors and people mak= ing the comments and > has been resolved. > >But it seems that some comments have not been discussed with the a= uthors of the comments. When ITU-T Q10/15 has been involved in discussing its= comments? > > > > >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: quarta-feira, 6 de Julho de 2011 16:44 >To: Rui Costa >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >Subject: Re: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >All, > >Since someone has commented about the process used for resolving >questions on >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group review >process is: > >On February 3rd 2011 the working group last call was issued >on version -03 > > This was copied to the the Ad Hoc Team List > and liaised to SG15 also on February 3rd > > This working group last call ended om Feb 28 > > > On Feb 28 we also received a liaison with comments from SG15 > > >The authors compiled a list of all comments received as part the = MPLS >working group last call; these comments - and the intended resolu= tion - >is included in the meeting minutes from the Prague meeting: > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > During the IETF meeting in Prague, we agreed with the BFD workin= g > group to do a separate working group last callfor the BFD workin= g > group > >The (BFD) working group last call was started on March 30th and ra= n >for 13 days. The last call ended on April 11th. > > The authors have since worked hard to resolve comments, some > issue has been brought to the working group mailing list for > resolution. > > Version -04 of the document was published June 28th. > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was se= nt > June 29th. > > The AD review resulted in a "New ID needed" due to mostly editor= ial > comments. Version -05 was published on June 29 and the IETF last= call > started as soon as the new ID was avaialbe. > > The current list of Last Call Comments resoltion is also avaiabl= e at: > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > The list of issues that the authors kept very carefully, shows w= ithout >doubt > that no comments been ignored. > > Loa > mpls wg document shepherd > > > > > > > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: quarta-feira, 6 de Julho de 2011 14:58 >To: Rui Costa; ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >Hi Rui: > >The comments were not ignored, the resolution of the Q10 comments = as well as those collected from the MPLS WG was presented at the last IETF. My= spreadsheet from which that report was generated and has been augmented to incl= ude the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last-Ca= ll-Comments . xls > >So you know... >Dave > > >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Beha= lf Of Rui Costa >Sent: segunda-feira, 4 de Julho de 2011 23:03 >To: ietf@ietf.org; IETF-Announce >Cc: mpls@ietf.org >Subject: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote D= efect indication for MPLS Transport Profile) to Proposed Standard > >IMHO and for the record: > >ITU-T comments regarding this draft haven't been discussed with IT= U-T but were simply ignored. No LS describing these comments' resolution wa= s sent. > >Several service providers regarded this draft as not meeting their= transport networks' needs. > >[The v03 draft was published in Feb and went to WG LC. >The v04 draft addressing WG LC comments was published on the 28th = June (same date as the proto write-up). >When was the WG LC launched, to verify LC comments resolution?] > >Regards, >Rui > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf Of The IESG >Sent: quinta-feira, 30 de Junho de 2011 14:47 >To: IETF-Announce >Cc: mpls@ietf.org >Subject: [mpls] Last Call: (= Proactive Connectivity Verification, Continuity Check and Remote Defect indic= ation for MPLS Transport Profile) to Proposed Standard > > >The IESG has received a request from the Multiprotocol Label Switc= hing WG >(mpls) to consider the following document: >- 'Proactive Connectivity Verification, Continuity Check and Remot= e > Defect indication for MPLS Transport Profile' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solic= its >final comments on this action. Please send substantive comments to= the >ietf@ietf.org mailing lists by 2011-07-14. 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 > > Continuity Check, Proactive Connectivity Verification and Remot= e > Defect Indication functionalities are required for MPLS-TP OAM. > > Continuity Check monitors the integrity of the continuity of th= e > label switched path for any loss of continuity defect. Connecti= vity > verification monitors the integrity of the routing of the label > switched path between sink and source for any connectivity issu= es. > Remote defect indication enables an End Point to report, to its > associated End Point, a fault or defect condition that it detec= ts on > a pseudo wire, label switched path or Section. > > This document specifies methods for proactive continuity check, > continuity verification, and remote defect indication for MPLS-= TP > label switched paths, pseudo wires and Sections using Bidirecti= onal > Forwarding Detection. > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > >No IPR declarations have been submitted directly on this I-D. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From DanielC@orckit.com Wed Jul 27 10:01:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED1321F8BC4 for ; Wed, 27 Jul 2011 10:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUeb6ysuuQHk for ; Wed, 27 Jul 2011 10:01:40 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3321F8BB9 for ; Wed, 27 Jul 2011 10:01:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C7F.3B625084" Date: Wed, 27 Jul 2011 20:01:35 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED8129@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Is m:n protection a critical requirement? Thread-Index: AcxMYqJRTN4OHV0iRwu8UWJPIHIRgQAG+mOg References: From: "Daniel Cohn" To: "Pablo Frank" , Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:01:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C7F.3B625084 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pablo, =20 When you write "...m:n use-case is probably better handled with shared-mesh protection...", are you talking about a particular m:n mechanism/standard? Can you pls specify? =20 DC =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pablo Frank Sent: Wednesday, July 27, 2011 9:36 AM To: mpls@ietf.org Subject: [mpls] Is m:n protection a critical requirement? =20 There was a question raised in monday's WG meeting as to whether there was a strong use-case for m:n protection. A related question was whether m:n has been standardized in the OTN / SONET world. After we consulted our OTN experts back at the ranch, the general consensus is that while 1+1 and 1:n are well standardized by the ITU-T, m:n is typically left for further study. There are proprietary solutions, including our own, but they don't seem to be widely deployed. I didn't get a specific m:n use-case. I suspect that any m:n use-case is probably better handled with shared-mesh protection anyway. =20 It seems that m:n shows up in all the standards, mainly for theoretical completeness, but never ends up being specified. =20 Based on this, I don't think we should slow-down the current 1:n standardization effort by requiring the authors to embark on an m:n science project. =20 Pablo Frank Ciena =20 =20 ------_=_NextPart_001_01CC4C7F.3B625084 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pablo,

 

When you write “…m:n use-case is probably better handled = with shared-mesh protection…”, are you talking about a = particular m:n mechanism/standard? Can you pls = specify?

 

DC

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Pablo Frank
Sent: Wednesday, July 27, 2011 9:36 = AM
To: mpls@ietf.org
Subject: [mpls] Is m:n = protection a critical requirement?

 

There was a = question raised in monday's WG meeting as to whether there was a strong = use-case for m:n protection.  A related question was whether m:n = has been standardized in the OTN / SONET world.  After we consulted = our OTN experts back at the ranch, the general consensus is that while = 1+1 and 1:n are well standardized by the ITU-T, m:n is typically left = for further study.  There are proprietary solutions, including our = own, but they don't seem to be widely deployed.  I didn't get a = specific m:n use-case.  I suspect that any m:n use-case is probably = better handled with shared-mesh protection anyway.

 

It seems that m:n shows up in all the standards, = mainly for theoretical completeness, but never ends up being = specified.

 

Based on this, I don't think we should slow-down the = current 1:n standardization effort by requiring the authors to embark on = an m:n science project.

 

Pablo Frank

Ciena  =

 

------_=_NextPart_001_01CC4C7F.3B625084-- From david.i.allan@ericsson.com Wed Jul 27 10:51:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20A21F8AF3; Wed, 27 Jul 2011 10:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9YXaUgAgLFa; Wed, 27 Jul 2011 10:51:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id B012111E80DF; Wed, 27 Jul 2011 10:51:15 -0700 (PDT) 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 p6RHonBK018840; Wed, 27 Jul 2011 12:51:13 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 13:51:04 -0400 From: David Allan I To: John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 13:51:02 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:51:18 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI John:
 
Thanks for this!
 
Updating 4928 to me is the right way to go but I'd al= so want=20 to see us revert to restricting GAL to bottom label at the same time.=20 It also means that we are saying SOMETHING prescript= ive=20 about ECMP implementations which is "where no MPLS RFC has gone before", bu= t I=20 for one am OK with that, IMO it is long overdue!
 
cheers
Dave

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 11:56 AM
To: David Alla= n I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_-- From jdrake@juniper.net Wed Jul 27 11:05:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F094B11E80DF; Wed, 27 Jul 2011 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNcoeTi2uoQ4; Wed, 27 Jul 2011 11:05:04 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id D133D11E8075; Wed, 27 Jul 2011 11:05:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTjBTRRpX/nlI6Llpz9i+HZDxt4TpW50A@postini.com; Wed, 27 Jul 2011 11:05:04 PDT 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; Wed, 27 Jul 2011 11:03:26 -0700 From: John E Drake To: David Allan I , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 11:03:25 -0700 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYA== Message-ID: <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:05:07 -0000 --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

<= p class=3DMsoNormal>Unfortunately that is not possible.   = The GAL effectively functions as an application label, and the logic at the= egress node uses the application label, in which it would normally expect = to see BOS set to 1, with BOS  set to 0 as an indicator of the presenc= e of an entropy label.

 

Thanks,

 

John

 

Sent from my iPhon= e

 <= /span>

From: David Allan I [mai= lto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 2011 1= 0:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.o= rg; Kireeti Kompella
Subject: RE: Entropy labels and the GAL....<= o:p>

 

=

HI John:

&= nbsp;

Thanks for this!

 

Upda= ting 4928 to me is the right way to go but I'd also want to see us revert t= o restricting GAL to bottom label at the same time. It also means that=  we are saying SOMETHING prescriptive about ECMP implementations which= is "where no MPLS RFC has gone before", but I for one am OK with= that, IMO it is long overdue!

&n= bsp;

cheers

Dave

 = ;

From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM
To: David Allan = I; pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subjec= t: RE: Entropy labels and the GAL....

Dave,

 

A previous version of t= he Entropy Label draft stipulated that reserved labels were not to be input= to a transit node’s load balancing function;  this was inadvert= ently dropped from the current version but will be re-added to the next ver= sion.  I am thinking that a bis version of Stewart’s ECMP consid= erations RFC that also specifies this behavior would be the appropriate pla= ce to codify this once and for all.

 

Thanks,

 

John

 

Sent= from my iPhone

 

From: pwe3-= bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of David A= llan I
Sent: Wednesday, July 27, 2011 7:09 AM
To: pwe3@= ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy labe= ls and the GAL....

 

HI

 

During yesterda= y's PWE session the subject of GALs and PWs came up.

<= /div>

 

To= reiterate my concern, it was that the use of the GAL for a PW in a network= that could employ ECMP rendered the OAM useless. For some strange reason t= his is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP n= etwork is not (where the explicit prohibition against ECMP means it COULD b= e safely used), huh!???

 <= o:p>

My belief is that permitting th= e use of the GAL for PWs in both domains will result in MS-PWs for which th= e OAM is useless. FM PM, and DM will return false indications due to the la= ck of fate sharing… so different latency, out of order delivery of PM= loss measurement, and potential false positives, or negatives for FM.=

 

<= div>

My conclusion was that IF steps were being taken such that = reserved labels (or at least the GAL) were explicitly excluded from ECMP pr= ocessing THEN it would make sense to open Pandora's box. During the meeting= it was suggested this was the case in work progressing in draft-ietf-mpls-= entropy-label-00 and so I withdrew my objection to things continuing on the= ir merry way.

 =

So I went and read the current version of= the entropy label draft and unfortunately this is only true in a narrow se= nse. Fate sharing would only be preserved for implementations that ONLY has= hed the bottom label of a PW using the entropy label. Not for any generic u= se of the GAL with PWs.

 <= o:p>

So not only do I now believe th= e problem not on it’s way to resolution, IMO the scenario is actually= GETTING WORSE. We are now permitting the GAL to be other than bottom label= to address a narrow case and only a small portion of RFC 4928. I would now= assert that allowing the GAL to be other than the bottom label is a worse = and incomplete solution vs. excluding label 13 from ECMP processing and is = perpetuating a bad situation.

&= nbsp;

So t'was my bad for rolli= ng over yesterday without doing my homework, but there you have it

 

=

Dave

 

BTW If I could make a suggestion, if w= e are XORing one or more labels together prior to doing further processing,= also XOR it with 13, and make the GAL the ONE label value that has no effe= ct. It would do the world a huge favor.

 

 

 

= --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_-- From gregimirsky@gmail.com Wed Jul 27 11:08:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E218821F8B89 for ; Wed, 27 Jul 2011 11:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+R55qt3FJkA for ; Wed, 27 Jul 2011 11:08:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5716B21F8B83 for ; Wed, 27 Jul 2011 11:08:01 -0700 (PDT) Received: by vws12 with SMTP id 12so1694798vws.31 for ; Wed, 27 Jul 2011 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=9xL/SvZOCSYWHwQC+akDVgiE3wqzkVl7w4NwlrEHmdM=; b=CQ0pD5t0AFznod7MFHA+yKzJ0J+hkZ1af05v0e56GTRMVdYdy9ShT++4ncmTymsMO+ Z8VEMEviaD8Nw0wCMRI+GIWB1GAmq3+G3FmkWLS4pa2agK68N6oIOk9lC4q1e3e0l4GF F54tINjSWi3pJfMEZPK9dZY3biG5WuGG+PQgs= MIME-Version: 1.0 Received: by 10.52.89.170 with SMTP id bp10mr100424vdb.493.1311790080668; Wed, 27 Jul 2011 11:08:00 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Wed, 27 Jul 2011 11:08:00 -0700 (PDT) Date: Wed, 27 Jul 2011 11:08:00 -0700 Message-ID: From: Greg Mirsky To: Daniel Cohn , rafir@orckit.com, ms-daikoku@kddi.com, ma.yuxia@zte.com.cn, yang.jian90@zte.com.cn, "D'Alessandro Alessandro Gerardo" , mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec5015f07c7327904a910edcf Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:08:02 -0000 --bcaec5015f07c7327904a910edcf Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, I think that it is function of the PHY layer to detect SD condition and convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical Section). In case of accumulating SD over LSP the e2e Packet Loss measurement, in my view, is addressing the issue. Regards, Greg --bcaec5015f07c7327904a910edcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
I think that it is function of the PHY layer to de= tect SD condition and convert it into Down for the MPLS-TP Layer 0 (what we= refer as Physical Section). In case of accumulating SD over LSP the e2e Pa= cket Loss measurement, in my view, is addressing the issue.

Regards,
Greg
--bcaec5015f07c7327904a910edcf-- From giles.heron@gmail.com Wed Jul 27 11:17:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967B021F8BE9 for ; Wed, 27 Jul 2011 11:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDqdQlaGguu4 for ; Wed, 27 Jul 2011 11:17:30 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 65BF021F8867 for ; Wed, 27 Jul 2011 11:17:30 -0700 (PDT) Received: by pzk6 with SMTP id 6so2901983pzk.26 for ; Wed, 27 Jul 2011 11:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=04anlP9HAwTtfvdrXKNinlrBa6nuZ9wR1vVDLTVoVrI=; b=M9yi21GN/1EfQ2IrcIDfWRA08cBE1lKCueIn84wtnGKl9AEqY2+hq3XXBHMe8REle9 PgasGJ32p08fT/4vaHo7hrb6yGJomlf88f/jUskQ37twYHp5YzPymmehYGVCyI+C/8JK cZJuinOSUL8ADtjUUNZwj7jnfmcHk+sUrKsRk= Received: by 10.68.8.230 with SMTP id u6mr140258pba.515.1311790649871; Wed, 27 Jul 2011 11:17:29 -0700 (PDT) Received: from [10.21.121.104] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id g4sm119804pbj.9.2011.07.27.11.17.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 11:17:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 27 Jul 2011 19:19:13 +0100 From: Giles Heron To: , , Message-ID: Thread-Topic: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? Thread-Index: AcxL01WCAHuEjjUhRfSPv7SRFQWdrQAAPKNgAAEPCaUAEobp8AAZw/u5 In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4405D1A6BFB@EMV62-UKRD.domain1.systemhost.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in section definitions? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:17:31 -0000 On 27/07/2011 07:27, "neil.2.harrison@bt.com" wrote: > Hi Giles...thanks....just one point in-line: > > who said 26 July 2011 22:11> >> But the "real transport network" MPLS sits on may be (and typically is) >> just >> a link. It doesn't have to be a network (in the sense of being >> something >> with more than two nodes and with some form of switching capability). > > NH=> This may or may not be true. We should not make a statement that it is > usually not networked....indeed it is often more efficient to 'switch' at the > lower layer in large traffic aggregates of the client in the core of the > network(s). A link (1-hop) in layer N is created by an E2E path (>=1hop) in > layer N+1 (ie towards the duct layer network direction). That lower layer > network may or may not be owned by the same party as the higher layer network. > It often won't have the same geographic span. It may or may not be the same > network mode as the client.....there is always a space resource layer network > at the very BOS. I was just stating current reality. Most of the MPLS networks I know of sit on top of wavelengths/fibres rather than on top of TDM or packet transport networks. I'd expect it to stay that way, since I don't see benefits in putting another time resource layer network (hopefully using your terminology correctly), whether that is packet or circuit based, below the MPLS layer (as the efficiency benefits of e.g. TDM vs packet are minimal compared to the costs of OEO conversion). In the 1990s we put IP on top of TDM or ATM for two main reasons: 1) Packet processing was slower than optical link speeds. 2) IP was a small portion of the carrier network as a whole. Neither of those two reasons is true in 2011... > A couple of observations one can make here are these: > - one needs to minimise the number of layer networks from true TOS to true > BOS...this obviously affects cost/complexity/reliability/perf/etc...so we > should remove all unnecessary layer networks. Aside=> MS PWs should not exist > in MPLS-TP....PWs are of course an artefact of the loss of source information > created by merging in LDP, but making them *MS* just generates an unnecessary > layer network that really should have no place in MPLS-TP. > - ...however the answer is for sure not one do-it-all layer network...that > view leads to increasing diseconomies of scale/scope. > - similarly, one cannot have a do-it-all common CP (or indeed any DP/CP > functional component) running TOS to BOS. So I'd agree in general on minimising layers (hence not wanting a packet or TDM layer under MPLS). As to PWs, they have multiple functions: 1) improving scale by hiding service state from the core. 2) creating a bidirectional P2P connection on top of 2 unidirectional P2P or MP2P LSPs (the MP2P case is the one you refer to). 3) adapting layer 2 PDUs onto MPLS. Sure, 1 could be solved using LSP hierarchy, and 2 isn't required in MPLS-TP as you have bidirectional P2P LSPs. So yes, it might have been better if we'd separated the functions out more explicitly (hindsight is always 20:20 of course). As for MS-PW in "pure" MPLS-TP I don't see it as useful. However there may be cases where you want an MS-PW that crosses an MPLS-TP access network and then an IP/MPLS core network (and where the S-PE is at the boundary). Giles > regards, Neil > This email contains BT information, which may be privileged or confidential. > It's meant only for the individual(s) or entity named above. If you're not the > intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you've received this email in error, please let me know > immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > >> >>> So the whole discussion about an MPLS 'section layer' is somewhat >>> moot/meaningless IMO. MPLS (any spin) simply has a lowest LSP >> level...below >>> that come the real transport layer networks. >> >> Agreed. >> >> Giles >> >>> regards, Neil >>> This email contains BT information, which may be privileged or >> confidential. >>> It's meant only for the individual(s) or entity named above. If >> you're not the >>> intended >>> recipient, note that disclosing, copying, distributing or using this >>> information >>> is prohibited. If you've received this email in error, please let me >> know >>> immediately >>> on the email address above. Thank you. >>> We monitor our email system, and may record your emails. >>> British Telecommunications plc >>> Registered office: 81 Newgate Street London EC1A 7AJ >>> Registered in England no: 1800000 >>> >>> >>> >>> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Greg >>> Mirsky >>> Sent: 26 July 2011 21:34 >>> To: David Allan I >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency >> in >>> section definitions? >>> >>> Hi Dave, Daniel, and All, >>> I'd like to start from Section MEP ID as defined in MPLS-TP ID >> document. I >>> think that there should not be distinction in Section MEP ID whether >> it is >>> Physical Section (Layer 0 for MPLS-TP) or Logical Section (Layer n-1 >> LSP). I >>> think that making MEP ID of Logical Section identical to MEP ID of >> Server >>> layer LSP MEP ID creates issues with properly executing PM OAM on >> Section >>> layer and Server layer LSP. >>> >>> Regards, >>> Greg >>> On Tue, Jul 26, 2011 at 12:52 PM, David Allan I >>> > >> wrote: >>> HI Daniel: >>> >>> We have a bit of an inconsistency creeping in in numerous places.... >>> >>> By the definition of a section as any (sub) layer "minus one" path >> component, >>> then a section can be a physical link for an SPME or LSP, an SPME for >> a LSP, >>> an LSP for a PW etc. >>> >>> So to invent terms to facilitate this discussion we have a physical >> section >>> (non-MPLS link) and a logical section (some MPLS path construct) >>> >>> Which means we have established procedures for configuring OAM for >> any logical >>> section, but as Greg Mirsky noted today, not for a physical section, >> at least >>> not ones we'd necessarily want to use. We have MEP identifiers >> specific to a >>> physical section in the identifiers draft what we would not use for >> logical >>> sections as we really do not need multiple identities for maintenance >> entity >>> components. I'm sure we have a few other places where this small >> dichotomy >>> raises its head. >>> >>> Nor do we want to confuse physical sections with logical sections.... >>> >>> Hence if we are to resolve some of this without revisiting >> established RFCs we >>> need to introduce some distinction to further define section "types" >> along the >>> lines I've suggested above (physcial and logical)... and apply it >> across the >>> current document set. >>> >>> WDYT? >>> Dave >>> >>> >>> >>> ________________________________ >>> From: mpls-bounces@ietf.org >>> [mailto:mpls-bounces@ietf.org] On >> Behalf Of >>> Daniel Cohn >>> Sent: Tuesday, July 26, 2011 1:55 PM >>> To: mpls@ietf.org >>> Subject: [mpls] draft-ietf-mpls-tp-oam-framework - inconsistency in >> section >>> definitions? >>> Hi, >>> >>> In several places in draft-ietf-mpls-tp-oam-framework-10, it is >> assumed and >>> sometimes explicitly stated that an MPLS-TP section is equivalent to >> a >>> non-MPLS-TP link (aka data link). >>> >>> See for example (there's more): >>> "MPLS-TP Section: As defined in [8], it is a link that can be >> traversed by >>> one or more MPLS-TP LSPs." >>> "in case of an MPLS-TP section, the MEG is inferred from the port on >> which an >>> OAM packet was received with the GAL at the top of the label stack" >>> "An SMEG is intended to be deployed for applications where it is >> preferable to >>> monitor the link between topologically adjacent..." >>> >>> However, as per RFC 5654 and especially RFC5960 >>> (http://tools.ietf.org/html/rfc5960#section-3.2), an MPLS-TP section >> can also >>> be an LSP carrying another LSP (SPME or generic H-LSP), or an LSP >> carrying a >>> PW. >>> >>> If my understanding is correct, the section OAM requirements in >>> draft-ietf-mpls-tp-oam-framework-10 are only relevant for data-link >> sections >>> (n=0 following RFC 5960 terminology). In this case, this should be >> clarified >>> in the draft. >>> >>> Comments? >>> >>> Regards, >>> >>> Daniel >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> > From david.i.allan@ericsson.com Wed Jul 27 11:18:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA221F8BB9; Wed, 27 Jul 2011 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqu2lR05-Af3; Wed, 27 Jul 2011 11:17:58 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0715921F8867; Wed, 27 Jul 2011 11:17:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6RIHvsb004739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2011 13:17:57 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 14:17:56 -0400 From: David Allan I To: John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:17:54 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KA Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D557C@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:18:01 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm confused, this suggests that the GAL is an ELI for OAM and somthing els= e is an ELI for payload. IMO that seems broken unless you are only hashing = top label. Presumably an entropy label can alias as a GAL or RA as well..? D ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm confused, this suggests that the GAL is an ELI fo= r OAM and=20 somthing else is an ELI for payload. IMO that seems broken unless you are o= nly=20 hashing top label.
 
Presumably an entropy label can alias as a GAL or RA = as=20 well..?
 
D
 
 

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_-- From DanielC@orckit.com Wed Jul 27 11:22:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A8F11E8103 for ; Wed, 27 Jul 2011 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPOOpYTU1YU5 for ; Wed, 27 Jul 2011 11:22:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 280E711E8116 for ; Wed, 27 Jul 2011 11:22:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C8A.7715D626" Date: Wed, 27 Jul 2011 21:21:59 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED8132@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxMiIOKaW7s33+ITlCekA7lBwhtlQAANU+w References: From: "Daniel Cohn" To: "Greg Mirsky" , "Rafi Ram" , , , , "D'Alessandro Alessandro Gerardo" , Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:22:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C8A.7715D626 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg and all, =20 The view of the authors is that you cannot rely on traffic (OAM or else) to detect error condition, because of: =20 - Implicit sampling bias - OAM messages are not an unbiased sample of all traffic, e.g. they have a specific (typically short) length, transmission periodicity, etc. - Traffic can be affected by congestion or other non-physical error conditions =20 That's why we don't think we should leave accumulated error detection to the transport path layer. =20 Regards, =20 Daniel =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Wednesday, July 27, 2011 2:08 PM To: Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org Subject: Comments to draft-rkhd-mpls-tp-sd-03 =20 Dear Authors and All, I think that it is function of the PHY layer to detect SD condition and convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical Section). In case of accumulating SD over LSP the e2e Packet Loss measurement, in my view, is addressing the issue. Regards, Greg ------_=_NextPart_001_01CC4C8A.7715D626 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg and all,

 

The view of the authors is that you cannot rely on traffic (OAM or = else) to detect error condition, because of:

 

-          = Implicit sampling bias - OAM messages are not an unbiased sample of = all traffic, e.g. they have a specific (typically short) length, = transmission periodicity, etc.

-          = Traffic can be affected by congestion or other non-physical error = conditions

 

That’s why we don’t think we should leave accumulated = error detection to the transport path layer.

 

Regards,

 

Daniel

 

From:= = Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Wednesday, = July 27, 2011 2:08 PM
To: Daniel Cohn; Rafi Ram; = ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; = D'Alessandro Alessandro Gerardo; mpls@ietf.org
Subject: = Comments to draft-rkhd-mpls-tp-sd-03

 

Dear Authors = and All,
I think that it is function of the PHY layer to detect SD = condition and convert it into Down for the MPLS-TP Layer 0 (what we = refer as Physical Section). In case of accumulating SD over LSP the e2e = Packet Loss measurement, in my view, is addressing the = issue.

Regards,
Greg

------_=_NextPart_001_01CC4C8A.7715D626-- From david.i.allan@ericsson.com Wed Jul 27 11:26:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662E611E809E; Wed, 27 Jul 2011 11:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPVwLSTwavf3; Wed, 27 Jul 2011 11:26:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 238DD11E8125; Wed, 27 Jul 2011 11:26:27 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RIQLcG026776; Wed, 27 Jul 2011 13:26:22 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 14:26:19 -0400 From: David Allan I To: David Allan I , John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:26:17 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KAAACdDtA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D5598@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:26:30 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I withdraw the second comment... D ________________________________ From: David Allan I Sent: Wednesday, July 27, 2011 2:18 PM To: 'John E Drake'; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... I'm confused, this suggests that the GAL is an ELI for OAM and somthing els= e is an ELI for payload. IMO that seems broken unless you are only hashing = top label. Presumably an entropy label can alias as a GAL or RA as well..? D ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I withdraw the second comment...
 
D

From: David Allan I
Sent: We= dnesday,=20 July 27, 2011 2:18 PM
To: 'John E Drake'; pwe3@ietf.org
Cc:= =20 mpls@ietf.org; Kireeti Kompella
Subject: RE: Entropy labels and t= he=20 GAL....

I'm confused, this suggests that the GAL is an ELI fo= r OAM and=20 somthing else is an ELI for payload. IMO that seems broken unless you are o= nly=20 hashing top label.
 
Presumably an entropy label can alias as a GAL or RA = as=20 well..?
 
D
 
 

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_-- From david.i.allan@ericsson.com Wed Jul 27 11:36:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E4621F8B53; Wed, 27 Jul 2011 11:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46Ai8fS1KVgn; Wed, 27 Jul 2011 11:36:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id D900221F8B3C; Wed, 27 Jul 2011 11:36:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RIaiKW029120; Wed, 27 Jul 2011 13:36:49 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 27 Jul 2011 14:36:42 -0400 From: David Allan I To: David Allan I , John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:36:40 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KAAADXB+A= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:36:53 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for repeated messages.... I'm confused as to why the GAL takes the role of the application label. It = does not seem necessary. If I want PW OAM the PW label would need to be the= re, if I were to fate share with the path taken for the flow associated wit= h the entopy label, the TL, AL, ELI etc. all have to be there as the draft = recommends using the whole stack as a key. So IMO there is no apparent justification for overloading the GAL and remov= ing the BOS restriction...There is justification for not hashing reserved l= abels... ? Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Apologies for repeated messages....
 
I'm=20 confused as to why the GAL takes the role of the application label. It= does=20 not seem necessary. If I want PW OAM the PW label would = ;need=20 to be there, if I were to fate share with the path taken for the flow= =20 associated with the entopy label, the TL, AL, ELI etc. all have to be there= as=20 the draft recommends using the whole stack as a=20 key. 
 
So IMO=20 there is no apparent justification for overloading the GAL and removing the= BOS=20 restriction...There is justification for not hashing reserved=20 labels...
 
?
Dave
 
 
From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_-- From stbryant@cisco.com Wed Jul 27 11:48:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C6411E8143; Wed, 27 Jul 2011 11:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6CWmwCco2C7; Wed, 27 Jul 2011 11:48:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F811E8084; Wed, 27 Jul 2011 11:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1290; q=dns/txt; s=iport; t=1311792525; x=1313002125; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=OsnFxgkOspkZaMwY0GAW0Uar1N8QzKrgstJjs5ZpiZw=; b=i8vnzP0Lrwf+aFixD7kXjx9VnzvAdHTZDzdtGjtO8XgCXcDSP4hs8x0+ kYlObipzplcNMMRg1VfZTk2COn2opXHTIGsvJQWTSrcl65o4Ha75rMWve +N+hfmelLbKpqbJuMQfNREhRTmkPTAhMN/mTiIYCNA6ZwQe7SP8Zrlkug A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMZcME6Q/khM/2dsb2JhbAAoDQEBAQECARQBBAFqAQUMDAMBHSIPCQMCAQIBAlEHDgEOAQEfpyN3iHyjKYMWDwGbRoZABJJ1kGM X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="45015943" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:48:44 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RImiU0017608; Wed, 27 Jul 2011 18:48:44 GMT Received: from dhcp-57a9.meeting.ietf.org (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6RImg9r023283; Wed, 27 Jul 2011 19:48:43 +0100 (BST) Message-ID: <4E305D8A.3080600@cisco.com> Date: Wed, 27 Jul 2011 19:48:42 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: David Allan I References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------070300060506000608040003" Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:48:52 -0000 This is a multi-part message in MIME format. --------------070300060506000608040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > There /is/ justification for not hashing reserved labels... That would fix a bunch of the OAM problems, but unfortunately would not be backwards compatible with deployed P routers or SPEs Stewart --------------070300060506000608040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

> There is justification for not hashing reserved labels...

That would fix a bunch of the OAM problems, but unfortunately 
would not be backwards compatible with deployed
P routers or SPEs

Stewart
 --------------070300060506000608040003-- From david.i.allan@ericsson.com Wed Jul 27 11:52:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1411E8084; Wed, 27 Jul 2011 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMoXKxPB+TFQ; Wed, 27 Jul 2011 11:52:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 68BDD21F8BA4; Wed, 27 Jul 2011 11:52:40 -0700 (PDT) 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 p6RIqc6P000305; Wed, 27 Jul 2011 13:52:39 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 14:52:35 -0400 From: David Allan I To: "stbryant@cisco.com" Date: Wed, 27 Jul 2011 14:52:35 -0400 Thread-Topic: [PWE3] Entropy labels and the GAL.... Thread-Index: AcxMjdbi8RLYVFA6SA+OdaTm68h1DgAACn1w Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D55DD@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> <4E305D8A.3080600@cisco.com> In-Reply-To: <4E305D8A.3080600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Entropy labels and the GAL.... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:52:43 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which gets back to my original point, creating an environment where we woul= d use a GAL where existing kit would obstruct fate sharing is IMO a mistake= ... I can't stuff toothpaste back into the tube, but I can avoid squeezing the = tube again.... D ________________________________ From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, July 27, 2011 2:49 PM To: David Allan I Cc: John E Drake; pwe3@ietf.org; Kireeti Kompella; mpls@ietf.org Subject: Re: [PWE3] Entropy labels and the GAL.... > There is justification for not hashing reserved labels... That would fix a bunch of the OAM problems, but unfortunately would not be backwards compatible with deployed P routers or SPEs Stewart --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Which gets back to my original point, creating an env= ironment=20 where we would use a GAL where existing kit would obstruct fate sharing is = IMO a=20 mistake...
 
I can't stuff toothpaste back into the tube, but I ca= n avoid=20 squeezing the tube again....
 
D

From: Stewart Bryant [mailto:stbryant@c= isco.com]=20
Sent: Wednesday, July 27, 2011 2:49 PM
To: David Allan= =20 I
Cc: John E Drake; pwe3@ietf.org; Kireeti Kompella;=20 mpls@ietf.org
Subject: Re: [PWE3] Entropy labels and the=20 GAL....



> There is justification for not hashing reserved= =20 labels...

That would fix a bunch of the OAM problems, but=20 unfortunately 
would not be backwards compatible with deployed P=20 routers or SPEs

Stewart
 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_-- From pabloisnot@gmail.com Wed Jul 27 12:31:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC9D5E800F for ; Wed, 27 Jul 2011 12:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJzxttViOiv0 for ; Wed, 27 Jul 2011 12:31:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE615E800B for ; Wed, 27 Jul 2011 12:31:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so1254387qyk.10 for ; Wed, 27 Jul 2011 12:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pX7M1VhB/r/6pCbcNMr7u88jtbIsaKJZw0IJhtWtIkw=; b=O9liFisJ+pnmSGs5/UBqqU9OolWTQGvCEAKZ+eCd83U8RYt3X/cHLFBWXbNVfsbUY0 sRHK781kdumx3wh9tdvWkmPikXFOAkPEy44gNLS14z/NLtIF3El5vadcen1EpCeH0xUS XhfhuNBEIVR9+qsDj4+JgwGj3Y/rb637CtX1Y= MIME-Version: 1.0 Received: by 10.224.27.75 with SMTP id h11mr159133qac.231.1311795079895; Wed, 27 Jul 2011 12:31:19 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Wed, 27 Jul 2011 12:31:19 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED8129@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED8129@tlvmail1> Date: Wed, 27 Jul 2011 15:31:19 -0400 Message-ID: From: Pablo Frank To: Daniel Cohn Content-Type: multipart/alternative; boundary=bcaec51b15f7c158f204a9121752 Cc: mpls@ietf.org Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:31:21 -0000 --bcaec51b15f7c158f204a9121752 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, Sorry, I wasn't particularly clear. I was just inserting some of my own intuition (i.e. I can't imagine any realistic use-case for m:n). There's n= o standard mechanism for m:n so really nothing that we can evaluate against. When I asked our experts if we've ever encountered m:n use-cases in our OT= N or sonet deployments, the response was that we always just solved the problem using shared mesh protection (of which we've deployed tonnes). cheers, Pablo On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn wrote: > Hi Pablo,**** > > ** ** > > When you write =93=85m:n use-case is probably better handled with shared-= mesh > protection=85=94, are you talking about a particular m:n mechanism/standa= rd? Can > you pls specify?**** > > ** ** > > DC**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Pablo Frank > *Sent:* Wednesday, July 27, 2011 9:36 AM > *To:* mpls@ietf.org > *Subject:* [mpls] Is m:n protection a critical requirement?**** > > ** ** > > There was a question raised in monday's WG meeting as to whether there wa= s > a strong use-case for m:n protection. A related question was whether m:n > has been standardized in the OTN / SONET world. After we consulted our O= TN > experts back at the ranch, the general consensus is that while 1+1 and 1:= n > are well standardized by the ITU-T, m:n is typically left for further stu= dy. > There are proprietary solutions, including our own, but they don't seem = to > be widely deployed. I didn't get a specific m:n use-case. I suspect tha= t > any m:n use-case is probably better handled with shared-mesh protection > anyway.**** > > ** ** > > It seems that m:n shows up in all the standards, mainly for theoretical > completeness, but never ends up being specified.**** > > ** ** > > Based on this, I don't think we should slow-down the current 1:n > standardization effort by requiring the authors to embark on an m:n scien= ce > project.**** > > ** ** > > Pablo Frank**** > > Ciena **** > > ** ** > --bcaec51b15f7c158f204a9121752 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel,

Sorry, I wasn't particularly clear. =A0I = was just inserting some of my own intuition (i.e. I can't imagine any r= ealistic use-case for m:n). =A0There's no standard mechanism for m:n so= really nothing that we can evaluate against. =A0When I asked our experts i= f we've ever encountered m:n use-cases in our OTN or sonet deployments,= the response was that we always just solved the problem using shared mesh = protection (of which we've deployed tonnes).

cheers,
Pablo

On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn <DanielC@orckit.com> wrote:

Hi Pablo,

=A0

When you write =93=85m:n use-case is probably better hand= led with shared-mesh protection=85=94, are you talking about a particular m= :n mechanism/standard? Can you pls specify?

=A0

DC

=A0

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] = On Behalf Of Pablo Frank
Sent: Wednesday, July 27, 2011 9:36 AM
To: mpls@ietf.org
Subject: [m= pls] Is m:n protection a critical requirement?

=A0

There wa= s a question raised in monday's WG meeting as to whether there was a st= rong use-case for m:n protection. =A0A related question was whether m:n has= been standardized in the OTN / SONET world. =A0After we consulted our OTN = experts back at the ranch, the general consensus is that while 1+1 and 1:n = are well standardized by the ITU-T, m:n is typically left for further study= . =A0There are proprietary solutions, including our own, but they don't= seem to be widely deployed. =A0I didn't get a specific m:n use-case. = =A0I suspect that any m:n use-case is probably better handled with shared-m= esh protection anyway.

=A0

It seems that m:n shows up in all the standards, mainly for theoret= ical completeness, but never ends up being specified.

=A0

Based on this, I don't think we should slow-down the current 1:= n standardization effort by requiring the authors to embark on an m:n scien= ce project.

=A0

Pablo Frank

Ciena=A0

=A0


--bcaec51b15f7c158f204a9121752-- From maarten.vissers@huawei.com Wed Jul 27 12:49:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8011E8155 for ; Wed, 27 Jul 2011 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrP-PnPKYz-j for ; Wed, 27 Jul 2011 12:49:20 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id AB32011E8084 for ; Wed, 27 Jul 2011 12:49:19 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0001FMCE5WG@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 20:49:18 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LP00049UCE522@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 20:49:17 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 20:49:09 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 20:49:16 +0100 Date: Wed, 27 Jul 2011 19:49:16 +0000 From: Maarten vissers In-reply-to: X-Originating-IP: [10.47.78.88] To: Eric Gray , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:49:22 -0000 G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, p2mp unidir connections. The p2p bidir connection can be co-routed, and then it is possible to perform e.g. loopback at intermediate nodes. The p2p bidir connection can be associated, and then a loopback at an intermediate node will not be possible. But the end-to-end monitoring is still performed without problems. Note that a co-routed bidir 1+1 protected connection can select it's A-to-Z traffic from working and its Z-to-A traffic from protection; this effectively creates an associated bidir connection in which e2e monitoring is supported but loopbacks at intermediate nodes are not successful. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: 27 July 2011 18:32 > To: mpls@ietf.org > Subject: [mpls] FW: R: RE: Last Call: 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Forwarding in plain text... > > ________________________________ > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Wednesday, July 13, 2011 10:57 PM > To: erminio.ottone_69@libero.it > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] R: RE: Last Call: 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > > Dear Erminio, > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is > even more narrow then of the document being discussed. The G.8113.1 > addresses only bi-directional co-routed LSP and has no model to handle > bi-directional associated LSP in independent mode. And unidirectional > p2p and p2mp LSPs are not addressed by the current revision of the > G.8113.1. > Can all these out-of-scope constructs be used to conclude that G.8113.1 > is not capable to solve these issues? I don't think so. Solutions are > not readily available, that's all. > > Regards, > Greg > > > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > wrote: > > > >I would not go so far as to say "similar to 1731", there is > actually a lot of > difference under the hood. As for uni-directional BFD, that is > a BFD WG problem > at the moment. > > > The fact that the BFD WG has not defined a solution for > unidirectional p2p and > p2mp transport paths does not make BFD a suitable OAM protocol > for MPLS-TP nor > does resolve the technical issue that have been raised. > > > >----Messaggio originale---- > >Da: david.i.allan@ericsson.com > > >Data: 8-lug-2011 18.13 > >A: "Rui Costa", "Stewart > Bryant" > >Cc: > "erminio.ottone_69@libero.it", "mpls@ietf. > org", "ietf@ietf.org", "IETF- > Announce" announce@ietf.org> > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed > Standard > > > >Rui: > > > > >You wrote: > > > >>Reading something, keeping it on record, without effect in > the draft and > "ignoring comments" have IMHO similar outcomes. As author of > the draft you are > free to do it. These standards have a great impact > >>in our work, so i'm also free to write what i did. > > > > >Numerous comments did have effect on the draft and those that > didn't were > either simply not actionable, were rhetorical or not > constructive, and a few > had to be balanced against comments coming from the MPLS & BFD > WGs. I would > translate "ingored" or "without effect" to "did not get one'e > way". In the > standards process it happens. > > > >Meanwhile as an editor of the document, I'll take the liberty > of responding > to some of the points you raise... > > > > >>My technical concerns regarding this draft were expressed... > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it > (LS281, i > believe); > >>...in operators' meetings' that took place during ITU-T's > Feb/2011 plenary > meeting; > > > > >I and the WG don't really have access to private grumblings. > > > > >>...in a comparison session that took place during that same > ITU-T meeting. > > > > >Lots of other opinions were expressed as well, and they did > not all agree > with you. > > > > >>Some: > >>CC/CV > >>I don't understand the need for 2 types of packets: a single > type allows CC; > mismatching identifiers in the same CC packets allow CV. > >>Besides adding complexity, we whether always activate both or > potentiate > undetected mismerges. > > > > >OK, lets walk through this. > > > >We want CV all the time so that any misconectivity can be > detected, but on > the list it was expressed that the group did not want the > overhead of > processing the source MEP TLV in every packet in order to > achieve this. We > could carry it in every packet and have the receiver simply > ignore most of > them, but then that would make the defect entry criteria > compeltely random and > the exit criteria unreliable as well, not really a good design. > Hence they are > separated using different ACH code points and the receiver is > obliged to > process every source MEP TLV it receives. I hope this is clear. > > > > >>(BTW: can't understand how we propose one ACH codepoint to > CC, another for > CV, [counting other drafts, another for frame loss ...] but > don't consider > assigning 1 single ACH protocol identifier codepoint >as > requested by ITU-T) > > > > >Because that puts you into two protocol ID demultiplexing > steps per OAM PDU > recevied to determine the intended function. Hence COSTS MORE. > That is pretty > basic... > > > > >> Uni P2P / P2MP > >> I can't see how BFD will support unidir and hence P2MP other > than... > >> ...eliminating the session "state variable" (down, init, > up), aiming just > the state variables we really need, bringing us to something > similar to 1731, > eventually with other bits on the wire or... > >> ...using IP to create the reverse way, which we cannot > assume per > requirements; > >> Will we create a complete different tool for that? > >> (BFD's B="bidirectional") > > > > >I would not go so far as to say "similar to 1731", there is > actually a lot of > difference under the hood. As for uni-directional BFD, that is > a BFD WG problem > at the moment. > > > > >> Provisioning list > >> This is an MPLS profile/subset (and i heard) achievable > through a > particular configuration. So, i expect each draft-ietf-mpls-TP- > * to focus on > that profile/configuration. However, i keep seeing > >> references f.i. to IP encapsulations unexpected under TP's > OAM. > >> I don't thus understand what the aim is: do we expect this > in TP, are we > talking about MPLS in general?... The TP profile is never quite > delimited. > >> Does chapter 4 contain ALL the configurable parameters list > agreed to > provide in the comparison session? > > > > >It should. As for encapsulations, unless TP is in a complete > island not > connected to anything (which as a network is rather useless) it > will be > expected to interoperate with the rest of the MPLS > architecture, and the stated > intention of tool development was that what resulted was > applicable to the > broader MPLS architecture. Which means backwards compatiblity > and procedures > for interoperation. > > > > >> Backwards compatibility > >> This was the main argument risen to ground MPLS-TP OAM on > BFD. It's not a > better argument than grounding MPLS-TP OAM on 1731 due to its > ETH deployment > plus coherence with SDH, OTN, as defended by ITU-T. > >> For reasons like the above, however, MPLS-TP BFD won't be > backwards > compatible with previous BFD (even considering just CC/CV). > They don't even > share the same codepoint. > > > > >The issue is not code point, which is the trivial part. It is > reuse of the > majority of the implementation. Again, pretty basic. > > > > >>Simplicity > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to > CC is simpler: > in each flow, a standard defined nr of constant heartbeat > signals (with > standard constant or provisioned period - no > >>auto/negotiated -) means OK. A standard defined number of > misses means lost > Rx connection. An RDI, the only articulation between Rx and Tx > flows, > meaningful in bidirectional applications, allows each > >>pear to identify Tx problems. > >>This OAM simplicity is the key for reliable fail finger > pointing, > performance reports and protection. Also to allow scaling, more > implementation > opportunities/manufacturers, which is valuable for > >>operators. > > > > >Well IMO there was not a lot of interest in T-MPLS until the > IETF was going > to re-define it and make it compatible with IP/MPLS. So there > was an industry > wide "design intent" implied here. > > > > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more > and more > difficult to tell which is which. > > > > >That is because MPLS-TP is not a new techology, it is an > addition to the > entire MPLS protocol suite. > > > >Hope this helps > >D > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > > >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; > IETF-Announce > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] R: Re: Last Call: cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >Hi Erminio: > > > > > >>Several service providers regarded this draft as not meeting > their > >>transport networks' needs. > > > > >E> This is a true statement: the solution in this draft is > useless for many > MPLS- TP deployments. > > > > >The two statements do not necessarily follow. > > > >What we established during discussions at the SG15 plenary in > February was > that the issue some service providers had was that the IETF BFD > solution > exceeded their requirements in that there was additional > functionality they did > not see a need for, and that they considered any additional > functionality > parasitic. > > > >However this is a consequence of adapting an existing > technology to a new > application. I do not see any way around that. And the entire > joint project was > based on the premise of engineering re-use not greenfield > design. That is what > it said on the tin up front, and IMO why when the IETF started > down this path > packet transport transitioned from being a minority sport to > mainstream, so it > is a bit late to cry foul.... > > > >My 2 cents > >Dave > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >Subject: RE: [mpls] R: Re: Last Call: cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >Hi Erminio: > > > >Two of the three document editors were present at SG15 plenary > in February > where the comments originated. The revised meeting schedule > resulted in a day > spent going through the document with the editors. IMO there > were lots of > discussion and legitimate issues with the document identified > and corrected so > it was a useful session. The liaison of same was in many ways > *after the > fact*. > > > >Cheers > >Dave > > > > > > > > > > >-----Original Message----- > >From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > > >Subject: R: Re: [mpls] Last Call: rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >The way this draft has been developed is a bit strange. > > > >The poll for its adoption as a WG document was halted by the > MPLS WG chair > because "it is not possible to judge consensus": > > > >http://www.ietf.org/mail- > archive/web/mpls/current/msg04502.html > > > >The lack of consensus was motivated by serious technical > concerns raised by > several transport experts during the poll. > > > >Nevertheless the MPLS WG chair decided to adopt the draft as a > WG document: > > > >http://www.ietf.org/mail- > archive/web/mpls/current/msg04512.html > > > >After several WG revisions and WG LCs, the technical issues > have not been > resolved. > > > > >>Several service providers regarded this draft as not meeting > their > >>transport > >networks' needs. > > > > >This is a true statement: the solution in this draft is > useless for many > MPLS- TP deployments. > > > > > > >-----Original Message----- > >From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > > >To: loa@pi.nu; Rui Costa > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >Subject: R: Re: [mpls] Last Call: rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >> Version -04 of the document was published June 28th. > >> > > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi > was sent > >> June 29th. > >> > > > >So when the WG LC to confirm the LC comment resolution has > been launched? > > > >The proto write-up says: > > > > It has also passed a working roup call to verify > that LC comments > were correctly with minor comments. > > > >It also says: > > > > The comments has been > > carefully discussed between the authors and people > making the > comments and > > has been resolved. > > > >But it seems that some comments have not been discussed with > the authors of > the comments. When ITU-T Q10/15 has been involved in discussing > its comments? > > > > > > > > > >-----Original Message----- > >From: Loa Andersson [mailto:loa@pi.nu] > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > >To: Rui Costa > > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > >Subject: Re: [mpls] Last Call: 05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >All, > > > >Since someone has commented about the process used for > resolving > >questions on > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details > below. > > > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group > review > >process is: > > > >On February 3rd 2011 the working group last call was issued > >on version -03 > > > > This was copied to the the Ad Hoc Team List > > and liaised to SG15 also on February 3rd > > > > This working group last call ended om Feb 28 > > > > > > On Feb 28 we also received a liaison with comments from > SG15 > > > > > >The authors compiled a list of all comments received as part > the MPLS > >working group last call; these comments - and the intended > resolution - > >is included in the meeting minutes from the Prague meeting: > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > During the IETF meeting in Prague, we agreed with the BFD > working > > group to do a separate working group last callfor the BFD > working > > group > > > >The (BFD) working group last call was started on March 30th > and ran > >for 13 days. The last call ended on April 11th. > > > > The authors have since worked hard to resolve comments, some > > issue has been brought to the working group mailing list for > > resolution. > > > > Version -04 of the document was published June 28th. > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > June 29th. > > > > The AD review resulted in a "New ID needed" due to mostly > editorial > > comments. Version -05 was published on June 29 and the IETF > last call > > started as soon as the new ID was avaialbe. > > > > The current list of Last Call Comments resoltion is also > avaiable at: > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > The list of issues that the authors kept very carefully, > shows without > >doubt > > that no comments been ignored. > > > > Loa > > mpls wg document shepherd > > > > > > > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] Last Call: 05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >Hi Rui: > > > >The comments were not ignored, the resolution of the Q10 > comments as well as > > those collected from the MPLS WG was presented at the last > IETF. My spreadsheet > > from which that report was generated and has been augmented to > include the BFD > > WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi- > Last-Call-Comments Comments> . > xls > > > > >So you know... > >Dave > > > > > >-----Original Message----- > > >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Rui > Costa > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > > >To: ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > >Subject: RE: [mpls] Last Call: 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >IMHO and for the record: > > > >ITU-T comments regarding this draft haven't been discussed > with ITU-T but > were simply ignored. No LS describing these comments' > resolution was sent. > > > > >Several service providers regarded this draft as not meeting > their transport > networks' needs. > > > > >[The v03 draft was published in Feb and went to WG LC. > >The v04 draft addressing WG LC comments was published on the > 28th June (same > date as the proto write-up). > >When was the WG LC launched, to verify LC comments > resolution?] > > > >Regards, > >Rui > > > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of The > IESG > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > >To: IETF-Announce > >Cc: mpls@ietf.org > > >Subject: [mpls] Last Call: 05.txt> (Proactive > > Connectivity Verification, Continuity Check and Remote Defect > indication for > MPLS Transport Profile) to Proposed Standard > > > > > > >The IESG has received a request from the Multiprotocol Label > Switching WG > >(mpls) to consider the following document: > >- 'Proactive Connectivity Verification, Continuity Check and > Remote > > Defect indication for MPLS Transport Profile' > > 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 2011-07-14. 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 > > > > Continuity Check, Proactive Connectivity Verification and > Remote > > Defect Indication functionalities are required for MPLS-TP > OAM. > > > > Continuity Check monitors the integrity of the continuity > of the > > label switched path for any loss of continuity defect. > Connectivity > > verification monitors the integrity of the routing of the > label > > switched path between sink and source for any connectivity > issues. > > Remote defect indication enables an End Point to report, to > its > > associated End Point, a fault or defect condition that it > detects on > > a pseudo wire, label switched path or Section. > > > > This document specifies methods for proactive continuity > check, > > continuity verification, and remote defect indication for > MPLS-TP > > label switched paths, pseudo wires and Sections using > Bidirectional > > Forwarding Detection. > > > > > >The file can be obtained via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > >IESG discussion can be tracked via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > >No IPR declarations have been submitted directly on this I-D. > >_______________________________________________ > > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Wed Jul 27 12:59:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079B21F8891 for ; Wed, 27 Jul 2011 12:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXLAKKAjFWV2 for ; Wed, 27 Jul 2011 12:59:47 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24521F859C for ; Wed, 27 Jul 2011 12:59:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6RJwvZ3012707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2011 14:58:58 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 15:58:32 -0400 From: Gregory Mirsky To: Maarten vissers , "mpls@ietf.org" Date: Wed, 27 Jul 2011 15:54:11 -0400 Thread-Topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcAAAID/GA== 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:59:49 -0000 Dear Maarten, the question was raised in regard to CC/CV, a.k.a. CCM, functionality. I ap= ologize that I didn't state that explicitly and left it as implied context = of the discussion. I don't question G.8113.1 capabilities you've listed but= only compare with corresponding CCM addressed in CC-CV-RDI. Regards, Greg ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Maarten vi= ssers [maarten.vissers@huawei.com] Sent: Wednesday, July 27, 2011 3:49 PM To: Eric Gray; mpls@ietf.org Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defe= ct indication for MPLS Transport Profile) to Proposed Standard G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, p2mp u= nidir connections. The p2p bidir connection can be co-routed, and then it is possible to perfo= rm e.g. loopback at intermediate nodes. The p2p bidir connection can be associated, and then a loopback at an inter= mediate node will not be possible. But the end-to-end monitoring is still p= erformed without problems. Note that a co-routed bidir 1+1 protected connection can select it's A-to-Z= traffic from working and its Z-to-A traffic from protection; this effectiv= ely creates an associated bidir connection in which e2e monitoring is suppo= rted but loopbacks at intermediate nodes are not successful. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: 27 July 2011 18:32 > To: mpls@ietf.org > Subject: [mpls] FW: R: RE: Last Call: 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Forwarding in plain text... > > ________________________________ > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Wednesday, July 13, 2011 10:57 PM > To: erminio.ottone_69@libero.it > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > ietf@ietf.org; IETF-Announce > Subject: Re: [mpls] R: RE: Last Call: 05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > > Dear Erminio, > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is > even more narrow then of the document being discussed. The G.8113.1 > addresses only bi-directional co-routed LSP and has no model to handle > bi-directional associated LSP in independent mode. And unidirectional > p2p and p2mp LSPs are not addressed by the current revision of the > G.8113.1. > Can all these out-of-scope constructs be used to conclude that G.8113.1 > is not capable to solve these issues? I don't think so. Solutions are > not readily available, that's all. > > Regards, > Greg > > > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > wrote: > > > >I would not go so far as to say "similar to 1731", there is > actually a lot of > difference under the hood. As for uni-directional BFD, that is > a BFD WG problem > at the moment. > > > The fact that the BFD WG has not defined a solution for > unidirectional p2p and > p2mp transport paths does not make BFD a suitable OAM protocol > for MPLS-TP nor > does resolve the technical issue that have been raised. > > > >----Messaggio originale---- > >Da: david.i.allan@ericsson.com > > >Data: 8-lug-2011 18.13 > >A: "Rui Costa", "Stewart > Bryant" > >Cc: > "erminio.ottone_69@libero.it", "mpls@ietf. > org", "ietf@ietf.org", "IETF- > Announce" announce@ietf.org> > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed > Standard > > > >Rui: > > > > >You wrote: > > > >>Reading something, keeping it on record, without effect in > the draft and > "ignoring comments" have IMHO similar outcomes. As author of > the draft you are > free to do it. These standards have a great impact > >>in our work, so i'm also free to write what i did. > > > > >Numerous comments did have effect on the draft and those that > didn't were > either simply not actionable, were rhetorical or not > constructive, and a few > had to be balanced against comments coming from the MPLS & BFD > WGs. I would > translate "ingored" or "without effect" to "did not get one'e > way". In the > standards process it happens. > > > >Meanwhile as an editor of the document, I'll take the liberty > of responding > to some of the points you raise... > > > > >>My technical concerns regarding this draft were expressed... > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it > (LS281, i > believe); > >>...in operators' meetings' that took place during ITU-T's > Feb/2011 plenary > meeting; > > > > >I and the WG don't really have access to private grumblings. > > > > >>...in a comparison session that took place during that same > ITU-T meeting. > > > > >Lots of other opinions were expressed as well, and they did > not all agree > with you. > > > > >>Some: > >>CC/CV > >>I don't understand the need for 2 types of packets: a single > type allows CC; > mismatching identifiers in the same CC packets allow CV. > >>Besides adding complexity, we whether always activate both or > potentiate > undetected mismerges. > > > > >OK, lets walk through this. > > > >We want CV all the time so that any misconectivity can be > detected, but on > the list it was expressed that the group did not want the > overhead of > processing the source MEP TLV in every packet in order to > achieve this. We > could carry it in every packet and have the receiver simply > ignore most of > them, but then that would make the defect entry criteria > compeltely random and > the exit criteria unreliable as well, not really a good design. > Hence they are > separated using different ACH code points and the receiver is > obliged to > process every source MEP TLV it receives. I hope this is clear. > > > > >>(BTW: can't understand how we propose one ACH codepoint to > CC, another for > CV, [counting other drafts, another for frame loss ...] but > don't consider > assigning 1 single ACH protocol identifier codepoint >as > requested by ITU-T) > > > > >Because that puts you into two protocol ID demultiplexing > steps per OAM PDU > recevied to determine the intended function. Hence COSTS MORE. > That is pretty > basic... > > > > >> Uni P2P / P2MP > >> I can't see how BFD will support unidir and hence P2MP other > than... > >> ...eliminating the session "state variable" (down, init, > up), aiming just > the state variables we really need, bringing us to something > similar to 1731, > eventually with other bits on the wire or... > >> ...using IP to create the reverse way, which we cannot > assume per > requirements; > >> Will we create a complete different tool for that? > >> (BFD's B=3D"bidirectional") > > > > >I would not go so far as to say "similar to 1731", there is > actually a lot of > difference under the hood. As for uni-directional BFD, that is > a BFD WG problem > at the moment. > > > > >> Provisioning list > >> This is an MPLS profile/subset (and i heard) achievable > through a > particular configuration. So, i expect each draft-ietf-mpls-TP- > * to focus on > that profile/configuration. However, i keep seeing > >> references f.i. to IP encapsulations unexpected under TP's > OAM. > >> I don't thus understand what the aim is: do we expect this > in TP, are we > talking about MPLS in general?... The TP profile is never quite > delimited. > >> Does chapter 4 contain ALL the configurable parameters list > agreed to > provide in the comparison session? > > > > >It should. As for encapsulations, unless TP is in a complete > island not > connected to anything (which as a network is rather useless) it > will be > expected to interoperate with the rest of the MPLS > architecture, and the stated > intention of tool development was that what resulted was > applicable to the > broader MPLS architecture. Which means backwards compatiblity > and procedures > for interoperation. > > > > >> Backwards compatibility > >> This was the main argument risen to ground MPLS-TP OAM on > BFD. It's not a > better argument than grounding MPLS-TP OAM on 1731 due to its > ETH deployment > plus coherence with SDH, OTN, as defended by ITU-T. > >> For reasons like the above, however, MPLS-TP BFD won't be > backwards > compatible with previous BFD (even considering just CC/CV). > They don't even > share the same codepoint. > > > > >The issue is not code point, which is the trivial part. It is > reuse of the > majority of the implementation. Again, pretty basic. > > > > >>Simplicity > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to > CC is simpler: > in each flow, a standard defined nr of constant heartbeat > signals (with > standard constant or provisioned period - no > >>auto/negotiated -) means OK. A standard defined number of > misses means lost > Rx connection. An RDI, the only articulation between Rx and Tx > flows, > meaningful in bidirectional applications, allows each > >>pear to identify Tx problems. > >>This OAM simplicity is the key for reliable fail finger > pointing, > performance reports and protection. Also to allow scaling, more > implementation > opportunities/manufacturers, which is valuable for > >>operators. > > > > >Well IMO there was not a lot of interest in T-MPLS until the > IETF was going > to re-define it and make it compatible with IP/MPLS. So there > was an industry > wide "design intent" implied here. > > > > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more > and more > difficult to tell which is which. > > > > >That is because MPLS-TP is not a new techology, it is an > addition to the > entire MPLS protocol suite. > > > >Hope this helps > >D > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > > >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; > IETF-Announce > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] R: Re: Last Call: cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >Hi Erminio: > > > > > >>Several service providers regarded this draft as not meeting > their > >>transport networks' needs. > > > > >E> This is a true statement: the solution in this draft is > useless for many > MPLS- TP deployments. > > > > >The two statements do not necessarily follow. > > > >What we established during discussions at the SG15 plenary in > February was > that the issue some service providers had was that the IETF BFD > solution > exceeded their requirements in that there was additional > functionality they did > not see a need for, and that they considered any additional > functionality > parasitic. > > > >However this is a consequence of adapting an existing > technology to a new > application. I do not see any way around that. And the entire > joint project was > based on the premise of engineering re-use not greenfield > design. That is what > it said on the tin up front, and IMO why when the IETF started > down this path > packet transport transitioned from being a minority sport to > mainstream, so it > is a bit late to cry foul.... > > > >My 2 cents > >Dave > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >Subject: RE: [mpls] R: Re: Last Call: cv-rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >Hi Erminio: > > > >Two of the three document editors were present at SG15 plenary > in February > where the comments originated. The revised meeting schedule > resulted in a day > spent going through the document with the editors. IMO there > were lots of > discussion and legitimate issues with the document identified > and corrected so > it was a useful session. The liaison of same was in many ways > *after the > fact*. > > > >Cheers > >Dave > > > > > > > > > > >-----Original Message----- > >From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > > >Subject: R: Re: [mpls] Last Call: rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >The way this draft has been developed is a bit strange. > > > >The poll for its adoption as a WG document was halted by the > MPLS WG chair > because "it is not possible to judge consensus": > > > >http://www.ietf.org/mail- > archive/web/mpls/current/msg04502.html > > > >The lack of consensus was motivated by serious technical > concerns raised by > several transport experts during the poll. > > > >Nevertheless the MPLS WG chair decided to adopt the draft as a > WG document: > > > >http://www.ietf.org/mail- > archive/web/mpls/current/msg04512.html > > > >After several WG revisions and WG LCs, the technical issues > have not been > resolved. > > > > >>Several service providers regarded this draft as not meeting > their > >>transport > >networks' needs. > > > > >This is a true statement: the solution in this draft is > useless for many > MPLS- TP deployments. > > > > > > >-----Original Message----- > >From: erminio.ottone_69@libero.it > [mailto:erminio.ottone_69@libero.it] > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > > >To: loa@pi.nu; Rui Costa > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >Subject: R: Re: [mpls] Last Call: rdi-05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >> Version -04 of the document was published June 28th. > >> > > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi > was sent > >> June 29th. > >> > > > >So when the WG LC to confirm the LC comment resolution has > been launched? > > > >The proto write-up says: > > > > It has also passed a working roup call to verify > that LC comments > were correctly with minor comments. > > > >It also says: > > > > The comments has been > > carefully discussed between the authors and people > making the > comments and > > has been resolved. > > > >But it seems that some comments have not been discussed with > the authors of > the comments. When ITU-T Q10/15 has been involved in discussing > its comments? > > > > > > > > > >-----Original Message----- > >From: Loa Andersson [mailto:loa@pi.nu] > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > >To: Rui Costa > > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > >Subject: Re: [mpls] Last Call: 05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >All, > > > >Since someone has commented about the process used for > resolving > >questions on > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details > below. > > > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group > review > >process is: > > > >On February 3rd 2011 the working group last call was issued > >on version -03 > > > > This was copied to the the Ad Hoc Team List > > and liaised to SG15 also on February 3rd > > > > This working group last call ended om Feb 28 > > > > > > On Feb 28 we also received a liaison with comments from > SG15 > > > > > >The authors compiled a list of all comments received as part > the MPLS > >working group last call; these comments - and the intended > resolution - > >is included in the meeting minutes from the Prague meeting: > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > During the IETF meeting in Prague, we agreed with the BFD > working > > group to do a separate working group last callfor the BFD > working > > group > > > >The (BFD) working group last call was started on March 30th > and ran > >for 13 days. The last call ended on April 11th. > > > > The authors have since worked hard to resolve comments, some > > issue has been brought to the working group mailing list for > > resolution. > > > > Version -04 of the document was published June 28th. > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi was > sent > > June 29th. > > > > The AD review resulted in a "New ID needed" due to mostly > editorial > > comments. Version -05 was published on June 29 and the IETF > last call > > started as soon as the new ID was avaialbe. > > > > The current list of Last Call Comments resoltion is also > avaiable at: > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > The list of issues that the authors kept very carefully, > shows without > >doubt > > that no comments been ignored. > > > > Loa > > mpls wg document shepherd > > > > > > > > > > > > > > > > >-----Original Message----- > >From: David Allan I [mailto:david.i.allan@ericsson.com] > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] Last Call: 05.txt> > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > >Hi Rui: > > > >The comments were not ignored, the resolution of the Q10 > comments as well as > > those collected from the MPLS WG was presented at the last > IETF. My spreadsheet > > from which that report was generated and has been augmented to > include the BFD > > WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi- > Last-Call-Comments Comments> . > xls > > > > >So you know... > >Dave > > > > > >-----Original Message----- > > >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Rui > Costa > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > > >To: ietf@ietf.org; IETF-Announce > >Cc: mpls@ietf.org > >Subject: RE: [mpls] Last Call: 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > Remote Defect > > indication for MPLS Transport Profile) to Proposed Standard > > > > >IMHO and for the record: > > > >ITU-T comments regarding this draft haven't been discussed > with ITU-T but > were simply ignored. No LS describing these comments' > resolution was sent. > > > > >Several service providers regarded this draft as not meeting > their transport > networks' needs. > > > > >[The v03 draft was published in Feb and went to WG LC. > >The v04 draft addressing WG LC comments was published on the > 28th June (same > date as the proto write-up). > >When was the WG LC launched, to verify LC comments > resolution?] > > > >Regards, > >Rui > > > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of The > IESG > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > >To: IETF-Announce > >Cc: mpls@ietf.org > > >Subject: [mpls] Last Call: 05.txt> (Proactive > > Connectivity Verification, Continuity Check and Remote Defect > indication for > MPLS Transport Profile) to Proposed Standard > > > > > > >The IESG has received a request from the Multiprotocol Label > Switching WG > >(mpls) to consider the following document: > >- 'Proactive Connectivity Verification, Continuity Check and > Remote > > Defect indication for MPLS Transport Profile' > > 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 2011-07-14. 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 > > > > Continuity Check, Proactive Connectivity Verification and > Remote > > Defect Indication functionalities are required for MPLS-TP > OAM. > > > > Continuity Check monitors the integrity of the continuity > of the > > label switched path for any loss of continuity defect. > Connectivity > > verification monitors the integrity of the routing of the > label > > switched path between sink and source for any connectivity > issues. > > Remote defect indication enables an End Point to report, to > its > > associated End Point, a fault or defect condition that it > detects on > > a pseudo wire, label switched path or Section. > > > > This document specifies methods for proactive continuity > check, > > continuity verification, and remote defect indication for > MPLS-TP > > label switched paths, pseudo wires and Sections using > Bidirectional > > Forwarding Detection. > > > > > >The file can be obtained via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > >IESG discussion can be tracked via > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ > > > > > >No IPR declarations have been submitted directly on this I-D. > >_______________________________________________ > > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From maarten.vissers@huawei.com Wed Jul 27 13:16:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5344C11E80D5 for ; Wed, 27 Jul 2011 13:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS3EdOm85ZhY for ; Wed, 27 Jul 2011 13:16:48 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfa.amsl.com (Postfix) with ESMTP id E401D11E8073 for ; Wed, 27 Jul 2011 13:16:47 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000025DNWGI@lhrga04-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 21:16:44 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0008SIDNWBB@lhrga04-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 21:16:44 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 21:16:36 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 21:16:43 +0100 Date: Wed, 27 Jul 2011 20:16:42 +0000 From: Maarten vissers In-reply-to: X-Originating-IP: [10.47.78.88] To: Gregory Mirsky , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcAAAID/GAAAQHbg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:16:50 -0000 Dear Greg, G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in - co-routed bidir p2p, - associated bidir p2p, - unidir p2p and - unidir p2mp PW, LSP, SPME and section connections. > The G.8113.1 addresses only bi-directional co-routed LSP and has no model to > handle bi-directional associated LSP in independent mode. And unidirectional > p2p and p2mp LSPs are not addressed by the current revision of the G.8113.1. > Can all these out-of-scope constructs be used to conclude that G.8113.1 > is not capable to solve these issues? I don't think so. Solutions are > not readily available, that's all. Solution for CCM is already available in G.8113.1. I.e. G.8113.1 already resolved these issues as such. Regards, Maarten > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: 27 July 2011 21:54 > To: Maarten vissers; mpls@ietf.org > Subject: RE: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Dear Maarten, > the question was raised in regard to CC/CV, a.k.a. CCM, functionality. > I apologize that I didn't state that explicitly and left it as implied > context of the discussion. I don't question G.8113.1 capabilities > you've listed but only compare with corresponding CCM addressed in CC- > CV-RDI. > > Regards, > Greg > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Maarten vissers [maarten.vissers@huawei.com] > Sent: Wednesday, July 27, 2011 3:49 PM > To: Eric Gray; mpls@ietf.org > Subject: Re: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, > p2mp unidir connections. > > The p2p bidir connection can be co-routed, and then it is possible to > perform e.g. loopback at intermediate nodes. > > The p2p bidir connection can be associated, and then a loopback at an > intermediate node will not be possible. But the end-to-end monitoring > is still performed without problems. > > Note that a co-routed bidir 1+1 protected connection can select it's A- > to-Z traffic from working and its Z-to-A traffic from protection; this > effectively creates an associated bidir connection in which e2e > monitoring is supported but loopbacks at intermediate nodes are not > successful. > > Regards, > Maarten > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Eric Gray > > Sent: 27 July 2011 18:32 > > To: mpls@ietf.org > > Subject: [mpls] FW: R: RE: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Forwarding in plain text... > > > > ________________________________ > > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > Sent: Wednesday, July 13, 2011 10:57 PM > > To: erminio.ottone_69@libero.it > > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > > ietf@ietf.org; IETF-Announce > > Subject: Re: [mpls] R: RE: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > > > Dear Erminio, > > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM > is > > even more narrow then of the document being discussed. The G.8113.1 > > addresses only bi-directional co-routed LSP and has no model to > handle > > bi-directional associated LSP in independent mode. And unidirectional > > p2p and p2mp LSPs are not addressed by the current revision of the > > G.8113.1. > > Can all these out-of-scope constructs be used to conclude that > G.8113.1 > > is not capable to solve these issues? I don't think so. Solutions are > > not readily available, that's all. > > > > Regards, > > Greg > > > > > > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > > wrote: > > > > > > >I would not go so far as to say "similar to 1731", there is > > actually a lot of > > difference under the hood. As for uni-directional BFD, that > is > > a BFD WG problem > > at the moment. > > > > > > The fact that the BFD WG has not defined a solution for > > unidirectional p2p and > > p2mp transport paths does not make BFD a suitable OAM > protocol > > for MPLS-TP nor > > does resolve the technical issue that have been raised. > > > > > > >----Messaggio originale---- > > >Da: david.i.allan@ericsson.com > > > > >Data: 8-lug-2011 18.13 > > >A: "Rui Costa", "Stewart > > Bryant" > > >Cc: > > "erminio.ottone_69@libero.it", > "mpls@ietf. > > org", "ietf@ietf.org", "IETF- > > Announce" > announce@ietf.org> > > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi- > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed > > Standard > > > > > >Rui: > > > > > > > >You wrote: > > > > > >>Reading something, keeping it on record, without effect in > > the draft and > > "ignoring comments" have IMHO similar outcomes. As author of > > the draft you are > > free to do it. These standards have a great impact > > >>in our work, so i'm also free to write what i did. > > > > > > > >Numerous comments did have effect on the draft and those > that > > didn't were > > either simply not actionable, were rhetorical or not > > constructive, and a few > > had to be balanced against comments coming from the MPLS & > BFD > > WGs. I would > > translate "ingored" or "without effect" to "did not get one'e > > way". In the > > standards process it happens. > > > > > >Meanwhile as an editor of the document, I'll take the > liberty > > of responding > > to some of the points you raise... > > > > > > > >>My technical concerns regarding this draft were > expressed... > > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it > > (LS281, i > > believe); > > >>...in operators' meetings' that took place during ITU-T's > > Feb/2011 plenary > > meeting; > > > > > > > >I and the WG don't really have access to private grumblings. > > > > > > > >>...in a comparison session that took place during that same > > ITU-T meeting. > > > > > > > >Lots of other opinions were expressed as well, and they did > > not all agree > > with you. > > > > > > > >>Some: > > >>CC/CV > > >>I don't understand the need for 2 types of packets: a > single > > type allows CC; > > mismatching identifiers in the same CC packets allow CV. > > >>Besides adding complexity, we whether always activate both > or > > potentiate > > undetected mismerges. > > > > > > > >OK, lets walk through this. > > > > > >We want CV all the time so that any misconectivity can be > > detected, but on > > the list it was expressed that the group did not want the > > overhead of > > processing the source MEP TLV in every packet in order to > > achieve this. We > > could carry it in every packet and have the receiver simply > > ignore most of > > them, but then that would make the defect entry criteria > > compeltely random and > > the exit criteria unreliable as well, not really a good > design. > > Hence they are > > separated using different ACH code points and the receiver is > > obliged to > > process every source MEP TLV it receives. I hope this is > clear. > > > > > > > >>(BTW: can't understand how we propose one ACH codepoint to > > CC, another for > > CV, [counting other drafts, another for frame loss ...] but > > don't consider > > assigning 1 single ACH protocol identifier codepoint >as > > requested by ITU-T) > > > > > > > >Because that puts you into two protocol ID demultiplexing > > steps per OAM PDU > > recevied to determine the intended function. Hence COSTS > MORE. > > That is pretty > > basic... > > > > > > > >> Uni P2P / P2MP > > >> I can't see how BFD will support unidir and hence P2MP > other > > than... > > >> ...eliminating the session "state variable" (down, init, > > up), aiming just > > the state variables we really need, bringing us to something > > similar to 1731, > > eventually with other bits on the wire or... > > >> ...using IP to create the reverse way, which we cannot > > assume per > > requirements; > > >> Will we create a complete different tool for that? > > >> (BFD's B="bidirectional") > > > > > > > >I would not go so far as to say "similar to 1731", there is > > actually a lot of > > difference under the hood. As for uni-directional BFD, that > is > > a BFD WG problem > > at the moment. > > > > > > > >> Provisioning list > > >> This is an MPLS profile/subset (and i heard) achievable > > through a > > particular configuration. So, i expect each draft-ietf-mpls- > TP- > > * to focus on > > that profile/configuration. However, i keep seeing > > >> references f.i. to IP encapsulations unexpected under TP's > > OAM. > > >> I don't thus understand what the aim is: do we expect this > > in TP, are we > > talking about MPLS in general?... The TP profile is never > quite > > delimited. > > >> Does chapter 4 contain ALL the configurable parameters > list > > agreed to > > provide in the comparison session? > > > > > > > >It should. As for encapsulations, unless TP is in a complete > > island not > > connected to anything (which as a network is rather useless) > it > > will be > > expected to interoperate with the rest of the MPLS > > architecture, and the stated > > intention of tool development was that what resulted was > > applicable to the > > broader MPLS architecture. Which means backwards compatiblity > > and procedures > > for interoperation. > > > > > > > >> Backwards compatibility > > >> This was the main argument risen to ground MPLS-TP OAM on > > BFD. It's not a > > better argument than grounding MPLS-TP OAM on 1731 due to its > > ETH deployment > > plus coherence with SDH, OTN, as defended by ITU-T. > > >> For reasons like the above, however, MPLS-TP BFD won't be > > backwards > > compatible with previous BFD (even considering just CC/CV). > > They don't even > > share the same codepoint. > > > > > > > >The issue is not code point, which is the trivial part. It > is > > reuse of the > > majority of the implementation. Again, pretty basic. > > > > > > > >>Simplicity > > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach > to > > CC is simpler: > > in each flow, a standard defined nr of constant heartbeat > > signals (with > > standard constant or provisioned period - no > > >>auto/negotiated -) means OK. A standard defined number of > > misses means lost > > Rx connection. An RDI, the only articulation between Rx and > Tx > > flows, > > meaningful in bidirectional applications, allows each > > >>pear to identify Tx problems. > > >>This OAM simplicity is the key for reliable fail finger > > pointing, > > performance reports and protection. Also to allow scaling, > more > > implementation > > opportunities/manufacturers, which is valuable for > > >>operators. > > > > > > > >Well IMO there was not a lot of interest in T-MPLS until the > > IETF was going > > to re-define it and make it compatible with IP/MPLS. So there > > was an industry > > wide "design intent" implied here. > > > > > > > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes > more > > and more > > difficult to tell which is which. > > > > > > > >That is because MPLS-TP is not a new techology, it is an > > addition to the > > entire MPLS protocol suite. > > > > > >Hope this helps > > >D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > > > > >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; > > IETF-Announce > > >Cc: mpls@ietf.org > > > > >Subject: RE: [mpls] R: Re: Last Call: cc- > > cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >Hi Erminio: > > > > > > > > >>Several service providers regarded this draft as not > meeting > > their > > >>transport networks' needs. > > > > > > > >E> This is a true statement: the solution in this draft is > > useless for many > > MPLS- TP deployments. > > > > > > > >The two statements do not necessarily follow. > > > > > >What we established during discussions at the SG15 plenary > in > > February was > > that the issue some service providers had was that the IETF > BFD > > solution > > exceeded their requirements in that there was additional > > functionality they did > > not see a need for, and that they considered any additional > > functionality > > parasitic. > > > > > >However this is a consequence of adapting an existing > > technology to a new > > application. I do not see any way around that. And the entire > > joint project was > > based on the premise of engineering re-use not greenfield > > design. That is what > > it said on the tin up front, and IMO why when the IETF > started > > down this path > > packet transport transitioned from being a minority sport to > > mainstream, so it > > is a bit late to cry foul.... > > > > > >My 2 cents > > >Dave > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > > > > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > >Subject: RE: [mpls] R: Re: Last Call: cc- > > cv-rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >Hi Erminio: > > > > > >Two of the three document editors were present at SG15 > plenary > > in February > > where the comments originated. The revised meeting schedule > > resulted in a day > > spent going through the document with the editors. IMO there > > were lots of > > discussion and legitimate issues with the document identified > > and corrected so > > it was a useful session. The liaison of same was in many ways > > *after the > > fact*. > > > > > >Cheers > > >Dave > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: erminio.ottone_69@libero.it > > [mailto:erminio.ottone_69@libero.it] > > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > >Cc: mpls@ietf.org > > > > >Subject: R: Re: [mpls] Last Call: > rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > >The way this draft has been developed is a bit strange. > > > > > >The poll for its adoption as a WG document was halted by the > > MPLS WG chair > > because "it is not possible to judge consensus": > > > > > >http://www.ietf.org/mail- > > archive/web/mpls/current/msg04502.html > > > > > >The lack of consensus was motivated by serious technical > > concerns raised by > > several transport experts during the poll. > > > > > >Nevertheless the MPLS WG chair decided to adopt the draft as > a > > WG document: > > > > > >http://www.ietf.org/mail- > > archive/web/mpls/current/msg04512.html > > > > > >After several WG revisions and WG LCs, the technical issues > > have not been > > resolved. > > > > > > > >>Several service providers regarded this draft as not > meeting > > their > > >>transport > > >networks' needs. > > > > > > > >This is a true statement: the solution in this draft is > > useless for many > > MPLS- TP deployments. > > > > > > > > > > >-----Original Message----- > > >From: erminio.ottone_69@libero.it > > [mailto:erminio.ottone_69@libero.it] > > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > > > > >To: loa@pi.nu; Rui Costa > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > >Subject: R: Re: [mpls] Last Call: > rdi-05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >> Version -04 of the document was published June 28th. > > >> > > > > >> The publication request for draft-ietf-mpls-tp-cc-cv-rdi > > was sent > > >> June 29th. > > >> > > > > > >So when the WG LC to confirm the LC comment resolution has > > been launched? > > > > > >The proto write-up says: > > > > > > It has also passed a working roup call to verify > > that LC comments > > were correctly with minor comments. > > > > > >It also says: > > > > > > The comments has been > > > carefully discussed between the authors and > people > > making the > > comments and > > > has been resolved. > > > > > >But it seems that some comments have not been discussed with > > the authors of > > the comments. When ITU-T Q10/15 has been involved in > discussing > > its comments? > > > > > > > > > > > > > > >-----Original Message----- > > >From: Loa Andersson [mailto:loa@pi.nu] > > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > > >To: Rui Costa > > > > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > > >Subject: Re: [mpls] Last Call: rdi- > > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > >All, > > > > > >Since someone has commented about the process used for > > resolving > > >questions on > > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details > > below. > > > > > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group > > review > > >process is: > > > > > >On February 3rd 2011 the working group last call was issued > > >on version -03 > > > > > > This was copied to the the Ad Hoc Team List > > > and liaised to SG15 also on February 3rd > > > > > > This working group last call ended om Feb 28 > > > > > > > > > On Feb 28 we also received a liaison with comments > from > > SG15 > > > > > > > > >The authors compiled a list of all comments received as > part > > the MPLS > > >working group last call; these comments - and the intended > > resolution - > > >is included in the meeting minutes from the Prague meeting: > > > > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > > > > During the IETF meeting in Prague, we agreed with the BFD > > working > > > group to do a separate working group last callfor the BFD > > working > > > group > > > > > >The (BFD) working group last call was started on March 30th > > and ran > > >for 13 days. The last call ended on April 11th. > > > > > > The authors have since worked hard to resolve comments, > some > > > issue has been brought to the working group mailing list > for > > > resolution. > > > > > > Version -04 of the document was published June 28th. > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi > was > > sent > > > June 29th. > > > > > > The AD review resulted in a "New ID needed" due to mostly > > editorial > > > comments. Version -05 was published on June 29 and the > IETF > > last call > > > started as soon as the new ID was avaialbe. > > > > > > The current list of Last Call Comments resoltion is also > > avaiable at: > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > > > The list of issues that the authors kept very carefully, > > shows without > > >doubt > > > that no comments been ignored. > > > > > > Loa > > > mpls wg document shepherd > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > >Cc: mpls@ietf.org > > > > >Subject: RE: [mpls] Last Call: rdi- > > 05.txt> > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > >Hi Rui: > > > > > >The comments were not ignored, the resolution of the Q10 > > comments as well as > > > > those collected from the MPLS WG was presented at the last > > IETF. My spreadsheet > > > > from which that report was generated and has been augmented > to > > include the BFD > > > > WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi- > > Last-Call-Comments > Comments> . > > xls > > > > > > > >So you know... > > >Dave > > > > > > > > >-----Original Message----- > > > > >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] > On > > Behalf Of Rui > > Costa > > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > > > > >To: ietf@ietf.org; IETF-Announce > > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] Last Call: rdi- > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check and > > Remote Defect > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >IMHO and for the record: > > > > > >ITU-T comments regarding this draft haven't been discussed > > with ITU-T but > > were simply ignored. No LS describing these comments' > > resolution was sent. > > > > > > > >Several service providers regarded this draft as not meeting > > their transport > > networks' needs. > > > > > > > >[The v03 draft was published in Feb and went to WG LC. > > >The v04 draft addressing WG LC comments was published on the > > 28th June (same > > date as the proto write-up). > > >When was the WG LC launched, to verify LC comments > > resolution?] > > > > > >Regards, > > >Rui > > > > > > > > >-----Original Message----- > > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > > Behalf Of The > > IESG > > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > > >To: IETF-Announce > > >Cc: mpls@ietf.org > > > > >Subject: [mpls] Last Call: > 05.txt> (Proactive > > > > Connectivity Verification, Continuity Check and Remote Defect > > indication for > > MPLS Transport Profile) to Proposed Standard > > > > > > > > > > >The IESG has received a request from the Multiprotocol Label > > Switching WG > > >(mpls) to consider the following document: > > >- 'Proactive Connectivity Verification, Continuity Check and > > Remote > > > Defect indication for MPLS Transport Profile' > > > 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 2011-07-14. 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 > > > > > > Continuity Check, Proactive Connectivity Verification and > > Remote > > > Defect Indication functionalities are required for MPLS- > TP > > OAM. > > > > > > Continuity Check monitors the integrity of the continuity > > of the > > > label switched path for any loss of continuity defect. > > Connectivity > > > verification monitors the integrity of the routing of the > > label > > > switched path between sink and source for any > connectivity > > issues. > > > Remote defect indication enables an End Point to report, > to > > its > > > associated End Point, a fault or defect condition that it > > detects on > > > a pseudo wire, label switched path or Section. > > > > > > This document specifies methods for proactive continuity > > check, > > > continuity verification, and remote defect indication for > > MPLS-TP > > > label switched paths, pseudo wires and Sections using > > Bidirectional > > > Forwarding Detection. > > > > > > > > >The file can be obtained via > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- > rdi/ > > > > > >IESG discussion can be tracked via > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- > rdi/ > > > > > > > > >No IPR declarations have been submitted directly on this I- > D. > > >_______________________________________________ > > > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > >_______________________________________________ > > >Ietf mailing list > > >Ietf@ietf.org > > >https://www.ietf.org/mailman/listinfo/ietf > > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Wed Jul 27 13:57:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D427011E80A8 for ; Wed, 27 Jul 2011 13:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj2VR1-0tE7G for ; Wed, 27 Jul 2011 13:57:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3FAC11E8082 for ; Wed, 27 Jul 2011 13:57:03 -0700 (PDT) Received: by vxi40 with SMTP id 40so1842923vxi.31 for ; Wed, 27 Jul 2011 13:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C8fSrh4kPyd9OsRHsCFxABn175GpR07M2RIJPvUW85s=; b=L1kadRXFl5MJj/RalVjyVRERSwntr1D+n234jWviSs5CGBvh6PWp6YVVnQVh+bWOgc mKMuyuAXVYTtuT41dgeow9oyClIaZ8wkrzX7gBs1y7hBEfjeq1NJd756d0fic1q9cDOR MOVCJk5YCFk1w2yCaYA+yxeKPrlsMPpXBWVEU= MIME-Version: 1.0 Received: by 10.52.72.20 with SMTP id z20mr322882vdu.225.1311800221414; Wed, 27 Jul 2011 13:57:01 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Wed, 27 Jul 2011 13:57:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 13:57:01 -0700 Message-ID: From: Greg Mirsky To: Maarten vissers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:57:06 -0000 Dear Maarten, I hope you can help me to interpret the following text from the TD 377 (PLEN/15), Geneva, 14-25 February 2011: "The MPLS-TP OAM mechanisms as described in this Recommendation apply to co-routed bidirectional point-to-point MPLS-TP connections. Unidirectional point-to-point and point-to-multipoint MPLS-TP connections will be addressed in a future version of this Recommendation." Regards, Greg On Wed, Jul 27, 2011 at 1:16 PM, Maarten vissers wrote: > Dear Greg, > > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in > - co-routed bidir p2p, > - associated bidir p2p, > - unidir p2p and > - unidir p2mp > PW, LSP, SPME and section connections. > >> The G.8113.1 addresses only bi-directional co-routed LSP and has no mode= l to >> handle bi-directional associated LSP in independent mode. And unidirecti= onal >> p2p and p2mp LSPs are not addressed by the current revision of the G.811= 3.1. >> Can all these out-of-scope constructs be used to conclude that G.8113.1 >> is not capable to solve these issues? I don't think so. Solutions are >> not readily available, that's all. > > Solution for CCM is already available in G.8113.1. > I.e. G.8113.1 already resolved these issues as such. > > Regards, > Maarten > > >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: 27 July 2011 21:54 >> To: Maarten vissers; mpls@ietf.org >> Subject: RE: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> Dear Maarten, >> the question was raised in regard to CC/CV, a.k.a. CCM, functionality. >> I apologize that I didn't state that explicitly and left it as implied >> context of the discussion. I don't question G.8113.1 capabilities >> you've listed but only compare with corresponding CCM addressed in CC- >> CV-RDI. >> >> Regards, >> Greg >> ________________________________________ >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of >> Maarten vissers [maarten.vissers@huawei.com] >> Sent: Wednesday, July 27, 2011 3:49 PM >> To: Eric Gray; mpls@ietf.org >> Subject: Re: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, >> p2mp unidir connections. >> >> The p2p bidir connection can be co-routed, and then it is possible to >> perform e.g. loopback at intermediate nodes. >> >> The p2p bidir connection can be associated, and then a loopback at an >> intermediate node will not be possible. But the end-to-end monitoring >> is still performed without problems. >> >> Note that a co-routed bidir 1+1 protected connection can select it's A- >> to-Z traffic from working and its Z-to-A traffic from protection; this >> effectively creates an associated bidir connection in which e2e >> monitoring is supported but loopbacks at intermediate nodes are not >> successful. >> >> Regards, >> Maarten >> >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> > Eric Gray >> > Sent: 27 July 2011 18:32 >> > To: mpls@ietf.org >> > Subject: [mpls] FW: R: RE: Last Call: > > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> > Remote Defect indication for MPLS Transport Profile) to Proposed >> > Standard >> > >> > Forwarding in plain text... >> > >> > ________________________________ >> > >> > From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> > Sent: Wednesday, July 13, 2011 10:57 PM >> > To: erminio.ottone_69@libero.it >> > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; >> > ietf@ietf.org; IETF-Announce >> > Subject: Re: [mpls] R: RE: Last Call: > > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> > Remote Defect indication for MPLS Transport Profile) to Proposed >> > Standard >> > >> > >> > Dear Erminio, >> > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM >> is >> > even more narrow then of the document being discussed. The G.8113.1 >> > addresses only bi-directional co-routed LSP and has no model to >> handle >> > bi-directional associated LSP in independent mode. And unidirectional >> > p2p and p2mp LSPs are not addressed by the current revision of the >> > G.8113.1. >> > Can all these out-of-scope constructs be used to conclude that >> G.8113.1 >> > is not capable to solve these issues? I don't think so. Solutions are >> > not readily available, that's all. >> > >> > Regards, >> > Greg >> > >> > >> > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it >> > wrote: >> > >> > >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731", th= ere is >> > actually a lot of >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional BFD,= that >> is >> > a BFD WG problem >> > =A0 =A0 =A0 =A0 at the moment. >> > >> > >> > =A0 =A0 =A0 =A0 The fact that the BFD WG has not defined a solution fo= r >> > unidirectional p2p and >> > =A0 =A0 =A0 =A0 p2mp transport paths does not make BFD a suitable OAM >> protocol >> > for MPLS-TP nor >> > =A0 =A0 =A0 =A0 does resolve the technical issue that have been raised= . >> > >> > >> > =A0 =A0 =A0 =A0 >----Messaggio originale---- >> > =A0 =A0 =A0 =A0 >Da: david.i.allan@ericsson.com >> > >> > =A0 =A0 =A0 =A0 >Data: 8-lug-2011 18.13 >> > =A0 =A0 =A0 =A0 >A: "Rui Costa", "Stewart >> > Bryant" >> > =A0 =A0 =A0 =A0 >Cc: >> > "erminio.ottone_69@libero.it", >> "mpls@ietf. >> > =A0 =A0 =A0 =A0 org", "ietf@ietf.org", "= IETF- >> > Announce"> > =A0 =A0 =A0 =A0 announce@ietf.org> >> > =A0 =A0 =A0 =A0 >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-= cv-rdi- >> > 05.txt> >> > >> > =A0 =A0 =A0 =A0 (Proactive =A0 =A0 =A0Connectivity Verification, Conti= nuity Check >> and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS =A0 =A0 Transport =A0 =A0 =A0 Prof= ile) to Proposed >> > Standard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Rui: >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >You wrote: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >>Reading something, keeping it on record, without eff= ect in >> > the draft and >> > =A0 =A0 =A0 =A0 "ignoring comments" have IMHO similar outcomes. As aut= hor of >> > the draft you are >> > =A0 =A0 =A0 =A0 free to do it. These standards have a great impact >> > =A0 =A0 =A0 =A0 >>in our work, so i'm also free to write what i did. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >Numerous comments did have effect on the draft and th= ose >> that >> > didn't were >> > =A0 =A0 =A0 =A0 either simply not actionable, were rhetorical or not >> > constructive, and a few >> > =A0 =A0 =A0 =A0 had to be balanced against comments coming from the MP= LS & >> BFD >> > WGs. I would >> > =A0 =A0 =A0 =A0 translate "ingored" or "without effect" to "did not ge= t one'e >> > way". In the >> > =A0 =A0 =A0 =A0 standards process it happens. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Meanwhile as an editor of the document, I'll take the >> liberty >> > of responding >> > =A0 =A0 =A0 =A0 to some of the points you raise... >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>My technical concerns regarding this draft were >> expressed... >> > =A0 =A0 =A0 =A0 >>...in the (ITU-T -> IETF, Feb/2011) liaison regardin= g it >> > (LS281, i >> > =A0 =A0 =A0 =A0 believe); >> > =A0 =A0 =A0 =A0 >>...in operators' meetings' that took place during IT= U-T's >> > Feb/2011 plenary >> > =A0 =A0 =A0 =A0 meeting; >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >I and the WG don't really have access to private grum= blings. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>...in a comparison session that took place during th= at same >> > ITU-T meeting. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >Lots of other opinions were expressed as well, and th= ey did >> > not all agree >> > =A0 =A0 =A0 =A0 with you. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>Some: >> > =A0 =A0 =A0 =A0 >>CC/CV >> > =A0 =A0 =A0 =A0 >>I don't understand the need for 2 types of packets: = a >> single >> > type allows CC; >> > =A0 =A0 =A0 =A0 mismatching identifiers in the same CC packets allow C= V. >> > =A0 =A0 =A0 =A0 >>Besides adding complexity, we whether always activat= e both >> or >> > potentiate >> > =A0 =A0 =A0 =A0 undetected mismerges. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >OK, lets walk through this. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >We want CV all the time so that any misconectivity ca= n be >> > detected, but on >> > =A0 =A0 =A0 =A0 the list it was expressed that the group did not want = the >> > overhead of >> > =A0 =A0 =A0 =A0 processing the source MEP TLV in every packet in order= to >> > achieve this. We >> > =A0 =A0 =A0 =A0 could carry it in every packet and have the receiver s= imply >> > ignore most of >> > =A0 =A0 =A0 =A0 them, but then that would make the defect entry criter= ia >> > compeltely random and >> > =A0 =A0 =A0 =A0 the exit criteria unreliable as well, not really a goo= d >> design. >> > Hence they are >> > =A0 =A0 =A0 =A0 separated using different ACH code points and the rece= iver is >> > obliged to >> > =A0 =A0 =A0 =A0 process every source MEP TLV it receives. I hope this = is >> clear. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>(BTW: can't understand how we propose one ACH codepo= int to >> > CC, another for >> > =A0 =A0 =A0 =A0 CV, [counting other drafts, another for frame loss ...= ] but >> > don't consider >> > =A0 =A0 =A0 =A0 assigning 1 single ACH protocol identifier codepoint >= as >> > requested by ITU-T) >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >Because that puts you into two protocol ID demultiple= xing >> > steps per OAM PDU >> > =A0 =A0 =A0 =A0 recevied to determine the intended function. Hence COS= TS >> MORE. >> > That is pretty >> > =A0 =A0 =A0 =A0 basic... >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >> Uni P2P / P2MP >> > =A0 =A0 =A0 =A0 >> I can't see how BFD will support unidir and hence P= 2MP >> other >> > than... >> > =A0 =A0 =A0 =A0 >> ...eliminating the session "state variable" (down, = init, >> > up), aiming just >> > =A0 =A0 =A0 =A0 the state variables we really need, bringing us to som= ething >> > similar to 1731, >> > =A0 =A0 =A0 =A0 eventually with other bits on the wire or... >> > =A0 =A0 =A0 =A0 >> ...using IP to create the reverse way, which we can= not >> > assume per >> > =A0 =A0 =A0 =A0 requirements; >> > =A0 =A0 =A0 =A0 >> Will we create a complete different tool for that? >> > =A0 =A0 =A0 =A0 >> (BFD's B=3D"bidirectional") >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731", th= ere is >> > actually a lot of >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional BFD,= that >> is >> > a BFD WG problem >> > =A0 =A0 =A0 =A0 at the moment. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >> Provisioning list >> > =A0 =A0 =A0 =A0 >> This is an MPLS profile/subset (and i heard) achiev= able >> > through a >> > =A0 =A0 =A0 =A0 particular configuration. So, i expect each draft-ietf= -mpls- >> TP- >> > * to focus on >> > =A0 =A0 =A0 =A0 that profile/configuration. However, i keep seeing >> > =A0 =A0 =A0 =A0 >> references f.i. to IP encapsulations unexpected und= er TP's >> > OAM. >> > =A0 =A0 =A0 =A0 >> I don't thus understand what the aim is: do we expe= ct this >> > in TP, are we >> > =A0 =A0 =A0 =A0 talking about MPLS in general?... The TP profile is ne= ver >> quite >> > delimited. >> > =A0 =A0 =A0 =A0 >> Does chapter 4 contain ALL the configurable paramet= ers >> list >> > agreed to >> > =A0 =A0 =A0 =A0 provide in the comparison session? >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >It should. As for encapsulations, unless TP is in a c= omplete >> > island not >> > =A0 =A0 =A0 =A0 connected to anything (which as a network is rather us= eless) >> it >> > will be >> > =A0 =A0 =A0 =A0 expected to interoperate with the rest of the MPLS >> > architecture, and the stated >> > =A0 =A0 =A0 =A0 intention of tool development was that what resulted w= as >> > applicable to the >> > =A0 =A0 =A0 =A0 broader MPLS architecture. Which means backwards compa= tiblity >> > and procedures >> > =A0 =A0 =A0 =A0 for interoperation. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >> Backwards compatibility >> > =A0 =A0 =A0 =A0 >> This was the main argument risen to ground MPLS-TP = OAM on >> > BFD. It's not a >> > =A0 =A0 =A0 =A0 better argument than grounding MPLS-TP OAM on 1731 due= to its >> > ETH deployment >> > =A0 =A0 =A0 =A0 plus coherence with SDH, OTN, as defended by ITU-T. >> > =A0 =A0 =A0 =A0 >> For reasons like the above, however, MPLS-TP BFD wo= n't be >> > backwards >> > =A0 =A0 =A0 =A0 compatible with previous BFD (even considering just CC= /CV). >> > They don't even >> > =A0 =A0 =A0 =A0 share the same codepoint. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >The issue is not code point, which is the trivial par= t. It >> is >> > reuse of the >> > =A0 =A0 =A0 =A0 majority of the implementation. Again, pretty basic. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>Simplicity >> > =A0 =A0 =A0 =A0 >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's app= roach >> to >> > CC is simpler: >> > =A0 =A0 =A0 =A0 in each flow, a standard defined nr of constant heartb= eat >> > signals (with >> > =A0 =A0 =A0 =A0 standard constant or provisioned period - no >> > =A0 =A0 =A0 =A0 >>auto/negotiated -) means OK. A standard defined numb= er of >> > misses means lost >> > =A0 =A0 =A0 =A0 Rx connection. An RDI, the only articulation between R= x and >> Tx >> > flows, >> > =A0 =A0 =A0 =A0 meaningful in bidirectional applications, allows each >> > =A0 =A0 =A0 =A0 >>pear to identify Tx problems. >> > =A0 =A0 =A0 =A0 >>This OAM simplicity is the key for reliable fail fin= ger >> > pointing, >> > =A0 =A0 =A0 =A0 performance reports and protection. Also to allow scal= ing, >> more >> > implementation >> > =A0 =A0 =A0 =A0 opportunities/manufacturers, which is valuable for >> > =A0 =A0 =A0 =A0 >>operators. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >Well IMO there was not a lot of interest in T-MPLS un= til the >> > IETF was going >> > =A0 =A0 =A0 =A0 to re-define it and make it compatible with IP/MPLS. S= o there >> > was an industry >> > =A0 =A0 =A0 =A0 wide "design intent" implied here. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >> IMHO, between your MPLS-TP view and MPLS/IP, it bec= omes >> more >> > and more >> > =A0 =A0 =A0 =A0 difficult to tell which is which. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >That is because MPLS-TP is not a new techology, it is= an >> > addition to the >> > =A0 =A0 =A0 =A0 entire MPLS protocol suite. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Hope this helps >> > =A0 =A0 =A0 =A0 >D >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.co= m] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 19:25 >> > >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf= .org; >> > IETF-Announce >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: > cc- >> > cv-rdi-05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Hi Erminio: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as not >> meeting >> > their >> > =A0 =A0 =A0 =A0 >>transport networks' needs. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >E> This is a true statement: the solution in this dra= ft is >> > useless for many >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >The two statements do not necessarily follow. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >What we established during discussions at the SG15 pl= enary >> in >> > February was >> > =A0 =A0 =A0 =A0 that the issue some service providers had was that the= IETF >> BFD >> > solution >> > =A0 =A0 =A0 =A0 exceeded their requirements in that there was addition= al >> > functionality they did >> > =A0 =A0 =A0 =A0 not see a need for, and that they considered any addit= ional >> > functionality >> > =A0 =A0 =A0 =A0 parasitic. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >However this is a consequence of adapting an existing >> > technology to a new >> > =A0 =A0 =A0 =A0 application. I do not see any way around that. And the= entire >> > joint project was >> > =A0 =A0 =A0 =A0 based on the premise of engineering re-use not greenfi= eld >> > design. That is what >> > =A0 =A0 =A0 =A0 it said on the tin up front, and IMO why when the IETF >> started >> > down this path >> > =A0 =A0 =A0 =A0 packet transport transitioned from being a minority sp= ort to >> > mainstream, so it >> > =A0 =A0 =A0 =A0 is a bit late to cry foul.... >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >My 2 cents >> > =A0 =A0 =A0 =A0 >Dave >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.co= m] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:36 >> > >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: > cc- >> > cv-rdi-05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Hi Erminio: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Two of the three document editors were present at SG1= 5 >> plenary >> > in February >> > =A0 =A0 =A0 =A0 where the comments originated. The revised meeting sch= edule >> > resulted in a day >> > =A0 =A0 =A0 =A0 spent going through the document with the editors. IMO= there >> > were lots of >> > =A0 =A0 =A0 =A0 discussion and legitimate issues with the document ide= ntified >> > and corrected so >> > =A0 =A0 =A0 =A0 it was a useful session. The liaison of same was in ma= ny ways >> > *after the >> > =A0 =A0 =A0 =A0 fact*. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Cheers >> > =A0 =A0 =A0 =A0 >Dave >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it >> > [mailto:erminio.ottone_69@libero.it] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:34 >> > >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> > >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: > > rdi-05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The way this draft has been developed is a bit strang= e. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The poll for its adoption as a WG document was halted= by the >> > MPLS WG chair >> > =A0 =A0 =A0 =A0 because "it is not possible to judge consensus": >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- >> > archive/web/mpls/current/msg04502.html >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The lack of consensus was motivated by serious techni= cal >> > concerns raised by >> > =A0 =A0 =A0 =A0 several transport experts during the poll. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Nevertheless the MPLS WG chair decided to adopt the d= raft as >> a >> > WG document: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- >> > archive/web/mpls/current/msg04512.html >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >After several WG revisions and WG LCs, the technical = issues >> > have not been >> > =A0 =A0 =A0 =A0 resolved. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as not >> meeting >> > their >> > =A0 =A0 =A0 =A0 >>transport >> > =A0 =A0 =A0 =A0 >networks' needs. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >This is a true statement: the solution in this draft = is >> > useless for many >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it >> > [mailto:erminio.ottone_69@libero.it] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:26 >> > >> > =A0 =A0 =A0 =A0 >To: loa@pi.nu; Rui Costa >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: > > rdi-05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >> =A0Version -04 of the document was published June 2= 8th. >> > =A0 =A0 =A0 =A0 >> >> > >> > =A0 =A0 =A0 =A0 >> =A0The publication request for draft-ietf-mpls-tp-c= c-cv-rdi >> > was =A0sent >> > =A0 =A0 =A0 =A0 >> June 29th. >> > =A0 =A0 =A0 =A0 >> >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >So when the WG LC to confirm the LC comment resolutio= n has >> > been launched? >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The proto write-up says: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0It has also passed a working = roup call to verify >> > that LC comments >> > =A0 =A0 =A0 =A0 were correctly with minor comments. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >It also says: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0The comments has been >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0carefully discussed between t= he authors and >> people >> > making the >> > =A0 =A0 =A0 =A0 comments and >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0has been resolved. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >But it seems that some comments have not been discuss= ed with >> > the authors of >> > =A0 =A0 =A0 =A0 the comments. When ITU-T Q10/15 has been involved in >> discussing >> > its comments? >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: Loa Andersson [mailto:loa@pi.nu] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 16:44 >> > =A0 =A0 =A0 =A0 >To: Rui Costa >> > >> > =A0 =A0 =A0 =A0 >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> > >> > =A0 =A0 =A0 =A0 >Subject: Re: [mpls] Last Call: > rdi- >> > 05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >All, >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Since someone has commented about the process used fo= r >> > resolving >> > =A0 =A0 =A0 =A0 >questions on >> > =A0 =A0 =A0 =A0 >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some deta= ils >> > below. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The history of draft-ietf-mpls-tp-cc-cv-rdi working g= roup >> > review >> > =A0 =A0 =A0 =A0 >process is: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >On February 3rd 2011 the working group last call was = issued >> > =A0 =A0 =A0 =A0 >on version -03 >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This was copied to the the Ad Hoc Team Li= st >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0and liaised to SG15 also on February 3rd >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This working group last call ended om Feb= 28 >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0On Feb 28 we also received a liaison with= comments >> from >> > SG15 >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The authors compiled a list of all comments received = =A0as >> part >> > the MPLS >> > =A0 =A0 =A0 =A0 >working group last call; these =A0comments - and the = intended >> > resolution - >> > =A0 =A0 =A0 =A0 >is included in the meeting minutes from the Prague me= eting: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0http://www.ietf.org/proceedings/80/slides= /mpls-9.pdf >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0During the IETF meeting in Prague, we agreed with= the BFD >> > working >> > =A0 =A0 =A0 =A0 > =A0group to do a separate working group last callfor= the BFD >> > working >> > =A0 =A0 =A0 =A0 > =A0group >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The (BFD) working group last call was started on Marc= h 30th >> > and ran >> > =A0 =A0 =A0 =A0 >for 13 days. The last call ended on April 11th. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0The authors have since worked hard to resolve com= ments, >> some >> > =A0 =A0 =A0 =A0 > =A0issue has been brought to the working group maili= ng list >> for >> > =A0 =A0 =A0 =A0 > =A0resolution. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0Version -04 of the document was published June 28= th. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0The publication request for draft-ietf-mpls-tp-cc= -cv-rdi >> was >> > sent >> > =A0 =A0 =A0 =A0 > =A0June 29th. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0The AD review resulted in a "New ID needed" due t= o mostly >> > editorial >> > =A0 =A0 =A0 =A0 > =A0comments. Version -05 was published on June 29 an= d the >> IETF >> > last call >> > =A0 =A0 =A0 =A0 > =A0started as soon as the new ID was avaialbe. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0The current list of Last Call Comments resoltion = is also >> > avaiable at: >> > =A0 =A0 =A0 =A0 > =A0http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comment= s.xls >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0The list of issues that the authors kept very car= efully, >> > shows without >> > =A0 =A0 =A0 =A0 >doubt >> > =A0 =A0 =A0 =A0 > =A0that no comments been ignored. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0Loa >> > =A0 =A0 =A0 =A0 > =A0mpls wg document shepherd >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.co= m] >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 14:58 >> > >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: > rdi- >> > 05.txt> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Hi Rui: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The comments were not ignored, the resolution of the = Q10 >> > comments as well as >> > >> > =A0 =A0 =A0 =A0 those collected from the MPLS WG was presented at the = last >> > IETF. My spreadsheet >> > >> > =A0 =A0 =A0 =A0 from which that report was generated and has been augm= ented >> to >> > include the BFD >> > >> > =A0 =A0 =A0 =A0 WG comments is available at http://www.pi.nu/~loa/cc-c= v-rdi- >> > Last-Call-Comments > > Comments> . >> > =A0 =A0 =A0 =A0 xls >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >So you know... >> > =A0 =A0 =A0 =A0 >Dave >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > >> > =A0 =A0 =A0 =A0 >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf= .org] >> On >> > Behalf Of Rui >> > =A0 =A0 =A0 =A0 Costa >> > =A0 =A0 =A0 =A0 >Sent: segunda-feira, 4 de Julho de 2011 23:03 >> > >> > =A0 =A0 =A0 =A0 >To: ietf@ietf.org; IETF-Announce >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: > rdi- >> > 05.txt> >> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Check= and >> > Remote Defect >> > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed Sta= ndard >> > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >IMHO and for the record: >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >ITU-T comments regarding this draft haven't been disc= ussed >> > with ITU-T but >> > =A0 =A0 =A0 =A0 were simply ignored. No LS describing these comments' >> > resolution was sent. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >Several service providers regarded this draft as not = meeting >> > their transport >> > =A0 =A0 =A0 =A0 networks' needs. >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >[The v03 draft was published in Feb and went to WG LC= . >> > =A0 =A0 =A0 =A0 >The v04 draft addressing WG LC comments was published= on the >> > 28th June (same >> > =A0 =A0 =A0 =A0 date as the proto write-up). >> > =A0 =A0 =A0 =A0 >When was the WG LC launched, to verify LC comments >> > resolution?] >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Regards, >> > =A0 =A0 =A0 =A0 >Rui >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> > =A0 =A0 =A0 =A0 >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf= .org] >> On >> > Behalf Of The >> > =A0 =A0 =A0 =A0 IESG >> > =A0 =A0 =A0 =A0 >Sent: quinta-feira, 30 de Junho de 2011 14:47 >> > =A0 =A0 =A0 =A0 >To: IETF-Announce >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> > >> > =A0 =A0 =A0 =A0 >Subject: [mpls] Last Call: > > 05.txt> (Proactive >> > >> > =A0 =A0 =A0 =A0 Connectivity Verification, Continuity Check and Remote= Defect >> > indication for >> > =A0 =A0 =A0 =A0 MPLS Transport Profile) to Proposed Standard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >The IESG has received a request from the Multiprotoco= l Label >> > Switching WG >> > =A0 =A0 =A0 =A0 >(mpls) to consider the following document: >> > =A0 =A0 =A0 =A0 >- 'Proactive Connectivity Verification, Continuity Ch= eck and >> > Remote >> > =A0 =A0 =A0 =A0 > =A0 Defect indication for MPLS Transport Profile' >> > =A0 =A0 =A0 =A0 > =A0 as a Propos= ed >> Standard >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The IESG plans to make a decision in the next few wee= ks, and >> > solicits >> > =A0 =A0 =A0 =A0 >final comments on this action. Please send substantiv= e >> > comments to the >> > =A0 =A0 =A0 =A0 >ietf@ietf.org mailing lists by 2011-07-14. Exceptiona= lly, >> > comments may be >> > =A0 =A0 =A0 =A0 >sent to iesg@ietf.org instead. In either case, please= retain >> > the >> > =A0 =A0 =A0 =A0 >beginning of the Subject line to allow automated sort= ing. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >Abstract >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check, Proactive Connectivity Verific= ation and >> > Remote >> > =A0 =A0 =A0 =A0 > =A0 Defect Indication functionalities are required f= or MPLS- >> TP >> > OAM. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check monitors the integrity of the c= ontinuity >> > of the >> > =A0 =A0 =A0 =A0 > =A0 label switched path for any loss of continuity d= efect. >> > Connectivity >> > =A0 =A0 =A0 =A0 > =A0 verification monitors the integrity of the routi= ng of the >> > label >> > =A0 =A0 =A0 =A0 > =A0 switched path between sink and source for any >> connectivity >> > issues. >> > =A0 =A0 =A0 =A0 > =A0 Remote defect indication enables an End Point to= report, >> to >> > its >> > =A0 =A0 =A0 =A0 > =A0 associated End Point, a fault or defect conditio= n that it >> > detects on >> > =A0 =A0 =A0 =A0 > =A0 a pseudo wire, label switched path or Section. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > =A0 This document specifies methods for proactive co= ntinuity >> > check, >> > =A0 =A0 =A0 =A0 > =A0 continuity verification, and remote defect indic= ation for >> > MPLS-TP >> > =A0 =A0 =A0 =A0 > =A0 label switched paths, pseudo wires and Sections = using >> > Bidirectional >> > =A0 =A0 =A0 =A0 > =A0 Forwarding Detection. >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >The file can be obtained via >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc= -cv- >> rdi/ >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >IESG discussion can be tracked via >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc= -cv- >> rdi/ >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 >No IPR declarations have been submitted directly on t= his I- >> D. >> > =A0 =A0 =A0 =A0 >_______________________________________________ >> > >> > =A0 =A0 =A0 =A0 >mpls mailing list >> > =A0 =A0 =A0 =A0 >mpls@ietf.org >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/mpls >> > =A0 =A0 =A0 =A0 > >> > =A0 =A0 =A0 =A0 > >> > >> > =A0 =A0 =A0 =A0 >_______________________________________________ >> > =A0 =A0 =A0 =A0 >Ietf mailing list >> > =A0 =A0 =A0 =A0 >Ietf@ietf.org >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/ietf >> > >> > =A0 =A0 =A0 =A0 > >> > >> > >> > =A0 =A0 =A0 =A0 _______________________________________________ >> > =A0 =A0 =A0 =A0 mpls mailing list >> > =A0 =A0 =A0 =A0 mpls@ietf.org >> > =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mpls >> > >> > >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From jdrake@juniper.net Wed Jul 27 15:05:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F356221F8783 for ; Wed, 27 Jul 2011 15:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEHQMjB8jyPq for ; Wed, 27 Jul 2011 15:05:39 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6511221F876F for ; Wed, 27 Jul 2011 15:05:39 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTjCLr+aX9PfwcNdkzn2neFvWKi7ij6M0@postini.com; Wed, 27 Jul 2011 15:05:39 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 27 Jul 2011 15:03:29 -0700 From: John E Drake To: Maarten vissers , Gregory Mirsky , "mpls@ietf.org" Date: Wed, 27 Jul 2011 15:03:28 -0700 Thread-Topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcAAAID/GAAAQHbgAAQo/NA= Message-ID: <5E893DB832F57341992548CDBB333163A0AAEAC501@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:05:42 -0000 Maarten, Actually it doesn't. G.8113.1, absent an IP forwarding capability, has no = ability to send replies from egress to ingress for unidirectional LSP const= ructs. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Maarten vissers > Sent: Wednesday, July 27, 2011 1:17 PM > To: Gregory Mirsky; mpls@ietf.org > Subject: Re: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Dear Greg, > > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in > - co-routed bidir p2p, > - associated bidir p2p, > - unidir p2p and > - unidir p2mp > PW, LSP, SPME and section connections. > > > The G.8113.1 addresses only bi-directional co-routed LSP and has no > model to > > handle bi-directional associated LSP in independent mode. And > unidirectional > > p2p and p2mp LSPs are not addressed by the current revision of the > G.8113.1. > > Can all these out-of-scope constructs be used to conclude that > G.8113.1 > > is not capable to solve these issues? I don't think so. Solutions are > > not readily available, that's all. > > Solution for CCM is already available in G.8113.1. > I.e. G.8113.1 already resolved these issues as such. > > Regards, > Maarten > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: 27 July 2011 21:54 > > To: Maarten vissers; mpls@ietf.org > > Subject: RE: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Dear Maarten, > > the question was raised in regard to CC/CV, a.k.a. CCM, > functionality. > > I apologize that I didn't state that explicitly and left it as > implied > > context of the discussion. I don't question G.8113.1 capabilities > > you've listed but only compare with corresponding CCM addressed in > CC- > > CV-RDI. > > > > Regards, > > Greg > > ________________________________________ > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > > Maarten vissers [maarten.vissers@huawei.com] > > Sent: Wednesday, July 27, 2011 3:49 PM > > To: Eric Gray; mpls@ietf.org > > Subject: Re: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, > > p2mp unidir connections. > > > > The p2p bidir connection can be co-routed, and then it is possible to > > perform e.g. loopback at intermediate nodes. > > > > The p2p bidir connection can be associated, and then a loopback at an > > intermediate node will not be possible. But the end-to-end monitoring > > is still performed without problems. > > > > Note that a co-routed bidir 1+1 protected connection can select it's > A- > > to-Z traffic from working and its Z-to-A traffic from protection; > this > > effectively creates an associated bidir connection in which e2e > > monitoring is supported but loopbacks at intermediate nodes are not > > successful. > > > > Regards, > > Maarten > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Eric Gray > > > Sent: 27 July 2011 18:32 > > > To: mpls@ietf.org > > > Subject: [mpls] FW: R: RE: Last Call: rdi- > > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > Forwarding in plain text... > > > > > > ________________________________ > > > > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > > Sent: Wednesday, July 13, 2011 10:57 PM > > > To: erminio.ottone_69@libero.it > > > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > > > ietf@ietf.org; IETF-Announce > > > Subject: Re: [mpls] R: RE: Last Call: rdi- > > > 05.txt> (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > > > > Dear Erminio, > > > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to > CCM > > is > > > even more narrow then of the document being discussed. The G.8113.1 > > > addresses only bi-directional co-routed LSP and has no model to > > handle > > > bi-directional associated LSP in independent mode. And > unidirectional > > > p2p and p2mp LSPs are not addressed by the current revision of the > > > G.8113.1. > > > Can all these out-of-scope constructs be used to conclude that > > G.8113.1 > > > is not capable to solve these issues? I don't think so. Solutions > are > > > not readily available, that's all. > > > > > > Regards, > > > Greg > > > > > > > > > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > > > wrote: > > > > > > > > > >I would not go so far as to say "similar to 1731", there > is > > > actually a lot of > > > difference under the hood. As for uni-directional BFD, that > > is > > > a BFD WG problem > > > at the moment. > > > > > > > > > The fact that the BFD WG has not defined a solution for > > > unidirectional p2p and > > > p2mp transport paths does not make BFD a suitable OAM > > protocol > > > for MPLS-TP nor > > > does resolve the technical issue that have been raised. > > > > > > > > > >----Messaggio originale---- > > > >Da: david.i.allan@ericsson.com > > > > > > >Data: 8-lug-2011 18.13 > > > >A: "Rui Costa", "Stewart > > > Bryant" > > > >Cc: > > > "erminio.ottone_69@libero.it", > > "mpls@ietf. > > > org", "ietf@ietf.org", "IETF- > > > Announce" > > announce@ietf.org> > > > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv- > rdi- > > > 05.txt> > > > > > > (Proactive Connectivity Verification, Continuity Check > > and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to > Proposed > > > Standard > > > > > > > >Rui: > > > > > > > > > > >You wrote: > > > > > > > >>Reading something, keeping it on record, without effect > in > > > the draft and > > > "ignoring comments" have IMHO similar outcomes. As author > of > > > the draft you are > > > free to do it. These standards have a great impact > > > >>in our work, so i'm also free to write what i did. > > > > > > > > > > >Numerous comments did have effect on the draft and those > > that > > > didn't were > > > either simply not actionable, were rhetorical or not > > > constructive, and a few > > > had to be balanced against comments coming from the MPLS & > > BFD > > > WGs. I would > > > translate "ingored" or "without effect" to "did not get > one'e > > > way". In the > > > standards process it happens. > > > > > > > >Meanwhile as an editor of the document, I'll take the > > liberty > > > of responding > > > to some of the points you raise... > > > > > > > > > > >>My technical concerns regarding this draft were > > expressed... > > > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it > > > (LS281, i > > > believe); > > > >>...in operators' meetings' that took place during ITU-T's > > > Feb/2011 plenary > > > meeting; > > > > > > > > > > >I and the WG don't really have access to private > grumblings. > > > > > > > > > > >>...in a comparison session that took place during that > same > > > ITU-T meeting. > > > > > > > > > > >Lots of other opinions were expressed as well, and they > did > > > not all agree > > > with you. > > > > > > > > > > >>Some: > > > >>CC/CV > > > >>I don't understand the need for 2 types of packets: a > > single > > > type allows CC; > > > mismatching identifiers in the same CC packets allow CV. > > > >>Besides adding complexity, we whether always activate > both > > or > > > potentiate > > > undetected mismerges. > > > > > > > > > > >OK, lets walk through this. > > > > > > > >We want CV all the time so that any misconectivity can be > > > detected, but on > > > the list it was expressed that the group did not want the > > > overhead of > > > processing the source MEP TLV in every packet in order to > > > achieve this. We > > > could carry it in every packet and have the receiver simply > > > ignore most of > > > them, but then that would make the defect entry criteria > > > compeltely random and > > > the exit criteria unreliable as well, not really a good > > design. > > > Hence they are > > > separated using different ACH code points and the receiver > is > > > obliged to > > > process every source MEP TLV it receives. I hope this is > > clear. > > > > > > > > > > >>(BTW: can't understand how we propose one ACH codepoint > to > > > CC, another for > > > CV, [counting other drafts, another for frame loss ...] but > > > don't consider > > > assigning 1 single ACH protocol identifier codepoint >as > > > requested by ITU-T) > > > > > > > > > > >Because that puts you into two protocol ID demultiplexing > > > steps per OAM PDU > > > recevied to determine the intended function. Hence COSTS > > MORE. > > > That is pretty > > > basic... > > > > > > > > > > >> Uni P2P / P2MP > > > >> I can't see how BFD will support unidir and hence P2MP > > other > > > than... > > > >> ...eliminating the session "state variable" (down, init, > > > up), aiming just > > > the state variables we really need, bringing us to > something > > > similar to 1731, > > > eventually with other bits on the wire or... > > > >> ...using IP to create the reverse way, which we cannot > > > assume per > > > requirements; > > > >> Will we create a complete different tool for that? > > > >> (BFD's B=3D"bidirectional") > > > > > > > > > > >I would not go so far as to say "similar to 1731", there > is > > > actually a lot of > > > difference under the hood. As for uni-directional BFD, that > > is > > > a BFD WG problem > > > at the moment. > > > > > > > > > > >> Provisioning list > > > >> This is an MPLS profile/subset (and i heard) achievable > > > through a > > > particular configuration. So, i expect each draft-ietf- > mpls- > > TP- > > > * to focus on > > > that profile/configuration. However, i keep seeing > > > >> references f.i. to IP encapsulations unexpected under > TP's > > > OAM. > > > >> I don't thus understand what the aim is: do we expect > this > > > in TP, are we > > > talking about MPLS in general?... The TP profile is never > > quite > > > delimited. > > > >> Does chapter 4 contain ALL the configurable parameters > > list > > > agreed to > > > provide in the comparison session? > > > > > > > > > > >It should. As for encapsulations, unless TP is in a > complete > > > island not > > > connected to anything (which as a network is rather > useless) > > it > > > will be > > > expected to interoperate with the rest of the MPLS > > > architecture, and the stated > > > intention of tool development was that what resulted was > > > applicable to the > > > broader MPLS architecture. Which means backwards > compatiblity > > > and procedures > > > for interoperation. > > > > > > > > > > >> Backwards compatibility > > > >> This was the main argument risen to ground MPLS-TP OAM > on > > > BFD. It's not a > > > better argument than grounding MPLS-TP OAM on 1731 due to > its > > > ETH deployment > > > plus coherence with SDH, OTN, as defended by ITU-T. > > > >> For reasons like the above, however, MPLS-TP BFD won't > be > > > backwards > > > compatible with previous BFD (even considering just CC/CV). > > > They don't even > > > share the same codepoint. > > > > > > > > > > >The issue is not code point, which is the trivial part. It > > is > > > reuse of the > > > majority of the implementation. Again, pretty basic. > > > > > > > > > > >>Simplicity > > > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach > > to > > > CC is simpler: > > > in each flow, a standard defined nr of constant heartbeat > > > signals (with > > > standard constant or provisioned period - no > > > >>auto/negotiated -) means OK. A standard defined number of > > > misses means lost > > > Rx connection. An RDI, the only articulation between Rx and > > Tx > > > flows, > > > meaningful in bidirectional applications, allows each > > > >>pear to identify Tx problems. > > > >>This OAM simplicity is the key for reliable fail finger > > > pointing, > > > performance reports and protection. Also to allow scaling, > > more > > > implementation > > > opportunities/manufacturers, which is valuable for > > > >>operators. > > > > > > > > > > >Well IMO there was not a lot of interest in T-MPLS until > the > > > IETF was going > > > to re-define it and make it compatible with IP/MPLS. So > there > > > was an industry > > > wide "design intent" implied here. > > > > > > > > > > >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes > > more > > > and more > > > difficult to tell which is which. > > > > > > > > > > >That is because MPLS-TP is not a new techology, it is an > > > addition to the > > > entire MPLS protocol suite. > > > > > > > >Hope this helps > > > >D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > > > > > > >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; > > > IETF-Announce > > > >Cc: mpls@ietf.org > > > > > > >Subject: RE: [mpls] R: Re: Last Call: > cc- > > > cv-rdi-05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > > > > >Hi Erminio: > > > > > > > > > > > >>Several service providers regarded this draft as not > > meeting > > > their > > > >>transport networks' needs. > > > > > > > > > > >E> This is a true statement: the solution in this draft is > > > useless for many > > > MPLS- TP deployments. > > > > > > > > > > >The two statements do not necessarily follow. > > > > > > > >What we established during discussions at the SG15 plenary > > in > > > February was > > > that the issue some service providers had was that the IETF > > BFD > > > solution > > > exceeded their requirements in that there was additional > > > functionality they did > > > not see a need for, and that they considered any additional > > > functionality > > > parasitic. > > > > > > > >However this is a consequence of adapting an existing > > > technology to a new > > > application. I do not see any way around that. And the > entire > > > joint project was > > > based on the premise of engineering re-use not greenfield > > > design. That is what > > > it said on the tin up front, and IMO why when the IETF > > started > > > down this path > > > packet transport transitioned from being a minority sport > to > > > mainstream, so it > > > is a bit late to cry foul.... > > > > > > > >My 2 cents > > > >Dave > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > > > > > > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > >Subject: RE: [mpls] R: Re: Last Call: > cc- > > > cv-rdi-05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > > > > >Hi Erminio: > > > > > > > >Two of the three document editors were present at SG15 > > plenary > > > in February > > > where the comments originated. The revised meeting schedule > > > resulted in a day > > > spent going through the document with the editors. IMO > there > > > were lots of > > > discussion and legitimate issues with the document > identified > > > and corrected so > > > it was a useful session. The liaison of same was in many > ways > > > *after the > > > fact*. > > > > > > > >Cheers > > > >Dave > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: erminio.ottone_69@libero.it > > > [mailto:erminio.ottone_69@libero.it] > > > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > > > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > > >Cc: mpls@ietf.org > > > > > > >Subject: R: Re: [mpls] Last Call: cv- > > > rdi-05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >The way this draft has been developed is a bit strange. > > > > > > > >The poll for its adoption as a WG document was halted by > the > > > MPLS WG chair > > > because "it is not possible to judge consensus": > > > > > > > >http://www.ietf.org/mail- > > > archive/web/mpls/current/msg04502.html > > > > > > > >The lack of consensus was motivated by serious technical > > > concerns raised by > > > several transport experts during the poll. > > > > > > > >Nevertheless the MPLS WG chair decided to adopt the draft > as > > a > > > WG document: > > > > > > > >http://www.ietf.org/mail- > > > archive/web/mpls/current/msg04512.html > > > > > > > >After several WG revisions and WG LCs, the technical > issues > > > have not been > > > resolved. > > > > > > > > > > >>Several service providers regarded this draft as not > > meeting > > > their > > > >>transport > > > >networks' needs. > > > > > > > > > > >This is a true statement: the solution in this draft is > > > useless for many > > > MPLS- TP deployments. > > > > > > > > > > > > > > >-----Original Message----- > > > >From: erminio.ottone_69@libero.it > > > [mailto:erminio.ottone_69@libero.it] > > > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > > > > > > >To: loa@pi.nu; Rui Costa > > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > >Subject: R: Re: [mpls] Last Call: cv- > > > rdi-05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > > > > >> Version -04 of the document was published June 28th. > > > >> > > > > > > >> The publication request for draft-ietf-mpls-tp-cc-cv- > rdi > > > was sent > > > >> June 29th. > > > >> > > > > > > > >So when the WG LC to confirm the LC comment resolution has > > > been launched? > > > > > > > >The proto write-up says: > > > > > > > > It has also passed a working roup call to > verify > > > that LC comments > > > were correctly with minor comments. > > > > > > > >It also says: > > > > > > > > The comments has been > > > > carefully discussed between the authors and > > people > > > making the > > > comments and > > > > has been resolved. > > > > > > > >But it seems that some comments have not been discussed > with > > > the authors of > > > the comments. When ITU-T Q10/15 has been involved in > > discussing > > > its comments? > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Loa Andersson [mailto:loa@pi.nu] > > > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > > > >To: Rui Costa > > > > > > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > > > > >Subject: Re: [mpls] Last Call: > rdi- > > > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >All, > > > > > > > >Since someone has commented about the process used for > > > resolving > > > >questions on > > > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details > > > below. > > > > > > > >The history of draft-ietf-mpls-tp-cc-cv-rdi working group > > > review > > > >process is: > > > > > > > >On February 3rd 2011 the working group last call was > issued > > > >on version -03 > > > > > > > > This was copied to the the Ad Hoc Team List > > > > and liaised to SG15 also on February 3rd > > > > > > > > This working group last call ended om Feb 28 > > > > > > > > > > > > On Feb 28 we also received a liaison with comments > > from > > > SG15 > > > > > > > > > > > >The authors compiled a list of all comments received as > > part > > > the MPLS > > > >working group last call; these comments - and the > intended > > > resolution - > > > >is included in the meeting minutes from the Prague > meeting: > > > > > > > > > > > > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf > > > > > > > > > > > > During the IETF meeting in Prague, we agreed with the > BFD > > > working > > > > group to do a separate working group last callfor the > BFD > > > working > > > > group > > > > > > > >The (BFD) working group last call was started on March > 30th > > > and ran > > > >for 13 days. The last call ended on April 11th. > > > > > > > > The authors have since worked hard to resolve comments, > > some > > > > issue has been brought to the working group mailing list > > for > > > > resolution. > > > > > > > > Version -04 of the document was published June 28th. > > > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv-rdi > > was > > > sent > > > > June 29th. > > > > > > > > The AD review resulted in a "New ID needed" due to > mostly > > > editorial > > > > comments. Version -05 was published on June 29 and the > > IETF > > > last call > > > > started as soon as the new ID was avaialbe. > > > > > > > > The current list of Last Call Comments resoltion is also > > > avaiable at: > > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > > > > > > The list of issues that the authors kept very carefully, > > > shows without > > > >doubt > > > > that no comments been ignored. > > > > > > > > Loa > > > > mpls wg document shepherd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > > > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > > >Cc: mpls@ietf.org > > > > > > >Subject: RE: [mpls] Last Call: > rdi- > > > 05.txt> > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > >Hi Rui: > > > > > > > >The comments were not ignored, the resolution of the Q10 > > > comments as well as > > > > > > those collected from the MPLS WG was presented at the last > > > IETF. My spreadsheet > > > > > > from which that report was generated and has been augmented > > to > > > include the BFD > > > > > > WG comments is available at http://www.pi.nu/~loa/cc-cv- > rdi- > > > Last-Call-Comments > > Comments> . > > > xls > > > > > > > > > > >So you know... > > > >Dave > > > > > > > > > > > >-----Original Message----- > > > > > > >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] > > On > > > Behalf Of Rui > > > Costa > > > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > > > > > > >To: ietf@ietf.org; IETF-Announce > > > >Cc: mpls@ietf.org > > > >Subject: RE: [mpls] Last Call: > rdi- > > > 05.txt> > > > > > > (Proactive Connectivity Verification, Continuity Check and > > > Remote Defect > > > > > > indication for MPLS Transport Profile) to Proposed Standard > > > > > > > > > > >IMHO and for the record: > > > > > > > >ITU-T comments regarding this draft haven't been discussed > > > with ITU-T but > > > were simply ignored. No LS describing these comments' > > > resolution was sent. > > > > > > > > > > >Several service providers regarded this draft as not > meeting > > > their transport > > > networks' needs. > > > > > > > > > > >[The v03 draft was published in Feb and went to WG LC. > > > >The v04 draft addressing WG LC comments was published on > the > > > 28th June (same > > > date as the proto write-up). > > > >When was the WG LC launched, to verify LC comments > > > resolution?] > > > > > > > >Regards, > > > >Rui > > > > > > > > > > > >-----Original Message----- > > > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On > > > Behalf Of The > > > IESG > > > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > > > >To: IETF-Announce > > > >Cc: mpls@ietf.org > > > > > > >Subject: [mpls] Last Call: > > 05.txt> (Proactive > > > > > > Connectivity Verification, Continuity Check and Remote > Defect > > > indication for > > > MPLS Transport Profile) to Proposed Standard > > > > > > > > > > > > > > >The IESG has received a request from the Multiprotocol > Label > > > Switching WG > > > >(mpls) to consider the following document: > > > >- 'Proactive Connectivity Verification, Continuity Check > and > > > Remote > > > > Defect indication for MPLS Transport Profile' > > > > 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 2011-07-14. 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 > > > > > > > > Continuity Check, Proactive Connectivity Verification > and > > > Remote > > > > Defect Indication functionalities are required for > MPLS- > > TP > > > OAM. > > > > > > > > Continuity Check monitors the integrity of the > continuity > > > of the > > > > label switched path for any loss of continuity defect. > > > Connectivity > > > > verification monitors the integrity of the routing of > the > > > label > > > > switched path between sink and source for any > > connectivity > > > issues. > > > > Remote defect indication enables an End Point to > report, > > to > > > its > > > > associated End Point, a fault or defect condition that > it > > > detects on > > > > a pseudo wire, label switched path or Section. > > > > > > > > This document specifies methods for proactive > continuity > > > check, > > > > continuity verification, and remote defect indication > for > > > MPLS-TP > > > > label switched paths, pseudo wires and Sections using > > > Bidirectional > > > > Forwarding Detection. > > > > > > > > > > > >The file can be obtained via > > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- > > rdi/ > > > > > > > >IESG discussion can be tracked via > > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- > > rdi/ > > > > > > > > > > > >No IPR declarations have been submitted directly on this > I- > > D. > > > >_______________________________________________ > > > > > > >mpls mailing list > > > >mpls@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > >_______________________________________________ > > > >Ietf mailing list > > > >Ietf@ietf.org > > > >https://www.ietf.org/mailman/listinfo/ietf > > > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From maarten.vissers@huawei.com Wed Jul 27 15:09:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A60321F87BC for ; Wed, 27 Jul 2011 15:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id humjUkYAy3qV for ; Wed, 27 Jul 2011 15:09:41 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8321F8784 for ; Wed, 27 Jul 2011 15:09:40 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP00014FIVZWG@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 23:09:36 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LP0001RXIVZWZ@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 23:09:35 +0100 (BST) Received: from LHREML401-HUB.china.huawei.com (10.201.5.30) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 23:09:27 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML401-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 23:09:33 +0100 Date: Wed, 27 Jul 2011 22:09:33 +0000 From: Maarten vissers In-reply-to: X-Originating-IP: [10.47.78.88] To: Greg Mirsky Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-GB, en-US Thread-topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcAAAID/GAAAQHbg///+xoD//96L0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:09:43 -0000 Dear Greg, You asked for G.8113.1 CCM applicability. The CCM applies to the four conne= ction types I have listed; i.e. no additions are necessary to support the l= ower three connection types in my list. Rationale is that CCM is 1-way OAM = with processing at MEPs (i.e. endpoints) only. It is just not documented to= day, but it can be inferred from looking at applicability of CC-CV-RDI type= OAM deployed in other transport technologies. As I have indicated in my first response, G.8113.1 loopback will not work i= n absence of a return path. Also other 2-way OAM will not work in unidir LS= Ps. Furthermore, any other 2-way OAM reflected at an intermediate point in = the LSP connection in associated bidir LSPs will not work (but will work if= reflected at end point, i.e. at a MEP). But any type of 1-way OAM will wor= k for all four connection types. Thus solutions for 2-way OAM are not readily available in G.8113.1 for unid= ir p2p and unidir p2mp and associated bidir p2p at intermediate points. Hope this clarifies. Regards, Maarten > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: 27 July 2011 22:57 > To: Maarten vissers > Cc: Gregory Mirsky; mpls@ietf.org > Subject: Re: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard >=20 > Dear Maarten, > I hope you can help me to interpret the following text from the TD 377 > (PLEN/15), Geneva, 14-25 February 2011: > "The MPLS-TP OAM mechanisms as described in this Recommendation apply > to co-routed bidirectional point-to-point MPLS-TP connections. > Unidirectional point-to-point and point-to-multipoint MPLS-TP > connections will be addressed in a future version of this > Recommendation." >=20 > Regards, > Greg >=20 > On Wed, Jul 27, 2011 at 1:16 PM, Maarten vissers > wrote: > > Dear Greg, > > > > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in > > - co-routed bidir p2p, > > - associated bidir p2p, > > - unidir p2p and > > - unidir p2mp > > PW, LSP, SPME and section connections. > > > >> The G.8113.1 addresses only bi-directional co-routed LSP and has no > model to > >> handle bi-directional associated LSP in independent mode. And > unidirectional > >> p2p and p2mp LSPs are not addressed by the current revision of the > G.8113.1. > >> Can all these out-of-scope constructs be used to conclude that > G.8113.1 > >> is not capable to solve these issues? I don't think so. Solutions > are > >> not readily available, that's all. > > > > Solution for CCM is already available in G.8113.1. > > I.e. G.8113.1 already resolved these issues as such. > > > > Regards, > > Maarten > > > > > >> -----Original Message----- > >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >> Sent: 27 July 2011 21:54 > >> To: Maarten vissers; mpls@ietf.org > >> Subject: RE: [mpls] FW: R: RE: Last Call: >> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Dear Maarten, > >> the question was raised in regard to CC/CV, a.k.a. CCM, > functionality. > >> I apologize that I didn't state that explicitly and left it as > implied > >> context of the discussion. I don't question G.8113.1 capabilities > >> you've listed but only compare with corresponding CCM addressed in > CC- > >> CV-RDI. > >> > >> Regards, > >> Greg > >> ________________________________________ > >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > >> Maarten vissers [maarten.vissers@huawei.com] > >> Sent: Wednesday, July 27, 2011 3:49 PM > >> To: Eric Gray; mpls@ietf.org > >> Subject: Re: [mpls] FW: R: RE: Last Call: >> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, > >> p2mp unidir connections. > >> > >> The p2p bidir connection can be co-routed, and then it is possible > to > >> perform e.g. loopback at intermediate nodes. > >> > >> The p2p bidir connection can be associated, and then a loopback at > an > >> intermediate node will not be possible. But the end-to-end > monitoring > >> is still performed without problems. > >> > >> Note that a co-routed bidir 1+1 protected connection can select it's > A- > >> to-Z traffic from working and its Z-to-A traffic from protection; > this > >> effectively creates an associated bidir connection in which e2e > >> monitoring is supported but loopbacks at intermediate nodes are not > >> successful. > >> > >> Regards, > >> Maarten > >> > >> > -----Original Message----- > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >> Of > >> > Eric Gray > >> > Sent: 27 July 2011 18:32 > >> > To: mpls@ietf.org > >> > Subject: [mpls] FW: R: RE: Last Call: rdi- > >> > 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> > Remote Defect indication for MPLS Transport Profile) to Proposed > >> > Standard > >> > > >> > Forwarding in plain text... > >> > > >> > ________________________________ > >> > > >> > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> > Sent: Wednesday, July 13, 2011 10:57 PM > >> > To: erminio.ottone_69@libero.it > >> > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > >> > ietf@ietf.org; IETF-Announce > >> > Subject: Re: [mpls] R: RE: Last Call: rdi- > >> > 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> > Remote Defect indication for MPLS Transport Profile) to Proposed > >> > Standard > >> > > >> > > >> > Dear Erminio, > >> > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to > CCM > >> is > >> > even more narrow then of the document being discussed. The > G.8113.1 > >> > addresses only bi-directional co-routed LSP and has no model to > >> handle > >> > bi-directional associated LSP in independent mode. And > unidirectional > >> > p2p and p2mp LSPs are not addressed by the current revision of the > >> > G.8113.1. > >> > Can all these out-of-scope constructs be used to conclude that > >> G.8113.1 > >> > is not capable to solve these issues? I don't think so. Solutions > are > >> > not readily available, that's all. > >> > > >> > Regards, > >> > Greg > >> > > >> > > >> > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > >> > wrote: > >> > > >> > > >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731", = there > is > >> > actually a lot of > >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional BF= D, > that > >> is > >> > a BFD WG problem > >> > =A0 =A0 =A0 =A0 at the moment. > >> > > >> > > >> > =A0 =A0 =A0 =A0 The fact that the BFD WG has not defined a solution = for > >> > unidirectional p2p and > >> > =A0 =A0 =A0 =A0 p2mp transport paths does not make BFD a suitable OA= M > >> protocol > >> > for MPLS-TP nor > >> > =A0 =A0 =A0 =A0 does resolve the technical issue that have been rais= ed. > >> > > >> > > >> > =A0 =A0 =A0 =A0 >----Messaggio originale---- > >> > =A0 =A0 =A0 =A0 >Da: david.i.allan@ericsson.com > >> > > >> > =A0 =A0 =A0 =A0 >Data: 8-lug-2011 18.13 > >> > =A0 =A0 =A0 =A0 >A: "Rui Costa", "Stewart > >> > Bryant" > >> > =A0 =A0 =A0 =A0 >Cc: > >> > "erminio.ottone_69@libero.it", > >> "mpls@ietf. > >> > =A0 =A0 =A0 =A0 org", "ietf@ietf.org", > "IETF- > >> > Announce" >> > =A0 =A0 =A0 =A0 announce@ietf.org> > >> > =A0 =A0 =A0 =A0 >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-c= c-cv- > rdi- > >> > 05.txt> > >> > > >> > =A0 =A0 =A0 =A0 (Proactive =A0 =A0 =A0Connectivity Verification, Con= tinuity > Check > >> and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS =A0 =A0 Transport =A0 =A0 =A0 Pr= ofile) to > Proposed > >> > Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Rui: > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >You wrote: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >>Reading something, keeping it on record, without e= ffect > in > >> > the draft and > >> > =A0 =A0 =A0 =A0 "ignoring comments" have IMHO similar outcomes. As a= uthor > of > >> > the draft you are > >> > =A0 =A0 =A0 =A0 free to do it. These standards have a great impact > >> > =A0 =A0 =A0 =A0 >>in our work, so i'm also free to write what i did. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >Numerous comments did have effect on the draft and = those > >> that > >> > didn't were > >> > =A0 =A0 =A0 =A0 either simply not actionable, were rhetorical or not > >> > constructive, and a few > >> > =A0 =A0 =A0 =A0 had to be balanced against comments coming from the = MPLS & > >> BFD > >> > WGs. I would > >> > =A0 =A0 =A0 =A0 translate "ingored" or "without effect" to "did not = get > one'e > >> > way". In the > >> > =A0 =A0 =A0 =A0 standards process it happens. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Meanwhile as an editor of the document, I'll take t= he > >> liberty > >> > of responding > >> > =A0 =A0 =A0 =A0 to some of the points you raise... > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>My technical concerns regarding this draft were > >> expressed... > >> > =A0 =A0 =A0 =A0 >>...in the (ITU-T -> IETF, Feb/2011) liaison regard= ing it > >> > (LS281, i > >> > =A0 =A0 =A0 =A0 believe); > >> > =A0 =A0 =A0 =A0 >>...in operators' meetings' that took place during = ITU- > T's > >> > Feb/2011 plenary > >> > =A0 =A0 =A0 =A0 meeting; > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >I and the WG don't really have access to private > grumblings. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>...in a comparison session that took place during = that > same > >> > ITU-T meeting. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >Lots of other opinions were expressed as well, and = they > did > >> > not all agree > >> > =A0 =A0 =A0 =A0 with you. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>Some: > >> > =A0 =A0 =A0 =A0 >>CC/CV > >> > =A0 =A0 =A0 =A0 >>I don't understand the need for 2 types of packets= : a > >> single > >> > type allows CC; > >> > =A0 =A0 =A0 =A0 mismatching identifiers in the same CC packets allow= CV. > >> > =A0 =A0 =A0 =A0 >>Besides adding complexity, we whether always activ= ate > both > >> or > >> > potentiate > >> > =A0 =A0 =A0 =A0 undetected mismerges. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >OK, lets walk through this. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >We want CV all the time so that any misconectivity = can be > >> > detected, but on > >> > =A0 =A0 =A0 =A0 the list it was expressed that the group did not wan= t the > >> > overhead of > >> > =A0 =A0 =A0 =A0 processing the source MEP TLV in every packet in ord= er to > >> > achieve this. We > >> > =A0 =A0 =A0 =A0 could carry it in every packet and have the receiver > simply > >> > ignore most of > >> > =A0 =A0 =A0 =A0 them, but then that would make the defect entry crit= eria > >> > compeltely random and > >> > =A0 =A0 =A0 =A0 the exit criteria unreliable as well, not really a g= ood > >> design. > >> > Hence they are > >> > =A0 =A0 =A0 =A0 separated using different ACH code points and the re= ceiver > is > >> > obliged to > >> > =A0 =A0 =A0 =A0 process every source MEP TLV it receives. I hope thi= s is > >> clear. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>(BTW: can't understand how we propose one ACH code= point > to > >> > CC, another for > >> > =A0 =A0 =A0 =A0 CV, [counting other drafts, another for frame loss .= ..] > but > >> > don't consider > >> > =A0 =A0 =A0 =A0 assigning 1 single ACH protocol identifier codepoint= >as > >> > requested by ITU-T) > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >Because that puts you into two protocol ID demultip= lexing > >> > steps per OAM PDU > >> > =A0 =A0 =A0 =A0 recevied to determine the intended function. Hence C= OSTS > >> MORE. > >> > That is pretty > >> > =A0 =A0 =A0 =A0 basic... > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >> Uni P2P / P2MP > >> > =A0 =A0 =A0 =A0 >> I can't see how BFD will support unidir and hence= P2MP > >> other > >> > than... > >> > =A0 =A0 =A0 =A0 >> ...eliminating the session "state variable" (down= , > init, > >> > up), aiming just > >> > =A0 =A0 =A0 =A0 the state variables we really need, bringing us to > something > >> > similar to 1731, > >> > =A0 =A0 =A0 =A0 eventually with other bits on the wire or... > >> > =A0 =A0 =A0 =A0 >> ...using IP to create the reverse way, which we c= annot > >> > assume per > >> > =A0 =A0 =A0 =A0 requirements; > >> > =A0 =A0 =A0 =A0 >> Will we create a complete different tool for that= ? > >> > =A0 =A0 =A0 =A0 >> (BFD's B=3D"bidirectional") > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731", = there > is > >> > actually a lot of > >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional BF= D, > that > >> is > >> > a BFD WG problem > >> > =A0 =A0 =A0 =A0 at the moment. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >> Provisioning list > >> > =A0 =A0 =A0 =A0 >> This is an MPLS profile/subset (and i heard) achi= evable > >> > through a > >> > =A0 =A0 =A0 =A0 particular configuration. So, i expect each draft-ie= tf- > mpls- > >> TP- > >> > * to focus on > >> > =A0 =A0 =A0 =A0 that profile/configuration. However, i keep seeing > >> > =A0 =A0 =A0 =A0 >> references f.i. to IP encapsulations unexpected u= nder > TP's > >> > OAM. > >> > =A0 =A0 =A0 =A0 >> I don't thus understand what the aim is: do we ex= pect > this > >> > in TP, are we > >> > =A0 =A0 =A0 =A0 talking about MPLS in general?... The TP profile is = never > >> quite > >> > delimited. > >> > =A0 =A0 =A0 =A0 >> Does chapter 4 contain ALL the configurable param= eters > >> list > >> > agreed to > >> > =A0 =A0 =A0 =A0 provide in the comparison session? > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >It should. As for encapsulations, unless TP is in a > complete > >> > island not > >> > =A0 =A0 =A0 =A0 connected to anything (which as a network is rather > useless) > >> it > >> > will be > >> > =A0 =A0 =A0 =A0 expected to interoperate with the rest of the MPLS > >> > architecture, and the stated > >> > =A0 =A0 =A0 =A0 intention of tool development was that what resulted= was > >> > applicable to the > >> > =A0 =A0 =A0 =A0 broader MPLS architecture. Which means backwards > compatiblity > >> > and procedures > >> > =A0 =A0 =A0 =A0 for interoperation. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >> Backwards compatibility > >> > =A0 =A0 =A0 =A0 >> This was the main argument risen to ground MPLS-T= P OAM > on > >> > BFD. It's not a > >> > =A0 =A0 =A0 =A0 better argument than grounding MPLS-TP OAM on 1731 d= ue to > its > >> > ETH deployment > >> > =A0 =A0 =A0 =A0 plus coherence with SDH, OTN, as defended by ITU-T. > >> > =A0 =A0 =A0 =A0 >> For reasons like the above, however, MPLS-TP BFD = won't > be > >> > backwards > >> > =A0 =A0 =A0 =A0 compatible with previous BFD (even considering just > CC/CV). > >> > They don't even > >> > =A0 =A0 =A0 =A0 share the same codepoint. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >The issue is not code point, which is the trivial p= art. > It > >> is > >> > reuse of the > >> > =A0 =A0 =A0 =A0 majority of the implementation. Again, pretty basic. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>Simplicity > >> > =A0 =A0 =A0 =A0 >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's > approach > >> to > >> > CC is simpler: > >> > =A0 =A0 =A0 =A0 in each flow, a standard defined nr of constant hear= tbeat > >> > signals (with > >> > =A0 =A0 =A0 =A0 standard constant or provisioned period - no > >> > =A0 =A0 =A0 =A0 >>auto/negotiated -) means OK. A standard defined nu= mber > of > >> > misses means lost > >> > =A0 =A0 =A0 =A0 Rx connection. An RDI, the only articulation between= Rx > and > >> Tx > >> > flows, > >> > =A0 =A0 =A0 =A0 meaningful in bidirectional applications, allows eac= h > >> > =A0 =A0 =A0 =A0 >>pear to identify Tx problems. > >> > =A0 =A0 =A0 =A0 >>This OAM simplicity is the key for reliable fail f= inger > >> > pointing, > >> > =A0 =A0 =A0 =A0 performance reports and protection. Also to allow sc= aling, > >> more > >> > implementation > >> > =A0 =A0 =A0 =A0 opportunities/manufacturers, which is valuable for > >> > =A0 =A0 =A0 =A0 >>operators. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >Well IMO there was not a lot of interest in T-MPLS = until > the > >> > IETF was going > >> > =A0 =A0 =A0 =A0 to re-define it and make it compatible with IP/MPLS.= So > there > >> > was an industry > >> > =A0 =A0 =A0 =A0 wide "design intent" implied here. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >> IMHO, between your MPLS-TP view and MPLS/IP, it b= ecomes > >> more > >> > and more > >> > =A0 =A0 =A0 =A0 difficult to tell which is which. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >That is because MPLS-TP is not a new techology, it = is an > >> > addition to the > >> > =A0 =A0 =A0 =A0 entire MPLS protocol suite. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Hope this helps > >> > =A0 =A0 =A0 =A0 >D > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.= com] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 19:25 > >> > > >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; Rui Costa; > ietf@ietf.org; > >> > IETF-Announce > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org > >> > > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: tp- > >> cc- > >> > cv-rdi-05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Hi Erminio: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as n= ot > >> meeting > >> > their > >> > =A0 =A0 =A0 =A0 >>transport networks' needs. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >E> This is a true statement: the solution in this d= raft > is > >> > useless for many > >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >The two statements do not necessarily follow. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >What we established during discussions at the SG15 > plenary > >> in > >> > February was > >> > =A0 =A0 =A0 =A0 that the issue some service providers had was that t= he > IETF > >> BFD > >> > solution > >> > =A0 =A0 =A0 =A0 exceeded their requirements in that there was additi= onal > >> > functionality they did > >> > =A0 =A0 =A0 =A0 not see a need for, and that they considered any > additional > >> > functionality > >> > =A0 =A0 =A0 =A0 parasitic. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >However this is a consequence of adapting an existi= ng > >> > technology to a new > >> > =A0 =A0 =A0 =A0 application. I do not see any way around that. And t= he > entire > >> > joint project was > >> > =A0 =A0 =A0 =A0 based on the premise of engineering re-use not green= field > >> > design. That is what > >> > =A0 =A0 =A0 =A0 it said on the tin up front, and IMO why when the IE= TF > >> started > >> > down this path > >> > =A0 =A0 =A0 =A0 packet transport transitioned from being a minority = sport > to > >> > mainstream, so it > >> > =A0 =A0 =A0 =A0 is a bit late to cry foul.... > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >My 2 cents > >> > =A0 =A0 =A0 =A0 >Dave > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.= com] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:36 > >> > > >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Cos= ta > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: tp- > >> cc- > >> > cv-rdi-05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Hi Erminio: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Two of the three document editors were present at S= G15 > >> plenary > >> > in February > >> > =A0 =A0 =A0 =A0 where the comments originated. The revised meeting > schedule > >> > resulted in a day > >> > =A0 =A0 =A0 =A0 spent going through the document with the editors. I= MO > there > >> > were lots of > >> > =A0 =A0 =A0 =A0 discussion and legitimate issues with the document > identified > >> > and corrected so > >> > =A0 =A0 =A0 =A0 it was a useful session. The liaison of same was in = many > ways > >> > *after the > >> > =A0 =A0 =A0 =A0 fact*. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Cheers > >> > =A0 =A0 =A0 =A0 >Dave > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it > >> > [mailto:erminio.ottone_69@libero.it] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:34 > >> > > >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org > >> > > >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: cv- > >> > rdi-05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The way this draft has been developed is a bit stra= nge. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The poll for its adoption as a WG document was halt= ed by > the > >> > MPLS WG chair > >> > =A0 =A0 =A0 =A0 because "it is not possible to judge consensus": > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- > >> > archive/web/mpls/current/msg04502.html > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The lack of consensus was motivated by serious tech= nical > >> > concerns raised by > >> > =A0 =A0 =A0 =A0 several transport experts during the poll. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Nevertheless the MPLS WG chair decided to adopt the= draft > as > >> a > >> > WG document: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- > >> > archive/web/mpls/current/msg04512.html > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >After several WG revisions and WG LCs, the technica= l > issues > >> > have not been > >> > =A0 =A0 =A0 =A0 resolved. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as n= ot > >> meeting > >> > their > >> > =A0 =A0 =A0 =A0 >>transport > >> > =A0 =A0 =A0 =A0 >networks' needs. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >This is a true statement: the solution in this draf= t is > >> > useless for many > >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it > >> > [mailto:erminio.ottone_69@libero.it] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:26 > >> > > >> > =A0 =A0 =A0 =A0 >To: loa@pi.nu; Rui Costa > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: cv- > >> > rdi-05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >> =A0Version -04 of the document was published June= 28th. > >> > =A0 =A0 =A0 =A0 >> > >> > > >> > =A0 =A0 =A0 =A0 >> =A0The publication request for draft-ietf-mpls-tp= -cc-cv- > rdi > >> > was =A0sent > >> > =A0 =A0 =A0 =A0 >> June 29th. > >> > =A0 =A0 =A0 =A0 >> > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >So when the WG LC to confirm the LC comment resolut= ion > has > >> > been launched? > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The proto write-up says: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0It has also passed a workin= g roup call to > verify > >> > that LC comments > >> > =A0 =A0 =A0 =A0 were correctly with minor comments. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >It also says: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0The comments has been > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0carefully discussed between= the authors and > >> people > >> > making the > >> > =A0 =A0 =A0 =A0 comments and > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0has been resolved. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >But it seems that some comments have not been discu= ssed > with > >> > the authors of > >> > =A0 =A0 =A0 =A0 the comments. When ITU-T Q10/15 has been involved in > >> discussing > >> > its comments? > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: Loa Andersson [mailto:loa@pi.nu] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 16:44 > >> > =A0 =A0 =A0 =A0 >To: Rui Costa > >> > > >> > =A0 =A0 =A0 =A0 >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> > > >> > =A0 =A0 =A0 =A0 >Subject: Re: [mpls] Last Call: >> rdi- > >> > 05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >All, > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Since someone has commented about the process used = for > >> > resolving > >> > =A0 =A0 =A0 =A0 >questions on > >> > =A0 =A0 =A0 =A0 >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some de= tails > >> > below. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The history of draft-ietf-mpls-tp-cc-cv-rdi working= group > >> > review > >> > =A0 =A0 =A0 =A0 >process is: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >On February 3rd 2011 the working group last call wa= s > issued > >> > =A0 =A0 =A0 =A0 >on version -03 > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This was copied to the the Ad Hoc Team = List > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0and liaised to SG15 also on February 3r= d > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This working group last call ended om F= eb 28 > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0On Feb 28 we also received a liaison wi= th comments > >> from > >> > SG15 > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The authors compiled a list of all comments receive= d =A0as > >> part > >> > the MPLS > >> > =A0 =A0 =A0 =A0 >working group last call; these =A0comments - and th= e > intended > >> > resolution - > >> > =A0 =A0 =A0 =A0 >is included in the meeting minutes from the Prague > meeting: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0http://www.ietf.org/proceedings/80/slid= es/mpls- > 9.pdf > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0During the IETF meeting in Prague, we agreed wi= th the > BFD > >> > working > >> > =A0 =A0 =A0 =A0 > =A0group to do a separate working group last callf= or the > BFD > >> > working > >> > =A0 =A0 =A0 =A0 > =A0group > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The (BFD) working group last call was started on Ma= rch > 30th > >> > and ran > >> > =A0 =A0 =A0 =A0 >for 13 days. The last call ended on April 11th. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0The authors have since worked hard to resolve c= omments, > >> some > >> > =A0 =A0 =A0 =A0 > =A0issue has been brought to the working group mai= ling > list > >> for > >> > =A0 =A0 =A0 =A0 > =A0resolution. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0Version -04 of the document was published June = 28th. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0The publication request for draft-ietf-mpls-tp-= cc-cv- > rdi > >> was > >> > sent > >> > =A0 =A0 =A0 =A0 > =A0June 29th. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0The AD review resulted in a "New ID needed" due= to > mostly > >> > editorial > >> > =A0 =A0 =A0 =A0 > =A0comments. Version -05 was published on June 29 = and the > >> IETF > >> > last call > >> > =A0 =A0 =A0 =A0 > =A0started as soon as the new ID was avaialbe. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0The current list of Last Call Comments resoltio= n is > also > >> > avaiable at: > >> > =A0 =A0 =A0 =A0 > =A0http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comme= nts.xls > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0The list of issues that the authors kept very > carefully, > >> > shows without > >> > =A0 =A0 =A0 =A0 >doubt > >> > =A0 =A0 =A0 =A0 > =A0that no comments been ignored. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0Loa > >> > =A0 =A0 =A0 =A0 > =A0mpls wg document shepherd > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson.= com] > >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 14:58 > >> > > >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org > >> > > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: >> rdi- > >> > 05.txt> > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Hi Rui: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The comments were not ignored, the resolution of th= e Q10 > >> > comments as well as > >> > > >> > =A0 =A0 =A0 =A0 those collected from the MPLS WG was presented at th= e last > >> > IETF. My spreadsheet > >> > > >> > =A0 =A0 =A0 =A0 from which that report was generated and has been > augmented > >> to > >> > include the BFD > >> > > >> > =A0 =A0 =A0 =A0 WG comments is available at http://www.pi.nu/~loa/cc= -cv- > rdi- > >> > Last-Call-Comments >> > Comments> . > >> > =A0 =A0 =A0 =A0 xls > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >So you know... > >> > =A0 =A0 =A0 =A0 >Dave > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > > >> > =A0 =A0 =A0 =A0 >From: ietf-bounces@ietf.org [mailto:ietf- > bounces@ietf.org] > >> On > >> > Behalf Of Rui > >> > =A0 =A0 =A0 =A0 Costa > >> > =A0 =A0 =A0 =A0 >Sent: segunda-feira, 4 de Julho de 2011 23:03 > >> > > >> > =A0 =A0 =A0 =A0 >To: ietf@ietf.org; IETF-Announce > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org > >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: >> rdi- > >> > 05.txt> > >> > > >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Che= ck and > >> > Remote Defect > >> > > >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed > Standard > >> > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >IMHO and for the record: > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >ITU-T comments regarding this draft haven't been > discussed > >> > with ITU-T but > >> > =A0 =A0 =A0 =A0 were simply ignored. No LS describing these comments= ' > >> > resolution was sent. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >Several service providers regarded this draft as no= t > meeting > >> > their transport > >> > =A0 =A0 =A0 =A0 networks' needs. > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >[The v03 draft was published in Feb and went to WG = LC. > >> > =A0 =A0 =A0 =A0 >The v04 draft addressing WG LC comments was publish= ed on > the > >> > 28th June (same > >> > =A0 =A0 =A0 =A0 date as the proto write-up). > >> > =A0 =A0 =A0 =A0 >When was the WG LC launched, to verify LC comments > >> > resolution?] > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Regards, > >> > =A0 =A0 =A0 =A0 >Rui > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >-----Original Message----- > >> > =A0 =A0 =A0 =A0 >From: mpls-bounces@ietf.org [mailto:mpls- > bounces@ietf.org] > >> On > >> > Behalf Of The > >> > =A0 =A0 =A0 =A0 IESG > >> > =A0 =A0 =A0 =A0 >Sent: quinta-feira, 30 de Junho de 2011 14:47 > >> > =A0 =A0 =A0 =A0 >To: IETF-Announce > >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org > >> > > >> > =A0 =A0 =A0 =A0 >Subject: [mpls] Last Call: >> > 05.txt> (Proactive > >> > > >> > =A0 =A0 =A0 =A0 Connectivity Verification, Continuity Check and Remo= te > Defect > >> > indication for > >> > =A0 =A0 =A0 =A0 MPLS Transport Profile) to Proposed Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >The IESG has received a request from the Multiproto= col > Label > >> > Switching WG > >> > =A0 =A0 =A0 =A0 >(mpls) to consider the following document: > >> > =A0 =A0 =A0 =A0 >- 'Proactive Connectivity Verification, Continuity = Check > and > >> > Remote > >> > =A0 =A0 =A0 =A0 > =A0 Defect indication for MPLS Transport Profile' > >> > =A0 =A0 =A0 =A0 > =A0 as a Prop= osed > >> Standard > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The IESG plans to make a decision in the next few w= eeks, > and > >> > solicits > >> > =A0 =A0 =A0 =A0 >final comments on this action. Please send substant= ive > >> > comments to the > >> > =A0 =A0 =A0 =A0 >ietf@ietf.org mailing lists by 2011-07-14. Exceptio= nally, > >> > comments may be > >> > =A0 =A0 =A0 =A0 >sent to iesg@ietf.org instead. In either case, plea= se > retain > >> > the > >> > =A0 =A0 =A0 =A0 >beginning of the Subject line to allow automated so= rting. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >Abstract > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check, Proactive Connectivity Verif= ication > and > >> > Remote > >> > =A0 =A0 =A0 =A0 > =A0 Defect Indication functionalities are required= for > MPLS- > >> TP > >> > OAM. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check monitors the integrity of the > continuity > >> > of the > >> > =A0 =A0 =A0 =A0 > =A0 label switched path for any loss of continuity= defect. > >> > Connectivity > >> > =A0 =A0 =A0 =A0 > =A0 verification monitors the integrity of the rou= ting of > the > >> > label > >> > =A0 =A0 =A0 =A0 > =A0 switched path between sink and source for any > >> connectivity > >> > issues. > >> > =A0 =A0 =A0 =A0 > =A0 Remote defect indication enables an End Point = to > report, > >> to > >> > its > >> > =A0 =A0 =A0 =A0 > =A0 associated End Point, a fault or defect condit= ion that > it > >> > detects on > >> > =A0 =A0 =A0 =A0 > =A0 a pseudo wire, label switched path or Section. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > =A0 This document specifies methods for proactive > continuity > >> > check, > >> > =A0 =A0 =A0 =A0 > =A0 continuity verification, and remote defect ind= ication > for > >> > MPLS-TP > >> > =A0 =A0 =A0 =A0 > =A0 label switched paths, pseudo wires and Section= s using > >> > Bidirectional > >> > =A0 =A0 =A0 =A0 > =A0 Forwarding Detection. > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >The file can be obtained via > >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-= cc-cv- > >> rdi/ > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >IESG discussion can be tracked via > >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-= cc-cv- > >> rdi/ > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 >No IPR declarations have been submitted directly on= this > I- > >> D. > >> > =A0 =A0 =A0 =A0 >_______________________________________________ > >> > > >> > =A0 =A0 =A0 =A0 >mpls mailing list > >> > =A0 =A0 =A0 =A0 >mpls@ietf.org > >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/mpls > >> > =A0 =A0 =A0 =A0 > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > =A0 =A0 =A0 =A0 >_______________________________________________ > >> > =A0 =A0 =A0 =A0 >Ietf mailing list > >> > =A0 =A0 =A0 =A0 >Ietf@ietf.org > >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/ietf > >> > > >> > =A0 =A0 =A0 =A0 > > >> > > >> > > >> > =A0 =A0 =A0 =A0 _______________________________________________ > >> > =A0 =A0 =A0 =A0 mpls mailing list > >> > =A0 =A0 =A0 =A0 mpls@ietf.org > >> > =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > > >> > > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From maarten.vissers@huawei.com Wed Jul 27 15:16:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D8511E80AC for ; Wed, 27 Jul 2011 15:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWBmUtU1lRIB for ; Wed, 27 Jul 2011 15:16:48 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id D9CF011E8097 for ; Wed, 27 Jul 2011 15:16:47 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP00019FJ7YWG@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 23:16:46 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LP0001ZPJ7YWZ@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 27 Jul 2011 23:16:46 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 23:16:36 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 23:16:45 +0100 Date: Wed, 27 Jul 2011 22:16:43 +0000 From: Maarten vissers In-reply-to: <5E893DB832F57341992548CDBB333163A0AAEAC501@EMBX01-HQ.jnpr.net> X-Originating-IP: [10.47.78.88] To: John E Drake , Gregory Mirsky , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-index: AcxB0cp/MPi362p/Qa6mptSj5vopyQKqOBdAAAaRTcAAAID/GAAAQHbgAAQo/NAAAGnnsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5E893DB832F57341992548CDBB333163A0AAEAC501@EMBX01-HQ.jnpr.net> Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:16:51 -0000 John, See my response to Greg a minute ago. In addition, have a look at e.g. PDH, SDH, ATM and OTN OAM. There is no requirement in transport networks to send RDI from MEP sink to MEP source function. Such requirement does not exist in MPLS-TP transport networks either. RDI is used to support bidirectional performance monitoring at transport service layer. Unidir PW/service-LSP connections are not required/unable to support bidir perf mon. So it is wasteful to try to send RDI from sink to source in unidir connections. Regards, Maarten > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: 28 July 2011 00:03 > To: Maarten vissers; Gregory Mirsky; mpls@ietf.org > Subject: RE: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Maarten, > > Actually it doesn't. G.8113.1, absent an IP forwarding capability, has > no ability to send replies from egress to ingress for unidirectional > LSP constructs. > > Thanks, > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Maarten vissers > > Sent: Wednesday, July 27, 2011 1:17 PM > > To: Gregory Mirsky; mpls@ietf.org > > Subject: Re: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > > Remote Defect indication for MPLS Transport Profile) to Proposed > > Standard > > > > Dear Greg, > > > > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in > > - co-routed bidir p2p, > > - associated bidir p2p, > > - unidir p2p and > > - unidir p2mp > > PW, LSP, SPME and section connections. > > > > > The G.8113.1 addresses only bi-directional co-routed LSP and has no > > model to > > > handle bi-directional associated LSP in independent mode. And > > unidirectional > > > p2p and p2mp LSPs are not addressed by the current revision of the > > G.8113.1. > > > Can all these out-of-scope constructs be used to conclude that > > G.8113.1 > > > is not capable to solve these issues? I don't think so. Solutions > are > > > not readily available, that's all. > > > > Solution for CCM is already available in G.8113.1. > > I.e. G.8113.1 already resolved these issues as such. > > > > Regards, > > Maarten > > > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: 27 July 2011 21:54 > > > To: Maarten vissers; mpls@ietf.org > > > Subject: RE: [mpls] FW: R: RE: Last Call: cv- > > > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > > and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > Dear Maarten, > > > the question was raised in regard to CC/CV, a.k.a. CCM, > > functionality. > > > I apologize that I didn't state that explicitly and left it as > > implied > > > context of the discussion. I don't question G.8113.1 capabilities > > > you've listed but only compare with corresponding CCM addressed in > > CC- > > > CV-RDI. > > > > > > Regards, > > > Greg > > > ________________________________________ > > > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > > > Maarten vissers [maarten.vissers@huawei.com] > > > Sent: Wednesday, July 27, 2011 3:49 PM > > > To: Eric Gray; mpls@ietf.org > > > Subject: Re: [mpls] FW: R: RE: Last Call: cv- > > > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > > and > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > Standard > > > > > > G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p > unidir, > > > p2mp unidir connections. > > > > > > The p2p bidir connection can be co-routed, and then it is possible > to > > > perform e.g. loopback at intermediate nodes. > > > > > > The p2p bidir connection can be associated, and then a loopback at > an > > > intermediate node will not be possible. But the end-to-end > monitoring > > > is still performed without problems. > > > > > > Note that a co-routed bidir 1+1 protected connection can select > it's > > A- > > > to-Z traffic from working and its Z-to-A traffic from protection; > > this > > > effectively creates an associated bidir connection in which e2e > > > monitoring is supported but loopbacks at intermediate nodes are not > > > successful. > > > > > > Regards, > > > Maarten > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > Of > > > > Eric Gray > > > > Sent: 27 July 2011 18:32 > > > > To: mpls@ietf.org > > > > Subject: [mpls] FW: R: RE: Last Call: > rdi- > > > > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > > Standard > > > > > > > > Forwarding in plain text... > > > > > > > > ________________________________ > > > > > > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > > > Sent: Wednesday, July 13, 2011 10:57 PM > > > > To: erminio.ottone_69@libero.it > > > > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > > > > ietf@ietf.org; IETF-Announce > > > > Subject: Re: [mpls] R: RE: Last Call: > rdi- > > > > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect indication for MPLS Transport Profile) to Proposed > > > > Standard > > > > > > > > > > > > Dear Erminio, > > > > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to > > CCM > > > is > > > > even more narrow then of the document being discussed. The > G.8113.1 > > > > addresses only bi-directional co-routed LSP and has no model to > > > handle > > > > bi-directional associated LSP in independent mode. And > > unidirectional > > > > p2p and p2mp LSPs are not addressed by the current revision of > the > > > > G.8113.1. > > > > Can all these out-of-scope constructs be used to conclude that > > > G.8113.1 > > > > is not capable to solve these issues? I don't think so. Solutions > > are > > > > not readily available, that's all. > > > > > > > > Regards, > > > > Greg > > > > > > > > > > > > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > > > > wrote: > > > > > > > > > > > > >I would not go so far as to say "similar to 1731", there > > is > > > > actually a lot of > > > > difference under the hood. As for uni-directional BFD, > that > > > is > > > > a BFD WG problem > > > > at the moment. > > > > > > > > > > > > The fact that the BFD WG has not defined a solution for > > > > unidirectional p2p and > > > > p2mp transport paths does not make BFD a suitable OAM > > > protocol > > > > for MPLS-TP nor > > > > does resolve the technical issue that have been raised. > > > > > > > > > > > > >----Messaggio originale---- > > > > >Da: david.i.allan@ericsson.com > > > > > > > > >Data: 8-lug-2011 18.13 > > > > >A: "Rui Costa", "Stewart > > > > Bryant" > > > > >Cc: > > > > "erminio.ottone_69@libero.it", > > > "mpls@ietf. > > > > org", "ietf@ietf.org", > "IETF- > > > > Announce" > > > announce@ietf.org> > > > > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv- > > rdi- > > > > 05.txt> > > > > > > > > (Proactive Connectivity Verification, Continuity > Check > > > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to > > Proposed > > > > Standard > > > > > > > > > >Rui: > > > > > > > > > > > > > >You wrote: > > > > > > > > > >>Reading something, keeping it on record, without effect > > in > > > > the draft and > > > > "ignoring comments" have IMHO similar outcomes. As author > > of > > > > the draft you are > > > > free to do it. These standards have a great impact > > > > >>in our work, so i'm also free to write what i did. > > > > > > > > > > > > > >Numerous comments did have effect on the draft and those > > > that > > > > didn't were > > > > either simply not actionable, were rhetorical or not > > > > constructive, and a few > > > > had to be balanced against comments coming from the MPLS > & > > > BFD > > > > WGs. I would > > > > translate "ingored" or "without effect" to "did not get > > one'e > > > > way". In the > > > > standards process it happens. > > > > > > > > > >Meanwhile as an editor of the document, I'll take the > > > liberty > > > > of responding > > > > to some of the points you raise... > > > > > > > > > > > > > >>My technical concerns regarding this draft were > > > expressed... > > > > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding > it > > > > (LS281, i > > > > believe); > > > > >>...in operators' meetings' that took place during ITU- > T's > > > > Feb/2011 plenary > > > > meeting; > > > > > > > > > > > > > >I and the WG don't really have access to private > > grumblings. > > > > > > > > > > > > > >>...in a comparison session that took place during that > > same > > > > ITU-T meeting. > > > > > > > > > > > > > >Lots of other opinions were expressed as well, and they > > did > > > > not all agree > > > > with you. > > > > > > > > > > > > > >>Some: > > > > >>CC/CV > > > > >>I don't understand the need for 2 types of packets: a > > > single > > > > type allows CC; > > > > mismatching identifiers in the same CC packets allow CV. > > > > >>Besides adding complexity, we whether always activate > > both > > > or > > > > potentiate > > > > undetected mismerges. > > > > > > > > > > > > > >OK, lets walk through this. > > > > > > > > > >We want CV all the time so that any misconectivity can > be > > > > detected, but on > > > > the list it was expressed that the group did not want the > > > > overhead of > > > > processing the source MEP TLV in every packet in order to > > > > achieve this. We > > > > could carry it in every packet and have the receiver > simply > > > > ignore most of > > > > them, but then that would make the defect entry criteria > > > > compeltely random and > > > > the exit criteria unreliable as well, not really a good > > > design. > > > > Hence they are > > > > separated using different ACH code points and the > receiver > > is > > > > obliged to > > > > process every source MEP TLV it receives. I hope this is > > > clear. > > > > > > > > > > > > > >>(BTW: can't understand how we propose one ACH codepoint > > to > > > > CC, another for > > > > CV, [counting other drafts, another for frame loss ...] > but > > > > don't consider > > > > assigning 1 single ACH protocol identifier codepoint >as > > > > requested by ITU-T) > > > > > > > > > > > > > >Because that puts you into two protocol ID > demultiplexing > > > > steps per OAM PDU > > > > recevied to determine the intended function. Hence COSTS > > > MORE. > > > > That is pretty > > > > basic... > > > > > > > > > > > > > >> Uni P2P / P2MP > > > > >> I can't see how BFD will support unidir and hence P2MP > > > other > > > > than... > > > > >> ...eliminating the session "state variable" (down, > init, > > > > up), aiming just > > > > the state variables we really need, bringing us to > > something > > > > similar to 1731, > > > > eventually with other bits on the wire or... > > > > >> ...using IP to create the reverse way, which we cannot > > > > assume per > > > > requirements; > > > > >> Will we create a complete different tool for that? > > > > >> (BFD's B="bidirectional") > > > > > > > > > > > > > >I would not go so far as to say "similar to 1731", there > > is > > > > actually a lot of > > > > difference under the hood. As for uni-directional BFD, > that > > > is > > > > a BFD WG problem > > > > at the moment. > > > > > > > > > > > > > >> Provisioning list > > > > >> This is an MPLS profile/subset (and i heard) > achievable > > > > through a > > > > particular configuration. So, i expect each draft-ietf- > > mpls- > > > TP- > > > > * to focus on > > > > that profile/configuration. However, i keep seeing > > > > >> references f.i. to IP encapsulations unexpected under > > TP's > > > > OAM. > > > > >> I don't thus understand what the aim is: do we expect > > this > > > > in TP, are we > > > > talking about MPLS in general?... The TP profile is never > > > quite > > > > delimited. > > > > >> Does chapter 4 contain ALL the configurable parameters > > > list > > > > agreed to > > > > provide in the comparison session? > > > > > > > > > > > > > >It should. As for encapsulations, unless TP is in a > > complete > > > > island not > > > > connected to anything (which as a network is rather > > useless) > > > it > > > > will be > > > > expected to interoperate with the rest of the MPLS > > > > architecture, and the stated > > > > intention of tool development was that what resulted was > > > > applicable to the > > > > broader MPLS architecture. Which means backwards > > compatiblity > > > > and procedures > > > > for interoperation. > > > > > > > > > > > > > >> Backwards compatibility > > > > >> This was the main argument risen to ground MPLS-TP OAM > > on > > > > BFD. It's not a > > > > better argument than grounding MPLS-TP OAM on 1731 due to > > its > > > > ETH deployment > > > > plus coherence with SDH, OTN, as defended by ITU-T. > > > > >> For reasons like the above, however, MPLS-TP BFD won't > > be > > > > backwards > > > > compatible with previous BFD (even considering just > CC/CV). > > > > They don't even > > > > share the same codepoint. > > > > > > > > > > > > > >The issue is not code point, which is the trivial part. > It > > > is > > > > reuse of the > > > > majority of the implementation. Again, pretty basic. > > > > > > > > > > > > > >>Simplicity > > > > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's > approach > > > to > > > > CC is simpler: > > > > in each flow, a standard defined nr of constant heartbeat > > > > signals (with > > > > standard constant or provisioned period - no > > > > >>auto/negotiated -) means OK. A standard defined number > of > > > > misses means lost > > > > Rx connection. An RDI, the only articulation between Rx > and > > > Tx > > > > flows, > > > > meaningful in bidirectional applications, allows each > > > > >>pear to identify Tx problems. > > > > >>This OAM simplicity is the key for reliable fail finger > > > > pointing, > > > > performance reports and protection. Also to allow > scaling, > > > more > > > > implementation > > > > opportunities/manufacturers, which is valuable for > > > > >>operators. > > > > > > > > > > > > > >Well IMO there was not a lot of interest in T-MPLS until > > the > > > > IETF was going > > > > to re-define it and make it compatible with IP/MPLS. So > > there > > > > was an industry > > > > wide "design intent" implied here. > > > > > > > > > > > > > >> IMHO, between your MPLS-TP view and MPLS/IP, it > becomes > > > more > > > > and more > > > > difficult to tell which is which. > > > > > > > > > > > > > >That is because MPLS-TP is not a new techology, it is an > > > > addition to the > > > > entire MPLS protocol suite. > > > > > > > > > >Hope this helps > > > > >D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > > > > > > > > >To: erminio.ottone_69@libero.it; Rui Costa; > ietf@ietf.org; > > > > IETF-Announce > > > > >Cc: mpls@ietf.org > > > > > > > > >Subject: RE: [mpls] R: Re: Last Call: tp- > > > cc- > > > > cv-rdi-05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > > > > > >Hi Erminio: > > > > > > > > > > > > > > >>Several service providers regarded this draft as not > > > meeting > > > > their > > > > >>transport networks' needs. > > > > > > > > > > > > > >E> This is a true statement: the solution in this draft > is > > > > useless for many > > > > MPLS- TP deployments. > > > > > > > > > > > > > >The two statements do not necessarily follow. > > > > > > > > > >What we established during discussions at the SG15 > plenary > > > in > > > > February was > > > > that the issue some service providers had was that the > IETF > > > BFD > > > > solution > > > > exceeded their requirements in that there was additional > > > > functionality they did > > > > not see a need for, and that they considered any > additional > > > > functionality > > > > parasitic. > > > > > > > > > >However this is a consequence of adapting an existing > > > > technology to a new > > > > application. I do not see any way around that. And the > > entire > > > > joint project was > > > > based on the premise of engineering re-use not greenfield > > > > design. That is what > > > > it said on the tin up front, and IMO why when the IETF > > > started > > > > down this path > > > > packet transport transitioned from being a minority sport > > to > > > > mainstream, so it > > > > is a bit late to cry foul.... > > > > > > > > > >My 2 cents > > > > >Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > > > > > > > > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > > > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > > >Subject: RE: [mpls] R: Re: Last Call: tp- > > > cc- > > > > cv-rdi-05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > > > > > >Hi Erminio: > > > > > > > > > >Two of the three document editors were present at SG15 > > > plenary > > > > in February > > > > where the comments originated. The revised meeting > schedule > > > > resulted in a day > > > > spent going through the document with the editors. IMO > > there > > > > were lots of > > > > discussion and legitimate issues with the document > > identified > > > > and corrected so > > > > it was a useful session. The liaison of same was in many > > ways > > > > *after the > > > > fact*. > > > > > > > > > >Cheers > > > > >Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: erminio.ottone_69@libero.it > > > > [mailto:erminio.ottone_69@libero.it] > > > > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > > > > > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > > > >Cc: mpls@ietf.org > > > > > > > > >Subject: R: Re: [mpls] Last Call: cc- > > cv- > > > > rdi-05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > >The way this draft has been developed is a bit strange. > > > > > > > > > >The poll for its adoption as a WG document was halted by > > the > > > > MPLS WG chair > > > > because "it is not possible to judge consensus": > > > > > > > > > >http://www.ietf.org/mail- > > > > archive/web/mpls/current/msg04502.html > > > > > > > > > >The lack of consensus was motivated by serious technical > > > > concerns raised by > > > > several transport experts during the poll. > > > > > > > > > >Nevertheless the MPLS WG chair decided to adopt the > draft > > as > > > a > > > > WG document: > > > > > > > > > >http://www.ietf.org/mail- > > > > archive/web/mpls/current/msg04512.html > > > > > > > > > >After several WG revisions and WG LCs, the technical > > issues > > > > have not been > > > > resolved. > > > > > > > > > > > > > >>Several service providers regarded this draft as not > > > meeting > > > > their > > > > >>transport > > > > >networks' needs. > > > > > > > > > > > > > >This is a true statement: the solution in this draft is > > > > useless for many > > > > MPLS- TP deployments. > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: erminio.ottone_69@libero.it > > > > [mailto:erminio.ottone_69@libero.it] > > > > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > > > > > > > > >To: loa@pi.nu; Rui Costa > > > > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > > > > >Subject: R: Re: [mpls] Last Call: cc- > > cv- > > > > rdi-05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > > > > > >> Version -04 of the document was published June 28th. > > > > >> > > > > > > > > >> The publication request for draft-ietf-mpls-tp-cc-cv- > > rdi > > > > was sent > > > > >> June 29th. > > > > >> > > > > > > > > > >So when the WG LC to confirm the LC comment resolution > has > > > > been launched? > > > > > > > > > >The proto write-up says: > > > > > > > > > > It has also passed a working roup call to > > verify > > > > that LC comments > > > > were correctly with minor comments. > > > > > > > > > >It also says: > > > > > > > > > > The comments has been > > > > > carefully discussed between the authors and > > > people > > > > making the > > > > comments and > > > > > has been resolved. > > > > > > > > > >But it seems that some comments have not been discussed > > with > > > > the authors of > > > > the comments. When ITU-T Q10/15 has been involved in > > > discussing > > > > its comments? > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Loa Andersson [mailto:loa@pi.nu] > > > > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > > > > >To: Rui Costa > > > > > > > > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > > > > > > > > >Subject: Re: [mpls] Last Call: cv- > > > rdi- > > > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > >All, > > > > > > > > > >Since someone has commented about the process used for > > > > resolving > > > > >questions on > > > > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details > > > > below. > > > > > > > > > >The history of draft-ietf-mpls-tp-cc-cv-rdi working > group > > > > review > > > > >process is: > > > > > > > > > >On February 3rd 2011 the working group last call was > > issued > > > > >on version -03 > > > > > > > > > > This was copied to the the Ad Hoc Team List > > > > > and liaised to SG15 also on February 3rd > > > > > > > > > > This working group last call ended om Feb 28 > > > > > > > > > > > > > > > On Feb 28 we also received a liaison with comments > > > from > > > > SG15 > > > > > > > > > > > > > > >The authors compiled a list of all comments received as > > > part > > > > the MPLS > > > > >working group last call; these comments - and the > > intended > > > > resolution - > > > > >is included in the meeting minutes from the Prague > > meeting: > > > > > > > > > > > > > > > http://www.ietf.org/proceedings/80/slides/mpls- > 9.pdf > > > > > > > > > > > > > > > During the IETF meeting in Prague, we agreed with the > > BFD > > > > working > > > > > group to do a separate working group last callfor the > > BFD > > > > working > > > > > group > > > > > > > > > >The (BFD) working group last call was started on March > > 30th > > > > and ran > > > > >for 13 days. The last call ended on April 11th. > > > > > > > > > > The authors have since worked hard to resolve > comments, > > > some > > > > > issue has been brought to the working group mailing > list > > > for > > > > > resolution. > > > > > > > > > > Version -04 of the document was published June 28th. > > > > > > > > > > The publication request for draft-ietf-mpls-tp-cc-cv- > rdi > > > was > > > > sent > > > > > June 29th. > > > > > > > > > > The AD review resulted in a "New ID needed" due to > > mostly > > > > editorial > > > > > comments. Version -05 was published on June 29 and the > > > IETF > > > > last call > > > > > started as soon as the new ID was avaialbe. > > > > > > > > > > The current list of Last Call Comments resoltion is > also > > > > avaiable at: > > > > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls > > > > > > > > > > > > > > The list of issues that the authors kept very > carefully, > > > > shows without > > > > >doubt > > > > > that no comments been ignored. > > > > > > > > > > Loa > > > > > mpls wg document shepherd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: David Allan I [mailto:david.i.allan@ericsson.com] > > > > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > > > > > > > > >To: Rui Costa; ietf@ietf.org; IETF-Announce > > > > >Cc: mpls@ietf.org > > > > > > > > >Subject: RE: [mpls] Last Call: cv- > > > rdi- > > > > 05.txt> > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > >Hi Rui: > > > > > > > > > >The comments were not ignored, the resolution of the Q10 > > > > comments as well as > > > > > > > > those collected from the MPLS WG was presented at the > last > > > > IETF. My spreadsheet > > > > > > > > from which that report was generated and has been > augmented > > > to > > > > include the BFD > > > > > > > > WG comments is available at http://www.pi.nu/~loa/cc-cv- > > rdi- > > > > Last-Call-Comments > > > Comments> . > > > > xls > > > > > > > > > > > > > >So you know... > > > > >Dave > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > > >From: ietf-bounces@ietf.org [mailto:ietf- > bounces@ietf.org] > > > On > > > > Behalf Of Rui > > > > Costa > > > > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > > > > > > > > >To: ietf@ietf.org; IETF-Announce > > > > >Cc: mpls@ietf.org > > > > >Subject: RE: [mpls] Last Call: cv- > > > rdi- > > > > 05.txt> > > > > > > > > (Proactive Connectivity Verification, Continuity Check > and > > > > Remote Defect > > > > > > > > indication for MPLS Transport Profile) to Proposed > Standard > > > > > > > > > > > > > >IMHO and for the record: > > > > > > > > > >ITU-T comments regarding this draft haven't been > discussed > > > > with ITU-T but > > > > were simply ignored. No LS describing these comments' > > > > resolution was sent. > > > > > > > > > > > > > >Several service providers regarded this draft as not > > meeting > > > > their transport > > > > networks' needs. > > > > > > > > > > > > > >[The v03 draft was published in Feb and went to WG LC. > > > > >The v04 draft addressing WG LC comments was published on > > the > > > > 28th June (same > > > > date as the proto write-up). > > > > >When was the WG LC launched, to verify LC comments > > > > resolution?] > > > > > > > > > >Regards, > > > > >Rui > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: mpls-bounces@ietf.org [mailto:mpls- > bounces@ietf.org] > > > On > > > > Behalf Of The > > > > IESG > > > > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > > > > >To: IETF-Announce > > > > >Cc: mpls@ietf.org > > > > > > > > >Subject: [mpls] Last Call: rdi- > > > > 05.txt> (Proactive > > > > > > > > Connectivity Verification, Continuity Check and Remote > > Defect > > > > indication for > > > > MPLS Transport Profile) to Proposed Standard > > > > > > > > > > > > > > > > > > >The IESG has received a request from the Multiprotocol > > Label > > > > Switching WG > > > > >(mpls) to consider the following document: > > > > >- 'Proactive Connectivity Verification, Continuity Check > > and > > > > Remote > > > > > Defect indication for MPLS Transport Profile' > > > > > 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 2011-07-14. > 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 > > > > > > > > > > Continuity Check, Proactive Connectivity Verification > > and > > > > Remote > > > > > Defect Indication functionalities are required for > > MPLS- > > > TP > > > > OAM. > > > > > > > > > > Continuity Check monitors the integrity of the > > continuity > > > > of the > > > > > label switched path for any loss of continuity > defect. > > > > Connectivity > > > > > verification monitors the integrity of the routing of > > the > > > > label > > > > > switched path between sink and source for any > > > connectivity > > > > issues. > > > > > Remote defect indication enables an End Point to > > report, > > > to > > > > its > > > > > associated End Point, a fault or defect condition > that > > it > > > > detects on > > > > > a pseudo wire, label switched path or Section. > > > > > > > > > > This document specifies methods for proactive > > continuity > > > > check, > > > > > continuity verification, and remote defect indication > > for > > > > MPLS-TP > > > > > label switched paths, pseudo wires and Sections using > > > > Bidirectional > > > > > Forwarding Detection. > > > > > > > > > > > > > > >The file can be obtained via > > > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc- > cv- > > > rdi/ > > > > > > > > > >IESG discussion can be tracked via > > > > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc- > cv- > > > rdi/ > > > > > > > > > > > > > > >No IPR declarations have been submitted directly on this > > I- > > > D. > > > > >_______________________________________________ > > > > > > > > >mpls mailing list > > > > >mpls@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >Ietf mailing list > > > > >Ietf@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/ietf > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Wed Jul 27 15:19:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F3211E80B7 for ; Wed, 27 Jul 2011 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFo-MQ2Okn5q for ; Wed, 27 Jul 2011 15:19:44 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C853511E8097 for ; Wed, 27 Jul 2011 15:19:43 -0700 (PDT) Received: by iye7 with SMTP id 7so2608056iye.31 for ; Wed, 27 Jul 2011 15:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rzEEo8k82ITYAbF+SqeRTcvrFtLZPJxLH6/N4xiaFN8=; b=ImP3Q4M8MpEQea5L7vGfBNIi5Mu7z4c/DHdeCShT7qDONF0D4IX8wjJfAd4s1J5Hdu 22CWVhT/rAveKtvqnGgHICK5FS/L8FVOgf8L1xw9Bl8RHCDxOeRNR8kEFTjY2QIUwR8z XVvgO1qGAESTeXr86fTqp4Qz3o7vb1F1HuaHQ= Received: by 10.42.149.131 with SMTP id w3mr270330icv.340.1311805183089; Wed, 27 Jul 2011 15:19:43 -0700 (PDT) Received: from McAsterix.local ([207.96.251.20]) by mx.google.com with ESMTPS id ue1sm417817icb.8.2011.07.27.15.19.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 15:19:42 -0700 (PDT) Message-ID: <4E308EFB.1090305@gmail.com> Date: Thu, 28 Jul 2011 00:19:39 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <5E893DB832F57341992548CDBB333163A0AAEAC501@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AAEAC501@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:19:46 -0000 Hi John, You asked: > Actually it doesn't. G.8113.1, absent an IP forwarding capability, has no ability to send replies from egress to ingress for unidirectional LSP constructs. How does draft-ietf-mpls-tp-cc-cv-rdi do it under the same circumstances? Use an iPhone? ;) Cheers, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Maarten vissers >> Sent: Wednesday, July 27, 2011 1:17 PM >> To: Gregory Mirsky; mpls@ietf.org >> Subject: Re: [mpls] FW: R: RE: Last Call:> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> Dear Greg, >> >> G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in >> - co-routed bidir p2p, >> - associated bidir p2p, >> - unidir p2p and >> - unidir p2mp >> PW, LSP, SPME and section connections. >> >>> The G.8113.1 addresses only bi-directional co-routed LSP and has no >> model to >>> handle bi-directional associated LSP in independent mode. And >> unidirectional >>> p2p and p2mp LSPs are not addressed by the current revision of the >> G.8113.1. >>> Can all these out-of-scope constructs be used to conclude that >> G.8113.1 >>> is not capable to solve these issues? I don't think so. Solutions are >>> not readily available, that's all. >> >> Solution for CCM is already available in G.8113.1. >> I.e. G.8113.1 already resolved these issues as such. >> >> Regards, >> Maarten >> >> >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: 27 July 2011 21:54 >>> To: Maarten vissers; mpls@ietf.org >>> Subject: RE: [mpls] FW: R: RE: Last Call:>> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check >> and >>> Remote Defect indication for MPLS Transport Profile) to Proposed >>> Standard >>> >>> Dear Maarten, >>> the question was raised in regard to CC/CV, a.k.a. CCM, >> functionality. >>> I apologize that I didn't state that explicitly and left it as >> implied >>> context of the discussion. I don't question G.8113.1 capabilities >>> you've listed but only compare with corresponding CCM addressed in >> CC- >>> CV-RDI. >>> >>> Regards, >>> Greg >>> ________________________________________ >>> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of >>> Maarten vissers [maarten.vissers@huawei.com] >>> Sent: Wednesday, July 27, 2011 3:49 PM >>> To: Eric Gray; mpls@ietf.org >>> Subject: Re: [mpls] FW: R: RE: Last Call:>> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check >> and >>> Remote Defect indication for MPLS Transport Profile) to Proposed >>> Standard >>> >>> G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, >>> p2mp unidir connections. >>> >>> The p2p bidir connection can be co-routed, and then it is possible to >>> perform e.g. loopback at intermediate nodes. >>> >>> The p2p bidir connection can be associated, and then a loopback at an >>> intermediate node will not be possible. But the end-to-end monitoring >>> is still performed without problems. >>> >>> Note that a co-routed bidir 1+1 protected connection can select it's >> A- >>> to-Z traffic from working and its Z-to-A traffic from protection; >> this >>> effectively creates an associated bidir connection in which e2e >>> monitoring is supported but loopbacks at intermediate nodes are not >>> successful. >>> >>> Regards, >>> Maarten >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf >>> Of >>>> Eric Gray >>>> Sent: 27 July 2011 18:32 >>>> To: mpls@ietf.org >>>> Subject: [mpls] FW: R: RE: Last Call:> rdi- >>>> 05.txt> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect indication for MPLS Transport Profile) to Proposed >>>> Standard >>>> >>>> Forwarding in plain text... >>>> >>>> ________________________________ >>>> >>>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >>>> Sent: Wednesday, July 13, 2011 10:57 PM >>>> To: erminio.ottone_69@libero.it >>>> Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; >>>> ietf@ietf.org; IETF-Announce >>>> Subject: Re: [mpls] R: RE: Last Call:> rdi- >>>> 05.txt> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect indication for MPLS Transport Profile) to Proposed >>>> Standard >>>> >>>> >>>> Dear Erminio, >>>> I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to >> CCM >>> is >>>> even more narrow then of the document being discussed. The G.8113.1 >>>> addresses only bi-directional co-routed LSP and has no model to >>> handle >>>> bi-directional associated LSP in independent mode. And >> unidirectional >>>> p2p and p2mp LSPs are not addressed by the current revision of the >>>> G.8113.1. >>>> Can all these out-of-scope constructs be used to conclude that >>> G.8113.1 >>>> is not capable to solve these issues? I don't think so. Solutions >> are >>>> not readily available, that's all. >>>> >>>> Regards, >>>> Greg >>>> >>>> >>>> On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it >>>> wrote: >>>> >>>> >>>> >I would not go so far as to say "similar to 1731", there >> is >>>> actually a lot of >>>> difference under the hood. As for uni-directional BFD, that >>> is >>>> a BFD WG problem >>>> at the moment. >>>> >>>> >>>> The fact that the BFD WG has not defined a solution for >>>> unidirectional p2p and >>>> p2mp transport paths does not make BFD a suitable OAM >>> protocol >>>> for MPLS-TP nor >>>> does resolve the technical issue that have been raised. >>>> >>>> >>>> >----Messaggio originale---- >>>> >Da: david.i.allan@ericsson.com >>>> >>>> >Data: 8-lug-2011 18.13 >>>> >A: "Rui Costa", "Stewart >>>> Bryant" >>>> >Cc: >>>> "erminio.ottone_69@libero.it", >>> "mpls@ietf. >>>> org", "ietf@ietf.org", "IETF- >>>> Announce">>> announce@ietf.org> >>>> >Ogg: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv- >> rdi- >>>> 05.txt> >>>> >>>> (Proactive Connectivity Verification, Continuity Check >>> and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to >> Proposed >>>> Standard >>>> > >>>> >Rui: >>>> >>>> > >>>> >You wrote: >>>> > >>>> >>Reading something, keeping it on record, without effect >> in >>>> the draft and >>>> "ignoring comments" have IMHO similar outcomes. As author >> of >>>> the draft you are >>>> free to do it. These standards have a great impact >>>> >>in our work, so i'm also free to write what i did. >>>> > >>>> >>>> >Numerous comments did have effect on the draft and those >>> that >>>> didn't were >>>> either simply not actionable, were rhetorical or not >>>> constructive, and a few >>>> had to be balanced against comments coming from the MPLS& >>> BFD >>>> WGs. I would >>>> translate "ingored" or "without effect" to "did not get >> one'e >>>> way". In the >>>> standards process it happens. >>>> > >>>> >Meanwhile as an editor of the document, I'll take the >>> liberty >>>> of responding >>>> to some of the points you raise... >>>> > >>>> >>>> >>My technical concerns regarding this draft were >>> expressed... >>>> >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it >>>> (LS281, i >>>> believe); >>>> >>...in operators' meetings' that took place during ITU-T's >>>> Feb/2011 plenary >>>> meeting; >>>> > >>>> >>>> >I and the WG don't really have access to private >> grumblings. >>>> > >>>> >>>> >>...in a comparison session that took place during that >> same >>>> ITU-T meeting. >>>> > >>>> >>>> >Lots of other opinions were expressed as well, and they >> did >>>> not all agree >>>> with you. >>>> > >>>> >>>> >>Some: >>>> >>CC/CV >>>> >>I don't understand the need for 2 types of packets: a >>> single >>>> type allows CC; >>>> mismatching identifiers in the same CC packets allow CV. >>>> >>Besides adding complexity, we whether always activate >> both >>> or >>>> potentiate >>>> undetected mismerges. >>>> > >>>> >>>> >OK, lets walk through this. >>>> > >>>> >We want CV all the time so that any misconectivity can be >>>> detected, but on >>>> the list it was expressed that the group did not want the >>>> overhead of >>>> processing the source MEP TLV in every packet in order to >>>> achieve this. We >>>> could carry it in every packet and have the receiver simply >>>> ignore most of >>>> them, but then that would make the defect entry criteria >>>> compeltely random and >>>> the exit criteria unreliable as well, not really a good >>> design. >>>> Hence they are >>>> separated using different ACH code points and the receiver >> is >>>> obliged to >>>> process every source MEP TLV it receives. I hope this is >>> clear. >>>> > >>>> >>>> >>(BTW: can't understand how we propose one ACH codepoint >> to >>>> CC, another for >>>> CV, [counting other drafts, another for frame loss ...] but >>>> don't consider >>>> assigning 1 single ACH protocol identifier codepoint>as >>>> requested by ITU-T) >>>> > >>>> >>>> >Because that puts you into two protocol ID demultiplexing >>>> steps per OAM PDU >>>> recevied to determine the intended function. Hence COSTS >>> MORE. >>>> That is pretty >>>> basic... >>>> > >>>> >>>> >> Uni P2P / P2MP >>>> >> I can't see how BFD will support unidir and hence P2MP >>> other >>>> than... >>>> >> ...eliminating the session "state variable" (down, init, >>>> up), aiming just >>>> the state variables we really need, bringing us to >> something >>>> similar to 1731, >>>> eventually with other bits on the wire or... >>>> >> ...using IP to create the reverse way, which we cannot >>>> assume per >>>> requirements; >>>> >> Will we create a complete different tool for that? >>>> >> (BFD's B="bidirectional") >>>> > >>>> >>>> >I would not go so far as to say "similar to 1731", there >> is >>>> actually a lot of >>>> difference under the hood. As for uni-directional BFD, that >>> is >>>> a BFD WG problem >>>> at the moment. >>>> > >>>> >>>> >> Provisioning list >>>> >> This is an MPLS profile/subset (and i heard) achievable >>>> through a >>>> particular configuration. So, i expect each draft-ietf- >> mpls- >>> TP- >>>> * to focus on >>>> that profile/configuration. However, i keep seeing >>>> >> references f.i. to IP encapsulations unexpected under >> TP's >>>> OAM. >>>> >> I don't thus understand what the aim is: do we expect >> this >>>> in TP, are we >>>> talking about MPLS in general?... The TP profile is never >>> quite >>>> delimited. >>>> >> Does chapter 4 contain ALL the configurable parameters >>> list >>>> agreed to >>>> provide in the comparison session? >>>> > >>>> >>>> >It should. As for encapsulations, unless TP is in a >> complete >>>> island not >>>> connected to anything (which as a network is rather >> useless) >>> it >>>> will be >>>> expected to interoperate with the rest of the MPLS >>>> architecture, and the stated >>>> intention of tool development was that what resulted was >>>> applicable to the >>>> broader MPLS architecture. Which means backwards >> compatiblity >>>> and procedures >>>> for interoperation. >>>> > >>>> >>>> >> Backwards compatibility >>>> >> This was the main argument risen to ground MPLS-TP OAM >> on >>>> BFD. It's not a >>>> better argument than grounding MPLS-TP OAM on 1731 due to >> its >>>> ETH deployment >>>> plus coherence with SDH, OTN, as defended by ITU-T. >>>> >> For reasons like the above, however, MPLS-TP BFD won't >> be >>>> backwards >>>> compatible with previous BFD (even considering just CC/CV). >>>> They don't even >>>> share the same codepoint. >>>> > >>>> >>>> >The issue is not code point, which is the trivial part. It >>> is >>>> reuse of the >>>> majority of the implementation. Again, pretty basic. >>>> > >>>> >>>> >>Simplicity >>>> >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach >>> to >>>> CC is simpler: >>>> in each flow, a standard defined nr of constant heartbeat >>>> signals (with >>>> standard constant or provisioned period - no >>>> >>auto/negotiated -) means OK. A standard defined number of >>>> misses means lost >>>> Rx connection. An RDI, the only articulation between Rx and >>> Tx >>>> flows, >>>> meaningful in bidirectional applications, allows each >>>> >>pear to identify Tx problems. >>>> >>This OAM simplicity is the key for reliable fail finger >>>> pointing, >>>> performance reports and protection. Also to allow scaling, >>> more >>>> implementation >>>> opportunities/manufacturers, which is valuable for >>>> >>operators. >>>> > >>>> >>>> >Well IMO there was not a lot of interest in T-MPLS until >> the >>>> IETF was going >>>> to re-define it and make it compatible with IP/MPLS. So >> there >>>> was an industry >>>> wide "design intent" implied here. >>>> > >>>> >>>> >> IMHO, between your MPLS-TP view and MPLS/IP, it becomes >>> more >>>> and more >>>> difficult to tell which is which. >>>> > >>>> >>>> >That is because MPLS-TP is not a new techology, it is an >>>> addition to the >>>> entire MPLS protocol suite. >>>> > >>>> >Hope this helps >>>> >D >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> >-----Original Message----- >>>> >From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> >Sent: quarta-feira, 6 de Julho de 2011 19:25 >>>> >>>> >To: erminio.ottone_69@libero.it; Rui Costa; ietf@ietf.org; >>>> IETF-Announce >>>> >Cc: mpls@ietf.org >>>> >>>> >Subject: RE: [mpls] R: Re: Last Call:>> cc- >>>> cv-rdi-05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> >>>> > >>>> >Hi Erminio: >>>> > >>>> > >>>> >>Several service providers regarded this draft as not >>> meeting >>>> their >>>> >>transport networks' needs. >>>> > >>>> >>>> >E> This is a true statement: the solution in this draft is >>>> useless for many >>>> MPLS- TP deployments. >>>> > >>>> >>>> >The two statements do not necessarily follow. >>>> > >>>> >What we established during discussions at the SG15 plenary >>> in >>>> February was >>>> that the issue some service providers had was that the IETF >>> BFD >>>> solution >>>> exceeded their requirements in that there was additional >>>> functionality they did >>>> not see a need for, and that they considered any additional >>>> functionality >>>> parasitic. >>>> > >>>> >However this is a consequence of adapting an existing >>>> technology to a new >>>> application. I do not see any way around that. And the >> entire >>>> joint project was >>>> based on the premise of engineering re-use not greenfield >>>> design. That is what >>>> it said on the tin up front, and IMO why when the IETF >>> started >>>> down this path >>>> packet transport transitioned from being a minority sport >> to >>>> mainstream, so it >>>> is a bit late to cry foul.... >>>> > >>>> >My 2 cents >>>> >Dave >>>> > >>>> > >>>> > >>>> > >>>> >>>> >-----Original Message----- >>>> >From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> >Sent: quarta-feira, 6 de Julho de 2011 18:36 >>>> >>>> >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa >>>> >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >>>> >Subject: RE: [mpls] R: Re: Last Call:>> cc- >>>> cv-rdi-05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> >>>> > >>>> >Hi Erminio: >>>> > >>>> >Two of the three document editors were present at SG15 >>> plenary >>>> in February >>>> where the comments originated. The revised meeting schedule >>>> resulted in a day >>>> spent going through the document with the editors. IMO >> there >>>> were lots of >>>> discussion and legitimate issues with the document >> identified >>>> and corrected so >>>> it was a useful session. The liaison of same was in many >> ways >>>> *after the >>>> fact*. >>>> > >>>> >Cheers >>>> >Dave >>>> > >>>> > >>>> > >>>> > >>>> >>>> >-----Original Message----- >>>> >From: erminio.ottone_69@libero.it >>>> [mailto:erminio.ottone_69@libero.it] >>>> >Sent: quarta-feira, 6 de Julho de 2011 18:34 >>>> >>>> >To: Rui Costa; ietf@ietf.org; IETF-Announce >>>> >Cc: mpls@ietf.org >>>> >>>> >Subject: R: Re: [mpls] Last Call:> cv- >>>> rdi-05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> > >>>> >The way this draft has been developed is a bit strange. >>>> > >>>> >The poll for its adoption as a WG document was halted by >> the >>>> MPLS WG chair >>>> because "it is not possible to judge consensus": >>>> > >>>> >http://www.ietf.org/mail- >>>> archive/web/mpls/current/msg04502.html >>>> > >>>> >The lack of consensus was motivated by serious technical >>>> concerns raised by >>>> several transport experts during the poll. >>>> > >>>> >Nevertheless the MPLS WG chair decided to adopt the draft >> as >>> a >>>> WG document: >>>> > >>>> >http://www.ietf.org/mail- >>>> archive/web/mpls/current/msg04512.html >>>> > >>>> >After several WG revisions and WG LCs, the technical >> issues >>>> have not been >>>> resolved. >>>> > >>>> >>>> >>Several service providers regarded this draft as not >>> meeting >>>> their >>>> >>transport >>>> >networks' needs. >>>> > >>>> >>>> >This is a true statement: the solution in this draft is >>>> useless for many >>>> MPLS- TP deployments. >>>> >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: erminio.ottone_69@libero.it >>>> [mailto:erminio.ottone_69@libero.it] >>>> >Sent: quarta-feira, 6 de Julho de 2011 18:26 >>>> >>>> >To: loa@pi.nu; Rui Costa >>>> >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >>>> >Subject: R: Re: [mpls] Last Call:> cv- >>>> rdi-05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> >>>> > >>>> >> Version -04 of the document was published June 28th. >>>> >> >>>> >>>> >> The publication request for draft-ietf-mpls-tp-cc-cv- >> rdi >>>> was sent >>>> >> June 29th. >>>> >> >>>> > >>>> >So when the WG LC to confirm the LC comment resolution has >>>> been launched? >>>> > >>>> >The proto write-up says: >>>> > >>>> > It has also passed a working roup call to >> verify >>>> that LC comments >>>> were correctly with minor comments. >>>> > >>>> >It also says: >>>> > >>>> > The comments has been >>>> > carefully discussed between the authors and >>> people >>>> making the >>>> comments and >>>> > has been resolved. >>>> > >>>> >But it seems that some comments have not been discussed >> with >>>> the authors of >>>> the comments. When ITU-T Q10/15 has been involved in >>> discussing >>>> its comments? >>>> > >>>> > >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: Loa Andersson [mailto:loa@pi.nu] >>>> >Sent: quarta-feira, 6 de Julho de 2011 16:44 >>>> >To: Rui Costa >>>> >>>> >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >>>> >>>> >Subject: Re: [mpls] Last Call:>> rdi- >>>> 05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> > >>>> >All, >>>> > >>>> >Since someone has commented about the process used for >>>> resolving >>>> >questions on >>>> >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details >>>> below. >>>> > >>>> >The history of draft-ietf-mpls-tp-cc-cv-rdi working group >>>> review >>>> >process is: >>>> > >>>> >On February 3rd 2011 the working group last call was >> issued >>>> >on version -03 >>>> > >>>> > This was copied to the the Ad Hoc Team List >>>> > and liaised to SG15 also on February 3rd >>>> > >>>> > This working group last call ended om Feb 28 >>>> > >>>> > >>>> > On Feb 28 we also received a liaison with comments >>> from >>>> SG15 >>>> > >>>> > >>>> >The authors compiled a list of all comments received as >>> part >>>> the MPLS >>>> >working group last call; these comments - and the >> intended >>>> resolution - >>>> >is included in the meeting minutes from the Prague >> meeting: >>>> > >>>> > >>>> > http://www.ietf.org/proceedings/80/slides/mpls-9.pdf >>>> > >>>> > >>>> > During the IETF meeting in Prague, we agreed with the >> BFD >>>> working >>>> > group to do a separate working group last callfor the >> BFD >>>> working >>>> > group >>>> > >>>> >The (BFD) working group last call was started on March >> 30th >>>> and ran >>>> >for 13 days. The last call ended on April 11th. >>>> > >>>> > The authors have since worked hard to resolve comments, >>> some >>>> > issue has been brought to the working group mailing list >>> for >>>> > resolution. >>>> > >>>> > Version -04 of the document was published June 28th. >>>> > >>>> > The publication request for draft-ietf-mpls-tp-cc-cv-rdi >>> was >>>> sent >>>> > June 29th. >>>> > >>>> > The AD review resulted in a "New ID needed" due to >> mostly >>>> editorial >>>> > comments. Version -05 was published on June 29 and the >>> IETF >>>> last call >>>> > started as soon as the new ID was avaialbe. >>>> > >>>> > The current list of Last Call Comments resoltion is also >>>> avaiable at: >>>> > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls >>>> >>>> > >>>> > The list of issues that the authors kept very carefully, >>>> shows without >>>> >doubt >>>> > that no comments been ignored. >>>> > >>>> > Loa >>>> > mpls wg document shepherd >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> >-----Original Message----- >>>> >From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> >Sent: quarta-feira, 6 de Julho de 2011 14:58 >>>> >>>> >To: Rui Costa; ietf@ietf.org; IETF-Announce >>>> >Cc: mpls@ietf.org >>>> >>>> >Subject: RE: [mpls] Last Call:>> rdi- >>>> 05.txt> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> > >>>> >Hi Rui: >>>> > >>>> >The comments were not ignored, the resolution of the Q10 >>>> comments as well as >>>> >>>> those collected from the MPLS WG was presented at the last >>>> IETF. My spreadsheet >>>> >>>> from which that report was generated and has been augmented >>> to >>>> include the BFD >>>> >>>> WG comments is available at http://www.pi.nu/~loa/cc-cv- >> rdi- >>>> Last-Call-Comments>>> Comments> . >>>> xls >>>> > >>>> >>>> >So you know... >>>> >Dave >>>> > >>>> > >>>> >-----Original Message----- >>>> >>>> >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] >>> On >>>> Behalf Of Rui >>>> Costa >>>> >Sent: segunda-feira, 4 de Julho de 2011 23:03 >>>> >>>> >To: ietf@ietf.org; IETF-Announce >>>> >Cc: mpls@ietf.org >>>> >Subject: RE: [mpls] Last Call:>> rdi- >>>> 05.txt> >>>> >>>> (Proactive Connectivity Verification, Continuity Check and >>>> Remote Defect >>>> >>>> indication for MPLS Transport Profile) to Proposed Standard >>>> >>>> > >>>> >IMHO and for the record: >>>> > >>>> >ITU-T comments regarding this draft haven't been discussed >>>> with ITU-T but >>>> were simply ignored. No LS describing these comments' >>>> resolution was sent. >>>> > >>>> >>>> >Several service providers regarded this draft as not >> meeting >>>> their transport >>>> networks' needs. >>>> > >>>> >>>> >[The v03 draft was published in Feb and went to WG LC. >>>> >The v04 draft addressing WG LC comments was published on >> the >>>> 28th June (same >>>> date as the proto write-up). >>>> >When was the WG LC launched, to verify LC comments >>>> resolution?] >>>> > >>>> >Regards, >>>> >Rui >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>> On >>>> Behalf Of The >>>> IESG >>>> >Sent: quinta-feira, 30 de Junho de 2011 14:47 >>>> >To: IETF-Announce >>>> >Cc: mpls@ietf.org >>>> >>>> >Subject: [mpls] Last Call:>>> 05.txt> (Proactive >>>> >>>> Connectivity Verification, Continuity Check and Remote >> Defect >>>> indication for >>>> MPLS Transport Profile) to Proposed Standard >>>> > >>>> > >>>> >>>> >The IESG has received a request from the Multiprotocol >> Label >>>> Switching WG >>>> >(mpls) to consider the following document: >>>> >- 'Proactive Connectivity Verification, Continuity Check >> and >>>> Remote >>>> > Defect indication for MPLS Transport Profile' >>>> > 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 2011-07-14. 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 >>>> > >>>> > Continuity Check, Proactive Connectivity Verification >> and >>>> Remote >>>> > Defect Indication functionalities are required for >> MPLS- >>> TP >>>> OAM. >>>> > >>>> > Continuity Check monitors the integrity of the >> continuity >>>> of the >>>> > label switched path for any loss of continuity defect. >>>> Connectivity >>>> > verification monitors the integrity of the routing of >> the >>>> label >>>> > switched path between sink and source for any >>> connectivity >>>> issues. >>>> > Remote defect indication enables an End Point to >> report, >>> to >>>> its >>>> > associated End Point, a fault or defect condition that >> it >>>> detects on >>>> > a pseudo wire, label switched path or Section. >>>> > >>>> > This document specifies methods for proactive >> continuity >>>> check, >>>> > continuity verification, and remote defect indication >> for >>>> MPLS-TP >>>> > label switched paths, pseudo wires and Sections using >>>> Bidirectional >>>> > Forwarding Detection. >>>> > >>>> > >>>> >The file can be obtained via >>>> >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- >>> rdi/ >>>> > >>>> >IESG discussion can be tracked via >>>> >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv- >>> rdi/ >>>> > >>>> > >>>> >No IPR declarations have been submitted directly on this >> I- >>> D. >>>> >_______________________________________________ >>>> >>>> >mpls mailing list >>>> >mpls@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/mpls >>>> > >>>> > >>>> >>>> >_______________________________________________ >>>> >Ietf mailing list >>>> >Ietf@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/ietf >>>> >>>> > >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Wed Jul 27 15:21:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD7711E8097 for ; Wed, 27 Jul 2011 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKQcUhaedCsV for ; Wed, 27 Jul 2011 15:21:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BED911E812A for ; Wed, 27 Jul 2011 15:21:23 -0700 (PDT) Received: by vxi40 with SMTP id 40so1903809vxi.31 for ; Wed, 27 Jul 2011 15:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7dsF7IgYrYeIF+tVlnaeY01Mh35gnvHjE7L5FWoCe0M=; b=hplZ7I5IBurLazhyfWZTAq923a6p00+ny5xl0wrQ+Pe6Z5Wg4Ntl4R+q57I0dXS8pT yXc/Rs/3cON2imF4vehaV759RhAqd8yYauZ4+7a/XRy+LtkvDspZv72PU8udnkUHMjl2 qJwYhJwOgFgo8ZewHMjiI4Pm2L8VT2ZucdgJk= MIME-Version: 1.0 Received: by 10.52.115.165 with SMTP id jp5mr413513vdb.158.1311805281273; Wed, 27 Jul 2011 15:21:21 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Wed, 27 Jul 2011 15:21:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 15:21:21 -0700 Message-ID: From: Greg Mirsky To: Maarten vissers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:21:29 -0000 Dear Maarten, I hope too that we can agree that the current version of the G.8113.1 does not address MPLS-TP constructs other than bi-directional co-routed p2p LSP. What other MPLS-TP constructs (bi-directional associated p2p LSP, unidirectional p2p and p2mp LSP, Segment, Section and PW) and when the G.8113.1 might address in the future is outside of this discussion. Regards, Greg On Wed, Jul 27, 2011 at 3:09 PM, Maarten vissers wrote: > Dear Greg, > > You asked for G.8113.1 CCM applicability. The CCM applies to the four con= nection types I have listed; i.e. no additions are necessary to support the= lower three connection types in my list. Rationale is that CCM is 1-way OA= M with processing at MEPs (i.e. endpoints) only. It is just not documented = today, but it can be inferred from looking at applicability of CC-CV-RDI ty= pe OAM deployed in other transport technologies. > > As I have indicated in my first response, G.8113.1 loopback will not work= in absence of a return path. Also other 2-way OAM will not work in unidir = LSPs. Furthermore, any other 2-way OAM reflected at an intermediate point i= n the LSP connection in associated bidir LSPs will not work (but will work = if reflected at end point, i.e. at a MEP). But any type of 1-way OAM will w= ork for all four connection types. > > Thus solutions for 2-way OAM are not readily available in G.8113.1 for un= idir p2p and unidir p2mp and associated bidir p2p at intermediate points. > > Hope this clarifies. > Regards, > Maarten > >> -----Original Message----- >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> Sent: 27 July 2011 22:57 >> To: Maarten vissers >> Cc: Gregory Mirsky; mpls@ietf.org >> Subject: Re: [mpls] FW: R: RE: Last Call: > rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and >> Remote Defect indication for MPLS Transport Profile) to Proposed >> Standard >> >> Dear Maarten, >> I hope you can help me to interpret the following text from the TD 377 >> (PLEN/15), Geneva, 14-25 February 2011: >> "The MPLS-TP OAM mechanisms as described in this Recommendation apply >> to co-routed bidirectional point-to-point MPLS-TP connections. >> Unidirectional point-to-point and point-to-multipoint MPLS-TP >> connections will be addressed in a future version of this >> Recommendation." >> >> Regards, >> Greg >> >> On Wed, Jul 27, 2011 at 1:16 PM, Maarten vissers >> wrote: >> > Dear Greg, >> > >> > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in >> > - co-routed bidir p2p, >> > - associated bidir p2p, >> > - unidir p2p and >> > - unidir p2mp >> > PW, LSP, SPME and section connections. >> > >> >> The G.8113.1 addresses only bi-directional co-routed LSP and has no >> model to >> >> handle bi-directional associated LSP in independent mode. And >> unidirectional >> >> p2p and p2mp LSPs are not addressed by the current revision of the >> G.8113.1. >> >> Can all these out-of-scope constructs be used to conclude that >> G.8113.1 >> >> is not capable to solve these issues? I don't think so. Solutions >> are >> >> not readily available, that's all. >> > >> > Solution for CCM is already available in G.8113.1. >> > I.e. G.8113.1 already resolved these issues as such. >> > >> > Regards, >> > Maarten >> > >> > >> >> -----Original Message----- >> >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> >> Sent: 27 July 2011 21:54 >> >> To: Maarten vissers; mpls@ietf.org >> >> Subject: RE: [mpls] FW: R: RE: Last Call: > >> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check >> and >> >> Remote Defect indication for MPLS Transport Profile) to Proposed >> >> Standard >> >> >> >> Dear Maarten, >> >> the question was raised in regard to CC/CV, a.k.a. CCM, >> functionality. >> >> I apologize that I didn't state that explicitly and left it as >> implied >> >> context of the discussion. I don't question G.8113.1 capabilities >> >> you've listed but only compare with corresponding CCM addressed in >> CC- >> >> CV-RDI. >> >> >> >> Regards, >> >> Greg >> >> ________________________________________ >> >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of >> >> Maarten vissers [maarten.vissers@huawei.com] >> >> Sent: Wednesday, July 27, 2011 3:49 PM >> >> To: Eric Gray; mpls@ietf.org >> >> Subject: Re: [mpls] FW: R: RE: Last Call: > >> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check >> and >> >> Remote Defect indication for MPLS Transport Profile) to Proposed >> >> Standard >> >> >> >> G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p unidir, >> >> p2mp unidir connections. >> >> >> >> The p2p bidir connection can be co-routed, and then it is possible >> to >> >> perform e.g. loopback at intermediate nodes. >> >> >> >> The p2p bidir connection can be associated, and then a loopback at >> an >> >> intermediate node will not be possible. But the end-to-end >> monitoring >> >> is still performed without problems. >> >> >> >> Note that a co-routed bidir 1+1 protected connection can select it's >> A- >> >> to-Z traffic from working and its Z-to-A traffic from protection; >> this >> >> effectively creates an associated bidir connection in which e2e >> >> monitoring is supported but loopbacks at intermediate nodes are not >> >> successful. >> >> >> >> Regards, >> >> Maarten >> >> >> >> > -----Original Message----- >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf >> >> Of >> >> > Eric Gray >> >> > Sent: 27 July 2011 18:32 >> >> > To: mpls@ietf.org >> >> > Subject: [mpls] FW: R: RE: Last Call: > rdi- >> >> > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> >> > Remote Defect indication for MPLS Transport Profile) to Proposed >> >> > Standard >> >> > >> >> > Forwarding in plain text... >> >> > >> >> > ________________________________ >> >> > >> >> > From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> >> > Sent: Wednesday, July 13, 2011 10:57 PM >> >> > To: erminio.ottone_69@libero.it >> >> > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; >> >> > ietf@ietf.org; IETF-Announce >> >> > Subject: Re: [mpls] R: RE: Last Call: > rdi- >> >> > 05.txt> (Proactive Connectivity Verification, Continuity Check and >> >> > Remote Defect indication for MPLS Transport Profile) to Proposed >> >> > Standard >> >> > >> >> > >> >> > Dear Erminio, >> >> > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to >> CCM >> >> is >> >> > even more narrow then of the document being discussed. The >> G.8113.1 >> >> > addresses only bi-directional co-routed LSP and has no model to >> >> handle >> >> > bi-directional associated LSP in independent mode. And >> unidirectional >> >> > p2p and p2mp LSPs are not addressed by the current revision of the >> >> > G.8113.1. >> >> > Can all these out-of-scope constructs be used to conclude that >> >> G.8113.1 >> >> > is not capable to solve these issues? I don't think so. Solutions >> are >> >> > not readily available, that's all. >> >> > >> >> > Regards, >> >> > Greg >> >> > >> >> > >> >> > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it >> >> > wrote: >> >> > >> >> > >> >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731",= there >> is >> >> > actually a lot of >> >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional B= FD, >> that >> >> is >> >> > a BFD WG problem >> >> > =A0 =A0 =A0 =A0 at the moment. >> >> > >> >> > >> >> > =A0 =A0 =A0 =A0 The fact that the BFD WG has not defined a solution= for >> >> > unidirectional p2p and >> >> > =A0 =A0 =A0 =A0 p2mp transport paths does not make BFD a suitable O= AM >> >> protocol >> >> > for MPLS-TP nor >> >> > =A0 =A0 =A0 =A0 does resolve the technical issue that have been rai= sed. >> >> > >> >> > >> >> > =A0 =A0 =A0 =A0 >----Messaggio originale---- >> >> > =A0 =A0 =A0 =A0 >Da: david.i.allan@ericsson.com >> >> > >> >> > =A0 =A0 =A0 =A0 >Data: 8-lug-2011 18.13 >> >> > =A0 =A0 =A0 =A0 >A: "Rui Costa", "Stewart >> >> > Bryant" >> >> > =A0 =A0 =A0 =A0 >Cc: >> >> > "erminio.ottone_69@libero.it", >> >> "mpls@ietf. >> >> > =A0 =A0 =A0 =A0 org", "ietf@ietf.org"= , >> "IETF- >> >> > Announce"> >> > =A0 =A0 =A0 =A0 announce@ietf.org> >> >> > =A0 =A0 =A0 =A0 >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-= cc-cv- >> rdi- >> >> > 05.txt> >> >> > >> >> > =A0 =A0 =A0 =A0 (Proactive =A0 =A0 =A0Connectivity Verification, Co= ntinuity >> Check >> >> and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS =A0 =A0 Transport =A0 =A0 =A0 P= rofile) to >> Proposed >> >> > Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Rui: >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >You wrote: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >>Reading something, keeping it on record, without = effect >> in >> >> > the draft and >> >> > =A0 =A0 =A0 =A0 "ignoring comments" have IMHO similar outcomes. As = author >> of >> >> > the draft you are >> >> > =A0 =A0 =A0 =A0 free to do it. These standards have a great impact >> >> > =A0 =A0 =A0 =A0 >>in our work, so i'm also free to write what i did= . >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >Numerous comments did have effect on the draft and= those >> >> that >> >> > didn't were >> >> > =A0 =A0 =A0 =A0 either simply not actionable, were rhetorical or no= t >> >> > constructive, and a few >> >> > =A0 =A0 =A0 =A0 had to be balanced against comments coming from the= MPLS & >> >> BFD >> >> > WGs. I would >> >> > =A0 =A0 =A0 =A0 translate "ingored" or "without effect" to "did not= get >> one'e >> >> > way". In the >> >> > =A0 =A0 =A0 =A0 standards process it happens. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Meanwhile as an editor of the document, I'll take = the >> >> liberty >> >> > of responding >> >> > =A0 =A0 =A0 =A0 to some of the points you raise... >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>My technical concerns regarding this draft were >> >> expressed... >> >> > =A0 =A0 =A0 =A0 >>...in the (ITU-T -> IETF, Feb/2011) liaison regar= ding it >> >> > (LS281, i >> >> > =A0 =A0 =A0 =A0 believe); >> >> > =A0 =A0 =A0 =A0 >>...in operators' meetings' that took place during= ITU- >> T's >> >> > Feb/2011 plenary >> >> > =A0 =A0 =A0 =A0 meeting; >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >I and the WG don't really have access to private >> grumblings. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>...in a comparison session that took place during= that >> same >> >> > ITU-T meeting. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >Lots of other opinions were expressed as well, and= they >> did >> >> > not all agree >> >> > =A0 =A0 =A0 =A0 with you. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>Some: >> >> > =A0 =A0 =A0 =A0 >>CC/CV >> >> > =A0 =A0 =A0 =A0 >>I don't understand the need for 2 types of packet= s: a >> >> single >> >> > type allows CC; >> >> > =A0 =A0 =A0 =A0 mismatching identifiers in the same CC packets allo= w CV. >> >> > =A0 =A0 =A0 =A0 >>Besides adding complexity, we whether always acti= vate >> both >> >> or >> >> > potentiate >> >> > =A0 =A0 =A0 =A0 undetected mismerges. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >OK, lets walk through this. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >We want CV all the time so that any misconectivity= can be >> >> > detected, but on >> >> > =A0 =A0 =A0 =A0 the list it was expressed that the group did not wa= nt the >> >> > overhead of >> >> > =A0 =A0 =A0 =A0 processing the source MEP TLV in every packet in or= der to >> >> > achieve this. We >> >> > =A0 =A0 =A0 =A0 could carry it in every packet and have the receive= r >> simply >> >> > ignore most of >> >> > =A0 =A0 =A0 =A0 them, but then that would make the defect entry cri= teria >> >> > compeltely random and >> >> > =A0 =A0 =A0 =A0 the exit criteria unreliable as well, not really a = good >> >> design. >> >> > Hence they are >> >> > =A0 =A0 =A0 =A0 separated using different ACH code points and the r= eceiver >> is >> >> > obliged to >> >> > =A0 =A0 =A0 =A0 process every source MEP TLV it receives. I hope th= is is >> >> clear. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>(BTW: can't understand how we propose one ACH cod= epoint >> to >> >> > CC, another for >> >> > =A0 =A0 =A0 =A0 CV, [counting other drafts, another for frame loss = ...] >> but >> >> > don't consider >> >> > =A0 =A0 =A0 =A0 assigning 1 single ACH protocol identifier codepoin= t >as >> >> > requested by ITU-T) >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >Because that puts you into two protocol ID demulti= plexing >> >> > steps per OAM PDU >> >> > =A0 =A0 =A0 =A0 recevied to determine the intended function. Hence = COSTS >> >> MORE. >> >> > That is pretty >> >> > =A0 =A0 =A0 =A0 basic... >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >> Uni P2P / P2MP >> >> > =A0 =A0 =A0 =A0 >> I can't see how BFD will support unidir and henc= e P2MP >> >> other >> >> > than... >> >> > =A0 =A0 =A0 =A0 >> ...eliminating the session "state variable" (dow= n, >> init, >> >> > up), aiming just >> >> > =A0 =A0 =A0 =A0 the state variables we really need, bringing us to >> something >> >> > similar to 1731, >> >> > =A0 =A0 =A0 =A0 eventually with other bits on the wire or... >> >> > =A0 =A0 =A0 =A0 >> ...using IP to create the reverse way, which we = cannot >> >> > assume per >> >> > =A0 =A0 =A0 =A0 requirements; >> >> > =A0 =A0 =A0 =A0 >> Will we create a complete different tool for tha= t? >> >> > =A0 =A0 =A0 =A0 >> (BFD's B=3D"bidirectional") >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >I would not go so far as to say "similar to 1731",= there >> is >> >> > actually a lot of >> >> > =A0 =A0 =A0 =A0 difference under the hood. As for uni-directional B= FD, >> that >> >> is >> >> > a BFD WG problem >> >> > =A0 =A0 =A0 =A0 at the moment. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >> Provisioning list >> >> > =A0 =A0 =A0 =A0 >> This is an MPLS profile/subset (and i heard) ach= ievable >> >> > through a >> >> > =A0 =A0 =A0 =A0 particular configuration. So, i expect each draft-i= etf- >> mpls- >> >> TP- >> >> > * to focus on >> >> > =A0 =A0 =A0 =A0 that profile/configuration. However, i keep seeing >> >> > =A0 =A0 =A0 =A0 >> references f.i. to IP encapsulations unexpected = under >> TP's >> >> > OAM. >> >> > =A0 =A0 =A0 =A0 >> I don't thus understand what the aim is: do we e= xpect >> this >> >> > in TP, are we >> >> > =A0 =A0 =A0 =A0 talking about MPLS in general?... The TP profile is= never >> >> quite >> >> > delimited. >> >> > =A0 =A0 =A0 =A0 >> Does chapter 4 contain ALL the configurable para= meters >> >> list >> >> > agreed to >> >> > =A0 =A0 =A0 =A0 provide in the comparison session? >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >It should. As for encapsulations, unless TP is in = a >> complete >> >> > island not >> >> > =A0 =A0 =A0 =A0 connected to anything (which as a network is rather >> useless) >> >> it >> >> > will be >> >> > =A0 =A0 =A0 =A0 expected to interoperate with the rest of the MPLS >> >> > architecture, and the stated >> >> > =A0 =A0 =A0 =A0 intention of tool development was that what resulte= d was >> >> > applicable to the >> >> > =A0 =A0 =A0 =A0 broader MPLS architecture. Which means backwards >> compatiblity >> >> > and procedures >> >> > =A0 =A0 =A0 =A0 for interoperation. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >> Backwards compatibility >> >> > =A0 =A0 =A0 =A0 >> This was the main argument risen to ground MPLS-= TP OAM >> on >> >> > BFD. It's not a >> >> > =A0 =A0 =A0 =A0 better argument than grounding MPLS-TP OAM on 1731 = due to >> its >> >> > ETH deployment >> >> > =A0 =A0 =A0 =A0 plus coherence with SDH, OTN, as defended by ITU-T. >> >> > =A0 =A0 =A0 =A0 >> For reasons like the above, however, MPLS-TP BFD= won't >> be >> >> > backwards >> >> > =A0 =A0 =A0 =A0 compatible with previous BFD (even considering just >> CC/CV). >> >> > They don't even >> >> > =A0 =A0 =A0 =A0 share the same codepoint. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >The issue is not code point, which is the trivial = part. >> It >> >> is >> >> > reuse of the >> >> > =A0 =A0 =A0 =A0 majority of the implementation. Again, pretty basic= . >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>Simplicity >> >> > =A0 =A0 =A0 =A0 >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's >> approach >> >> to >> >> > CC is simpler: >> >> > =A0 =A0 =A0 =A0 in each flow, a standard defined nr of constant hea= rtbeat >> >> > signals (with >> >> > =A0 =A0 =A0 =A0 standard constant or provisioned period - no >> >> > =A0 =A0 =A0 =A0 >>auto/negotiated -) means OK. A standard defined n= umber >> of >> >> > misses means lost >> >> > =A0 =A0 =A0 =A0 Rx connection. An RDI, the only articulation betwee= n Rx >> and >> >> Tx >> >> > flows, >> >> > =A0 =A0 =A0 =A0 meaningful in bidirectional applications, allows ea= ch >> >> > =A0 =A0 =A0 =A0 >>pear to identify Tx problems. >> >> > =A0 =A0 =A0 =A0 >>This OAM simplicity is the key for reliable fail = finger >> >> > pointing, >> >> > =A0 =A0 =A0 =A0 performance reports and protection. Also to allow s= caling, >> >> more >> >> > implementation >> >> > =A0 =A0 =A0 =A0 opportunities/manufacturers, which is valuable for >> >> > =A0 =A0 =A0 =A0 >>operators. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >Well IMO there was not a lot of interest in T-MPLS= until >> the >> >> > IETF was going >> >> > =A0 =A0 =A0 =A0 to re-define it and make it compatible with IP/MPLS= . So >> there >> >> > was an industry >> >> > =A0 =A0 =A0 =A0 wide "design intent" implied here. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >> IMHO, between your MPLS-TP view and MPLS/IP, it = becomes >> >> more >> >> > and more >> >> > =A0 =A0 =A0 =A0 difficult to tell which is which. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >That is because MPLS-TP is not a new techology, it= is an >> >> > addition to the >> >> > =A0 =A0 =A0 =A0 entire MPLS protocol suite. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Hope this helps >> >> > =A0 =A0 =A0 =A0 >D >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson= .com] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 19:25 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; Rui Costa; >> ietf@ietf.org; >> >> > IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> >> > >> >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: > tp- >> >> cc- >> >> > cv-rdi-05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Hi Erminio: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as = not >> >> meeting >> >> > their >> >> > =A0 =A0 =A0 =A0 >>transport networks' needs. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >E> This is a true statement: the solution in this = draft >> is >> >> > useless for many >> >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >The two statements do not necessarily follow. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >What we established during discussions at the SG15 >> plenary >> >> in >> >> > February was >> >> > =A0 =A0 =A0 =A0 that the issue some service providers had was that = the >> IETF >> >> BFD >> >> > solution >> >> > =A0 =A0 =A0 =A0 exceeded their requirements in that there was addit= ional >> >> > functionality they did >> >> > =A0 =A0 =A0 =A0 not see a need for, and that they considered any >> additional >> >> > functionality >> >> > =A0 =A0 =A0 =A0 parasitic. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >However this is a consequence of adapting an exist= ing >> >> > technology to a new >> >> > =A0 =A0 =A0 =A0 application. I do not see any way around that. And = the >> entire >> >> > joint project was >> >> > =A0 =A0 =A0 =A0 based on the premise of engineering re-use not gree= nfield >> >> > design. That is what >> >> > =A0 =A0 =A0 =A0 it said on the tin up front, and IMO why when the I= ETF >> >> started >> >> > down this path >> >> > =A0 =A0 =A0 =A0 packet transport transitioned from being a minority= sport >> to >> >> > mainstream, so it >> >> > =A0 =A0 =A0 =A0 is a bit late to cry foul.... >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >My 2 cents >> >> > =A0 =A0 =A0 =A0 >Dave >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson= .com] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:36 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Co= sta >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] R: Re: Last Call: > tp- >> >> cc- >> >> > cv-rdi-05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Hi Erminio: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Two of the three document editors were present at = SG15 >> >> plenary >> >> > in February >> >> > =A0 =A0 =A0 =A0 where the comments originated. The revised meeting >> schedule >> >> > resulted in a day >> >> > =A0 =A0 =A0 =A0 spent going through the document with the editors. = IMO >> there >> >> > were lots of >> >> > =A0 =A0 =A0 =A0 discussion and legitimate issues with the document >> identified >> >> > and corrected so >> >> > =A0 =A0 =A0 =A0 it was a useful session. The liaison of same was in= many >> ways >> >> > *after the >> >> > =A0 =A0 =A0 =A0 fact*. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Cheers >> >> > =A0 =A0 =A0 =A0 >Dave >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it >> >> > [mailto:erminio.ottone_69@libero.it] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:34 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> >> > >> >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: > cv- >> >> > rdi-05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The way this draft has been developed is a bit str= ange. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The poll for its adoption as a WG document was hal= ted by >> the >> >> > MPLS WG chair >> >> > =A0 =A0 =A0 =A0 because "it is not possible to judge consensus": >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- >> >> > archive/web/mpls/current/msg04502.html >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The lack of consensus was motivated by serious tec= hnical >> >> > concerns raised by >> >> > =A0 =A0 =A0 =A0 several transport experts during the poll. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Nevertheless the MPLS WG chair decided to adopt th= e draft >> as >> >> a >> >> > WG document: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >http://www.ietf.org/mail- >> >> > archive/web/mpls/current/msg04512.html >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >After several WG revisions and WG LCs, the technic= al >> issues >> >> > have not been >> >> > =A0 =A0 =A0 =A0 resolved. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >>Several service providers regarded this draft as = not >> >> meeting >> >> > their >> >> > =A0 =A0 =A0 =A0 >>transport >> >> > =A0 =A0 =A0 =A0 >networks' needs. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >This is a true statement: the solution in this dra= ft is >> >> > useless for many >> >> > =A0 =A0 =A0 =A0 MPLS- TP deployments. >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: erminio.ottone_69@libero.it >> >> > [mailto:erminio.ottone_69@libero.it] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 18:26 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: loa@pi.nu; Rui Costa >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Subject: R: Re: [mpls] Last Call: > cv- >> >> > rdi-05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >> =A0Version -04 of the document was published Jun= e 28th. >> >> > =A0 =A0 =A0 =A0 >> >> >> > >> >> > =A0 =A0 =A0 =A0 >> =A0The publication request for draft-ietf-mpls-t= p-cc-cv- >> rdi >> >> > was =A0sent >> >> > =A0 =A0 =A0 =A0 >> June 29th. >> >> > =A0 =A0 =A0 =A0 >> >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >So when the WG LC to confirm the LC comment resolu= tion >> has >> >> > been launched? >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The proto write-up says: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0It has also passed a worki= ng roup call to >> verify >> >> > that LC comments >> >> > =A0 =A0 =A0 =A0 were correctly with minor comments. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >It also says: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0The comments has been >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0carefully discussed betwee= n the authors and >> >> people >> >> > making the >> >> > =A0 =A0 =A0 =A0 comments and >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0has been resolved. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >But it seems that some comments have not been disc= ussed >> with >> >> > the authors of >> >> > =A0 =A0 =A0 =A0 the comments. When ITU-T Q10/15 has been involved i= n >> >> discussing >> >> > its comments? >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: Loa Andersson [mailto:loa@pi.nu] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 16:44 >> >> > =A0 =A0 =A0 =A0 >To: Rui Costa >> >> > >> >> > =A0 =A0 =A0 =A0 >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org >> >> > >> >> > =A0 =A0 =A0 =A0 >Subject: Re: [mpls] Last Call: > >> rdi- >> >> > 05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >All, >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Since someone has commented about the process used= for >> >> > resolving >> >> > =A0 =A0 =A0 =A0 >questions on >> >> > =A0 =A0 =A0 =A0 >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some d= etails >> >> > below. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The history of draft-ietf-mpls-tp-cc-cv-rdi workin= g group >> >> > review >> >> > =A0 =A0 =A0 =A0 >process is: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >On February 3rd 2011 the working group last call w= as >> issued >> >> > =A0 =A0 =A0 =A0 >on version -03 >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This was copied to the the Ad Hoc Team= List >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0and liaised to SG15 also on February 3= rd >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0This working group last call ended om = Feb 28 >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0On Feb 28 we also received a liaison w= ith comments >> >> from >> >> > SG15 >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The authors compiled a list of all comments receiv= ed =A0as >> >> part >> >> > the MPLS >> >> > =A0 =A0 =A0 =A0 >working group last call; these =A0comments - and t= he >> intended >> >> > resolution - >> >> > =A0 =A0 =A0 =A0 >is included in the meeting minutes from the Prague >> meeting: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 =A0 =A0http://www.ietf.org/proceedings/80/sli= des/mpls- >> 9.pdf >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0During the IETF meeting in Prague, we agreed w= ith the >> BFD >> >> > working >> >> > =A0 =A0 =A0 =A0 > =A0group to do a separate working group last call= for the >> BFD >> >> > working >> >> > =A0 =A0 =A0 =A0 > =A0group >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The (BFD) working group last call was started on M= arch >> 30th >> >> > and ran >> >> > =A0 =A0 =A0 =A0 >for 13 days. The last call ended on April 11th. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0The authors have since worked hard to resolve = comments, >> >> some >> >> > =A0 =A0 =A0 =A0 > =A0issue has been brought to the working group ma= iling >> list >> >> for >> >> > =A0 =A0 =A0 =A0 > =A0resolution. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0Version -04 of the document was published June= 28th. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0The publication request for draft-ietf-mpls-tp= -cc-cv- >> rdi >> >> was >> >> > sent >> >> > =A0 =A0 =A0 =A0 > =A0June 29th. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0The AD review resulted in a "New ID needed" du= e to >> mostly >> >> > editorial >> >> > =A0 =A0 =A0 =A0 > =A0comments. Version -05 was published on June 29= and the >> >> IETF >> >> > last call >> >> > =A0 =A0 =A0 =A0 > =A0started as soon as the new ID was avaialbe. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0The current list of Last Call Comments resolti= on is >> also >> >> > avaiable at: >> >> > =A0 =A0 =A0 =A0 > =A0http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comm= ents.xls >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0The list of issues that the authors kept very >> carefully, >> >> > shows without >> >> > =A0 =A0 =A0 =A0 >doubt >> >> > =A0 =A0 =A0 =A0 > =A0that no comments been ignored. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0Loa >> >> > =A0 =A0 =A0 =A0 > =A0mpls wg document shepherd >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: David Allan I [mailto:david.i.allan@ericsson= .com] >> >> > =A0 =A0 =A0 =A0 >Sent: quarta-feira, 6 de Julho de 2011 14:58 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: Rui Costa; ietf@ietf.org; IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> >> > >> >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: > >> rdi- >> >> > 05.txt> >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Hi Rui: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The comments were not ignored, the resolution of t= he Q10 >> >> > comments as well as >> >> > >> >> > =A0 =A0 =A0 =A0 those collected from the MPLS WG was presented at t= he last >> >> > IETF. My spreadsheet >> >> > >> >> > =A0 =A0 =A0 =A0 from which that report was generated and has been >> augmented >> >> to >> >> > include the BFD >> >> > >> >> > =A0 =A0 =A0 =A0 WG comments is available at http://www.pi.nu/~loa/c= c-cv- >> rdi- >> >> > Last-Call-Comments > >> > Comments> . >> >> > =A0 =A0 =A0 =A0 xls >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >So you know... >> >> > =A0 =A0 =A0 =A0 >Dave >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > >> >> > =A0 =A0 =A0 =A0 >From: ietf-bounces@ietf.org [mailto:ietf- >> bounces@ietf.org] >> >> On >> >> > Behalf Of Rui >> >> > =A0 =A0 =A0 =A0 Costa >> >> > =A0 =A0 =A0 =A0 >Sent: segunda-feira, 4 de Julho de 2011 23:03 >> >> > >> >> > =A0 =A0 =A0 =A0 >To: ietf@ietf.org; IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> >> > =A0 =A0 =A0 =A0 >Subject: RE: [mpls] Last Call: > >> rdi- >> >> > 05.txt> >> >> > >> >> > =A0 =A0 =A0 =A0 (Proactive Connectivity Verification, Continuity Ch= eck and >> >> > Remote Defect >> >> > >> >> > =A0 =A0 =A0 =A0 indication for MPLS Transport Profile) to Proposed >> Standard >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >IMHO and for the record: >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >ITU-T comments regarding this draft haven't been >> discussed >> >> > with ITU-T but >> >> > =A0 =A0 =A0 =A0 were simply ignored. No LS describing these comment= s' >> >> > resolution was sent. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >Several service providers regarded this draft as n= ot >> meeting >> >> > their transport >> >> > =A0 =A0 =A0 =A0 networks' needs. >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >[The v03 draft was published in Feb and went to WG= LC. >> >> > =A0 =A0 =A0 =A0 >The v04 draft addressing WG LC comments was publis= hed on >> the >> >> > 28th June (same >> >> > =A0 =A0 =A0 =A0 date as the proto write-up). >> >> > =A0 =A0 =A0 =A0 >When was the WG LC launched, to verify LC comments >> >> > resolution?] >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Regards, >> >> > =A0 =A0 =A0 =A0 >Rui >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >-----Original Message----- >> >> > =A0 =A0 =A0 =A0 >From: mpls-bounces@ietf.org [mailto:mpls- >> bounces@ietf.org] >> >> On >> >> > Behalf Of The >> >> > =A0 =A0 =A0 =A0 IESG >> >> > =A0 =A0 =A0 =A0 >Sent: quinta-feira, 30 de Junho de 2011 14:47 >> >> > =A0 =A0 =A0 =A0 >To: IETF-Announce >> >> > =A0 =A0 =A0 =A0 >Cc: mpls@ietf.org >> >> > >> >> > =A0 =A0 =A0 =A0 >Subject: [mpls] Last Call: > >> > 05.txt> (Proactive >> >> > >> >> > =A0 =A0 =A0 =A0 Connectivity Verification, Continuity Check and Rem= ote >> Defect >> >> > indication for >> >> > =A0 =A0 =A0 =A0 MPLS Transport Profile) to Proposed Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >The IESG has received a request from the Multiprot= ocol >> Label >> >> > Switching WG >> >> > =A0 =A0 =A0 =A0 >(mpls) to consider the following document: >> >> > =A0 =A0 =A0 =A0 >- 'Proactive Connectivity Verification, Continuity= Check >> and >> >> > Remote >> >> > =A0 =A0 =A0 =A0 > =A0 Defect indication for MPLS Transport Profile' >> >> > =A0 =A0 =A0 =A0 > =A0 as a Pro= posed >> >> Standard >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The IESG plans to make a decision in the next few = weeks, >> and >> >> > solicits >> >> > =A0 =A0 =A0 =A0 >final comments on this action. Please send substan= tive >> >> > comments to the >> >> > =A0 =A0 =A0 =A0 >ietf@ietf.org mailing lists by 2011-07-14. Excepti= onally, >> >> > comments may be >> >> > =A0 =A0 =A0 =A0 >sent to iesg@ietf.org instead. In either case, ple= ase >> retain >> >> > the >> >> > =A0 =A0 =A0 =A0 >beginning of the Subject line to allow automated s= orting. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >Abstract >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check, Proactive Connectivity Veri= fication >> and >> >> > Remote >> >> > =A0 =A0 =A0 =A0 > =A0 Defect Indication functionalities are require= d for >> MPLS- >> >> TP >> >> > OAM. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 Continuity Check monitors the integrity of th= e >> continuity >> >> > of the >> >> > =A0 =A0 =A0 =A0 > =A0 label switched path for any loss of continuit= y defect. >> >> > Connectivity >> >> > =A0 =A0 =A0 =A0 > =A0 verification monitors the integrity of the ro= uting of >> the >> >> > label >> >> > =A0 =A0 =A0 =A0 > =A0 switched path between sink and source for any >> >> connectivity >> >> > issues. >> >> > =A0 =A0 =A0 =A0 > =A0 Remote defect indication enables an End Point= to >> report, >> >> to >> >> > its >> >> > =A0 =A0 =A0 =A0 > =A0 associated End Point, a fault or defect condi= tion that >> it >> >> > detects on >> >> > =A0 =A0 =A0 =A0 > =A0 a pseudo wire, label switched path or Section= . >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > =A0 This document specifies methods for proactive >> continuity >> >> > check, >> >> > =A0 =A0 =A0 =A0 > =A0 continuity verification, and remote defect in= dication >> for >> >> > MPLS-TP >> >> > =A0 =A0 =A0 =A0 > =A0 label switched paths, pseudo wires and Sectio= ns using >> >> > Bidirectional >> >> > =A0 =A0 =A0 =A0 > =A0 Forwarding Detection. >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >The file can be obtained via >> >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp= -cc-cv- >> >> rdi/ >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >IESG discussion can be tracked via >> >> > =A0 =A0 =A0 =A0 >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp= -cc-cv- >> >> rdi/ >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 >No IPR declarations have been submitted directly o= n this >> I- >> >> D. >> >> > =A0 =A0 =A0 =A0 >_______________________________________________ >> >> > >> >> > =A0 =A0 =A0 =A0 >mpls mailing list >> >> > =A0 =A0 =A0 =A0 >mpls@ietf.org >> >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/mpls >> >> > =A0 =A0 =A0 =A0 > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > =A0 =A0 =A0 =A0 >_______________________________________________ >> >> > =A0 =A0 =A0 =A0 >Ietf mailing list >> >> > =A0 =A0 =A0 =A0 >Ietf@ietf.org >> >> > =A0 =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/ietf >> >> > >> >> > =A0 =A0 =A0 =A0 > >> >> > >> >> > >> >> > =A0 =A0 =A0 =A0 _______________________________________________ >> >> > =A0 =A0 =A0 =A0 mpls mailing list >> >> > =A0 =A0 =A0 =A0 mpls@ietf.org >> >> > =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > mpls mailing list >> >> > mpls@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> > > From jdrake@juniper.net Wed Jul 27 15:33:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B1A11E80EF for ; Wed, 27 Jul 2011 15:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0VA4NUbC9Ov for ; Wed, 27 Jul 2011 15:33:40 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE9711E8092 for ; Wed, 27 Jul 2011 15:33:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTjCSIjN8oRbo0JCJ3Oa7zeNNmJ5AGISY@postini.com; Wed, 27 Jul 2011 15:33:39 PDT 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; Wed, 27 Jul 2011 15:33:06 -0700 From: John E Drake To: Greg Mirsky , Maarten vissers Date: Wed, 27 Jul 2011 15:33:04 -0700 Thread-Topic: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Thread-Index: AcxMq5LWeRZed2FwR26BC7izwHMfXwAARfWw Message-ID: <5E893DB832F57341992548CDBB333163A0AAEAC5A8@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:33:42 -0000 Hi, I think Greg has it just about right. Cc-cv-rdi specifically acknowledges = that unicast (p2p and p2mp) is FFS. The proponents of G.8113.1 claim, evid= ence to the contrary, that it addresses unicast. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Wednesday, July 27, 2011 3:21 PM > To: Maarten vissers > Cc: mpls@ietf.org > Subject: Re: [mpls] FW: R: RE: Last Call: rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and > Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > Dear Maarten, > I hope too that we can agree that the current version of the G.8113.1 > does not address MPLS-TP constructs other than bi-directional > co-routed p2p LSP. What other MPLS-TP constructs (bi-directional > associated p2p LSP, unidirectional p2p and p2mp LSP, Segment, Section > and PW) and when the G.8113.1 might address in the future is outside > of this discussion. > > Regards, > Greg > > On Wed, Jul 27, 2011 at 3:09 PM, Maarten vissers > wrote: > > Dear Greg, > > > > You asked for G.8113.1 CCM applicability. The CCM applies to the four > connection types I have listed; i.e. no additions are necessary to > support the lower three connection types in my list. Rationale is that > CCM is 1-way OAM with processing at MEPs (i.e. endpoints) only. It is > just not documented today, but it can be inferred from looking at > applicability of CC-CV-RDI type OAM deployed in other transport > technologies. > > > > As I have indicated in my first response, G.8113.1 loopback will not > work in absence of a return path. Also other 2-way OAM will not work in > unidir LSPs. Furthermore, any other 2-way OAM reflected at an > intermediate point in the LSP connection in associated bidir LSPs will > not work (but will work if reflected at end point, i.e. at a MEP). But > any type of 1-way OAM will work for all four connection types. > > > > Thus solutions for 2-way OAM are not readily available in G.8113.1 > for unidir p2p and unidir p2mp and associated bidir p2p at intermediate > points. > > > > Hope this clarifies. > > Regards, > > Maarten > > > >> -----Original Message----- > >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> Sent: 27 July 2011 22:57 > >> To: Maarten vissers > >> Cc: Gregory Mirsky; mpls@ietf.org > >> Subject: Re: [mpls] FW: R: RE: Last Call: >> rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> Dear Maarten, > >> I hope you can help me to interpret the following text from the TD > 377 > >> (PLEN/15), Geneva, 14-25 February 2011: > >> "The MPLS-TP OAM mechanisms as described in this Recommendation > apply > >> to co-routed bidirectional point-to-point MPLS-TP connections. > >> Unidirectional point-to-point and point-to-multipoint MPLS-TP > >> connections will be addressed in a future version of this > >> Recommendation." > >> > >> Regards, > >> Greg > >> > >> On Wed, Jul 27, 2011 at 1:16 PM, Maarten vissers > >> wrote: > >> > Dear Greg, > >> > > >> > G.8113.1 MPLS-TP CCM supports CC, CV and RDI functionality in > >> > - co-routed bidir p2p, > >> > - associated bidir p2p, > >> > - unidir p2p and > >> > - unidir p2mp > >> > PW, LSP, SPME and section connections. > >> > > >> >> The G.8113.1 addresses only bi-directional co-routed LSP and has > no > >> model to > >> >> handle bi-directional associated LSP in independent mode. And > >> unidirectional > >> >> p2p and p2mp LSPs are not addressed by the current revision of > the > >> G.8113.1. > >> >> Can all these out-of-scope constructs be used to conclude that > >> G.8113.1 > >> >> is not capable to solve these issues? I don't think so. Solutions > >> are > >> >> not readily available, that's all. > >> > > >> > Solution for CCM is already available in G.8113.1. > >> > I.e. G.8113.1 already resolved these issues as such. > >> > > >> > Regards, > >> > Maarten > >> > > >> > > >> >> -----Original Message----- > >> >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >> >> Sent: 27 July 2011 21:54 > >> >> To: Maarten vissers; mpls@ietf.org > >> >> Subject: RE: [mpls] FW: R: RE: Last Call: cv- > >> >> rdi-05.txt> (Proactive Connectivity Verification, Continuity > Check > >> and > >> >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> >> Standard > >> >> > >> >> Dear Maarten, > >> >> the question was raised in regard to CC/CV, a.k.a. CCM, > >> functionality. > >> >> I apologize that I didn't state that explicitly and left it as > >> implied > >> >> context of the discussion. I don't question G.8113.1 capabilities > >> >> you've listed but only compare with corresponding CCM addressed > in > >> CC- > >> >> CV-RDI. > >> >> > >> >> Regards, > >> >> Greg > >> >> ________________________________________ > >> >> From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > >> >> Maarten vissers [maarten.vissers@huawei.com] > >> >> Sent: Wednesday, July 27, 2011 3:49 PM > >> >> To: Eric Gray; mpls@ietf.org > >> >> Subject: Re: [mpls] FW: R: RE: Last Call: cv- > >> >> rdi-05.txt> (Proactive Connectivity Verification, Continuity > Check > >> and > >> >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> >> Standard > >> >> > >> >> G.8113.1 (like G.707, G.709, G.1731) supports p2p bidir, p2p > unidir, > >> >> p2mp unidir connections. > >> >> > >> >> The p2p bidir connection can be co-routed, and then it is > possible > >> to > >> >> perform e.g. loopback at intermediate nodes. > >> >> > >> >> The p2p bidir connection can be associated, and then a loopback > at > >> an > >> >> intermediate node will not be possible. But the end-to-end > >> monitoring > >> >> is still performed without problems. > >> >> > >> >> Note that a co-routed bidir 1+1 protected connection can select > it's > >> A- > >> >> to-Z traffic from working and its Z-to-A traffic from protection; > >> this > >> >> effectively creates an associated bidir connection in which e2e > >> >> monitoring is supported but loopbacks at intermediate nodes are > not > >> >> successful. > >> >> > >> >> Regards, > >> >> Maarten > >> >> > >> >> > -----Original Message----- > >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf > >> >> Of > >> >> > Eric Gray > >> >> > Sent: 27 July 2011 18:32 > >> >> > To: mpls@ietf.org > >> >> > Subject: [mpls] FW: R: RE: Last Call: cv- > >> rdi- > >> >> > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect indication for MPLS Transport Profile) to > Proposed > >> >> > Standard > >> >> > > >> >> > Forwarding in plain text... > >> >> > > >> >> > ________________________________ > >> >> > > >> >> > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> >> > Sent: Wednesday, July 13, 2011 10:57 PM > >> >> > To: erminio.ottone_69@libero.it > >> >> > Cc: David Allan I; Rui Costa; Stewart Bryant; mpls@ietf.org; > >> >> > ietf@ietf.org; IETF-Announce > >> >> > Subject: Re: [mpls] R: RE: Last Call: cv- > >> rdi- > >> >> > 05.txt> (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect indication for MPLS Transport Profile) to > Proposed > >> >> > Standard > >> >> > > >> >> > > >> >> > Dear Erminio, > >> >> > I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard > to > >> CCM > >> >> is > >> >> > even more narrow then of the document being discussed. The > >> G.8113.1 > >> >> > addresses only bi-directional co-routed LSP and has no model to > >> >> handle > >> >> > bi-directional associated LSP in independent mode. And > >> unidirectional > >> >> > p2p and p2mp LSPs are not addressed by the current revision of > the > >> >> > G.8113.1. > >> >> > Can all these out-of-scope constructs be used to conclude that > >> >> G.8113.1 > >> >> > is not capable to solve these issues? I don't think so. > Solutions > >> are > >> >> > not readily available, that's all. > >> >> > > >> >> > Regards, > >> >> > Greg > >> >> > > >> >> > > >> >> > On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone_69@libero.it > >> >> > wrote: > >> >> > > >> >> > > >> >> > >I would not go so far as to say "similar to 1731", > there > >> is > >> >> > actually a lot of > >> >> > difference under the hood. As for uni-directional BFD, > >> that > >> >> is > >> >> > a BFD WG problem > >> >> > at the moment. > >> >> > > >> >> > > >> >> > The fact that the BFD WG has not defined a solution for > >> >> > unidirectional p2p and > >> >> > p2mp transport paths does not make BFD a suitable OAM > >> >> protocol > >> >> > for MPLS-TP nor > >> >> > does resolve the technical issue that have been raised. > >> >> > > >> >> > > >> >> > >----Messaggio originale---- > >> >> > >Da: david.i.allan@ericsson.com > >> >> > > >> >> > >Data: 8-lug-2011 18.13 > >> >> > >A: "Rui Costa", "Stewart > >> >> > Bryant" > >> >> > >Cc: > >> >> > "erminio.ottone_69@libero.it", > >> >> "mpls@ietf. > >> >> > org", "ietf@ietf.org", > >> "IETF- > >> >> > Announce" >> >> > announce@ietf.org> > >> >> > >Ogg: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc- > cv- > >> rdi- > >> >> > 05.txt> > >> >> > > >> >> > (Proactive Connectivity Verification, Continuity > >> Check > >> >> and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to > >> Proposed > >> >> > Standard > >> >> > > > >> >> > >Rui: > >> >> > > >> >> > > > >> >> > >You wrote: > >> >> > > > >> >> > >>Reading something, keeping it on record, without > effect > >> in > >> >> > the draft and > >> >> > "ignoring comments" have IMHO similar outcomes. As > author > >> of > >> >> > the draft you are > >> >> > free to do it. These standards have a great impact > >> >> > >>in our work, so i'm also free to write what i did. > >> >> > > > >> >> > > >> >> > >Numerous comments did have effect on the draft and > those > >> >> that > >> >> > didn't were > >> >> > either simply not actionable, were rhetorical or not > >> >> > constructive, and a few > >> >> > had to be balanced against comments coming from the > MPLS & > >> >> BFD > >> >> > WGs. I would > >> >> > translate "ingored" or "without effect" to "did not get > >> one'e > >> >> > way". In the > >> >> > standards process it happens. > >> >> > > > >> >> > >Meanwhile as an editor of the document, I'll take the > >> >> liberty > >> >> > of responding > >> >> > to some of the points you raise... > >> >> > > > >> >> > > >> >> > >>My technical concerns regarding this draft were > >> >> expressed... > >> >> > >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding > it > >> >> > (LS281, i > >> >> > believe); > >> >> > >>...in operators' meetings' that took place during > ITU- > >> T's > >> >> > Feb/2011 plenary > >> >> > meeting; > >> >> > > > >> >> > > >> >> > >I and the WG don't really have access to private > >> grumblings. > >> >> > > > >> >> > > >> >> > >>...in a comparison session that took place during > that > >> same > >> >> > ITU-T meeting. > >> >> > > > >> >> > > >> >> > >Lots of other opinions were expressed as well, and > they > >> did > >> >> > not all agree > >> >> > with you. > >> >> > > > >> >> > > >> >> > >>Some: > >> >> > >>CC/CV > >> >> > >>I don't understand the need for 2 types of packets: a > >> >> single > >> >> > type allows CC; > >> >> > mismatching identifiers in the same CC packets allow > CV. > >> >> > >>Besides adding complexity, we whether always activate > >> both > >> >> or > >> >> > potentiate > >> >> > undetected mismerges. > >> >> > > > >> >> > > >> >> > >OK, lets walk through this. > >> >> > > > >> >> > >We want CV all the time so that any misconectivity can > be > >> >> > detected, but on > >> >> > the list it was expressed that the group did not want > the > >> >> > overhead of > >> >> > processing the source MEP TLV in every packet in order > to > >> >> > achieve this. We > >> >> > could carry it in every packet and have the receiver > >> simply > >> >> > ignore most of > >> >> > them, but then that would make the defect entry > criteria > >> >> > compeltely random and > >> >> > the exit criteria unreliable as well, not really a good > >> >> design. > >> >> > Hence they are > >> >> > separated using different ACH code points and the > receiver > >> is > >> >> > obliged to > >> >> > process every source MEP TLV it receives. I hope this > is > >> >> clear. > >> >> > > > >> >> > > >> >> > >>(BTW: can't understand how we propose one ACH > codepoint > >> to > >> >> > CC, another for > >> >> > CV, [counting other drafts, another for frame loss ...] > >> but > >> >> > don't consider > >> >> > assigning 1 single ACH protocol identifier codepoint > >as > >> >> > requested by ITU-T) > >> >> > > > >> >> > > >> >> > >Because that puts you into two protocol ID > demultiplexing > >> >> > steps per OAM PDU > >> >> > recevied to determine the intended function. Hence > COSTS > >> >> MORE. > >> >> > That is pretty > >> >> > basic... > >> >> > > > >> >> > > >> >> > >> Uni P2P / P2MP > >> >> > >> I can't see how BFD will support unidir and hence > P2MP > >> >> other > >> >> > than... > >> >> > >> ...eliminating the session "state variable" (down, > >> init, > >> >> > up), aiming just > >> >> > the state variables we really need, bringing us to > >> something > >> >> > similar to 1731, > >> >> > eventually with other bits on the wire or... > >> >> > >> ...using IP to create the reverse way, which we > cannot > >> >> > assume per > >> >> > requirements; > >> >> > >> Will we create a complete different tool for that? > >> >> > >> (BFD's B=3D"bidirectional") > >> >> > > > >> >> > > >> >> > >I would not go so far as to say "similar to 1731", > there > >> is > >> >> > actually a lot of > >> >> > difference under the hood. As for uni-directional BFD, > >> that > >> >> is > >> >> > a BFD WG problem > >> >> > at the moment. > >> >> > > > >> >> > > >> >> > >> Provisioning list > >> >> > >> This is an MPLS profile/subset (and i heard) > achievable > >> >> > through a > >> >> > particular configuration. So, i expect each draft-ietf- > >> mpls- > >> >> TP- > >> >> > * to focus on > >> >> > that profile/configuration. However, i keep seeing > >> >> > >> references f.i. to IP encapsulations unexpected > under > >> TP's > >> >> > OAM. > >> >> > >> I don't thus understand what the aim is: do we > expect > >> this > >> >> > in TP, are we > >> >> > talking about MPLS in general?... The TP profile is > never > >> >> quite > >> >> > delimited. > >> >> > >> Does chapter 4 contain ALL the configurable > parameters > >> >> list > >> >> > agreed to > >> >> > provide in the comparison session? > >> >> > > > >> >> > > >> >> > >It should. As for encapsulations, unless TP is in a > >> complete > >> >> > island not > >> >> > connected to anything (which as a network is rather > >> useless) > >> >> it > >> >> > will be > >> >> > expected to interoperate with the rest of the MPLS > >> >> > architecture, and the stated > >> >> > intention of tool development was that what resulted > was > >> >> > applicable to the > >> >> > broader MPLS architecture. Which means backwards > >> compatiblity > >> >> > and procedures > >> >> > for interoperation. > >> >> > > > >> >> > > >> >> > >> Backwards compatibility > >> >> > >> This was the main argument risen to ground MPLS-TP > OAM > >> on > >> >> > BFD. It's not a > >> >> > better argument than grounding MPLS-TP OAM on 1731 due > to > >> its > >> >> > ETH deployment > >> >> > plus coherence with SDH, OTN, as defended by ITU-T. > >> >> > >> For reasons like the above, however, MPLS-TP BFD > won't > >> be > >> >> > backwards > >> >> > compatible with previous BFD (even considering just > >> CC/CV). > >> >> > They don't even > >> >> > share the same codepoint. > >> >> > > > >> >> > > >> >> > >The issue is not code point, which is the trivial > part. > >> It > >> >> is > >> >> > reuse of the > >> >> > majority of the implementation. Again, pretty basic. > >> >> > > > >> >> > > >> >> > >>Simplicity > >> >> > >>Whether we look to PDH, SDH, OTN or ETH, ITU-T's > >> approach > >> >> to > >> >> > CC is simpler: > >> >> > in each flow, a standard defined nr of constant > heartbeat > >> >> > signals (with > >> >> > standard constant or provisioned period - no > >> >> > >>auto/negotiated -) means OK. A standard defined > number > >> of > >> >> > misses means lost > >> >> > Rx connection. An RDI, the only articulation between Rx > >> and > >> >> Tx > >> >> > flows, > >> >> > meaningful in bidirectional applications, allows each > >> >> > >>pear to identify Tx problems. > >> >> > >>This OAM simplicity is the key for reliable fail > finger > >> >> > pointing, > >> >> > performance reports and protection. Also to allow > scaling, > >> >> more > >> >> > implementation > >> >> > opportunities/manufacturers, which is valuable for > >> >> > >>operators. > >> >> > > > >> >> > > >> >> > >Well IMO there was not a lot of interest in T-MPLS > until > >> the > >> >> > IETF was going > >> >> > to re-define it and make it compatible with IP/MPLS. So > >> there > >> >> > was an industry > >> >> > wide "design intent" implied here. > >> >> > > > >> >> > > >> >> > >> IMHO, between your MPLS-TP view and MPLS/IP, it > becomes > >> >> more > >> >> > and more > >> >> > difficult to tell which is which. > >> >> > > > >> >> > > >> >> > >That is because MPLS-TP is not a new techology, it is > an > >> >> > addition to the > >> >> > entire MPLS protocol suite. > >> >> > > > >> >> > >Hope this helps > >> >> > >D > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: David Allan I > [mailto:david.i.allan@ericsson.com] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 19:25 > >> >> > > >> >> > >To: erminio.ottone_69@libero.it; Rui Costa; > >> ietf@ietf.org; > >> >> > IETF-Announce > >> >> > >Cc: mpls@ietf.org > >> >> > > >> >> > >Subject: RE: [mpls] R: Re: Last Call: mpls- > >> tp- > >> >> cc- > >> >> > cv-rdi-05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > >> >> > > > >> >> > >Hi Erminio: > >> >> > > > >> >> > > > >> >> > >>Several service providers regarded this draft as not > >> >> meeting > >> >> > their > >> >> > >>transport networks' needs. > >> >> > > > >> >> > > >> >> > >E> This is a true statement: the solution in this > draft > >> is > >> >> > useless for many > >> >> > MPLS- TP deployments. > >> >> > > > >> >> > > >> >> > >The two statements do not necessarily follow. > >> >> > > > >> >> > >What we established during discussions at the SG15 > >> plenary > >> >> in > >> >> > February was > >> >> > that the issue some service providers had was that the > >> IETF > >> >> BFD > >> >> > solution > >> >> > exceeded their requirements in that there was > additional > >> >> > functionality they did > >> >> > not see a need for, and that they considered any > >> additional > >> >> > functionality > >> >> > parasitic. > >> >> > > > >> >> > >However this is a consequence of adapting an existing > >> >> > technology to a new > >> >> > application. I do not see any way around that. And the > >> entire > >> >> > joint project was > >> >> > based on the premise of engineering re-use not > greenfield > >> >> > design. That is what > >> >> > it said on the tin up front, and IMO why when the IETF > >> >> started > >> >> > down this path > >> >> > packet transport transitioned from being a minority > sport > >> to > >> >> > mainstream, so it > >> >> > is a bit late to cry foul.... > >> >> > > > >> >> > >My 2 cents > >> >> > >Dave > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: David Allan I > [mailto:david.i.allan@ericsson.com] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 18:36 > >> >> > > >> >> > >To: erminio.ottone_69@libero.it; loa@pi.nu; Rui Costa > >> >> > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> >> > >Subject: RE: [mpls] R: Re: Last Call: mpls- > >> tp- > >> >> cc- > >> >> > cv-rdi-05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > >> >> > > > >> >> > >Hi Erminio: > >> >> > > > >> >> > >Two of the three document editors were present at SG15 > >> >> plenary > >> >> > in February > >> >> > where the comments originated. The revised meeting > >> schedule > >> >> > resulted in a day > >> >> > spent going through the document with the editors. IMO > >> there > >> >> > were lots of > >> >> > discussion and legitimate issues with the document > >> identified > >> >> > and corrected so > >> >> > it was a useful session. The liaison of same was in > many > >> ways > >> >> > *after the > >> >> > fact*. > >> >> > > > >> >> > >Cheers > >> >> > >Dave > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: erminio.ottone_69@libero.it > >> >> > [mailto:erminio.ottone_69@libero.it] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 18:34 > >> >> > > >> >> > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >> >> > >Cc: mpls@ietf.org > >> >> > > >> >> > >Subject: R: Re: [mpls] Last Call: cc- > >> cv- > >> >> > rdi-05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > > >> >> > >The way this draft has been developed is a bit > strange. > >> >> > > > >> >> > >The poll for its adoption as a WG document was halted > by > >> the > >> >> > MPLS WG chair > >> >> > because "it is not possible to judge consensus": > >> >> > > > >> >> > >http://www.ietf.org/mail- > >> >> > archive/web/mpls/current/msg04502.html > >> >> > > > >> >> > >The lack of consensus was motivated by serious > technical > >> >> > concerns raised by > >> >> > several transport experts during the poll. > >> >> > > > >> >> > >Nevertheless the MPLS WG chair decided to adopt the > draft > >> as > >> >> a > >> >> > WG document: > >> >> > > > >> >> > >http://www.ietf.org/mail- > >> >> > archive/web/mpls/current/msg04512.html > >> >> > > > >> >> > >After several WG revisions and WG LCs, the technical > >> issues > >> >> > have not been > >> >> > resolved. > >> >> > > > >> >> > > >> >> > >>Several service providers regarded this draft as not > >> >> meeting > >> >> > their > >> >> > >>transport > >> >> > >networks' needs. > >> >> > > > >> >> > > >> >> > >This is a true statement: the solution in this draft > is > >> >> > useless for many > >> >> > MPLS- TP deployments. > >> >> > > >> >> > > > >> >> > > > >> >> > >-----Original Message----- > >> >> > >From: erminio.ottone_69@libero.it > >> >> > [mailto:erminio.ottone_69@libero.it] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 18:26 > >> >> > > >> >> > >To: loa@pi.nu; Rui Costa > >> >> > >Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce > >> >> > >Subject: R: Re: [mpls] Last Call: cc- > >> cv- > >> >> > rdi-05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > >> >> > > > >> >> > >> Version -04 of the document was published June > 28th. > >> >> > >> > >> >> > > >> >> > >> The publication request for draft-ietf-mpls-tp-cc- > cv- > >> rdi > >> >> > was sent > >> >> > >> June 29th. > >> >> > >> > >> >> > > > >> >> > >So when the WG LC to confirm the LC comment resolution > >> has > >> >> > been launched? > >> >> > > > >> >> > >The proto write-up says: > >> >> > > > >> >> > > It has also passed a working roup call to > >> verify > >> >> > that LC comments > >> >> > were correctly with minor comments. > >> >> > > > >> >> > >It also says: > >> >> > > > >> >> > > The comments has been > >> >> > > carefully discussed between the authors > and > >> >> people > >> >> > making the > >> >> > comments and > >> >> > > has been resolved. > >> >> > > > >> >> > >But it seems that some comments have not been > discussed > >> with > >> >> > the authors of > >> >> > the comments. When ITU-T Q10/15 has been involved in > >> >> discussing > >> >> > its comments? > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > >-----Original Message----- > >> >> > >From: Loa Andersson [mailto:loa@pi.nu] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 16:44 > >> >> > >To: Rui Costa > >> >> > > >> >> > >Cc: ietf@ietf.org; IETF-Announce; mpls@ietf.org > >> >> > > >> >> > >Subject: Re: [mpls] Last Call: cv- > >> >> rdi- > >> >> > 05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > > >> >> > >All, > >> >> > > > >> >> > >Since someone has commented about the process used for > >> >> > resolving > >> >> > >questions on > >> >> > >draft-ietf-mpls-tp-cc-cv-rdi I am supplying some > details > >> >> > below. > >> >> > > > >> >> > >The history of draft-ietf-mpls-tp-cc-cv-rdi working > group > >> >> > review > >> >> > >process is: > >> >> > > > >> >> > >On February 3rd 2011 the working group last call was > >> issued > >> >> > >on version -03 > >> >> > > > >> >> > > This was copied to the the Ad Hoc Team List > >> >> > > and liaised to SG15 also on February 3rd > >> >> > > > >> >> > > This working group last call ended om Feb 28 > >> >> > > > >> >> > > > >> >> > > On Feb 28 we also received a liaison with > comments > >> >> from > >> >> > SG15 > >> >> > > > >> >> > > > >> >> > >The authors compiled a list of all comments received > as > >> >> part > >> >> > the MPLS > >> >> > >working group last call; these comments - and the > >> intended > >> >> > resolution - > >> >> > >is included in the meeting minutes from the Prague > >> meeting: > >> >> > > > >> >> > > > >> >> > > http://www.ietf.org/proceedings/80/slides/mpls- > >> 9.pdf > >> >> > > > >> >> > > > >> >> > > During the IETF meeting in Prague, we agreed with > the > >> BFD > >> >> > working > >> >> > > group to do a separate working group last callfor > the > >> BFD > >> >> > working > >> >> > > group > >> >> > > > >> >> > >The (BFD) working group last call was started on March > >> 30th > >> >> > and ran > >> >> > >for 13 days. The last call ended on April 11th. > >> >> > > > >> >> > > The authors have since worked hard to resolve > comments, > >> >> some > >> >> > > issue has been brought to the working group mailing > >> list > >> >> for > >> >> > > resolution. > >> >> > > > >> >> > > Version -04 of the document was published June 28th. > >> >> > > > >> >> > > The publication request for draft-ietf-mpls-tp-cc- > cv- > >> rdi > >> >> was > >> >> > sent > >> >> > > June 29th. > >> >> > > > >> >> > > The AD review resulted in a "New ID needed" due to > >> mostly > >> >> > editorial > >> >> > > comments. Version -05 was published on June 29 and > the > >> >> IETF > >> >> > last call > >> >> > > started as soon as the new ID was avaialbe. > >> >> > > > >> >> > > The current list of Last Call Comments resoltion is > >> also > >> >> > avaiable at: > >> >> > > http://www.pi.nu/~loa/cc-cv-rdi-Last-Call- > Comments.xls > >> >> > > >> >> > > > >> >> > > The list of issues that the authors kept very > >> carefully, > >> >> > shows without > >> >> > >doubt > >> >> > > that no comments been ignored. > >> >> > > > >> >> > > Loa > >> >> > > mpls wg document shepherd > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: David Allan I > [mailto:david.i.allan@ericsson.com] > >> >> > >Sent: quarta-feira, 6 de Julho de 2011 14:58 > >> >> > > >> >> > >To: Rui Costa; ietf@ietf.org; IETF-Announce > >> >> > >Cc: mpls@ietf.org > >> >> > > >> >> > >Subject: RE: [mpls] Last Call: cv- > >> >> rdi- > >> >> > 05.txt> > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > > >> >> > >Hi Rui: > >> >> > > > >> >> > >The comments were not ignored, the resolution of the > Q10 > >> >> > comments as well as > >> >> > > >> >> > those collected from the MPLS WG was presented at the > last > >> >> > IETF. My spreadsheet > >> >> > > >> >> > from which that report was generated and has been > >> augmented > >> >> to > >> >> > include the BFD > >> >> > > >> >> > WG comments is available at http://www.pi.nu/~loa/cc- > cv- > >> rdi- > >> >> > Last-Call-Comments Call- > >> >> > Comments> . > >> >> > xls > >> >> > > > >> >> > > >> >> > >So you know... > >> >> > >Dave > >> >> > > > >> >> > > > >> >> > >-----Original Message----- > >> >> > > >> >> > >From: ietf-bounces@ietf.org [mailto:ietf- > >> bounces@ietf.org] > >> >> On > >> >> > Behalf Of Rui > >> >> > Costa > >> >> > >Sent: segunda-feira, 4 de Julho de 2011 23:03 > >> >> > > >> >> > >To: ietf@ietf.org; IETF-Announce > >> >> > >Cc: mpls@ietf.org > >> >> > >Subject: RE: [mpls] Last Call: cv- > >> >> rdi- > >> >> > 05.txt> > >> >> > > >> >> > (Proactive Connectivity Verification, Continuity Check > and > >> >> > Remote Defect > >> >> > > >> >> > indication for MPLS Transport Profile) to Proposed > >> Standard > >> >> > > >> >> > > > >> >> > >IMHO and for the record: > >> >> > > > >> >> > >ITU-T comments regarding this draft haven't been > >> discussed > >> >> > with ITU-T but > >> >> > were simply ignored. No LS describing these comments' > >> >> > resolution was sent. > >> >> > > > >> >> > > >> >> > >Several service providers regarded this draft as not > >> meeting > >> >> > their transport > >> >> > networks' needs. > >> >> > > > >> >> > > >> >> > >[The v03 draft was published in Feb and went to WG LC. > >> >> > >The v04 draft addressing WG LC comments was published > on > >> the > >> >> > 28th June (same > >> >> > date as the proto write-up). > >> >> > >When was the WG LC launched, to verify LC comments > >> >> > resolution?] > >> >> > > > >> >> > >Regards, > >> >> > >Rui > >> >> > > > >> >> > > > >> >> > >-----Original Message----- > >> >> > >From: mpls-bounces@ietf.org [mailto:mpls- > >> bounces@ietf.org] > >> >> On > >> >> > Behalf Of The > >> >> > IESG > >> >> > >Sent: quinta-feira, 30 de Junho de 2011 14:47 > >> >> > >To: IETF-Announce > >> >> > >Cc: mpls@ietf.org > >> >> > > >> >> > >Subject: [mpls] Last Call: rdi- > >> >> > 05.txt> (Proactive > >> >> > > >> >> > Connectivity Verification, Continuity Check and Remote > >> Defect > >> >> > indication for > >> >> > MPLS Transport Profile) to Proposed Standard > >> >> > > > >> >> > > > >> >> > > >> >> > >The IESG has received a request from the Multiprotocol > >> Label > >> >> > Switching WG > >> >> > >(mpls) to consider the following document: > >> >> > >- 'Proactive Connectivity Verification, Continuity > Check > >> and > >> >> > Remote > >> >> > > Defect indication for MPLS Transport Profile' > >> >> > > 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 2011-07-14. > 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 > >> >> > > > >> >> > > Continuity Check, Proactive Connectivity > Verification > >> and > >> >> > Remote > >> >> > > Defect Indication functionalities are required for > >> MPLS- > >> >> TP > >> >> > OAM. > >> >> > > > >> >> > > Continuity Check monitors the integrity of the > >> continuity > >> >> > of the > >> >> > > label switched path for any loss of continuity > defect. > >> >> > Connectivity > >> >> > > verification monitors the integrity of the routing > of > >> the > >> >> > label > >> >> > > switched path between sink and source for any > >> >> connectivity > >> >> > issues. > >> >> > > Remote defect indication enables an End Point to > >> report, > >> >> to > >> >> > its > >> >> > > associated End Point, a fault or defect condition > that > >> it > >> >> > detects on > >> >> > > a pseudo wire, label switched path or Section. > >> >> > > > >> >> > > This document specifies methods for proactive > >> continuity > >> >> > check, > >> >> > > continuity verification, and remote defect > indication > >> for > >> >> > MPLS-TP > >> >> > > label switched paths, pseudo wires and Sections > using > >> >> > Bidirectional > >> >> > > Forwarding Detection. > >> >> > > > >> >> > > > >> >> > >The file can be obtained via > >> >> > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc- > cv- > >> >> rdi/ > >> >> > > > >> >> > >IESG discussion can be tracked via > >> >> > >http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc- > cv- > >> >> rdi/ > >> >> > > > >> >> > > > >> >> > >No IPR declarations have been submitted directly on > this > >> I- > >> >> D. > >> >> > >_______________________________________________ > >> >> > > >> >> > >mpls mailing list > >> >> > >mpls@ietf.org > >> >> > >https://www.ietf.org/mailman/listinfo/mpls > >> >> > > > >> >> > > > >> >> > > >> >> > >_______________________________________________ > >> >> > >Ietf mailing list > >> >> > >Ietf@ietf.org > >> >> > >https://www.ietf.org/mailman/listinfo/ietf > >> >> > > >> >> > > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > mpls mailing list > >> >> > mpls@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/mpls > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > mpls mailing list > >> >> > mpls@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/mpls > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From zhang.fei3@zte.com.cn Wed Jul 27 15:34:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D24811E8180; Wed, 27 Jul 2011 15:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.025 X-Spam-Level: X-Spam-Status: No, score=-97.025 tagged_above=-999 required=5 tests=[AWL=0.010, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guZsDt6IE8NL; Wed, 27 Jul 2011 15:34:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3A11E8195; Wed, 27 Jul 2011 15:34:36 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Thu, 28 Jul 2011 06:32:30 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3211079689; Thu, 28 Jul 2011 06:34:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6RMYFGi049636; Thu, 28 Jul 2011 06:34:15 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Pablo Frank MIME-Version: 1.0 X-KeepSent: FC5956C5:6BC78620-482578DA:007B0830; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 28 Jul 2011 06:34:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-28 06:34:15, Serialize complete at 2011-07-28 06:34:15 Content-Type: multipart/alternative; boundary="=_alternative 007BF901482578DA_=" X-MAIL: mse02.zte.com.cn p6RMYFGi049636 Cc: mpls-bounces@ietf.org, mpls@ietf.org Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:34:38 -0000 This is a multipart message in MIME format. --=_alternative 007BF901482578DA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGFibG8NCg0KSSBhbSBub3Qgc3VyZSBJIGNhdGNoICB0aGUgZGlzY3Vzc2lvbi4uLi4NCg0K VGhlIHJlcXVpcmVtZW50cyBvZiBNUExTLVRQIGRvIG5vdCBpbmNsdWRlIG07biBbUkZDNTY1NF0s IGFuZCBpdCBpcyBjbGVhbHkgDQpzdGF0ZWQgaW4gdGhlIHNlY3Rpb24gNC4zLjIgb2YgdGhlIGRv Y3VtZW50IFt0cC1zdXJ2aXZlLWZ3a10gYXMgYmxvdzoNCg0KIk5vdGUgdGhhdCB0aGVyZSBpcyBu byByZXF1aXJlbWVudCBmb3IgbTpuIHJlY292ZXJ5IGluIHRoZSBsaXN0IG9mIE1QTFMtVFAgDQpy ZXF1aXJlbWVudHMgZG9jdW1lbnRlZCBpbiBbUkZDNTY1NF0iLg0KDQpBcyB0byB0aGUgc2hhcmVk IG1lc2ggcHJvdGVjdGlvbiwgRy5zbXAgaXMgZGV2ZWxvcGluZyBub3cgaW4gSVRVLVQsIA0KaW5s Y3VkaW5nIHBhY2tldCBhbmQgY2lyY3VpdCBzb2x1dGlvbnMsIGFuZCB0aGVyZSBhcmUgc2V2ZXJh bCBpbmRpdmlkdWFsIA0KZG9jdW1lbnRzIG5vdyBpbiBNUExTIFdHLg0KDQpCZXN0IHJlZ2FyZHMN Cg0KRmVpDQoNCg0KDQpQYWJsbyBGcmFuayA8cGFibG9pc25vdEBnbWFpbC5jb20+IA0Kt6K8/sjL OiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA3LTI4IDAzOjMxDQoNCsrVvP7Iyw0KRGFu aWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbT4NCrOty80NCm1wbHNAaWV0Zi5vcmcNCtb3zOIN ClJlOiBbbXBsc10gSXMgbTpuIHByb3RlY3Rpb24gYSBjcml0aWNhbCByZXF1aXJlbWVudD8NCg0K DQoNCg0KDQoNCkhpIERhbmllbCwNCg0KU29ycnksIEkgd2Fzbid0IHBhcnRpY3VsYXJseSBjbGVh ci4gIEkgd2FzIGp1c3QgaW5zZXJ0aW5nIHNvbWUgb2YgbXkgb3duIA0KaW50dWl0aW9uIChpLmUu IEkgY2FuJ3QgaW1hZ2luZSBhbnkgcmVhbGlzdGljIHVzZS1jYXNlIGZvciBtOm4pLiAgVGhlcmUn cyANCm5vIHN0YW5kYXJkIG1lY2hhbmlzbSBmb3IgbTpuIHNvIHJlYWxseSBub3RoaW5nIHRoYXQg d2UgY2FuIGV2YWx1YXRlIA0KYWdhaW5zdC4gIFdoZW4gSSBhc2tlZCBvdXIgZXhwZXJ0cyBpZiB3 ZSd2ZSBldmVyIGVuY291bnRlcmVkIG06biB1c2UtY2FzZXMgDQppbiBvdXIgT1ROIG9yIHNvbmV0 IGRlcGxveW1lbnRzLCB0aGUgcmVzcG9uc2Ugd2FzIHRoYXQgd2UgYWx3YXlzIGp1c3QgDQpzb2x2 ZWQgdGhlIHByb2JsZW0gdXNpbmcgc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiAob2Ygd2hpY2ggd2Un dmUgZGVwbG95ZWQgDQp0b25uZXMpLg0KDQpjaGVlcnMsDQpQYWJsbw0KDQpPbiBXZWQsIEp1bCAy NywgMjAxMSBhdCAxOjAxIFBNLCBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNraXQuY29tPiB3cm90 ZToNCkhpIFBhYmxvLA0KIA0KV2hlbiB5b3Ugd3JpdGUgobChrW06biB1c2UtY2FzZSBpcyBwcm9i YWJseSBiZXR0ZXIgaGFuZGxlZCB3aXRoIA0Kc2hhcmVkLW1lc2ggcHJvdGVjdGlvbqGtobEsIGFy ZSB5b3UgdGFsa2luZyBhYm91dCBhIHBhcnRpY3VsYXIgbTpuIA0KbWVjaGFuaXNtL3N0YW5kYXJk PyBDYW4geW91IHBscyBzcGVjaWZ5Pw0KIA0KREMNCiANCkZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KUGFibG8g RnJhbmsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyNywgMjAxMSA5OjM2IEFNDQpUbzogbXBsc0Bp ZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIElzIG06biBwcm90ZWN0aW9uIGEgY3JpdGljYWwgcmVx dWlyZW1lbnQ/DQogDQpUaGVyZSB3YXMgYSBxdWVzdGlvbiByYWlzZWQgaW4gbW9uZGF5J3MgV0cg bWVldGluZyBhcyB0byB3aGV0aGVyIHRoZXJlIHdhcyANCmEgc3Ryb25nIHVzZS1jYXNlIGZvciBt Om4gcHJvdGVjdGlvbi4gIEEgcmVsYXRlZCBxdWVzdGlvbiB3YXMgd2hldGhlciBtOm4gDQpoYXMg YmVlbiBzdGFuZGFyZGl6ZWQgaW4gdGhlIE9UTiAvIFNPTkVUIHdvcmxkLiAgQWZ0ZXIgd2UgY29u c3VsdGVkIG91ciANCk9UTiBleHBlcnRzIGJhY2sgYXQgdGhlIHJhbmNoLCB0aGUgZ2VuZXJhbCBj b25zZW5zdXMgaXMgdGhhdCB3aGlsZSAxKzEgYW5kIA0KMTpuIGFyZSB3ZWxsIHN0YW5kYXJkaXpl ZCBieSB0aGUgSVRVLVQsIG06biBpcyB0eXBpY2FsbHkgbGVmdCBmb3IgZnVydGhlciANCnN0dWR5 LiAgVGhlcmUgYXJlIHByb3ByaWV0YXJ5IHNvbHV0aW9ucywgaW5jbHVkaW5nIG91ciBvd24sIGJ1 dCB0aGV5IGRvbid0IA0Kc2VlbSB0byBiZSB3aWRlbHkgZGVwbG95ZWQuICBJIGRpZG4ndCBnZXQg YSBzcGVjaWZpYyBtOm4gdXNlLWNhc2UuICBJIA0Kc3VzcGVjdCB0aGF0IGFueSBtOm4gdXNlLWNh c2UgaXMgcHJvYmFibHkgYmV0dGVyIGhhbmRsZWQgd2l0aCBzaGFyZWQtbWVzaCANCnByb3RlY3Rp b24gYW55d2F5Lg0KIA0KSXQgc2VlbXMgdGhhdCBtOm4gc2hvd3MgdXAgaW4gYWxsIHRoZSBzdGFu ZGFyZHMsIG1haW5seSBmb3IgdGhlb3JldGljYWwgDQpjb21wbGV0ZW5lc3MsIGJ1dCBuZXZlciBl bmRzIHVwIGJlaW5nIHNwZWNpZmllZC4NCiANCkJhc2VkIG9uIHRoaXMsIEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIHNsb3ctZG93biB0aGUgY3VycmVudCAxOm4gDQpzdGFuZGFyZGl6YXRpb24gZWZm b3J0IGJ5IHJlcXVpcmluZyB0aGUgYXV0aG9ycyB0byBlbWJhcmsgb24gYW4gbTpuIA0Kc2NpZW5j ZSBwcm9qZWN0Lg0KIA0KUGFibG8gRnJhbmsNCkNpZW5hICANCiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 007BF901482578DA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhYmxvPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFtIG5vdCBzdXJlIEkgY2F0 Y2ggJm5ic3A7dGhlIGRpc2N1c3Npb24uLi4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgcmVxdWlyZW1lbnRzIG9mIE1QTFMtVFAgZG8gbm90IGlu Y2x1ZGUNCm07biBbUkZDNTY1NF0sIGFuZCBpdCBpcyBjbGVhbHkgc3RhdGVkIGluIHRoZSBzZWN0 aW9uIDQuMy4yIG9mIHRoZSBkb2N1bWVudA0KW3RwLXN1cnZpdmUtZndrXSBhcyBibG93OjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Tm90ZSB0 aGF0IHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50DQpmb3IgbTpuIHJlY292ZXJ5IGluIHRoZSBsaXN0 IG9mIE1QTFMtVFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50ZWQgaW4gWzwvZm9udD48YSBocmVmPWh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU2NTQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+UkZDNTY1NDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5dJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QXMgdG8gdGhlIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24sIEcuc21w DQppcyBkZXZlbG9waW5nIG5vdyBpbiBJVFUtVCwgaW5sY3VkaW5nIHBhY2tldCBhbmQgY2lyY3Vp dCBzb2x1dGlvbnMsIGFuZA0KdGhlcmUgYXJlIHNldmVyYWwgaW5kaXZpZHVhbCBkb2N1bWVudHMg bm93IGluIE1QTFMgV0cuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5QYWJsbyBGcmFuayAmbHQ7cGFibG9pc25vdEBnbWFpbC5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZu YnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDExLTA3LTI4IDAzOjMxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkRhbmllbCBDb2huICZsdDtEYW5pZWxDQG9yY2tp dC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5tcGxzQGlldGYub3JnPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW21wbHNdIElzIG06biBwcm90ZWN0aW9uIGEgY3JpdGljYWwNCnJlcXVpcmVtZW50 PzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5I aSBEYW5pZWwsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5Tb3JyeSwgSSB3YXNuJ3Qg cGFydGljdWxhcmx5IGNsZWFyLiAmbmJzcDtJIHdhcyBqdXN0IGluc2VydGluZw0Kc29tZSBvZiBt eSBvd24gaW50dWl0aW9uIChpLmUuIEkgY2FuJ3QgaW1hZ2luZSBhbnkgcmVhbGlzdGljIHVzZS1j YXNlIGZvcg0KbTpuKS4gJm5ic3A7VGhlcmUncyBubyBzdGFuZGFyZCBtZWNoYW5pc20gZm9yIG06 biBzbyByZWFsbHkgbm90aGluZyB0aGF0DQp3ZSBjYW4gZXZhbHVhdGUgYWdhaW5zdC4gJm5ic3A7 V2hlbiBJIGFza2VkIG91ciBleHBlcnRzIGlmIHdlJ3ZlIGV2ZXIgZW5jb3VudGVyZWQNCm06biB1 c2UtY2FzZXMgaW4gb3VyIE9UTiBvciBzb25ldCBkZXBsb3ltZW50cywgdGhlIHJlc3BvbnNlIHdh cyB0aGF0IHdlDQphbHdheXMganVzdCBzb2x2ZWQgdGhlIHByb2JsZW0gdXNpbmcgc2hhcmVkIG1l c2ggcHJvdGVjdGlvbiAob2Ygd2hpY2ggd2UndmUNCmRlcGxveWVkIHRvbm5lcykuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz5jaGVlcnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5Q YWJsbzxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gV2VkLCBKdWwgMjcsIDIwMTEg YXQgMTowMSBQTSwgRGFuaWVsIENvaG4gJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpEYW5pZWxD QG9yY2tpdC5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+RGFuaWVsQ0BvcmNraXQuY29t PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZD5IaSBQYWJsbyw8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZD4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZD5XaGVuIHlvdSB3cml0ZSChsKGtbTpuIHVzZS1jYXNlIGlzIHByb2JhYmx5DQpiZXR0ZXIgaGFu ZGxlZCB3aXRoIHNoYXJlZC1tZXNoIHByb3RlY3Rpb26hraGxLCBhcmUgeW91IHRhbGtpbmcgYWJv dXQNCmEgcGFydGljdWxhciBtOm4gbWVjaGFuaXNtL3N0YW5kYXJkPyBDYW4geW91IHBscyBzcGVj aWZ5PzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkPiZuYnNwOzwvZm9udD4N CjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkPkRDPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2Q+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPjxiPkZyb206PC9i PiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTI+DQpbbWFpbHRvOjwvZm9udD48YSBocmVmPSJtYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1i bHVlPjx1Pm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mj5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhYmxvIEZyYW5rPGI+PGJyPg0KU2VudDo8L2I+IFdlZG5l c2RheSwgSnVseSAyNywgMjAxMSA5OjM2IEFNPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1i bHVlPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTI+PGI+PGJyPg0K U3ViamVjdDo8L2I+IFttcGxzXSBJcyBtOm4gcHJvdGVjdGlvbiBhIGNyaXRpY2FsIHJlcXVpcmVt ZW50PzwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTM+VGhlcmUgd2FzIGEgcXVlc3Rpb24gcmFpc2VkIGluIG1vbmRheSdzIFdHIG1lZXRpbmcgYXMg dG8NCndoZXRoZXIgdGhlcmUgd2FzIGEgc3Ryb25nIHVzZS1jYXNlIGZvciBtOm4gcHJvdGVjdGlv bi4gJm5ic3A7QSByZWxhdGVkDQpxdWVzdGlvbiB3YXMgd2hldGhlciBtOm4gaGFzIGJlZW4gc3Rh bmRhcmRpemVkIGluIHRoZSBPVE4gLyBTT05FVCB3b3JsZC4NCiZuYnNwO0FmdGVyIHdlIGNvbnN1 bHRlZCBvdXIgT1ROIGV4cGVydHMgYmFjayBhdCB0aGUgcmFuY2gsIHRoZSBnZW5lcmFsDQpjb25z ZW5zdXMgaXMgdGhhdCB3aGlsZSAxKzEgYW5kIDE6biBhcmUgd2VsbCBzdGFuZGFyZGl6ZWQgYnkg dGhlIElUVS1ULA0KbTpuIGlzIHR5cGljYWxseSBsZWZ0IGZvciBmdXJ0aGVyIHN0dWR5LiAmbmJz cDtUaGVyZSBhcmUgcHJvcHJpZXRhcnkgc29sdXRpb25zLA0KaW5jbHVkaW5nIG91ciBvd24sIGJ1 dCB0aGV5IGRvbid0IHNlZW0gdG8gYmUgd2lkZWx5IGRlcGxveWVkLiAmbmJzcDtJIGRpZG4ndA0K Z2V0IGEgc3BlY2lmaWMgbTpuIHVzZS1jYXNlLiAmbmJzcDtJIHN1c3BlY3QgdGhhdCBhbnkgbTpu IHVzZS1jYXNlIGlzIHByb2JhYmx5DQpiZXR0ZXIgaGFuZGxlZCB3aXRoIHNoYXJlZC1tZXNoIHBy b3RlY3Rpb24gYW55d2F5LjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTM+SXQgc2VlbXMgdGhhdCBtOm4gc2hvd3MgdXAgaW4gYWxsIHRoZSBzdGFu ZGFyZHMsIG1haW5seQ0KZm9yIHRoZW9yZXRpY2FsIGNvbXBsZXRlbmVzcywgYnV0IG5ldmVyIGVu ZHMgdXAgYmVpbmcgc3BlY2lmaWVkLjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDs8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTM+QmFzZWQgb24gdGhpcywgSSBkb24ndCB0aGluayB3ZSBzaG91 bGQgc2xvdy1kb3duIHRoZSBjdXJyZW50DQoxOm4gc3RhbmRhcmRpemF0aW9uIGVmZm9ydCBieSBy ZXF1aXJpbmcgdGhlIGF1dGhvcnMgdG8gZW1iYXJrIG9uIGFuIG06bg0Kc2NpZW5jZSBwcm9qZWN0 LjwvZm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+ UGFibG8gRnJhbms8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+Q2llbmEmbmJzcDsgPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxwPjx0dD48Zm9udCBzaXplPTI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxp bmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPg0K --=_alternative 007BF901482578DA_=-- From pranjal.dutta@alcatel-lucent.com Wed Jul 27 19:11:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA2721F8BDB; Wed, 27 Jul 2011 19:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5q7N30rj3El; Wed, 27 Jul 2011 19:11:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 824D521F8BD9; Wed, 27 Jul 2011 19:11:45 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6S2Bfn4026660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 21:11:43 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6S2BeQw000548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 07:41:40 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 28 Jul 2011 07:41:40 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Ilya Varlashkin , IETF MPLS , "pwe3@ietf.org" Date: Thu, 28 Jul 2011 07:41:37 +0530 Thread-Topic: [mpls] terminology in draft-pkwok-pwe3-pw-communities Thread-Index: AcxL1w02weKgkv+9SLWeA9YGvo4X4gA884eQ Message-ID: References: <73460629-CAAC-4C2E-9ECA-7FEC8570480A@nobulus.com> In-Reply-To: <73460629-CAAC-4C2E-9ECA-7FEC8570480A@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Kwok, Paul \(Paul\)" Subject: Re: [mpls] terminology in draft-pkwok-pwe3-pw-communities X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:11:46 -0000 Hi, The intent was to keep the context similar to BGP communities and henc= e the terminology as "PW Communities". I am not able to think of any case tha= t would made us to ship PW communities thru BGP, even if we would ever do i= t there would be a mapping function from LDP Community->BGP X attribute, s= imilar to what we do for FEC129 AII->BGP NLRI.=20 Thanks, Pranjal=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ily= a Varlashkin Sent: Tuesday, July 26, 2011 2:00 PM To: IETF MPLS Subject: [mpls] terminology in draft-pkwok-pwe3-pw-communities Hi, sooner or later most of control-plane information makes its way into BGP. S= ome day somebody will want to carry PW communities in BGP. That's going to = be confusing as BGP already has community attribute. Presentation at the PW= E3 meeting mentioned "coloring". Couldn't then "PW color" be adopted instea= d of "PW community"? /iLya _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From sboutros@cisco.com Thu Jul 28 06:30:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC85921F8CA9 for ; Thu, 28 Jul 2011 06:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU7o6+4GJ2EX for ; Thu, 28 Jul 2011 06:30:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DFE8C21F8CA8 for ; Thu, 28 Jul 2011 06:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=4039; q=dns/txt; s=iport; t=1311859810; x=1313069410; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=9p+M+Ry5LngWQ9MZK80F2RXzapbK3Qd83+cL2RvVkes=; b=XaUORXcNQYLQGOVv1dmcRzNs/YBiPn0xrfYfLHjf9aTJdoASUqX1Ny9W MqshUk9mjbKP3Qfn+XvSGGU/uVaBoKSxkak+5SEqtjiz6n51591iloua3 sir8OKadApKOewveUveWm7viPzNSFAwCvm76mgzx0krF5/kWXG0o4p31n A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALNjMU6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQEpAjoLEQgEDgoqEBQGEjkHFyAHh0KfbneIfASjOp5hhkEEh1mQMIt0 X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7376136" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 13:30:09 +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 p6SDU86a002220; Thu, 28 Jul 2011 13:30:08 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 06:29:53 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.168.32]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 06:29:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jul 2011 06:29:49 -0700 To: Thomas Beckhaus From: Sami Boutros In-Reply-To: References: <23532.1309359379@erosen-linux> <35DDAE74-5B9B-4600-AFB3-57129E2870B4@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jul 2011 13:29:53.0423 (UTC) FILETIME=[6F10A9F0:01CC4D2A] Cc: mpls@ietf.org Subject: Re: [mpls] [MPLS] LDP DoD and PW Signalling ... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:30:10 -0000 Thomas, I am not suggesting higher value for the timer, I do agree with you that smaller timer would be preferable but this could lead to more label requests being sent. The question is wether it is acceptable to wait for up to 2 minutes to get the label binding for the egress node of the service after this node becomes reachable, since this would delay the convergence. Thanks, Sami At 12:47 PM 7/27/2011, Thomas Beckhaus wrote: >Sami, > >do you have any concerns regarding the 2 minutes? For the general AN >scenario (only very limited number of FECs), I could imagine also a >smaller number to get a faster recovery time. I do not see a need to >get a higher value. But I am not sure to change the RFC5036 value >because of this. > >Best wishes to Quebec City >Thomas > >Am 25.07.2011 um 17:09 schrieb Sami Boutros: > > > Maciek, > > > > Will the 2 mins back off be acceptable? or will you address this > aspect in your draft? and if so how? > > > > Thanks, > > > > Sami > > At 06:16 AM 7/12/2011, Maciek Konstantynowicz wrote: > >> Eric, > >> > >> Regarding your question about handling unreachable FEC becoming > reachable again:- > >> > >> We wrote a separate draft with a detailed description of LDP DoD > behaviours in the context of Seamless MPLS > >> http://tools.ietf.org/html/draft-beckhaus-ldp-dod-00 > >> > >> In this draft, #section-4.4.3 describes the behaviour in case > specific requested FEC is unreachable: > >> > >> 4.4.3. Label Request Retry Procedure > >> > >> If AN or AGN receives a "No route" Notification in response to its > >> label request message, it should retry with exponential backoff > >> algorithm similar to the backoff algoritm mentioned in the LDP > >> session negotiation section 4.3. > >> ... > >> AN should follow the exponential backoff algorithm as specified in > >> the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays > >> grow to a maximum delay of 2 minutes. > >> > >> Maciek > >> > >> > >> > >> > >> On 29 Jun 2011, at 15:56, Eric Rosen wrote: > >> > >> > > >> >> For a more long term approach we are in favour of a change to > RFC5036 by > >> >> defining a new TLV which denotes the DU/DoD mode per FEC type. > >> > > >> > Does that mean you expect every FEC type to be able to work in > both modes? > >> > If you only anticipate needing DoD for address prefix FECs, a more > >> > conservative solution might be to just clarify that the > negotiated session > >> > mode applies only to address prefix FECs. > >> > > >> > While on the topic, I do have a question about the use of DoD > for address > >> > prefix FECs. > >> > > >> > From draft-leymann-mpls-seamless-mpls-03: > >> > > >> > the AN will use LDP DoD to only request the label bindings > >> > for the FECs corresponding to the loopback addresses of those egress > >> > nodes to which it has services configured. > >> > > >> > Suppose one of the configured egress nodes is down or > otherwise unreachable > >> > at the time the AN asks for a label binding. How does the AN > get the label > >> > binding when the egress node becomes reachable? Is the AN > expected to ask > >> > periodically for the binding? Is the periodic interval expected to be > >> > configurable? The draft should say something about this. > >> > > >> > I don't think RFC 5036 requires the AGN to remember what the > AN has asked > >> > for, so that it can reply when and if the egress becomes reachable. > >> > > >> > > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From pabloisnot@gmail.com Thu Jul 28 07:18:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37021F8B8C; Thu, 28 Jul 2011 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.196 X-Spam-Level: *** X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[AWL=-6.795, BAYES_00=-2.599, FR_P_END_P_MANY10=10.539, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxhXLA0pAAga; Thu, 28 Jul 2011 07:18:50 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 804CF21F8B46; Thu, 28 Jul 2011 07:18:50 -0700 (PDT) Received: by qyk9 with SMTP id 9so3131966qyk.10 for ; Thu, 28 Jul 2011 07:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iBrzoZKZsLAMHixH/0um1cTPJBrFaXefyOCAOUfr650=; b=Q6CI9uR1ZOBZXY8gRgcHWetIaWzhTmNC0JzOF6KJIpL04DXovE7iAk5wPFcyHPjj7O Bop84osc5XD+pax6S49hY9x75/krm9GGJF4dkb5s0fPBRDvpON6/J+TM093cYI1WvwMf 8fhINbGGVadKRgwEYo1Dh5qYIGEbhs25g/MK8= MIME-Version: 1.0 Received: by 10.224.193.72 with SMTP id dt8mr37716qab.331.1311862729906; Thu, 28 Jul 2011 07:18:49 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Thu, 28 Jul 2011 07:18:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 10:18:49 -0400 Message-ID: From: Pablo Frank To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=20cf30050c2c02990804a921d85a Cc: mpls-bounces@ietf.org, mpls@ietf.org Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:18:53 -0000 --20cf30050c2c02990804a921d85a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Well, I think that pretty much settles it then. There had been a suggestio= n made in the wg meeting that m:n should be addressed by the 1:n protection draft, under the assumption that m:n was a requirement for MPLS-TP and that= , intuitively, m:n was a more general case of 1:n. However, as you've now correctly pointed out, m:n was never a requirement of MPLS-TP. From a practical implementation perspective, there is a significant jump in complexity between 1:n and m:n so it seems unreasonable to me to expect the 1-to-n draft to address this solution (especially given that it is not a requirement). I think there is greater potential in bringing the 1:n proposal closer to the original 1:1 linear protection, rather than the othe= r way. regards, Pablo 2011/7/27 > > Hi Pablo > > I am not sure I catch the discussion.... > > The requirements of MPLS-TP do not include m;n [RFC5654], and it is cleal= y > stated in the section 4.3.2 of the document [tp-survive-fwk] as blow: > > "Note that there is no requirement for m:n recovery in the list of MPLS-T= P > requirements documented in [*RFC5654* > ]". > > As to the shared mesh protection, G.smp is developing now in ITU-T, > inlcuding packet and circuit solutions, and there are several individual > documents now in MPLS WG. > > Best regards > > Fei > > > *Pablo Frank * > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > > 2011-07-28 03:31 > =CA=D5=BC=FE=C8=CB > Daniel Cohn > =B3=AD=CB=CD > mpls@ietf.org > =D6=F7=CC=E2 > Re: [mpls] Is m:n protection a critical requirement? > > > > > Hi Daniel, > > Sorry, I wasn't particularly clear. I was just inserting some of my own > intuition (i.e. I can't imagine any realistic use-case for m:n). There's= no > standard mechanism for m:n so really nothing that we can evaluate against= . > When I asked our experts if we've ever encountered m:n use-cases in our = OTN > or sonet deployments, the response was that we always just solved the > problem using shared mesh protection (of which we've deployed tonnes). > > cheers, > Pablo > > On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn <*DanielC@orckit.com*> > wrote: > Hi Pablo, > > > > When you write =A1=B0=A1=ADm:n use-case is probably better handled with s= hared-mesh > protection=A1=AD=A1=B1, are you talking about a particular m:n mechanism/= standard? Can > you pls specify? > > > > DC > > > > *From:* *mpls-bounces@ietf.org* [mailto:* > mpls-bounces@ietf.org* ] *On Behalf Of *Pablo Fran= k > * > Sent:* Wednesday, July 27, 2011 9:36 AM* > To:* *mpls@ietf.org* * > Subject:* [mpls] Is m:n protection a critical requirement? > > > > There was a question raised in monday's WG meeting as to whether there wa= s > a strong use-case for m:n protection. A related question was whether m:n > has been standardized in the OTN / SONET world. After we consulted our O= TN > experts back at the ranch, the general consensus is that while 1+1 and 1:= n > are well standardized by the ITU-T, m:n is typically left for further stu= dy. > There are proprietary solutions, including our own, but they don't seem = to > be widely deployed. I didn't get a specific m:n use-case. I suspect tha= t > any m:n use-case is probably better handled with shared-mesh protection > anyway. > > > > It seems that m:n shows up in all the standards, mainly for theoretical > completeness, but never ends up being specified. > > > > Based on this, I don't think we should slow-down the current 1:n > standardization effort by requiring the authors to embark on an m:n scien= ce > project. > > > > Pablo Frank > > Ciena > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf30050c2c02990804a921d85a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Well, I think that pretty much settles it then.  There had been a sugg= estion made in the wg meeting that m:n should be addressed by the 1:n prote= ction draft, under the assumption that m:n was a requirement for MPLS-TP an= d that, intuitively, m:n was a more general case of 1:n.  However, as = you've now correctly pointed out, m:n was never a requirement of MPLS-T= P.  From a practical implementation perspective, there is a significan= t jump in complexity between 1:n and m:n so it seems unreasonable to me to = expect the 1-to-n draft to address this solution (especially given that it = is not a requirement).  I think there is greater potential in bringing= the 1:n proposal closer to the original 1:1 linear protection, rather than= the other way.

regards,
Pablo

2= 011/7/27 <zh= ang.fei3@zte.com.cn>

Hi Pablo

I am not sure I catch  the di= scussion....

The requirements of MPLS-TP do not= include m;n [RFC5654], and it is clealy stated in the section 4.3.2 of the document [tp-survive-fwk] as blow:

"Note that there is no requir= ement for m:n recovery in the list of MPLS-TP requirements documented in [= RFC5654]".

As to the shared mesh protection, = G.smp is developing now in ITU-T, inlcuding packet and circuit solutions, and there are several individual documents now in MPLS WG.

Best regards

Fei


Pablo Frank <<= a href=3D"mailto:pabloisnot@gmail.com" target=3D"_blank">pabloisnot@gmail.c= om>
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org

2011-07-28 03:31

=CA=D5=BC=FE=C8= =CB
Daniel Cohn <DanielC@orckit.com>
=B3=AD=CB=CD
mpls@ietf.org
=D6=F7=CC=E2
Re: [mpls] Is m:n protection = a critical requirement?





Hi Daniel,

Sorry, I wasn't particularly clear.  I was ju= st inserting some of my own intuition (i.e. I can't imagine any realistic use-case f= or m:n).  There's no standard mechanism for m:n so really nothing tha= t we can evaluate against.  When I asked our experts if we've ever e= ncountered m:n use-cases in our OTN or sonet deployments, the response was that we always just solved the problem using shared mesh protection (of which we= 9;ve deployed tonnes).

cheers,
Pablo
On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn <DanielC@orckit.com> wrote:
Hi Pablo,

 

When you write “…m:n= use-case is probably better handled with shared-mesh protection…”, are you talking = about a particular m:n mechanism/standard? Can you pls specify?

 

DC

 

From: mpls-bounces= @ietf.org [mailto:<= font size=3D"2" color=3D"blue">mpls-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Wednesday, July 27, 2011 9:36 AM
To: mpls@ietf.org<= br> Subject: [mpls] Is m:n protection a critical requirement?

 

There was a question raised in monday's WG meet= ing as to whether there was a strong use-case for m:n protection.  A related question was whether m:n has been standardized in the OTN / SONET world.  After we consulted our OTN experts back at the ranch, the general consensus is that while 1+1 and 1:n are well standardized by the ITU-T, m:n is typically left for further study.  There are proprietary soluti= ons, including our own, but they don't seem to be widely deployed.  I d= idn't get a specific m:n use-case.  I suspect that any m:n use-case is proba= bly better handled with shared-mesh protection anyway.

 

It seems that m:n shows up in all the standards, ma= inly for theoretical completeness, but never ends up being specified.

 

Based on this, I don't think we should slow-dow= n the current 1:n standardization effort by requiring the authors to embark on an m:n science project.

 

Pablo Frank

Ciena 

 

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

<= p>


--20cf30050c2c02990804a921d85a-- From eosborne@cisco.com Thu Jul 28 07:24:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E239A21F8AFD for ; Thu, 28 Jul 2011 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0wWcRlXThUd for ; Thu, 28 Jul 2011 07:24:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 232FF21F8AE4 for ; Thu, 28 Jul 2011 07:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=2627; q=dns/txt; s=iport; t=1311863065; x=1313072665; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CFOyPUzss4YDtporTlKt0XRo7RpvCyAsfLtJtukJa4w=; b=HBjY0hvJrR//PvNlYkRqVNA3vt2n1Xklx4xsv/YBGYYw+2Z4IRI4GK27 thWhEosOxpt1FWMcBWj+zvngO/4OUK2VmE97ZBU15mfMWBeH6On3kNQ/4 7LHQJ3aUftold+U1oHMT57dBQYbZW6doVFnialXQJacn06VfDi7Czl81f Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAA1wMU6tJXG//2dsb2JhbAA0AQEBAQMUASEKNw4MBQIBCREEAQEBCgYjAQYBEzsOCAEBBQEWDBQHl2KPT3esbZ5chWJfBIdZkDCLcg X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7396787" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2011 14:24:24 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SEOOL3002776; Thu, 28 Jul 2011 14:24:24 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 09:24:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 09:24:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Is m:n protection a critical requirement? Thread-Index: AcxMk8s1KwxKp5/PQCGamUS02Z0X0wAnftKQ References: <44F4E579A764584EA9BDFD07D0CA081306ED8129@tlvmail1> From: "Eric Osborne (eosborne)" To: "Pablo Frank" , "Daniel Cohn" X-OriginalArrivalTime: 28 Jul 2011 14:24:24.0165 (UTC) FILETIME=[0C944950:01CC4D32] Cc: mpls@ietf.org Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:24:26 -0000 I agree that there's no requirement to provide an m:n solution, and as such I'm inclined to stay away from providing it, at least until we're well and truly done with 1:1, 1:n and shared mesh. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Pablo Frank > Sent: Wednesday, July 27, 2011 3:31 PM > To: Daniel Cohn > Cc: mpls@ietf.org > Subject: Re: [mpls] Is m:n protection a critical requirement? >=20 > Hi Daniel, >=20 > Sorry, I wasn't particularly clear. I was just inserting some of my own > intuition (i.e. I can't imagine any realistic use-case for m:n). There's > no standard mechanism for m:n so really nothing that we can evaluate > against. When I asked our experts if we've ever encountered m:n use-cases > in our OTN or sonet deployments, the response was that we always just > solved the problem using shared mesh protection (of which we've deployed > tonnes). >=20 > cheers, > Pablo >=20 >=20 > On Wed, Jul 27, 2011 at 1:01 PM, Daniel Cohn wrote: >=20 >=20 > Hi Pablo, >=20 >=20 >=20 > When you write "...m:n use-case is probably better handled with > shared-mesh protection...", are you talking about a particular m:n > mechanism/standard? Can you pls specify? >=20 >=20 >=20 > DC >=20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Pablo Frank > Sent: Wednesday, July 27, 2011 9:36 AM > To: mpls@ietf.org > Subject: [mpls] Is m:n protection a critical requirement? >=20 >=20 >=20 > There was a question raised in monday's WG meeting as to whether > there was a strong use-case for m:n protection. A related question was > whether m:n has been standardized in the OTN / SONET world. After we > consulted our OTN experts back at the ranch, the general consensus is that > while 1+1 and 1:n are well standardized by the ITU-T, m:n is typically > left for further study. There are proprietary solutions, including our > own, but they don't seem to be widely deployed. I didn't get a specific > m:n use-case. I suspect that any m:n use-case is probably better handled > with shared-mesh protection anyway. >=20 >=20 >=20 > It seems that m:n shows up in all the standards, mainly for > theoretical completeness, but never ends up being specified. >=20 >=20 >=20 > Based on this, I don't think we should slow-down the current 1:n > standardization effort by requiring the authors to embark on an m:n > science project. >=20 >=20 >=20 > Pablo Frank >=20 > Ciena >=20 >=20 >=20 From zhang.fei3@zte.com.cn Thu Jul 28 07:31:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495621F8B31; Thu, 28 Jul 2011 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.029 X-Spam-Level: X-Spam-Status: No, score=-97.029 tagged_above=-999 required=5 tests=[AWL=0.006, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5mIhgcHItJO; Thu, 28 Jul 2011 07:31:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 00E6021F8B2E; Thu, 28 Jul 2011 07:31:13 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Thu, 28 Jul 2011 22:29:05 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.3211079689; Thu, 28 Jul 2011 22:31:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6SEV0At046253; Thu, 28 Jul 2011 22:31:00 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Pablo Frank MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 28 Jul 2011 22:30:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-28 22:31:03, Serialize complete at 2011-07-28 22:31:03 Content-Type: multipart/alternative; boundary="=_alternative 004FBB63482578DB_=" X-MAIL: mse01.zte.com.cn p6SEV0At046253 Cc: mpls-bounces@ietf.org, mpls@ietf.org Subject: Re: [mpls] Is m:n protection a critical requirement? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:31:15 -0000 This is a multipart message in MIME format. --=_alternative 004FBB63482578DB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGFibG8NCg0KWWVhaCwgc3VyZWx5LiAxOm4gcHJvcG9zYWwgd2lsbCBiZSBjbG9zZWVyIHRv IHRoZSAxOjEgbGluZWFyIHByb3RlY3Rpb24NCg0KVGhhbmtzDQoNCkZlaQ0KDQoNCg0KUGFibG8g RnJhbmsgPHBhYmxvaXNub3RAZ21haWwuY29tPiANCjIwMTEtMDctMjggMjI6MTgNCg0KytW8/sjL DQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NCrOty80NCkRhbmllbCBDb2huIDxEYW5pZWxDQG9yY2tp dC5jb20+LCBtcGxzQGlldGYub3JnLCBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBb bXBsc10gSXMgbTpuIHByb3RlY3Rpb24gYSBjcml0aWNhbCByZXF1aXJlbWVudD8NCg0KDQoNCg0K DQoNCldlbGwsIEkgdGhpbmsgdGhhdCBwcmV0dHkgbXVjaCBzZXR0bGVzIGl0IHRoZW4uICBUaGVy ZSBoYWQgYmVlbiBhIA0Kc3VnZ2VzdGlvbiBtYWRlIGluIHRoZSB3ZyBtZWV0aW5nIHRoYXQgbTpu IHNob3VsZCBiZSBhZGRyZXNzZWQgYnkgdGhlIDE6biANCnByb3RlY3Rpb24gZHJhZnQsIHVuZGVy IHRoZSBhc3N1bXB0aW9uIHRoYXQgbTpuIHdhcyBhIHJlcXVpcmVtZW50IGZvciANCk1QTFMtVFAg YW5kIHRoYXQsIGludHVpdGl2ZWx5LCBtOm4gd2FzIGEgbW9yZSBnZW5lcmFsIGNhc2Ugb2YgMTpu LiANCkhvd2V2ZXIsIGFzIHlvdSd2ZSBub3cgY29ycmVjdGx5IHBvaW50ZWQgb3V0LCBtOm4gd2Fz IG5ldmVyIGEgcmVxdWlyZW1lbnQgDQpvZiBNUExTLVRQLiAgRnJvbSBhIHByYWN0aWNhbCBpbXBs ZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgdGhlcmUgaXMgYSANCnNpZ25pZmljYW50IGp1bXAgaW4g Y29tcGxleGl0eSBiZXR3ZWVuIDE6biBhbmQgbTpuIHNvIGl0IHNlZW1zIA0KdW5yZWFzb25hYmxl IHRvIG1lIHRvIGV4cGVjdCB0aGUgMS10by1uIGRyYWZ0IHRvIGFkZHJlc3MgdGhpcyBzb2x1dGlv biANCihlc3BlY2lhbGx5IGdpdmVuIHRoYXQgaXQgaXMgbm90IGEgcmVxdWlyZW1lbnQpLiAgSSB0 aGluayB0aGVyZSBpcyBncmVhdGVyIA0KcG90ZW50aWFsIGluIGJyaW5naW5nIHRoZSAxOm4gcHJv cG9zYWwgY2xvc2VyIHRvIHRoZSBvcmlnaW5hbCAxOjEgbGluZWFyIA0KcHJvdGVjdGlvbiwgcmF0 aGVyIHRoYW4gdGhlIG90aGVyIHdheS4NCg0KcmVnYXJkcywNClBhYmxvDQoNCjIwMTEvNy8yNyA8 emhhbmcuZmVpM0B6dGUuY29tLmNuPg0KDQpIaSBQYWJsbyANCg0KSSBhbSBub3Qgc3VyZSBJIGNh dGNoICB0aGUgZGlzY3Vzc2lvbi4uLi4gDQoNClRoZSByZXF1aXJlbWVudHMgb2YgTVBMUy1UUCBk byBub3QgaW5jbHVkZSBtO24gW1JGQzU2NTRdLCBhbmQgaXQgaXMgY2xlYWx5IA0Kc3RhdGVkIGlu IHRoZSBzZWN0aW9uIDQuMy4yIG9mIHRoZSBkb2N1bWVudCBbdHAtc3Vydml2ZS1md2tdIGFzIGJs b3c6IA0KDQoiTm90ZSB0aGF0IHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciBtOm4gcmVjb3Zl cnkgaW4gdGhlIGxpc3Qgb2YgTVBMUy1UUCANCnJlcXVpcmVtZW50cyBkb2N1bWVudGVkIGluIFtS RkM1NjU0XSIuIA0KDQpBcyB0byB0aGUgc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiwgRy5zbXAgaXMg ZGV2ZWxvcGluZyBub3cgaW4gSVRVLVQsIA0KaW5sY3VkaW5nIHBhY2tldCBhbmQgY2lyY3VpdCBz b2x1dGlvbnMsIGFuZCB0aGVyZSBhcmUgc2V2ZXJhbCBpbmRpdmlkdWFsIA0KZG9jdW1lbnRzIG5v dyBpbiBNUExTIFdHLiANCg0KQmVzdCByZWdhcmRzIA0KDQpGZWkgDQoNCg0KDQpQYWJsbyBGcmFu ayA8cGFibG9pc25vdEBnbWFpbC5jb20+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3Jn IA0KMjAxMS0wNy0yOCAwMzozMSANCg0KDQrK1bz+yMsNCkRhbmllbCBDb2huIDxEYW5pZWxDQG9y Y2tpdC5jb20+IA0Ks63LzQ0KbXBsc0BpZXRmLm9yZyANCtb3zOINClJlOiBbbXBsc10gSXMgbTpu IHByb3RlY3Rpb24gYSBjcml0aWNhbCByZXF1aXJlbWVudD8NCg0KDQoNCg0KDQoNCg0KDQpIaSBE YW5pZWwsIA0KDQpTb3JyeSwgSSB3YXNuJ3QgcGFydGljdWxhcmx5IGNsZWFyLiAgSSB3YXMganVz dCBpbnNlcnRpbmcgc29tZSBvZiBteSBvd24gDQppbnR1aXRpb24gKGkuZS4gSSBjYW4ndCBpbWFn aW5lIGFueSByZWFsaXN0aWMgdXNlLWNhc2UgZm9yIG06bikuICBUaGVyZSdzIA0Kbm8gc3RhbmRh cmQgbWVjaGFuaXNtIGZvciBtOm4gc28gcmVhbGx5IG5vdGhpbmcgdGhhdCB3ZSBjYW4gZXZhbHVh dGUgDQphZ2FpbnN0LiAgV2hlbiBJIGFza2VkIG91ciBleHBlcnRzIGlmIHdlJ3ZlIGV2ZXIgZW5j b3VudGVyZWQgbTpuIHVzZS1jYXNlcyANCmluIG91ciBPVE4gb3Igc29uZXQgZGVwbG95bWVudHMs IHRoZSByZXNwb25zZSB3YXMgdGhhdCB3ZSBhbHdheXMganVzdCANCnNvbHZlZCB0aGUgcHJvYmxl bSB1c2luZyBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uIChvZiB3aGljaCB3ZSd2ZSBkZXBsb3llZCAN CnRvbm5lcykuIA0KDQpjaGVlcnMsIA0KUGFibG8NCg0KT24gV2VkLCBKdWwgMjcsIDIwMTEgYXQg MTowMSBQTSwgRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbT4gd3JvdGU6IA0KSGkgUGFi bG8sIA0KICANCldoZW4geW91IHdyaXRlIKGwoa1tOm4gdXNlLWNhc2UgaXMgcHJvYmFibHkgYmV0 dGVyIGhhbmRsZWQgd2l0aCANCnNoYXJlZC1tZXNoIHByb3RlY3Rpb26hraGxLCBhcmUgeW91IHRh bGtpbmcgYWJvdXQgYSBwYXJ0aWN1bGFyIG06biANCm1lY2hhbmlzbS9zdGFuZGFyZD8gQ2FuIHlv dSBwbHMgc3BlY2lmeT8gDQogIA0KREMgDQogIA0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpQYWJsbyBGcmFu aw0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDk6MzYgQU0NClRvOiBtcGxzQGlldGYu b3JnDQpTdWJqZWN0OiBbbXBsc10gSXMgbTpuIHByb3RlY3Rpb24gYSBjcml0aWNhbCByZXF1aXJl bWVudD8gDQogDQpUaGVyZSB3YXMgYSBxdWVzdGlvbiByYWlzZWQgaW4gbW9uZGF5J3MgV0cgbWVl dGluZyBhcyB0byB3aGV0aGVyIHRoZXJlIHdhcyANCmEgc3Ryb25nIHVzZS1jYXNlIGZvciBtOm4g cHJvdGVjdGlvbi4gIEEgcmVsYXRlZCBxdWVzdGlvbiB3YXMgd2hldGhlciBtOm4gDQpoYXMgYmVl biBzdGFuZGFyZGl6ZWQgaW4gdGhlIE9UTiAvIFNPTkVUIHdvcmxkLiAgQWZ0ZXIgd2UgY29uc3Vs dGVkIG91ciANCk9UTiBleHBlcnRzIGJhY2sgYXQgdGhlIHJhbmNoLCB0aGUgZ2VuZXJhbCBjb25z ZW5zdXMgaXMgdGhhdCB3aGlsZSAxKzEgYW5kIA0KMTpuIGFyZSB3ZWxsIHN0YW5kYXJkaXplZCBi eSB0aGUgSVRVLVQsIG06biBpcyB0eXBpY2FsbHkgbGVmdCBmb3IgZnVydGhlciANCnN0dWR5LiAg VGhlcmUgYXJlIHByb3ByaWV0YXJ5IHNvbHV0aW9ucywgaW5jbHVkaW5nIG91ciBvd24sIGJ1dCB0 aGV5IGRvbid0IA0Kc2VlbSB0byBiZSB3aWRlbHkgZGVwbG95ZWQuICBJIGRpZG4ndCBnZXQgYSBz cGVjaWZpYyBtOm4gdXNlLWNhc2UuICBJIA0Kc3VzcGVjdCB0aGF0IGFueSBtOm4gdXNlLWNhc2Ug aXMgcHJvYmFibHkgYmV0dGVyIGhhbmRsZWQgd2l0aCBzaGFyZWQtbWVzaCANCnByb3RlY3Rpb24g YW55d2F5LiANCiANCkl0IHNlZW1zIHRoYXQgbTpuIHNob3dzIHVwIGluIGFsbCB0aGUgc3RhbmRh cmRzLCBtYWlubHkgZm9yIHRoZW9yZXRpY2FsIA0KY29tcGxldGVuZXNzLCBidXQgbmV2ZXIgZW5k cyB1cCBiZWluZyBzcGVjaWZpZWQuIA0KIA0KQmFzZWQgb24gdGhpcywgSSBkb24ndCB0aGluayB3 ZSBzaG91bGQgc2xvdy1kb3duIHRoZSBjdXJyZW50IDE6biANCnN0YW5kYXJkaXphdGlvbiBlZmZv cnQgYnkgcmVxdWlyaW5nIHRoZSBhdXRob3JzIHRvIGVtYmFyayBvbiBhbiBtOm4gDQpzY2llbmNl IHByb2plY3QuIA0KIA0KUGFibG8gRnJhbmsgDQpDaWVuYSANCiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 004FBB63482578DB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhYmxvPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ZZWFoLCBzdXJlbHkuIDE6biBw cm9wb3NhbCB3aWxsIGJlIGNsb3NlZXINCnRvIHRoZSAxOjEgbGluZWFyIHByb3RlY3Rpb248L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBhYmxvIEZyYW5r ICZsdDtwYWJsb2lzbm90QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0yOCAyMjoxODwvZm9udD4NCjx0ZCB3aWR0aD02 NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20u Y248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkRhbmllbCBDb2huICZsdDtEYW5pZWxDQG9yY2tpdC5jb20m Z3Q7LA0KbXBsc0BpZXRmLm9yZywgbXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW21wbHNdIElzIG06biBwcm90ZWN0aW9uIGEgY3JpdGljYWwNCnJlcXVpcmVtZW50 PzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj5XZWxsLCBJIHRoaW5rIHRoYXQgcHJldHR5IG11Y2ggc2V0dGxlcw0K aXQgdGhlbi4gJm5ic3A7VGhlcmUgaGFkIGJlZW4gYSBzdWdnZXN0aW9uIG1hZGUgaW4gdGhlIHdn IG1lZXRpbmcgdGhhdA0KbTpuIHNob3VsZCBiZSBhZGRyZXNzZWQgYnkgdGhlIDE6biBwcm90ZWN0 aW9uIGRyYWZ0LCB1bmRlciB0aGUgYXNzdW1wdGlvbg0KdGhhdCBtOm4gd2FzIGEgcmVxdWlyZW1l bnQgZm9yIE1QTFMtVFAgYW5kIHRoYXQsIGludHVpdGl2ZWx5LCBtOm4gd2FzIGENCm1vcmUgZ2Vu ZXJhbCBjYXNlIG9mIDE6bi4gJm5ic3A7SG93ZXZlciwgYXMgeW91J3ZlIG5vdyBjb3JyZWN0bHkg cG9pbnRlZA0Kb3V0LCBtOm4gd2FzIG5ldmVyIGEgcmVxdWlyZW1lbnQgb2YgTVBMUy1UUC4gJm5i c3A7RnJvbSBhIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbg0KcGVyc3BlY3RpdmUsIHRoZXJlIGlz IGEgc2lnbmlmaWNhbnQganVtcCBpbiBjb21wbGV4aXR5IGJldHdlZW4gMTpuIGFuZA0KbTpuIHNv IGl0IHNlZW1zIHVucmVhc29uYWJsZSB0byBtZSB0byBleHBlY3QgdGhlIDEtdG8tbiBkcmFmdCB0 byBhZGRyZXNzDQp0aGlzIHNvbHV0aW9uIChlc3BlY2lhbGx5IGdpdmVuIHRoYXQgaXQgaXMgbm90 IGEgcmVxdWlyZW1lbnQpLiAmbmJzcDtJDQp0aGluayB0aGVyZSBpcyBncmVhdGVyIHBvdGVudGlh bCBpbiBicmluZ2luZyB0aGUgMTpuIHByb3Bvc2FsIGNsb3NlciB0bw0KdGhlIG9yaWdpbmFsIDE6 MSBsaW5lYXIgcHJvdGVjdGlvbiwgcmF0aGVyIHRoYW4gdGhlIG90aGVyIHdheS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnJlZ2FyZHMsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5QYWJsbzxicj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS83LzI3ICZsdDs8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBQYWJsbzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KSSBhbSBub3Qgc3VyZSBJIGNhdGNoICZuYnNwO3RoZSBkaXNjdXNzaW9uLi4u LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSByZXF1aXJlbWVudHMgb2YgTVBM Uy1UUCBkbyBub3QgaW5jbHVkZSBtO24gW1JGQzU2NTRdLCBhbmQgaXQgaXMgY2xlYWx5DQpzdGF0 ZWQgaW4gdGhlIHNlY3Rpb24gNC4zLjIgb2YgdGhlIGRvY3VtZW50IFt0cC1zdXJ2aXZlLWZ3a10g YXMgYmxvdzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomcXVvdDtOb3RlIHRoYXQg dGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIG06biByZWNvdmVyeSBpbiB0aGUgbGlzdCBvZg0K TVBMUy1UUCByZXF1aXJlbWVudHMgZG9jdW1lbnRlZCBpbiBbPC9mb250PjxhIGhyZWY9aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTY1NCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PlJGQzU2NTQ8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+XSZxdW90Oy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpBcyB0byB0aGUgc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiwgRy5zbXAgaXMgZGV2 ZWxvcGluZyBub3cgaW4gSVRVLVQsIGlubGN1ZGluZw0KcGFja2V0IGFuZCBjaXJjdWl0IHNvbHV0 aW9ucywgYW5kIHRoZXJlIGFyZSBzZXZlcmFsIGluZGl2aWR1YWwgZG9jdW1lbnRzDQpub3cgaW4g TVBMUyBXRy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkJlc3QgcmVnYXJkczwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRmVpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQxJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+UGFibG8gRnJhbmsgJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGFibG9p c25vdEBnbWFpbC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48Yj48dT5wYWJsb2lzbm90QGdtYWlsLmNvbTwvdT48L2I+PC9mb250Pjwv YT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjxicj4NCreivP7I yzogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ bXBscy1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIw MTEtMDctMjggMDM6MzE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pg0KPHRkIHdpZHRoPTU4JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MTAlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RGFuaWVsIENvaG4gJmx0OzwvZm9udD48YSBocmVmPW1h aWx0bzpEYW5pZWxDQG9yY2tpdC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5EYW5pZWxDQG9yY2tpdC5jb208L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbbXBsc10gSXMgbTpuIHByb3RlY3Rpb24gYSBjcml0aWNhbA0KcmVxdWlyZW1l bnQ/PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 YnI+DQpIaSBEYW5pZWwsIDxicj4NCjxicj4NClNvcnJ5LCBJIHdhc24ndCBwYXJ0aWN1bGFybHkg Y2xlYXIuICZuYnNwO0kgd2FzIGp1c3QgaW5zZXJ0aW5nIHNvbWUgb2YNCm15IG93biBpbnR1aXRp b24gKGkuZS4gSSBjYW4ndCBpbWFnaW5lIGFueSByZWFsaXN0aWMgdXNlLWNhc2UgZm9yIG06biku DQombmJzcDtUaGVyZSdzIG5vIHN0YW5kYXJkIG1lY2hhbmlzbSBmb3IgbTpuIHNvIHJlYWxseSBu b3RoaW5nIHRoYXQgd2UgY2FuDQpldmFsdWF0ZSBhZ2FpbnN0LiAmbmJzcDtXaGVuIEkgYXNrZWQg b3VyIGV4cGVydHMgaWYgd2UndmUgZXZlciBlbmNvdW50ZXJlZA0KbTpuIHVzZS1jYXNlcyBpbiBv dXIgT1ROIG9yIHNvbmV0IGRlcGxveW1lbnRzLCB0aGUgcmVzcG9uc2Ugd2FzIHRoYXQgd2UNCmFs d2F5cyBqdXN0IHNvbHZlZCB0aGUgcHJvYmxlbSB1c2luZyBzaGFyZWQgbWVzaCBwcm90ZWN0aW9u IChvZiB3aGljaCB3ZSd2ZQ0KZGVwbG95ZWQgdG9ubmVzKS4gPGJyPg0KPGJyPg0KY2hlZXJzLCA8 YnI+DQpQYWJsbzxicj4NCjxicj4NCk9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6MDEgUE0sIERh bmllbCBDb2huICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ RGFuaWVsQ0BvcmNraXQuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZndDsNCndyb3RlOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGkgUGFibG8sPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYi PldoZW4geW91IHdyaXRlIKGwoa1tOm4NCnVzZS1jYXNlIGlzIHByb2JhYmx5IGJldHRlciBoYW5k bGVkIHdpdGggc2hhcmVkLW1lc2ggcHJvdGVjdGlvbqGtobEsDQphcmUgeW91IHRhbGtpbmcgYWJv dXQgYSBwYXJ0aWN1bGFyIG06biBtZWNoYW5pc20vc3RhbmRhcmQ/IENhbiB5b3UgcGxzDQpzcGVj aWZ5PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD4NCjxwPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj5EQzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxiPkZyb206 PC9iPiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5tcGxz LWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+DQpbbWFpbHRvOjwvZm9udD48YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhYmxvIEZyYW5rPGI+PGJy Pg0KU2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyNywgMjAxMSA5OjM2IEFNPGI+PGJyPg0KVG86 PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm1wbHNAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PGJyPg0KU3Vi amVjdDo8L2I+IFttcGxzXSBJcyBtOm4gcHJvdGVjdGlvbiBhIGNyaXRpY2FsIHJlcXVpcmVtZW50 PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxwPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSB3YXMgYSBxdWVzdGlvbiByYWlzZWQgaW4gbW9uZGF5 J3MNCldHIG1lZXRpbmcgYXMgdG8gd2hldGhlciB0aGVyZSB3YXMgYSBzdHJvbmcgdXNlLWNhc2Ug Zm9yIG06biBwcm90ZWN0aW9uLg0KJm5ic3A7QSByZWxhdGVkIHF1ZXN0aW9uIHdhcyB3aGV0aGVy IG06biBoYXMgYmVlbiBzdGFuZGFyZGl6ZWQgaW4gdGhlIE9UTg0KLyBTT05FVCB3b3JsZC4gJm5i c3A7QWZ0ZXIgd2UgY29uc3VsdGVkIG91ciBPVE4gZXhwZXJ0cyBiYWNrIGF0IHRoZSByYW5jaCwN CnRoZSBnZW5lcmFsIGNvbnNlbnN1cyBpcyB0aGF0IHdoaWxlIDErMSBhbmQgMTpuIGFyZSB3ZWxs IHN0YW5kYXJkaXplZCBieQ0KdGhlIElUVS1ULCBtOm4gaXMgdHlwaWNhbGx5IGxlZnQgZm9yIGZ1 cnRoZXIgc3R1ZHkuICZuYnNwO1RoZXJlIGFyZSBwcm9wcmlldGFyeQ0Kc29sdXRpb25zLCBpbmNs dWRpbmcgb3VyIG93biwgYnV0IHRoZXkgZG9uJ3Qgc2VlbSB0byBiZSB3aWRlbHkgZGVwbG95ZWQu DQombmJzcDtJIGRpZG4ndCBnZXQgYSBzcGVjaWZpYyBtOm4gdXNlLWNhc2UuICZuYnNwO0kgc3Vz cGVjdCB0aGF0IGFueSBtOm4NCnVzZS1jYXNlIGlzIHByb2JhYmx5IGJldHRlciBoYW5kbGVkIHdp dGggc2hhcmVkLW1lc2ggcHJvdGVjdGlvbiBhbnl3YXkuDQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj5JdCBzZWVtcyB0aGF0IG06biBzaG93cyB1cCBpbiBhbGwgdGhlDQpzdGFu ZGFyZHMsIG1haW5seSBmb3IgdGhlb3JldGljYWwgY29tcGxldGVuZXNzLCBidXQgbmV2ZXIgZW5k cyB1cCBiZWluZw0Kc3BlY2lmaWVkLiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij5CYXNlZCBvbiB0aGlzLCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZA0Kc2xvdy1kb3duIHRoZSBj dXJyZW50IDE6biBzdGFuZGFyZGl6YXRpb24gZWZmb3J0IGJ5IHJlcXVpcmluZyB0aGUgYXV0aG9y cw0KdG8gZW1iYXJrIG9uIGFuIG06biBzY2llbmNlIHByb2plY3QuIDwvZm9udD4NCjxwPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPlBhYmxvIEZyYW5rIDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj5DaWVuYSAmbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxwPjx0dD48Zm9udCBzaXplPTI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxp bmcgbGlzdDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8 L3U+PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5r Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48 L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48 L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIHRh cmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvdT48L2ZvbnQ+PC90dD48L2E+DQo8cD4NCjxw Pg0K --=_alternative 004FBB63482578DB_=-- From Rolf.Winter@neclab.eu Thu Jul 28 08:04:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC5121F8CB6 for ; Thu, 28 Jul 2011 08:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMzGqwF1UD6O for ; Thu, 28 Jul 2011 08:04:46 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92311E8085 for ; Thu, 28 Jul 2011 08:04:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AC3D8280001AA for ; Thu, 28 Jul 2011 17:04:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNli+7WeXfng for ; Thu, 28 Jul 2011 17:04:44 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 937EB28000329 for ; Thu, 28 Jul 2011 17:04:39 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 17:04:39 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: internal MIP addressing Thread-Index: AcxNN6sawyO6Jwt6RMSElPxaLn8V1w== Date: Thu, 28 Jul 2011 15:04:39 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D03312B@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] internal MIP addressing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:04:46 -0000 Hi, I'd like to encourage the WG to discuss internal MIP addressing on the list= (see draft: http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map). = As I said during the meeting, I think it would be good if the WG could take= this work on and start defining how the per-interface MIP OAM would look l= ike now that the first solutions end up in the RFC editor's queue. Basicall= y I'd like to know whether you think it is useful, we define it the right w= ay or whether you have a preference for one of the options outlined in the = document. In case you comment on the document, please mention whether you h= ave read the last version of the draft. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From eosborne@cisco.com Thu Jul 28 08:12:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1592621F8C80 for ; Thu, 28 Jul 2011 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahHsXYdqi2nI for ; Thu, 28 Jul 2011 08:12:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 767E021F8C7D for ; Thu, 28 Jul 2011 08:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1839; q=dns/txt; s=iport; t=1311865944; x=1313075544; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+fLFs35mu1L1dzYvG1Ii7mGQx5+y+aql3afidaHZeVc=; b=LNgMrZKJekpPn2XmI7MG6UhiR3EPp/X3r4kAOZdprN8Xoc+fRBVHXBYq gic5+otET2gvY3R6ScrcPcS4GQHk6dyCSBHAltBvMDx8O0d5h2Cn6JSqN vURiR0544nM12Ace1jrLWfhuH70r0aFf3dxT/O2IQMqP9fbVR+pZd4nOR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAACR7MU6tJXHB/2dsb2JhbAA0AQEBAQMUASEKUQUCAQkRBAEBCwYjAQYBEzsOCAEBBQEWDBuXYo9Pd60JnleFYl8Eh1mQMIty X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7411749" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 15:12:24 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6SFCO68015003; Thu, 28 Jul 2011 15:12:24 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 10:12:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 10:12:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxMiCTG2SfwwA/wTJSxPVjwVswzDAAr7vjw References: From: "Eric Osborne (eosborne)" To: "Greg Mirsky" , "Daniel Cohn" , , , , , "D'Alessandro Alessandro Gerardo" , X-OriginalArrivalTime: 28 Jul 2011 15:12:23.0443 (UTC) FILETIME=[C0C33E30:01CC4D38] Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:12:25 -0000 Hi Greg- There is a difference between SF and SD. Converting SD into Down means that it will be interpreted exactly the same as SF, and if that's the case why have SD at all? If SD is necessary it must be somehow different from SD. All- Having said that, I'm not sure I disagree with Greg. It seems that this idea of propagating server layer SD up into TP is being done because there's no good way to do SD entirely within the TP layer. I suspect that if there were a way to do SD within the TP layer that made everyone happy, we wouldn't have the approach propsed in draft-rkhd-mpls-tp-sd. And I think that if the motivation for this draft is: - we must have SD in TP because it is possible to do in other technologies - it is not possible to SD entirely within TP - therefore we must get SD from somewhere else is a reasonable one. If we do that, where do we stop? Should we propagate information about signal quality up to TCP so it can adjust its windows according? (please note that this is intended to be a reductio ad absurdum question and not a serious one. :) ) eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Wednesday, July 27, 2011 2:08 PM > To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Dear Authors and All, > I think that it is function of the PHY layer to detect SD condition and > convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical > Section). In case of accumulating SD over LSP the e2e Packet Loss > measurement, in my view, is addressing the issue. >=20 > Regards, > Greg From david.i.allan@ericsson.com Thu Jul 28 09:49:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8160921F8AE1 for ; Thu, 28 Jul 2011 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qB8XYaL6EZk for ; Thu, 28 Jul 2011 09:49:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C21D211E807E for ; Thu, 28 Jul 2011 09:49:37 -0700 (PDT) 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 p6SGnTcb012087; Thu, 28 Jul 2011 11:49:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 28 Jul 2011 12:49:24 -0400 From: David Allan I To: "Eric Osborne (eosborne)" , Greg Mirsky , Daniel Cohn , "rafir@orckit.com" , "ms-daikoku@kddi.com" , "ma.yuxia@zte.com.cn" , "yang.jian90@zte.com.cn" , "D'Alessandro Alessandro Gerardo" , "mpls@ietf.org" Date: Thu, 28 Jul 2011 12:49:23 -0400 Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxMiCTG2SfwwA/wTJSxPVjwVswzDAAr7vjwAANcZPA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D5B95@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:49:38 -0000 IMO SD criteria has technology specific characteristics for each PHY that c= arriers MPLS. Punting/exposing it into the MPLS layer is a mistake as we wi= ll need to keep revisiting the definition for different PHY types.=20 I don't think we want to continuously run MPLS layer PM on every section ei= ther in order to stunt double for and/or supercede the functionality of the= server layer. My 2 cents D -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: Thursday, July 28, 2011 11:12 AM To: Greg Mirsky; Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; ma.yux= ia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpl= s@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Greg- There is a difference between SF and SD. Converting SD into Down means t= hat it will be interpreted exactly the same as SF, and if that's the case w= hy have SD at all? If SD is necessary it must be somehow different from SD= . All- Having said that, I'm not sure I disagree with Greg. It seems that this = idea of propagating server layer SD up into TP is being done because there'= s no good way to do SD entirely within the TP layer. I suspect that if the= re were a way to do SD within the TP layer that made everyone happy, we wou= ldn't have the approach propsed in draft-rkhd-mpls-tp-sd. And I think that= if the motivation for this draft is: - we must have SD in TP because it is possible to do in other technologie= s - it is not possible to SD entirely within TP - therefore we must get SD from somewhere else is a reasonable one. If we do that, where do we stop? Should we propagate= information about signal quality up to TCP so it can adjust its windows ac= cording? (please note that this is intended to be a reductio ad absurdum q= uestion and not a serious one. :) ) eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Wednesday, July 27, 2011 2:08 PM > To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com;=20 > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro=20 > Gerardo; mpls@ietf.org > Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Dear Authors and All, > I think that it is function of the PHY layer to detect SD condition and > convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical > Section). In case of accumulating SD over LSP the e2e Packet Loss=20 > measurement, in my view, is addressing the issue. >=20 > Regards, > Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From DanielC@orckit.com Thu Jul 28 09:51:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653821F891F for ; Thu, 28 Jul 2011 09:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pefIFOm7WYsK for ; Thu, 28 Jul 2011 09:51:53 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5169621F874A for ; Thu, 28 Jul 2011 09:51:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 19:51:45 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxMiCTG2SfwwA/wTJSxPVjwVswzDAAr7vjwAAMeysA= References: From: "Daniel Cohn" To: "Eric Osborne (eosborne)" , "Greg Mirsky" , "Rafi Ram" , , , , "D'Alessandro Alessandro Gerardo" , Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:51:54 -0000 Hi Eric, One of the reasons why we need SD in TP is because TP is supposed to provide the same "look and feel" of existing transport networks, as specified in the TP requirements document. Transport networks technologies have long supported the distinction between "degraded" and " faulty". In particular, protection technologies in use have this distinction built into the innermost recedes of their protocols.=20 Even in the TP requirements didn't spell this out, I think it would be a mistake not to take advantage of years of experience in transport networks OAM. Regards, Daniel -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, July 28, 2011 11:12 AM To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Greg- There is a difference between SF and SD. Converting SD into Down means that it will be interpreted exactly the same as SF, and if that's the case why have SD at all? If SD is necessary it must be somehow different from SD. All- Having said that, I'm not sure I disagree with Greg. It seems that this idea of propagating server layer SD up into TP is being done because there's no good way to do SD entirely within the TP layer. I suspect that if there were a way to do SD within the TP layer that made everyone happy, we wouldn't have the approach propsed in draft-rkhd-mpls-tp-sd. And I think that if the motivation for this draft is: - we must have SD in TP because it is possible to do in other technologies - it is not possible to SD entirely within TP - therefore we must get SD from somewhere else is a reasonable one. If we do that, where do we stop? Should we propagate information about signal quality up to TCP so it can adjust its windows according? (please note that this is intended to be a reductio ad absurdum question and not a serious one. :) ) eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Wednesday, July 27, 2011 2:08 PM > To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Dear Authors and All, > I think that it is function of the PHY layer to detect SD condition and > convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical > Section). In case of accumulating SD over LSP the e2e Packet Loss > measurement, in my view, is addressing the issue. >=20 > Regards, > Greg From gregimirsky@gmail.com Thu Jul 28 10:00:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9721F8BC2 for ; Thu, 28 Jul 2011 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4+ITdMoUjEQ for ; Thu, 28 Jul 2011 10:00:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 154DF11E8109 for ; Thu, 28 Jul 2011 10:00:15 -0700 (PDT) Received: by vxi40 with SMTP id 40so2620645vxi.31 for ; Thu, 28 Jul 2011 10:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=f4yyLRO8I4pHJmr12CkQhbTb/C2P5tsCu8xikxOBeoo=; b=MvkVj6KjVE0GsdZdnNsT/TfFLh7ZiQyXKP2UIfeQQF9wT3NvRFYm8iek4hcFaCh+QN ce2dyR/8dgVexmFWXreDpmknNO1G48BrLkkp2nUayYoGASkA/xE7/1LP891+EINyXj1J s6hig8T9tJfgdu/kUcVHkNjSn/PyycuOjCeE0= MIME-Version: 1.0 Received: by 10.52.115.165 with SMTP id jp5mr292594vdb.158.1311872414318; Thu, 28 Jul 2011 10:00:14 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Thu, 28 Jul 2011 10:00:14 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> Date: Thu, 28 Jul 2011 10:00:14 -0700 Message-ID: From: Greg Mirsky To: Daniel Cohn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:00:19 -0000 Hi Daniel, I think that while we're building MPLS-TP to be suited for the transport we need to remember that it, as Neil pointed out on number of occasions, is not BOS layer and doesn't put bits on a wire. Thus it has characteristic that makes it different from other layers of a transport network and, I think, as result not all existing concepts of transport are applicable to packet layer realized by MPLS-TP. Regards, Greg On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > Hi Eric, > > One of the reasons why we need SD in TP is because TP is supposed to > provide the same "look and feel" of existing transport networks, as > specified in the TP requirements document. > Transport networks technologies have long supported the distinction > between "degraded" and " faulty". In particular, protection technologies > in use have this distinction built into the innermost recedes of their > protocols. > Even in the TP requirements didn't spell this out, I think it would be a > mistake not to take advantage of years of experience in transport > networks OAM. > > Regards, > > Daniel > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 11:12 AM > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Greg- > =A0There is a difference between SF and SD. =A0Converting SD into Down > means that it will be interpreted exactly the same as SF, and if that's > the case why have SD at all? =A0If SD is necessary it must be somehow > different from SD. > > All- > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems that > this idea of propagating server layer SD up into TP is being done > because there's no good way to do SD entirely within the TP layer. =A0I > suspect that if there were a way to do SD within the TP layer that made > everyone happy, we wouldn't have the approach propsed in > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for this > draft is: > > =A0- we must have SD in TP because it is possible to do in other > technologies > =A0- it is not possible to SD entirely within TP > =A0- therefore we must get SD from somewhere else > > is a reasonable one. =A0If we do that, where do we stop? =A0Should we > propagate information about signal quality up to TCP so it can adjust > its windows according? =A0(please note that this is intended to be a > reductio ad absurdum question and not a serious one. :) ) > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Greg Mirsky >> Sent: Wednesday, July 27, 2011 2:08 PM >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Dear Authors and All, >> I think that it is function of the PHY layer to detect SD condition > and >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > Physical >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> measurement, in my view, is addressing the issue. >> >> Regards, >> Greg > > From c-sai@bx.jp.nec.com Thu Jul 28 10:05:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73A11E80E1 for ; Thu, 28 Jul 2011 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeZbc8YhaeB2 for ; Thu, 28 Jul 2011 10:05:17 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 028D321F8BA4 for ; Thu, 28 Jul 2011 10:05:16 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6SH55ST001903; Fri, 29 Jul 2011 02:05:05 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6SH55V08628; Fri, 29 Jul 2011 02:05:05 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6SH55UJ028295; Fri, 29 Jul 2011 02:05:05 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-98358; Fri, 29 Jul 2011 02:04:30 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTPA id BT-MMP-78; Fri, 29 Jul 2011 02:04:29 +0900 From: "Zhenlong Cui" To: "'Eric Gray'" , "'Sam Aldrin'" References: <4DFA60E3.90807@pi.nu> <791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd> <60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp> <5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com> <9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> Date: Fri, 29 Jul 2011 02:04:29 +0900 Message-ID: <662500A437844CE68AC30DB3B9E41C40@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQAAIYSLAADzDIUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:05:18 -0000 Hi Eric, Sorry, protocol redundancy is what I had in mind when I wrote my original mail. I didn't understand why to define a different behavior for "destination node identifier" and "destination interface identifier". In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface MIP case). I do understand the draft contains no such requirements for the for P2MP case. Essentially, the requestor receiving multiple responses which include different return code may not be a problem. Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here. Thanks for your response. > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Thursday, July 28, 2011 12:45 AM > To: Zhenlong Cui; 'Sam Aldrin' > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Not sure why you think the protocol redundancy is necessary, > or even a good idea. > > The DSMAP TLV as defined allows specification of an interface. > > Asking for a potentially new TLV that will also provide this > information in the event that one is unable to handle, read or > interpret the DSMAP TLV is pointless. If one cannot use one > TLV, the chances are very good that one cannot use a newer one > either. > > -----Original Message----- > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > Sent: Wednesday, July 27, 2011 10:46 AM > To: 'Sam Aldrin'; Eric Gray > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > Importance: High > > Hi Sam and Eric, > > Ok, I understand that the issue of unknown TLVs is outside the scope of this document. > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > 1) Which return code to send when source/destination identifiersare wrong or drop the request. > > As said above, it should be dropped, if the source is unknown. > > OK, I think this is clear now: > - A responder will drop requests from an unknown source. > - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.) > > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below. > The information collected MUST include identifiers related to the nodes and interfaces composing that route. > > I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity, > therefore they > should have the same behavior in the responder. > > So, my suggestions regarding these issues are as follows. > 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. > 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV. > > > Best, > Zhenlong > > > -----Original Message----- > > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > > Sent: Wednesday, July 27, 2011 6:29 AM > > To: Zhenlong Cui > > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft. > > Having said that, please find responses inline. > > > > Sam > > > > Sent from my iPad > > > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: > > > > > Hi Eric, > > > > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem > > with > > > responding. > > > On the other hand, you say that you should send a reply when the request includes an unknown TLV. > > > > > Unknown source is not same as receiving malformed Tlv or unsupported tlv. > > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers. > > > > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does > > the responder > > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it? > > If received from unknown source, most vendors drop the packet. > > > > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > 1) Which return code to send when source/destination identifiers are wrong or drop the request. > > As said above, it should be dropped, if the source is unknown. > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > > > > Best, > > > Zhenlong > > > > > >> -----Original Message----- > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >> Sent: Wednesday, July 27, 2011 12:56 AM > > >> To: Zhenlong Cui > > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > >> > > >> Zhenlong, > > >> > > >> Q-1: See RFC 4379, where these regitry entries are derived from. > > >> RFC 4379 sets up a number of registries - including the TLV > > >> registry - and defines explicitly how to handle unknown TLV > > >> types in section 3, in two very obscure paragraphs on page > > >> 10, just before section 3.1. > > >> > > >> Q-2: "ingress port" is not correct - thanks for spotting this > > >> cut-and-paste duplication error. > > >> > > >> -- > > >> Eric > > >> > > >> -----Original Message----- > > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > >> Sent: Tuesday, July 12, 2011 5:20 AM > > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > >> > > >> Dear Authors, > > >> > > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > > >> > > >> Question 1: > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > >>>>> request received?) or drop the packet. > > >>>>> > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > >>>>> EG > screaming into the night. What does one do when one gets > > >>>>> EG > something either not recognizably intended for one, or not > > >>>>> EG > from a source that one recognizes? From a security point > > >>>>> EG > of view, we cannot require an implementation to reply to > > >>>>> EG > the requester in this case (this is an attack vector for > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > >>>>> > > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One > > >> or > > >> more of the TLVs was not understood)? Can this way two answers be generated? > > >> > > >> > > >> Question 2: > > >> In section 2.1.1, Is below("ingress port") correct? > > >> > > >> Egress IF_Num identifies the ingress port on the target node. A > > >> value of 0 indicates that the port is not part of the identifier. > > >> > > >> > > >> Best, > > >> zhenlong > > >> > > >>> -----Original Message----- > > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > > >>> Sent: Monday, June 27, 2011 8:04 PM > > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > >>> > > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > > >>> > > >>> Types are defined below; Length is the length of the Value field in > > >>> octets. The Value field depends on the Type; it is zero padded to > > >>> align to a 4-octet boundary. > > >>> > > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is > > determined > > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your > > argument > > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information > > >> is > > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure > > >> of > > >>> each TLV to extract the value instead of applying the simple rule above. > > >>> > > >>> > > >>> Best, > > >>> > > >>> Rolf > > >>> > > >>> > > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >>>> Sent: Montag, 27. Juni 2011 12:42 > > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > >>>> cv@tools.ietf.org > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > >>>> cv > > >>>> > > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > > >>>> an errata? > > >>>> > > >>>> TLVs are meant to follow each other, where the beginning of the > > >>>> next TLV is determined by the length of the current TLV - hence > > >>>> it is not correct to specify any content as having any value at > > >>>> all if it is beyond the end of the TLV. > > >>>> > > >>>> -----Original Message----- > > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > >>>> Sent: Monday, June 27, 2011 5:06 AM > > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > >>>> cv@tools.ietf.org > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > >>>> cv > > >>>> Importance: High > > >>>> > > >>>> Hi Eric, > > >>>> > > >>>> just one more to follow up. You say: > > >>>> > > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > >>>>> EG > even if the last two octets "Must be Zero"). The length of > > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > > >>>> > > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > >>>> included in the length of the sub-TLVs. Why are they included here? > > >>>> > > >>>> Best, > > >>>> > > >>>> Rolf > > >>>> > > >>>> > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > >>>> London W3 6BL | Registered in England 2832014 > > >>>> > > >>>> > > >>>>> > > >>>>> EG > Apparently. > > >>>>> > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > >>>>> request received?) or drop the packet. > > >>>>> > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > >>>>> EG > screaming into the night. What does one do when one gets > > >>>>> EG > something either not recognizably intended for one, or not > > >>>>> EG > from a source that one recognizes? From a security point > > >>>>> EG > of view, we cannot require an implementation to reply to > > >>>>> EG > the requester in this case (this is an attack vector for > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > >>>>> > > >>>>> Using the per-interface model and say the DSMAP TLV did not match the > > >>>>> ingress IF identifier, then should this request frame be dropped? > > >>>>> Should we reply to the requestor? Can this way two answers be > > >>>>> generated? > > >>>>> > > >>>>> Nit (section 2.1): s/mpls/MPLS/ > > >>>>> > > >>>>> EG > Thanks. > > >>>>> > > >>>>> > > >>>>> Best, > > >>>>> > > >>>>> > > >>>>> > > >>>>> Rolf > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > >>>>> London W3 6BL | Registered in England 2832014 > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >>>> Behalf > > >>>>> Of > > >>>>>> Loa Andersson > > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > >>>>> Ross > > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > >>>> cv > > >>>>>> > > >>>>>> Working Group. > > >>>>>> > > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > >>>>>> after wg last call and published version -04 of the document. > > >>>>>> > > >>>>>> A document detailing how the comments have been addressed will be > > >>>>>> found at: > > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > > >>>>>> > > >>>>>> This is to start a working group call to verify that all comments > > >>>>>> been adequately addressed. Please send your comments to the > > >>>>>> mpls working group mailing list before June 24th. > > >>>>>> > > >>>>>> Loa > > >>>>>> on behalf of the MPLS wg co-chairs > > >>>>>> > > >>>>>> -- > > >>>>>> > > >>>>>> > > >>>>>> Loa Andersson email: > > >>>>> loa.andersson@ericsson.com > > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > > >>>>>> +46 767 72 92 13 > > >>>>>> _______________________________________________ > > >>>>>> mpls mailing list > > >>>>>> mpls@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > > >>>>> _______________________________________________ > > >>>>> mpls mailing list > > >>>>> mpls@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mpls > > >>> _______________________________________________ > > >>> mpls mailing list > > >>> mpls@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From DanielC@orckit.com Thu Jul 28 10:15:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667C21F8BC2 for ; Thu, 28 Jul 2011 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN1YMcqi2mbJ for ; Thu, 28 Jul 2011 10:15:10 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id D8AEE21F8BC3 for ; Thu, 28 Jul 2011 10:15:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 20:15:07 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHg References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> From: "Daniel Cohn" To: "Greg Mirsky" Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:15:11 -0000 True enough in general. But in this particular example, there is nothing = suggested by this draft that requires huge implementation efforts or = paradigm changes. So I fail to see why we should settle for less = functionality than is available in existing transport networks. DC=20 -----Original Message----- From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Thursday, July 28, 2011 1:00 PM To: Daniel Cohn Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; = ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro = Gerardo; mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Daniel, I think that while we're building MPLS-TP to be suited for the transport we need to remember that it, as Neil pointed out on number of occasions, is not BOS layer and doesn't put bits on a wire. Thus it has characteristic that makes it different from other layers of a transport network and, I think, as result not all existing concepts of transport are applicable to packet layer realized by MPLS-TP. Regards, Greg On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > Hi Eric, > > One of the reasons why we need SD in TP is because TP is supposed to > provide the same "look and feel" of existing transport networks, as > specified in the TP requirements document. > Transport networks technologies have long supported the distinction > between "degraded" and " faulty". In particular, protection = technologies > in use have this distinction built into the innermost recedes of their > protocols. > Even in the TP requirements didn't spell this out, I think it would be = a > mistake not to take advantage of years of experience in transport > networks OAM. > > Regards, > > Daniel > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 11:12 AM > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Greg- > =A0There is a difference between SF and SD. =A0Converting SD into Down > means that it will be interpreted exactly the same as SF, and if = that's > the case why have SD at all? =A0If SD is necessary it must be somehow > different from SD. > > All- > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems = that > this idea of propagating server layer SD up into TP is being done > because there's no good way to do SD entirely within the TP layer. = =A0I > suspect that if there were a way to do SD within the TP layer that = made > everyone happy, we wouldn't have the approach propsed in > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for this > draft is: > > =A0- we must have SD in TP because it is possible to do in other > technologies > =A0- it is not possible to SD entirely within TP > =A0- therefore we must get SD from somewhere else > > is a reasonable one. =A0If we do that, where do we stop? =A0Should we > propagate information about signal quality up to TCP so it can adjust > its windows according? =A0(please note that this is intended to be a > reductio ad absurdum question and not a serious one. :) ) > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Greg Mirsky >> Sent: Wednesday, July 27, 2011 2:08 PM >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Dear Authors and All, >> I think that it is function of the PHY layer to detect SD condition > and >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > Physical >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> measurement, in my view, is addressing the issue. >> >> Regards, >> Greg > > From c-sai@bx.jp.nec.com Thu Jul 28 10:23:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73F921F8BD6 for ; Thu, 28 Jul 2011 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA5GYNWlVTwj for ; Thu, 28 Jul 2011 10:23:09 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE721F8BD1 for ; Thu, 28 Jul 2011 10:23:05 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6SHMmC8011569; Fri, 29 Jul 2011 02:22:48 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6SHMmQ10663; Fri, 29 Jul 2011 02:22:48 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6SHMllL013290; Fri, 29 Jul 2011 02:22:47 +0900 (JST) Received: from kameyata.jp.nec.com ([10.26.220.29] [10.26.220.29]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-98275; Fri, 29 Jul 2011 02:22:24 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTPA id BT-MMP-166; Fri, 29 Jul 2011 02:22:23 +0900 From: "Zhenlong Cui" To: "'Eric Gray'" , "'Sam Aldrin'" References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd><60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp><5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com><9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> <662500A437844CE68AC30DB3B9E41C40@nsl.ad.nec.co.jp> Date: Fri, 29 Jul 2011 02:22:21 +0900 Message-ID: <5FF7D74540DE4099930540A97AA013CE@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <662500A437844CE68AC30DB3B9E41C40@nsl.ad.nec.co.jp> Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQAAIYSLAADzDIUAAmgkLg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:23:11 -0000 Hi, Eric Small correction to the mail I just sent: ... "protocol redundancy is _not_ what I had in mind when I wrote my original mail." ... Best Zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Zhenlong Cui > Sent: Friday, July 29, 2011 2:04 AM > To: 'Eric Gray'; 'Sam Aldrin' > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Hi Eric, > > Sorry, protocol redundancy is what I had in mind when I wrote my original mail. > > I didn't understand why to define a different behavior for "destination node identifier" and "destination interface > identifier". > > In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface > MIP case). > > I do understand the draft contains no such requirements for the for P2MP case. > Essentially, the requestor receiving multiple responses which include different return code may not be a problem. > > Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here. > > > Thanks for your response. > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Thursday, July 28, 2011 12:45 AM > > To: Zhenlong Cui; 'Sam Aldrin' > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > Not sure why you think the protocol redundancy is necessary, > > or even a good idea. > > > > The DSMAP TLV as defined allows specification of an interface. > > > > Asking for a potentially new TLV that will also provide this > > information in the event that one is unable to handle, read or > > interpret the DSMAP TLV is pointless. If one cannot use one > > TLV, the chances are very good that one cannot use a newer one > > either. > > > > -----Original Message----- > > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > Sent: Wednesday, July 27, 2011 10:46 AM > > To: 'Sam Aldrin'; Eric Gray > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Importance: High > > > > Hi Sam and Eric, > > > > Ok, I understand that the issue of unknown TLVs is outside the scope of this document. > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > > 1) Which return code to send when source/destination identifiersare wrong or drop the request. > > > As said above, it should be dropped, if the source is unknown. > > > > OK, I think this is clear now: > > - A responder will drop requests from an unknown source. > > - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.) > > > > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below. > > The information collected MUST include identifiers related to the nodes and interfaces composing that route. > > > > I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity, > > therefore they > > should have the same behavior in the responder. > > > > So, my suggestions regarding these issues are as follows. > > 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. > > 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV. > > > > > > Best, > > Zhenlong > > > > > -----Original Message----- > > > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > > > Sent: Wednesday, July 27, 2011 6:29 AM > > > To: Zhenlong Cui > > > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > > > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft. > > > Having said that, please find responses inline. > > > > > > Sam > > > > > > Sent from my iPad > > > > > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: > > > > > > > Hi Eric, > > > > > > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security > problem > > > with > > > > responding. > > > > On the other hand, you say that you should send a reply when the request includes an unknown TLV. > > > > > > > Unknown source is not same as receiving malformed Tlv or unsupported tlv. > > > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers. > > > > > > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does > > > the responder > > > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it? > > > If received from unknown source, most vendors drop the packet. > > > > > > > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > > 1) Which return code to send when source/destination identifiers are wrong or drop the request. > > > As said above, it should be dropped, if the source is unknown. > > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > > > > > > > Best, > > > > Zhenlong > > > > > > > >> -----Original Message----- > > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > >> Sent: Wednesday, July 27, 2011 12:56 AM > > > >> To: Zhenlong Cui > > > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > >> > > > >> Zhenlong, > > > >> > > > >> Q-1: See RFC 4379, where these regitry entries are derived from. > > > >> RFC 4379 sets up a number of registries - including the TLV > > > >> registry - and defines explicitly how to handle unknown TLV > > > >> types in section 3, in two very obscure paragraphs on page > > > >> 10, just before section 3.1. > > > >> > > > >> Q-2: "ingress port" is not correct - thanks for spotting this > > > >> cut-and-paste duplication error. > > > >> > > > >> -- > > > >> Eric > > > >> > > > >> -----Original Message----- > > > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > > >> Sent: Tuesday, July 12, 2011 5:20 AM > > > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > >> > > > >> Dear Authors, > > > >> > > > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > > > >> > > > >> Question 1: > > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > > >>>>> request received?) or drop the packet. > > > >>>>> > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > >>>>> EG > screaming into the night. What does one do when one gets > > > >>>>> EG > something either not recognizably intended for one, or not > > > >>>>> EG > from a source that one recognizes? From a security point > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > >>>>> EG > the requester in this case (this is an attack vector for > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > >>>>> > > > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the > requestor(One > > > >> or > > > >> more of the TLVs was not understood)? Can this way two answers be generated? > > > >> > > > >> > > > >> Question 2: > > > >> In section 2.1.1, Is below("ingress port") correct? > > > >> > > > >> Egress IF_Num identifies the ingress port on the target node. A > > > >> value of 0 indicates that the port is not part of the identifier. > > > >> > > > >> > > > >> Best, > > > >> zhenlong > > > >> > > > >>> -----Original Message----- > > > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > > > >>> Sent: Monday, June 27, 2011 8:04 PM > > > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > > >>> > > > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > > > >>> > > > >>> Types are defined below; Length is the length of the Value field in > > > >>> octets. The Value field depends on the Type; it is zero padded to > > > >>> align to a 4-octet boundary. > > > >>> > > > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV > is > > > determined > > > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow > your > > > argument > > > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information > > > >> is > > > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure > > > >> of > > > >>> each TLV to extract the value instead of applying the simple rule above. > > > >>> > > > >>> > > > >>> Best, > > > >>> > > > >>> Rolf > > > >>> > > > >>> > > > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > >>>> Sent: Montag, 27. Juni 2011 12:42 > > > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > >>>> cv@tools.ietf.org > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > >>>> cv > > > >>>> > > > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > > > >>>> an errata? > > > >>>> > > > >>>> TLVs are meant to follow each other, where the beginning of the > > > >>>> next TLV is determined by the length of the current TLV - hence > > > >>>> it is not correct to specify any content as having any value at > > > >>>> all if it is beyond the end of the TLV. > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > > >>>> Sent: Monday, June 27, 2011 5:06 AM > > > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > >>>> cv@tools.ietf.org > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > >>>> cv > > > >>>> Importance: High > > > >>>> > > > >>>> Hi Eric, > > > >>>> > > > >>>> just one more to follow up. You say: > > > >>>> > > > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > >>>>> EG > even if the last two octets "Must be Zero"). The length of > > > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > > > >>>> > > > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > > >>>> included in the length of the sub-TLVs. Why are they included here? > > > >>>> > > > >>>> Best, > > > >>>> > > > >>>> Rolf > > > >>>> > > > >>>> > > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > >>>> London W3 6BL | Registered in England 2832014 > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> EG > Apparently. > > > >>>>> > > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > > >>>>> request received?) or drop the packet. > > > >>>>> > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > >>>>> EG > screaming into the night. What does one do when one gets > > > >>>>> EG > something either not recognizably intended for one, or not > > > >>>>> EG > from a source that one recognizes? From a security point > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > >>>>> EG > the requester in this case (this is an attack vector for > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > >>>>> > > > >>>>> Using the per-interface model and say the DSMAP TLV did not match the > > > >>>>> ingress IF identifier, then should this request frame be dropped? > > > >>>>> Should we reply to the requestor? Can this way two answers be > > > >>>>> generated? > > > >>>>> > > > >>>>> Nit (section 2.1): s/mpls/MPLS/ > > > >>>>> > > > >>>>> EG > Thanks. > > > >>>>> > > > >>>>> > > > >>>>> Best, > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Rolf > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > >>>>> London W3 6BL | Registered in England 2832014 > > > >>>>> > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > >>>> Behalf > > > >>>>> Of > > > >>>>>> Loa Andersson > > > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > > > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > > >>>>> Ross > > > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > > > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > >>>> cv > > > >>>>>> > > > >>>>>> Working Group. > > > >>>>>> > > > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > > >>>>>> after wg last call and published version -04 of the document. > > > >>>>>> > > > >>>>>> A document detailing how the comments have been addressed will be > > > >>>>>> found at: > > > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > > > >>>>>> > > > >>>>>> This is to start a working group call to verify that all comments > > > >>>>>> been adequately addressed. Please send your comments to the > > > >>>>>> mpls working group mailing list before June 24th. > > > >>>>>> > > > >>>>>> Loa > > > >>>>>> on behalf of the MPLS wg co-chairs > > > >>>>>> > > > >>>>>> -- > > > >>>>>> > > > >>>>>> > > > >>>>>> Loa Andersson email: > > > >>>>> loa.andersson@ericsson.com > > > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > > > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > > > >>>>>> +46 767 72 92 13 > > > >>>>>> _______________________________________________ > > > >>>>>> mpls mailing list > > > >>>>>> mpls@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>>>> _______________________________________________ > > > >>>>> mpls mailing list > > > >>>>> mpls@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>> _______________________________________________ > > > >>> mpls mailing list > > > >>> mpls@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Thu Jul 28 10:39:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5635E8012 for ; Thu, 28 Jul 2011 10:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkPnH3Az1-ZS for ; Thu, 28 Jul 2011 10:39:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 469885E8014 for ; Thu, 28 Jul 2011 10:39:38 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6SHdQh6021012; Thu, 28 Jul 2011 12:39:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 28 Jul 2011 13:39:21 -0400 From: Eric Gray To: Zhenlong Cui , "'Sam Aldrin'" Date: Thu, 28 Jul 2011 13:39:19 -0400 Thread-Topic: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQAAIYSLAADzDIUAAmgkLgAABh89A= Message-ID: References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd><60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp><5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com><9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> <662500A437844CE68AC30DB3B9E41C40@nsl.ad.nec.co.jp> <5FF7D74540DE4099930540A97AA013CE@nsl.ad.nec.co.jp> In-Reply-To: <5FF7D74540DE4099930540A97AA013CE@nsl.ad.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:39:39 -0000 Zhenlong, I'm not sure what you mean by a different behavior between node ID and interface ID. There is certainly a minimum difference associated with what box-local entity it is that is logically responsible for replying to a message. But it seems as if we have converged in this discussion. Thanks for taking the time to review and discuss the draft! -- E -----Original Message----- From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] Sent: Thursday, July 28, 2011 1:22 PM To: Eric Gray; 'Sam Aldrin' Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 Importance: High Hi, Eric Small correction to the mail I just sent: ... "protocol redundancy is _not_ what I had in mind when I wrote my origin= al mail." ... Best Zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Z= henlong Cui > Sent: Friday, July 29, 2011 2:04 AM > To: 'Eric Gray'; 'Sam Aldrin' > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Hi Eric, > > Sorry, protocol redundancy is what I had in mind when I wrote my original= mail. > > I didn't understand why to define a different behavior for "destination n= ode identifier" and "destination interface > identifier". > > In a P2MP scenario, an intermediate node may send multiple responses Whic= h include different return codes (per-interface > MIP case). > > I do understand the draft contains no such requirements for the for P2MP = case. > Essentially, the requestor receiving multiple responses which include dif= ferent return code may not be a problem. > > Lastly, I think this issue might be discussed in the draft-farrel-mpls- t= p-mip-mep-map, not here. > > > Thanks for your response. > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Thursday, July 28, 2011 12:45 AM > > To: Zhenlong Cui; 'Sam Aldrin' > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > Not sure why you think the protocol redundancy is necessary, > > or even a good idea. > > > > The DSMAP TLV as defined allows specification of an interface. > > > > Asking for a potentially new TLV that will also provide this > > information in the event that one is unable to handle, read or > > interpret the DSMAP TLV is pointless. If one cannot use one > > TLV, the chances are very good that one cannot use a newer one > > either. > > > > -----Original Message----- > > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > Sent: Wednesday, July 27, 2011 10:46 AM > > To: 'Sam Aldrin'; Eric Gray > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Importance: High > > > > Hi Sam and Eric, > > > > Ok, I understand that the issue of unknown TLVs is outside the scope of= this document. > > > > > > Lastly, I suggest that add some mention to this draft regarding res= ponder's behavior for new TLV. > > > > 1) Which return code to send when source/destination identifiersare= wrong or drop the request. > > > As said above, it should be dropped, if the source is unknown. > > > > OK, I think this is clear now: > > - A responder will drop requests from an unknown source. > > - A responder will drop requests in case of destination identifier mism= atch. (as defined in section 4.2.3.) > > > > > > 2) Which return code to send when ingress if_num/egress if_num of D= SMAP TLV are wrong or drop the request. > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > Regarding the identifiers of nodes and interfaces for route trace which= are defined in RFC 5860 as below. > > The information collected MUST include identifiers related to the nodes= and interfaces composing that route. > > > > I think "destination node identifier" and "destination interface identi= fier" are composed for one maintenance entity, > > therefore they > > should have the same behavior in the responder. > > > > So, my suggestions regarding these issues are as follows. > > 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. > > 2) If not, the "interface identifier" should be included in the Destina= tion identifier TLV, or one might define a new TLV. > > > > > > Best, > > Zhenlong > > > > > -----Original Message----- > > > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > > > Sent: Wednesday, July 27, 2011 6:29 AM > > > To: Zhenlong Cui > > > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.i= etf.org > > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > > > As Eric said in earlier email, these questions are more related to RF= C4379 and not just this draft. > > > Having said that, please find responses inline. > > > > > > Sam > > > > > > Sent from my iPad > > > > > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wro= te: > > > > > > > Hi Eric, > > > > > > > > I remember you said earlier that you should drop the packet from un= known source nodes, because there is a security > problem > > > with > > > > responding. > > > > On the other hand, you say that you should send a reply when the re= quest includes an unknown TLV. > > > > > > > Unknown source is not same as receiving malformed Tlv or unsupported = tlv. > > > > I think if the responder receives a request it checks the type of t= he TLV before it checks the identifiers. > > > > > > > > So, my question is "if the responder receives a request from an unk= nown source node that includes an unknown TLV, does > > > the responder > > > > have to reply to the unknown source node?". If yes, this has the se= curity problem you mentioned earlier, doesn't it? > > > If received from unknown source, most vendors drop the packet. > > > > > > > > > > > > Lastly, I suggest that add some mention to this draft regarding res= ponder's behavior for new TLV. > > > > 1) Which return code to send when source/destination identifiers ar= e wrong or drop the request. > > > As said above, it should be dropped, if the source is unknown. > > > > 2) Which return code to send when ingress if_num/egress if_num of D= SMAP TLV are wrong or drop the request. > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > > > > > > > Best, > > > > Zhenlong > > > > > > > >> -----Original Message----- > > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > >> Sent: Wednesday, July 27, 2011 12:56 AM > > > >> To: Zhenlong Cui > > > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-= 05 > > > >> > > > >> Zhenlong, > > > >> > > > >> Q-1: See RFC 4379, where these regitry entries are derived from. > > > >> RFC 4379 sets up a number of registries - including the TLV > > > >> registry - and defines explicitly how to handle unknown TLV > > > >> types in section 3, in two very obscure paragraphs on page > > > >> 10, just before section 3.1. > > > >> > > > >> Q-2: "ingress port" is not correct - thanks for spotting this > > > >> cut-and-paste duplication error. > > > >> > > > >> -- > > > >> Eric > > > >> > > > >> -----Original Message----- > > > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > > >> Sent: Tuesday, July 12, 2011 5:20 AM > > > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > >> > > > >> Dear Authors, > > > >> > > > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > > > >> > > > >> Question 1: > > > >>>>> Which return code to send when identifiers are wrong (Malformed= echo > > > >>>>> request received?) or drop the packet. > > > >>>>> > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > >>>>> EG > screaming into the night. What does one do when one gets > > > >>>>> EG > something either not recognizably intended for one, or not > > > >>>>> EG > from a source that one recognizes? From a security point > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > >>>>> EG > the requester in this case (this is an attack vector for > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > >>>>> > > > >> If the "type" of identifier TLV is incorrect, then should this req= uest frame be dropped? Should we reply to the > requestor(One > > > >> or > > > >> more of the TLVs was not understood)? Can this way two answers be = generated? > > > >> > > > >> > > > >> Question 2: > > > >> In section 2.1.1, Is below("ingress port") correct? > > > >> > > > >> Egress IF_Num identifies the ingress port on the target node. A > > > >> value of 0 indicates that the port is not part of the identifier= . > > > >> > > > >> > > > >> Best, > > > >> zhenlong > > > >> > > > >>> -----Original Message----- > > > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf Of Rolf Winter > > > >>> Sent: Monday, June 27, 2011 8:04 PM > > > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@too= ls.ietf.org > > > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-de= mand-cv > > > >>> > > > >>> I think that's OK, since the value is not beyond but within the T= LV. Taken from 4379: > > > >>> > > > >>> Types are defined below; Length is the length of the Value field = in > > > >>> octets. The Value field depends on the Type; it is zero padded t= o > > > >>> align to a 4-octet boundary. > > > >>> > > > >>> That means the length is the length of the actual value (excludin= g the padding). So the beginning of the next TLV > is > > > determined > > > >>> by the length plus a value that makes it align on a 4-octet bound= ary (which of course can be 0). I cannot follow > your > > > argument > > > >>> why this is not correct. I am sure I am missing something trivial= , so sorry for spamming the list. But all information > > > >> is > > > >>> encoded in the packet (plus the simple rule quoted above). Otherw= ise, a node needs to understand the internal structure > > > >> of > > > >>> each TLV to extract the value instead of applying the simple rule= above. > > > >>> > > > >>> > > > >>> Best, > > > >>> > > > >>> Rolf > > > >>> > > > >>> > > > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d, London W3 6BL | Registered in England 2832014 > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > >>>> Sent: Montag, 27. Juni 2011 12:42 > > > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > >>>> cv@tools.ietf.org > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-d= emand- > > > >>>> cv > > > >>>> > > > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > > > >>>> an errata? > > > >>>> > > > >>>> TLVs are meant to follow each other, where the beginning of the > > > >>>> next TLV is determined by the length of the current TLV - hence > > > >>>> it is not correct to specify any content as having any value at > > > >>>> all if it is beyond the end of the TLV. > > > >>>> > > > >>>> -----Original Message----- > > > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > > >>>> Sent: Monday, June 27, 2011 5:06 AM > > > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > >>>> cv@tools.ietf.org > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-d= emand- > > > >>>> cv > > > >>>> Importance: High > > > >>>> > > > >>>> Hi Eric, > > > >>>> > > > >>>> just one more to follow up. You say: > > > >>>> > > > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words lo= ng, > > > >>>>> EG > even if the last two octets "Must be Zero"). The length o= f > > > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was ma= de > > > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > > > >>>> > > > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to b= e > > > >>>> included in the length of the sub-TLVs. Why are they included he= re? > > > >>>> > > > >>>> Best, > > > >>>> > > > >>>> Rolf > > > >>>> > > > >>>> > > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Ro= ad, > > > >>>> London W3 6BL | Registered in England 2832014 > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> EG > Apparently. > > > >>>>> > > > >>>>> Which return code to send when identifiers are wrong (Malformed= echo > > > >>>>> request received?) or drop the packet. > > > >>>>> > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > >>>>> EG > screaming into the night. What does one do when one gets > > > >>>>> EG > something either not recognizably intended for one, or not > > > >>>>> EG > from a source that one recognizes? From a security point > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > >>>>> EG > the requester in this case (this is an attack vector for > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > >>>>> > > > >>>>> Using the per-interface model and say the DSMAP TLV did not mat= ch the > > > >>>>> ingress IF identifier, then should this request frame be droppe= d? > > > >>>>> Should we reply to the requestor? Can this way two answers be > > > >>>>> generated? > > > >>>>> > > > >>>>> Nit (section 2.1): s/mpls/MPLS/ > > > >>>>> > > > >>>>> EG > Thanks. > > > >>>>> > > > >>>>> > > > >>>>> Best, > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Rolf > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria R= oad, > > > >>>>> London W3 6BL | Registered in England 2832014 > > > >>>>> > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > >>>> Behalf > > > >>>>> Of > > > >>>>>> Loa Andersson > > > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > > > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.= org; > > > >>>>> Ross > > > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > > > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-dem= and- > > > >>>> cv > > > >>>>>> > > > >>>>>> Working Group. > > > >>>>>> > > > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated th= e ID > > > >>>>>> after wg last call and published version -04 of the document. > > > >>>>>> > > > >>>>>> A document detailing how the comments have been addressed will= be > > > >>>>>> found at: > > > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > > > >>>>>> > > > >>>>>> This is to start a working group call to verify that all comme= nts > > > >>>>>> been adequately addressed. Please send your comments to the > > > >>>>>> mpls working group mailing list before June 24th. > > > >>>>>> > > > >>>>>> Loa > > > >>>>>> on behalf of the MPLS wg co-chairs > > > >>>>>> > > > >>>>>> -- > > > >>>>>> > > > >>>>>> > > > >>>>>> Loa Andersson email: > > > >>>>> loa.andersson@ericsson.com > > > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > > > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > > > >>>>>> +46 767 72 92 13 > > > >>>>>> _______________________________________________ > > > >>>>>> mpls mailing list > > > >>>>>> mpls@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>>>> _______________________________________________ > > > >>>>> mpls mailing list > > > >>>>> mpls@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>> _______________________________________________ > > > >>> mpls mailing list > > > >>> mpls@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eosborne@cisco.com Thu Jul 28 11:05:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49EA11E80C9 for ; Thu, 28 Jul 2011 11:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8HXvAbezNuF for ; Thu, 28 Jul 2011 11:05:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D064311E807B for ; Thu, 28 Jul 2011 11:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=5316; q=dns/txt; s=iport; t=1311876301; x=1313085901; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NlRuJwiCKzFH65LMhqsDVNNxSkfBd56vglb7hevh+5Y=; b=EqPQp83xIPcZP7+QtimCACjVqLewzElAwhH7S2tL94L9hPdyhS0OXQDt DpQu/L5nmA75+8Y+p9Qg46Mkj+gfu4xZ1C0hXdlqTtT9Gwy2taDYTq4gv /nTzoVWY5Bk0mBBWHxDMAAqtHfW8DfdKMMtNCc0i/oPjtkvjKYY10+8u+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAN+jMU6tJXG//2dsb2JhbAA0AQEBAQIBFAEhTwUHBQIBCREEAQEBCgYjAQYBExIpDggBAQUBFgwbl2uPT3eIfKQ4nkWFYl8EhyovkDCEW4cX X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7476811" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 18:05:00 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6SI4xVx015344; Thu, 28 Jul 2011 18:04:59 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 13:05:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 13:04:58 -0500 Message-ID: In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAAHcgEA= References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> From: "Eric Osborne (eosborne)" To: "Daniel Cohn" , "Greg Mirsky" X-OriginalArrivalTime: 28 Jul 2011 18:05:00.0117 (UTC) FILETIME=[DDD24850:01CC4D50] Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:05:01 -0000 I don't quite buy "settle for less functionality". The point I made in = my last email is that the SD functionality you want just isn't = *relevant* to MPLS. The concept of degradation at the packet level is = pretty slippery. There've been ECN-type proposals over the years, but = they never went anywhere and certainly don't exist in MPLS. If we had = ECN in MPLS then I would agree that it could be mapped to SD in some = fashion, but we don't. Deciding that you need an unapplicable = technology and then shoehorning something else into acting as a = substitute is, IMO, a mistake. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Thursday, July 28, 2011 1:15 PM > To: Greg Mirsky > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > True enough in general. But in this particular example, there is = nothing > suggested by this draft that requires huge implementation efforts or > paradigm changes. So I fail to see why we should settle for less > functionality than is available in existing transport networks. >=20 > DC >=20 > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, July 28, 2011 1:00 PM > To: Daniel Cohn > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the = transport > we need to remember that it, as Neil pointed out on number of = occasions, > is not BOS layer and doesn't put bits on a wire. Thus it has > characteristic that makes it different from other layers of a = transport > network and, I think, as result not all existing concepts of transport = are > applicable to packet layer realized by MPLS-TP. >=20 > Regards, > Greg >=20 > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn = wrote: > > Hi Eric, > > > > One of the reasons why we need SD in TP is because TP is supposed to > > provide the same "look and feel" of existing transport networks, as > > specified in the TP requirements document. > > Transport networks technologies have long supported the distinction > > between "degraded" and " faulty". In particular, protection > > technologies in use have this distinction built into the innermost > > recedes of their protocols. > > Even in the TP requirements didn't spell this out, I think it would = be > > a mistake not to take advantage of years of experience in transport > > networks OAM. > > > > Regards, > > > > Daniel > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, July 28, 2011 11:12 AM > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Greg- > > =A0There is a difference between SF and SD. =A0Converting SD into = Down > > means that it will be interpreted exactly the same as SF, and if > > that's the case why have SD at all? =A0If SD is necessary it must be > > somehow different from SD. > > > > All- > > > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems = that > > this idea of propagating server layer SD up into TP is being done > > because there's no good way to do SD entirely within the TP layer. = =A0I > > suspect that if there were a way to do SD within the TP layer that > > made everyone happy, we wouldn't have the approach propsed in > > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for = this > > draft is: > > > > =A0- we must have SD in TP because it is possible to do in other > > technologies > > =A0- it is not possible to SD entirely within TP > > =A0- therefore we must get SD from somewhere else > > > > is a reasonable one. =A0If we do that, where do we stop? =A0Should = we > > propagate information about signal quality up to TCP so it can = adjust > > its windows according? =A0(please note that this is intended to be a > > reductio ad absurdum question and not a serious one. :) ) > > > > > > > > eric > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf > > Of > >> Greg Mirsky > >> Sent: Wednesday, July 27, 2011 2:08 PM > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro = Alessandro > >> Gerardo; mpls@ietf.org > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Dear Authors and All, > >> I think that it is function of the PHY layer to detect SD condition > > and > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > Physical > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > >> measurement, in my view, is addressing the issue. > >> > >> Regards, > >> Greg > > > > From DanielC@orckit.com Thu Jul 28 11:11:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4949311E810F for ; Thu, 28 Jul 2011 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrXlH4WhKA0A for ; Thu, 28 Jul 2011 11:11:28 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id A925D11E807B for ; Thu, 28 Jul 2011 11:11:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 21:11:21 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED829D@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAAHcgEAAAD3gsA== References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> From: "Daniel Cohn" To: "Eric Osborne (eosborne)" , "Greg Mirsky" Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:11:29 -0000 Eric, I believe degradation is relevant to any technology where errors can = occur (i.e. all kinds). ECN reports congestion which is completely = orthogonal to the physical error condition we want to detect and correct = via SD detection and report. So I don=92t think ECN-like proposals are = relevant to the discussion. DC -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, July 28, 2011 2:05 PM To: Daniel Cohn; Greg Mirsky Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; = yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 I don't quite buy "settle for less functionality". The point I made in = my last email is that the SD functionality you want just isn't = *relevant* to MPLS. The concept of degradation at the packet level is = pretty slippery. There've been ECN-type proposals over the years, but = they never went anywhere and certainly don't exist in MPLS. If we had = ECN in MPLS then I would agree that it could be mapped to SD in some = fashion, but we don't. Deciding that you need an unapplicable = technology and then shoehorning something else into acting as a = substitute is, IMO, a mistake. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Thursday, July 28, 2011 1:15 PM > To: Greg Mirsky > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > True enough in general. But in this particular example, there is = nothing > suggested by this draft that requires huge implementation efforts or > paradigm changes. So I fail to see why we should settle for less > functionality than is available in existing transport networks. >=20 > DC >=20 > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, July 28, 2011 1:00 PM > To: Daniel Cohn > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the = transport > we need to remember that it, as Neil pointed out on number of = occasions, > is not BOS layer and doesn't put bits on a wire. Thus it has > characteristic that makes it different from other layers of a = transport > network and, I think, as result not all existing concepts of transport = are > applicable to packet layer realized by MPLS-TP. >=20 > Regards, > Greg >=20 > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn = wrote: > > Hi Eric, > > > > One of the reasons why we need SD in TP is because TP is supposed to > > provide the same "look and feel" of existing transport networks, as > > specified in the TP requirements document. > > Transport networks technologies have long supported the distinction > > between "degraded" and " faulty". In particular, protection > > technologies in use have this distinction built into the innermost > > recedes of their protocols. > > Even in the TP requirements didn't spell this out, I think it would = be > > a mistake not to take advantage of years of experience in transport > > networks OAM. > > > > Regards, > > > > Daniel > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, July 28, 2011 11:12 AM > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Greg- > > =A0There is a difference between SF and SD. =A0Converting SD into = Down > > means that it will be interpreted exactly the same as SF, and if > > that's the case why have SD at all? =A0If SD is necessary it must be > > somehow different from SD. > > > > All- > > > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems = that > > this idea of propagating server layer SD up into TP is being done > > because there's no good way to do SD entirely within the TP layer. = =A0I > > suspect that if there were a way to do SD within the TP layer that > > made everyone happy, we wouldn't have the approach propsed in > > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for = this > > draft is: > > > > =A0- we must have SD in TP because it is possible to do in other > > technologies > > =A0- it is not possible to SD entirely within TP > > =A0- therefore we must get SD from somewhere else > > > > is a reasonable one. =A0If we do that, where do we stop? =A0Should = we > > propagate information about signal quality up to TCP so it can = adjust > > its windows according? =A0(please note that this is intended to be a > > reductio ad absurdum question and not a serious one. :) ) > > > > > > > > eric > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf > > Of > >> Greg Mirsky > >> Sent: Wednesday, July 27, 2011 2:08 PM > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro = Alessandro > >> Gerardo; mpls@ietf.org > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Dear Authors and All, > >> I think that it is function of the PHY layer to detect SD condition > > and > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > Physical > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > >> measurement, in my view, is addressing the issue. > >> > >> Regards, > >> Greg > > > > From eosborne@cisco.com Thu Jul 28 11:21:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE8C11E8078 for ; Thu, 28 Jul 2011 11:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc6ndw6V5xE4 for ; Thu, 28 Jul 2011 11:21:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4971D11E8118 for ; Thu, 28 Jul 2011 11:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=7261; q=dns/txt; s=iport; t=1311877298; x=1313086898; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SOLs+Efu/QMFaWcIgDY8YTmf+8mamGAWv9eFCpNkmZM=; b=FPzJo121izlitFvz9yIuS3rHRQiUMPR2eRXw3mFxj/m0GHfC+rQSpioS jHTj4JAPRcrWlvFhBp2Kl1HiaH+cSkkz8l5ZUOvO1jscz0QA9D+3OmZPK zyCwFGWj/AL1wK/e/oYu6zCUNx2suGbHstThYlnFwMNViwDiSZyF32nOi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAIenMU6tJXG8/2dsb2JhbAA0AQEBAQMUASFPDAUCAQkRBAEBAQoGIwEGARMSKQ4IAQEFARYMG5drj093rWCeRIViXwSHKi+QMIRbhxc X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7482406" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2011 18:21:37 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SILbd0029906; Thu, 28 Jul 2011 18:21:37 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 13:21:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 13:21:37 -0500 Message-ID: In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED829D@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAAHcgEAAAD3gsAAAZBFQ References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED829D@tlvmail1> From: "Eric Osborne (eosborne)" To: "Daniel Cohn" , "Greg Mirsky" X-OriginalArrivalTime: 28 Jul 2011 18:21:37.0244 (UTC) FILETIME=[3027C9C0:01CC4D53] Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:21:39 -0000 My point with ECN is that you need some sort of SD-detecting thingy at = the MPLS level in order to have SD in MPLS. The only 'degradation' I = can think of at the packet level is sporadic loss for a reason *not* due = to underlying transport issues, as that's handled by the server layer. = And the only reason for these drops that comes to mind is for QoS during = congestion. So I used ECN to mean "if you have packet drops which = originate at the TP layer, ECN=3D=3D1 else ECN=3D=3D0". I may have = confused the issue by oversimpifying with ECN, I hope this clears it up. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Thursday, July 28, 2011 2:11 PM > To: Eric Osborne (eosborne); Greg Mirsky > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Eric, >=20 > I believe degradation is relevant to any technology where errors can = occur > (i.e. all kinds). ECN reports congestion which is completely = orthogonal to > the physical error condition we want to detect and correct via SD > detection and report. So I don't think ECN-like proposals are relevant = to > the discussion. >=20 > DC >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 2:05 PM > To: Daniel Cohn; Greg Mirsky > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > I don't quite buy "settle for less functionality". The point I made = in my > last email is that the SD functionality you want just isn't *relevant* = to > MPLS. The concept of degradation at the packet level is pretty = slippery. > There've been ECN-type proposals over the years, but they never went > anywhere and certainly don't exist in MPLS. If we had ECN in MPLS = then I > would agree that it could be mapped to SD in some fashion, but we = don't. > Deciding that you need an unapplicable technology and then shoehorning > something else into acting as a substitute is, IMO, a mistake. >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Thursday, July 28, 2011 1:15 PM > > To: Greg Mirsky > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > True enough in general. But in this particular example, there is > > nothing suggested by this draft that requires huge implementation > > efforts or paradigm changes. So I fail to see why we should settle = for > > less functionality than is available in existing transport networks. > > > > DC > > > > -----Original Message----- > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > Sent: Thursday, July 28, 2011 1:00 PM > > To: Daniel Cohn > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Daniel, > > I think that while we're building MPLS-TP to be suited for the > > transport we need to remember that it, as Neil pointed out on number > > of occasions, is not BOS layer and doesn't put bits on a wire. Thus = it > > has characteristic that makes it different from other layers of a > > transport network and, I think, as result not all existing concepts = of > > transport are applicable to packet layer realized by MPLS-TP. > > > > Regards, > > Greg > > > > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn = wrote: > > > Hi Eric, > > > > > > One of the reasons why we need SD in TP is because TP is supposed = to > > > provide the same "look and feel" of existing transport networks, = as > > > specified in the TP requirements document. > > > Transport networks technologies have long supported the = distinction > > > between "degraded" and " faulty". In particular, protection > > > technologies in use have this distinction built into the innermost > > > recedes of their protocols. > > > Even in the TP requirements didn't spell this out, I think it = would > > > be a mistake not to take advantage of years of experience in > > > transport networks OAM. > > > > > > Regards, > > > > > > Daniel > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, July 28, 2011 11:12 AM > > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro = Alessandro > > > Gerardo; mpls@ietf.org > > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > Hi Greg- > > > =A0There is a difference between SF and SD. =A0Converting SD into = Down > > > means that it will be interpreted exactly the same as SF, and if > > > that's the case why have SD at all? =A0If SD is necessary it must = be > > > somehow different from SD. > > > > > > All- > > > > > > =A0Having said that, I'm not sure I disagree with Greg. =A0It = seems that > > > this idea of propagating server layer SD up into TP is being done > > > because there's no good way to do SD entirely within the TP layer. > > > I suspect that if there were a way to do SD within the TP layer = that > > > made everyone happy, we wouldn't have the approach propsed in > > > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for = this > > > draft is: > > > > > > =A0- we must have SD in TP because it is possible to do in other > > > technologies > > > =A0- it is not possible to SD entirely within TP > > > =A0- therefore we must get SD from somewhere else > > > > > > is a reasonable one. =A0If we do that, where do we stop? =A0Should = we > > > propagate information about signal quality up to TCP so it can > > > adjust its windows according? =A0(please note that this is = intended to > > > be a reductio ad absurdum question and not a serious one. :) ) > > > > > > > > > > > > eric > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf > > > Of > > >> Greg Mirsky > > >> Sent: Wednesday, July 27, 2011 2:08 PM > > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > >> Alessandro Gerardo; mpls@ietf.org > > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >> > > >> Dear Authors and All, > > >> I think that it is function of the PHY layer to detect SD = condition > > > and > > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > > Physical > > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > > >> measurement, in my view, is addressing the issue. > > >> > > >> Regards, > > >> Greg > > > > > > From DanielC@orckit.com Thu Jul 28 11:29:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E0A11E8105 for ; Thu, 28 Jul 2011 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY5u4NYzGGZW for ; Thu, 28 Jul 2011 11:29:37 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F14D11E8078 for ; Thu, 28 Jul 2011 11:29:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 21:29:32 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82A3@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAAHcgEAAAD3gsAAAZBFQAAA26dA= References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED829D@tlvmail1> From: "Daniel Cohn" To: "Eric Osborne (eosborne)" , "Greg Mirsky" Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:29:39 -0000 But what the SD draft specifies is that the SD condition should be = *detected* at the server layer, and *reported* at the MPLS layer. The = MPLS layer can use this SD report as a trigger to protection schemes, as = specified in the linear protection draft. Congestion reports are already covered by MPLS OAM tools such as packet = loss (LM). The SD drafts draws a clear distinction between physical and = non-physical errors.=20 Daniel -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, July 28, 2011 2:22 PM To: Daniel Cohn; Greg Mirsky Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; = yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 My point with ECN is that you need some sort of SD-detecting thingy at = the MPLS level in order to have SD in MPLS. The only 'degradation' I = can think of at the packet level is sporadic loss for a reason *not* due = to underlying transport issues, as that's handled by the server layer. = And the only reason for these drops that comes to mind is for QoS during = congestion. So I used ECN to mean "if you have packet drops which = originate at the TP layer, ECN=3D=3D1 else ECN=3D=3D0". I may have = confused the issue by oversimpifying with ECN, I hope this clears it up. eric > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Thursday, July 28, 2011 2:11 PM > To: Eric Osborne (eosborne); Greg Mirsky > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Eric, >=20 > I believe degradation is relevant to any technology where errors can = occur > (i.e. all kinds). ECN reports congestion which is completely = orthogonal to > the physical error condition we want to detect and correct via SD > detection and report. So I don't think ECN-like proposals are relevant = to > the discussion. >=20 > DC >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 2:05 PM > To: Daniel Cohn; Greg Mirsky > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > I don't quite buy "settle for less functionality". The point I made = in my > last email is that the SD functionality you want just isn't *relevant* = to > MPLS. The concept of degradation at the packet level is pretty = slippery. > There've been ECN-type proposals over the years, but they never went > anywhere and certainly don't exist in MPLS. If we had ECN in MPLS = then I > would agree that it could be mapped to SD in some fashion, but we = don't. > Deciding that you need an unapplicable technology and then shoehorning > something else into acting as a substitute is, IMO, a mistake. >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Thursday, July 28, 2011 1:15 PM > > To: Greg Mirsky > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > True enough in general. But in this particular example, there is > > nothing suggested by this draft that requires huge implementation > > efforts or paradigm changes. So I fail to see why we should settle = for > > less functionality than is available in existing transport networks. > > > > DC > > > > -----Original Message----- > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > Sent: Thursday, July 28, 2011 1:00 PM > > To: Daniel Cohn > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Daniel, > > I think that while we're building MPLS-TP to be suited for the > > transport we need to remember that it, as Neil pointed out on number > > of occasions, is not BOS layer and doesn't put bits on a wire. Thus = it > > has characteristic that makes it different from other layers of a > > transport network and, I think, as result not all existing concepts = of > > transport are applicable to packet layer realized by MPLS-TP. > > > > Regards, > > Greg > > > > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn = wrote: > > > Hi Eric, > > > > > > One of the reasons why we need SD in TP is because TP is supposed = to > > > provide the same "look and feel" of existing transport networks, = as > > > specified in the TP requirements document. > > > Transport networks technologies have long supported the = distinction > > > between "degraded" and " faulty". In particular, protection > > > technologies in use have this distinction built into the innermost > > > recedes of their protocols. > > > Even in the TP requirements didn't spell this out, I think it = would > > > be a mistake not to take advantage of years of experience in > > > transport networks OAM. > > > > > > Regards, > > > > > > Daniel > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, July 28, 2011 11:12 AM > > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro = Alessandro > > > Gerardo; mpls@ietf.org > > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > Hi Greg- > > > =A0There is a difference between SF and SD. =A0Converting SD into = Down > > > means that it will be interpreted exactly the same as SF, and if > > > that's the case why have SD at all? =A0If SD is necessary it must = be > > > somehow different from SD. > > > > > > All- > > > > > > =A0Having said that, I'm not sure I disagree with Greg. =A0It = seems that > > > this idea of propagating server layer SD up into TP is being done > > > because there's no good way to do SD entirely within the TP layer. > > > I suspect that if there were a way to do SD within the TP layer = that > > > made everyone happy, we wouldn't have the approach propsed in > > > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for = this > > > draft is: > > > > > > =A0- we must have SD in TP because it is possible to do in other > > > technologies > > > =A0- it is not possible to SD entirely within TP > > > =A0- therefore we must get SD from somewhere else > > > > > > is a reasonable one. =A0If we do that, where do we stop? =A0Should = we > > > propagate information about signal quality up to TCP so it can > > > adjust its windows according? =A0(please note that this is = intended to > > > be a reductio ad absurdum question and not a serious one. :) ) > > > > > > > > > > > > eric > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf > > > Of > > >> Greg Mirsky > > >> Sent: Wednesday, July 27, 2011 2:08 PM > > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > >> Alessandro Gerardo; mpls@ietf.org > > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >> > > >> Dear Authors and All, > > >> I think that it is function of the PHY layer to detect SD = condition > > > and > > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > > Physical > > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > > >> measurement, in my view, is addressing the issue. > > >> > > >> Regards, > > >> Greg > > > > > > From DanielC@orckit.com Thu Jul 28 11:34:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD811E810A for ; Thu, 28 Jul 2011 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d71PcYO-p79L for ; Thu, 28 Jul 2011 11:34:13 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2211E8078 for ; Thu, 28 Jul 2011 11:34:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 21:34:03 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82A5@tlvmail1> In-reply-to: <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAALPihAAAB2EoA== References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> From: "Daniel Cohn" To: "Shahram Davari" , "Greg Mirsky" Cc: Rafi Ram , mpls@ietf.org, ms-daikoku@kddi.com, yang.jian90@zte.com.cn Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:34:14 -0000 You can make the same argument about SF - should be handled in the = server layer. Yet I see no discussion on whether MPLS-TP needs SF = reporting. The server layer cannot always overcome error conditions. A TP = protection scheme should be able to overcome it by switching to an = error-free path. Isn't this something we can all agree to? DC -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com]=20 Sent: Thursday, July 28, 2011 2:30 PM To: Daniel Cohn; Greg Mirsky Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi, I also don't believe SD is needed for MPLS-TP. Such defect is not = related to MPLS-TP and should be handled in the server layer, such as = changing the FEC type in OTN, etc. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Daniel Cohn Sent: Thursday, July 28, 2011 10:15 AM To: Greg Mirsky Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 True enough in general. But in this particular example, there is nothing = suggested by this draft that requires huge implementation efforts or = paradigm changes. So I fail to see why we should settle for less = functionality than is available in existing transport networks. DC=20 -----Original Message----- From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Thursday, July 28, 2011 1:00 PM To: Daniel Cohn Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; = ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro = Gerardo; mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Daniel, I think that while we're building MPLS-TP to be suited for the transport we need to remember that it, as Neil pointed out on number of occasions, is not BOS layer and doesn't put bits on a wire. Thus it has characteristic that makes it different from other layers of a transport network and, I think, as result not all existing concepts of transport are applicable to packet layer realized by MPLS-TP. Regards, Greg On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > Hi Eric, > > One of the reasons why we need SD in TP is because TP is supposed to > provide the same "look and feel" of existing transport networks, as > specified in the TP requirements document. > Transport networks technologies have long supported the distinction > between "degraded" and " faulty". In particular, protection = technologies > in use have this distinction built into the innermost recedes of their > protocols. > Even in the TP requirements didn't spell this out, I think it would be = a > mistake not to take advantage of years of experience in transport > networks OAM. > > Regards, > > Daniel > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 11:12 AM > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Greg- > =A0There is a difference between SF and SD. =A0Converting SD into Down > means that it will be interpreted exactly the same as SF, and if = that's > the case why have SD at all? =A0If SD is necessary it must be somehow > different from SD. > > All- > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems = that > this idea of propagating server layer SD up into TP is being done > because there's no good way to do SD entirely within the TP layer. = =A0I > suspect that if there were a way to do SD within the TP layer that = made > everyone happy, we wouldn't have the approach propsed in > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for this > draft is: > > =A0- we must have SD in TP because it is possible to do in other > technologies > =A0- it is not possible to SD entirely within TP > =A0- therefore we must get SD from somewhere else > > is a reasonable one. =A0If we do that, where do we stop? =A0Should we > propagate information about signal quality up to TCP so it can adjust > its windows according? =A0(please note that this is intended to be a > reductio ad absurdum question and not a serious one. :) ) > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Greg Mirsky >> Sent: Wednesday, July 27, 2011 2:08 PM >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Dear Authors and All, >> I think that it is function of the PHY layer to detect SD condition > and >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > Physical >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> measurement, in my view, is addressing the issue. >> >> Regards, >> Greg > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Jul 28 11:37:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E842421F86A6 for ; Thu, 28 Jul 2011 11:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ncAzWmmRPf3 for ; Thu, 28 Jul 2011 11:37:16 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0171621F8681 for ; Thu, 28 Jul 2011 11:37:13 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 28 Jul 2011 11:35:11 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 28 Jul 2011 11:30:17 -0700 From: "Shahram Davari" To: "Daniel Cohn" , "Greg Mirsky" Date: Thu, 28 Jul 2011 11:30:06 -0700 Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAALPihA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 622F74553KO239114-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rafi Ram , "mpls@ietf.org" , "ms-daikoku@kddi.com" , "yang.jian90@zte.com.cn" Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:37:17 -0000 Hi, I also don't believe SD is needed for MPLS-TP. Such defect is not related t= o MPLS-TP and should be handled in the server layer, such as changing the F= EC type in OTN, etc. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dan= iel Cohn Sent: Thursday, July 28, 2011 10:15 AM To: Greg Mirsky Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 True enough in general. But in this particular example, there is nothing su= ggested by this draft that requires huge implementation efforts or paradigm= changes. So I fail to see why we should settle for less functionality than= is available in existing transport networks. DC=20 -----Original Message----- From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: Thursday, July 28, 2011 1:00 PM To: Daniel Cohn Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.co= m.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.or= g Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Daniel, I think that while we're building MPLS-TP to be suited for the transport we need to remember that it, as Neil pointed out on number of occasions, is not BOS layer and doesn't put bits on a wire. Thus it has characteristic that makes it different from other layers of a transport network and, I think, as result not all existing concepts of transport are applicable to packet layer realized by MPLS-TP. Regards, Greg On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > Hi Eric, > > One of the reasons why we need SD in TP is because TP is supposed to > provide the same "look and feel" of existing transport networks, as > specified in the TP requirements document. > Transport networks technologies have long supported the distinction > between "degraded" and " faulty". In particular, protection technologies > in use have this distinction built into the innermost recedes of their > protocols. > Even in the TP requirements didn't spell this out, I think it would be a > mistake not to take advantage of years of experience in transport > networks OAM. > > Regards, > > Daniel > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 11:12 AM > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Greg- > =A0There is a difference between SF and SD. =A0Converting SD into Down > means that it will be interpreted exactly the same as SF, and if that's > the case why have SD at all? =A0If SD is necessary it must be somehow > different from SD. > > All- > > =A0Having said that, I'm not sure I disagree with Greg. =A0It seems that > this idea of propagating server layer SD up into TP is being done > because there's no good way to do SD entirely within the TP layer. =A0I > suspect that if there were a way to do SD within the TP layer that made > everyone happy, we wouldn't have the approach propsed in > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation for this > draft is: > > =A0- we must have SD in TP because it is possible to do in other > technologies > =A0- it is not possible to SD entirely within TP > =A0- therefore we must get SD from somewhere else > > is a reasonable one. =A0If we do that, where do we stop? =A0Should we > propagate information about signal quality up to TCP so it can adjust > its windows according? =A0(please note that this is intended to be a > reductio ad absurdum question and not a serious one. :) ) > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Greg Mirsky >> Sent: Wednesday, July 27, 2011 2:08 PM >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Dear Authors and All, >> I think that it is function of the PHY layer to detect SD condition > and >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > Physical >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> measurement, in my view, is addressing the issue. >> >> Regards, >> Greg > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From prvs=11903ce5a6=hshah@ciena.com Thu Jul 28 11:41:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460955E8015 for ; Thu, 28 Jul 2011 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyTRqdqL5lOO for ; Thu, 28 Jul 2011 11:41:25 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42821F8865 for ; Thu, 28 Jul 2011 11:41:25 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p6SIeWgq017209; Thu, 28 Jul 2011 14:41:21 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id xuc85864b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 14:41:21 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Thu, 28 Jul 2011 14:41:21 -0400 From: "Shah, Himanshu" To: Shahram Davari , Daniel Cohn , Greg Mirsky Content-Class: urn:content-classes:message Date: Thu, 28 Jul 2011 14:41:19 -0400 Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNSDV7fMxb2T8LQRuSPYVKCJEGiQAALTHgAALPihAAAFf24A== Message-ID: References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1><44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18290.001 x-tm-as-result: No--48.562500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-28_05:2011-07-28, 2011-07-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=100 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107280154 Cc: Rafi Ram , "yang.jian90@zte.com.cn" , "ms-daikoku@kddi.com" , "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:41:26 -0000 I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made t= his exact point at the mike during presentation. /himanshu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Thursday, July 28, 2011 2:30 PM To: Daniel Cohn; Greg Mirsky Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi, I also don't believe SD is needed for MPLS-TP. Such defect is not related t= o MPLS-TP and should be handled in the server layer, such as changing the F= EC type in OTN, etc. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dan= iel Cohn Sent: Thursday, July 28, 2011 10:15 AM To: Greg Mirsky Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 True enough in general. But in this particular example, there is nothing su= ggested by this draft that requires huge implementation efforts or paradigm= changes. So I fail to see why we should settle for less functionality than= is available in existing transport networks. DC -----Original Message----- From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, July 28, 2011 1:00 PM To: Daniel Cohn Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.co= m.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.or= g Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Daniel, I think that while we're building MPLS-TP to be suited for the transport we need to remember that it, as Neil pointed out on number of occasions, is not BOS layer and doesn't put bits on a wire. Thus it has characteristic that makes it different from other layers of a transport network and, I think, as result not all existing concepts of transport are applicable to packet layer realized by MPLS-TP. Regards, Greg On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > Hi Eric, > > One of the reasons why we need SD in TP is because TP is supposed to > provide the same "look and feel" of existing transport networks, as > specified in the TP requirements document. > Transport networks technologies have long supported the distinction > between "degraded" and " faulty". In particular, protection technologies > in use have this distinction built into the innermost recedes of their > protocols. > Even in the TP requirements didn't spell this out, I think it would be a > mistake not to take advantage of years of experience in transport > networks OAM. > > Regards, > > Daniel > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, July 28, 2011 11:12 AM > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Greg- > There is a difference between SF and SD. Converting SD into Down > means that it will be interpreted exactly the same as SF, and if that's > the case why have SD at all? If SD is necessary it must be somehow > different from SD. > > All- > > Having said that, I'm not sure I disagree with Greg. It seems that > this idea of propagating server layer SD up into TP is being done > because there's no good way to do SD entirely within the TP layer. I > suspect that if there were a way to do SD within the TP layer that made > everyone happy, we wouldn't have the approach propsed in > draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > draft is: > > - we must have SD in TP because it is possible to do in other > technologies > - it is not possible to SD entirely within TP > - therefore we must get SD from somewhere else > > is a reasonable one. If we do that, where do we stop? Should we > propagate information about signal quality up to TCP so it can adjust > its windows according? (please note that this is intended to be a > reductio ad absurdum question and not a serious one. :) ) > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Greg Mirsky >> Sent: Wednesday, July 27, 2011 2:08 PM >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Dear Authors and All, >> I think that it is function of the PHY layer to detect SD condition > and >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > Physical >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> measurement, in my view, is addressing the issue. >> >> Regards, >> Greg > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Thu Jul 28 11:46:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5725E801C for ; Thu, 28 Jul 2011 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIOQEAokCdV2 for ; Thu, 28 Jul 2011 11:46:17 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3335E8010 for ; Thu, 28 Jul 2011 11:46:16 -0700 (PDT) Received: by qwc23 with SMTP id 23so1986958qwc.31 for ; Thu, 28 Jul 2011 11:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ScyacyL25fpXk9FW/hOMVmsq2ryRqT8BcIkXDbwUUJc=; b=U5KudMMhmU2CsH+J2R70Qb+eiB7fQVXPjf5GdwmYJ8a8OEG6IlIshU1VNybpg1WZ+M kTp1wr9Bf+X4ZZ7A0n7PBOYSnQ6xDTpEAi75y9PuO7+Fou1eOhH/JcPJQSMyN0N4KV3k M/4KI+IwDttbQj5aFtcxr5Lg8pNehInS13pAQ= Received: by 10.224.193.66 with SMTP id dt2mr311758qab.175.1311878774508; Thu, 28 Jul 2011 11:46:14 -0700 (PDT) Received: from [130.129.23.104] (dhcp-1768.meeting.ietf.org [130.129.23.104]) by mx.google.com with ESMTPS id s14sm864086qct.30.2011.07.28.11.46.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 11:46:13 -0700 (PDT) References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0A740D6F-3FB2-436A-B1ED-D8560FE89485@gmail.com> X-Mailer: iPad Mail (8J2) From: Sam Aldrin Date: Thu, 28 Jul 2011 11:48:08 -0700 To: "Shah, Himanshu" Cc: "mpls@ietf.org" , "yang.jian90@zte.com.cn" , "ms-daikoku@kddi.com" , Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:46:17 -0000 Agree with others. Don't think we should be handling this at mpls-TP but sho= uld be handled at server layer. Cheers Sam Sent from my iPad On Jul 28, 2011, at 11:41 AM, "Shah, Himanshu" wrote: > I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made t= his exact point at the mike > during presentation. >=20 > /himanshu >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sh= ahram Davari > Sent: Thursday, July 28, 2011 2:30 PM > To: Daniel Cohn; Greg Mirsky > Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi, >=20 > I also don't believe SD is needed for MPLS-TP. Such defect is not related t= o MPLS-TP and should be handled in the server layer, such as changing the FE= C type in OTN, etc. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Da= niel Cohn > Sent: Thursday, July 28, 2011 10:15 AM > To: Greg Mirsky > Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > True enough in general. But in this particular example, there is nothing s= uggested by this draft that requires huge implementation efforts or paradigm= changes. So I fail to see why we should settle for less functionality than i= s available in existing transport networks. >=20 > DC >=20 > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, July 28, 2011 1:00 PM > To: Daniel Cohn > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.c= om.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.or= g > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the > transport we need to remember that it, as Neil pointed out on number > of occasions, is not BOS layer and doesn't put bits on a wire. Thus it > has characteristic that makes it different from other layers of a > transport network and, I think, as result not all existing concepts of > transport are applicable to packet layer realized by MPLS-TP. >=20 > Regards, > Greg >=20 > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >> Hi Eric, >>=20 >> One of the reasons why we need SD in TP is because TP is supposed to >> provide the same "look and feel" of existing transport networks, as >> specified in the TP requirements document. >> Transport networks technologies have long supported the distinction >> between "degraded" and " faulty". In particular, protection technologies >> in use have this distinction built into the innermost recedes of their >> protocols. >> Even in the TP requirements didn't spell this out, I think it would be a >> mistake not to take advantage of years of experience in transport >> networks OAM. >>=20 >> Regards, >>=20 >> Daniel >>=20 >> -----Original Message----- >> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >> Sent: Thursday, July 28, 2011 11:12 AM >> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>=20 >> Hi Greg- >> There is a difference between SF and SD. Converting SD into Down >> means that it will be interpreted exactly the same as SF, and if that's >> the case why have SD at all? If SD is necessary it must be somehow >> different from SD. >>=20 >> All- >>=20 >> Having said that, I'm not sure I disagree with Greg. It seems that >> this idea of propagating server layer SD up into TP is being done >> because there's no good way to do SD entirely within the TP layer. I >> suspect that if there were a way to do SD within the TP layer that made >> everyone happy, we wouldn't have the approach propsed in >> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >> draft is: >>=20 >> - we must have SD in TP because it is possible to do in other >> technologies >> - it is not possible to SD entirely within TP >> - therefore we must get SD from somewhere else >>=20 >> is a reasonable one. If we do that, where do we stop? Should we >> propagate information about signal quality up to TCP so it can adjust >> its windows according? (please note that this is intended to be a >> reductio ad absurdum question and not a serious one. :) ) >>=20 >>=20 >>=20 >> eric >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Greg Mirsky >>> Sent: Wednesday, July 27, 2011 2:08 PM >>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>=20 >>> Dear Authors and All, >>> I think that it is function of the PHY layer to detect SD condition >> and >>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >> Physical >>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>> measurement, in my view, is addressing the issue. >>>=20 >>> Regards, >>> Greg >>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Thu Jul 28 12:04:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328935E8017 for ; Thu, 28 Jul 2011 12:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIG3gYiH8BzV for ; Thu, 28 Jul 2011 12:04:55 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2384C5E8010 for ; Thu, 28 Jul 2011 12:04:55 -0700 (PDT) Received: by qwc23 with SMTP id 23so1997283qwc.31 for ; Thu, 28 Jul 2011 12:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Tua8BtFHF8As01x1z5GnNLjGVfi5dF/3lh7hG2CGRxM=; b=lpsaO34tP51JK+ZxRPVMwpA2tBABcSllvOqXWwbytSKkQaAw8xPLBkPKSTOGx+WmL9 i6I+fxIVyB6Jzrd+zCida1j8a/dL0sr3j+xL5t2lChy5MBoaefVCmJLZWiidHETRBSxh B/UK6ZoLrMpzRV2UxOQvlX9T1NaeWT63d6GK4= Received: by 10.224.193.72 with SMTP id dt8mr321240qab.197.1311879894337; Thu, 28 Jul 2011 12:04:54 -0700 (PDT) Received: from [130.129.22.210] (dhcp-16d2.meeting.ietf.org [130.129.22.210]) by mx.google.com with ESMTPS id s14sm878091qct.18.2011.07.28.12.04.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:04:53 -0700 (PDT) References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> X-Mailer: iPhone Mail (8J2) From: Sam Aldrin Date: Thu, 28 Jul 2011 15:04:42 -0400 To: "Shah, Himanshu" Cc: "mpls@ietf.org" , "yang.jian90@zte.com.cn" , "ms-daikoku@kddi.com" , Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:04:56 -0000 Also, if we were to propagate to Tp, why stop there? It should be propagated= to PW as well, right? Sam Sent from my iPhone On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made t= his exact point at the mike > during presentation. >=20 > /himanshu >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sh= ahram Davari > Sent: Thursday, July 28, 2011 2:30 PM > To: Daniel Cohn; Greg Mirsky > Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi, >=20 > I also don't believe SD is needed for MPLS-TP. Such defect is not related t= o MPLS-TP and should be handled in the server layer, such as changing the FE= C type in OTN, etc. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Da= niel Cohn > Sent: Thursday, July 28, 2011 10:15 AM > To: Greg Mirsky > Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > True enough in general. But in this particular example, there is nothing s= uggested by this draft that requires huge implementation efforts or paradigm= changes. So I fail to see why we should settle for less functionality than i= s available in existing transport networks. >=20 > DC >=20 > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, July 28, 2011 1:00 PM > To: Daniel Cohn > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.c= om.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.or= g > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the > transport we need to remember that it, as Neil pointed out on number > of occasions, is not BOS layer and doesn't put bits on a wire. Thus it > has characteristic that makes it different from other layers of a > transport network and, I think, as result not all existing concepts of > transport are applicable to packet layer realized by MPLS-TP. >=20 > Regards, > Greg >=20 > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >> Hi Eric, >>=20 >> One of the reasons why we need SD in TP is because TP is supposed to >> provide the same "look and feel" of existing transport networks, as >> specified in the TP requirements document. >> Transport networks technologies have long supported the distinction >> between "degraded" and " faulty". In particular, protection technologies >> in use have this distinction built into the innermost recedes of their >> protocols. >> Even in the TP requirements didn't spell this out, I think it would be a >> mistake not to take advantage of years of experience in transport >> networks OAM. >>=20 >> Regards, >>=20 >> Daniel >>=20 >> -----Original Message----- >> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >> Sent: Thursday, July 28, 2011 11:12 AM >> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>=20 >> Hi Greg- >> There is a difference between SF and SD. Converting SD into Down >> means that it will be interpreted exactly the same as SF, and if that's >> the case why have SD at all? If SD is necessary it must be somehow >> different from SD. >>=20 >> All- >>=20 >> Having said that, I'm not sure I disagree with Greg. It seems that >> this idea of propagating server layer SD up into TP is being done >> because there's no good way to do SD entirely within the TP layer. I >> suspect that if there were a way to do SD within the TP layer that made >> everyone happy, we wouldn't have the approach propsed in >> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >> draft is: >>=20 >> - we must have SD in TP because it is possible to do in other >> technologies >> - it is not possible to SD entirely within TP >> - therefore we must get SD from somewhere else >>=20 >> is a reasonable one. If we do that, where do we stop? Should we >> propagate information about signal quality up to TCP so it can adjust >> its windows according? (please note that this is intended to be a >> reductio ad absurdum question and not a serious one. :) ) >>=20 >>=20 >>=20 >> eric >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Greg Mirsky >>> Sent: Wednesday, July 27, 2011 2:08 PM >>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>=20 >>> Dear Authors and All, >>> I think that it is function of the PHY layer to detect SD condition >> and >>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >> Physical >>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>> measurement, in my view, is addressing the issue. >>>=20 >>> Regards, >>> Greg >>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pabloisnot@gmail.com Thu Jul 28 12:30:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3868321F8669 for ; Thu, 28 Jul 2011 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=1.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HskU1167eEkn for ; Thu, 28 Jul 2011 12:30:39 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 887BC21F85EC for ; Thu, 28 Jul 2011 12:30:39 -0700 (PDT) Received: by qyk29 with SMTP id 29so1929468qyk.10 for ; Thu, 28 Jul 2011 12:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XttWyahEnjvjWTmdsK7ZENpNAMAVc5YwQbUk5lPQ0w8=; b=r12XSG5ddAAajVWwuXMBZ2jJPfDa2pmtWZN897EkZxQMHibqEE87csF+89NU3j8X4Y mlvdVm45xCzyNOmMSFQ6q0PU/eOa9YXLBVFW+CTw1lf+JKgjisvEYbYztlBuRK1aHtEe fW5AgpU1nn6XXHiOcVJGnjv7ThBp5T0D5OlwA= MIME-Version: 1.0 Received: by 10.224.192.202 with SMTP id dr10mr327448qab.131.1311881438714; Thu, 28 Jul 2011 12:30:38 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Thu, 28 Jul 2011 12:30:38 -0700 (PDT) In-Reply-To: References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED829D@tlvmail1> Date: Thu, 28 Jul 2011 15:30:38 -0400 Message-ID: From: Pablo Frank To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=20cf300fb1f1245bd404a9263361 Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:30:41 -0000 --20cf300fb1f1245bd404a9263361 Content-Type: text/plain; charset=ISO-8859-1 I agree that there is no defined way to detect "degradation" in an LSP or PW. LM/DM is the closest thing that could measure something approximating "degradation" but several have already indicated that they don't want to use LM/DM for this purpose. The problem is that both the Survivability framework and the Linear Protection draft expect us to handle "degraded" transport paths. Well, if we're not interested in server-layer indications of degradation (as Daniel has proposed) and we're not interested in OAM providing some sort of degradation, then there is no way for us have "degraded" transport paths. Either we agree on what a degraded transport path means or we should delete it from the various documents that mention it. Pablo On Thu, Jul 28, 2011 at 2:21 PM, Eric Osborne (eosborne) wrote: > My point with ECN is that you need some sort of SD-detecting thingy at the > MPLS level in order to have SD in MPLS. The only 'degradation' I can think > of at the packet level is sporadic loss for a reason *not* due to underlying > transport issues, as that's handled by the server layer. And the only > reason for these drops that comes to mind is for QoS during congestion. So > I used ECN to mean "if you have packet drops which originate at the TP > layer, ECN==1 else ECN==0". I may have confused the issue by oversimpifying > with ECN, I hope this clears it up. > > > > eric > > > > -----Original Message----- > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > Sent: Thursday, July 28, 2011 2:11 PM > > To: Eric Osborne (eosborne); Greg Mirsky > > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Eric, > > > > I believe degradation is relevant to any technology where errors can > occur > > (i.e. all kinds). ECN reports congestion which is completely orthogonal > to > > the physical error condition we want to detect and correct via SD > > detection and report. So I don't think ECN-like proposals are relevant to > > the discussion. > > > > DC > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, July 28, 2011 2:05 PM > > To: Daniel Cohn; Greg Mirsky > > Cc: Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; > > yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > I don't quite buy "settle for less functionality". The point I made in > my > > last email is that the SD functionality you want just isn't *relevant* to > > MPLS. The concept of degradation at the packet level is pretty slippery. > > There've been ECN-type proposals over the years, but they never went > > anywhere and certainly don't exist in MPLS. If we had ECN in MPLS then I > > would agree that it could be mapped to SD in some fashion, but we don't. > > Deciding that you need an unapplicable technology and then shoehorning > > something else into acting as a substitute is, IMO, a mistake. > > > > > > > > eric > > > > > -----Original Message----- > > > From: Daniel Cohn [mailto:DanielC@orckit.com] > > > Sent: Thursday, July 28, 2011 1:15 PM > > > To: Greg Mirsky > > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > > Gerardo; mpls@ietf.org > > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > True enough in general. But in this particular example, there is > > > nothing suggested by this draft that requires huge implementation > > > efforts or paradigm changes. So I fail to see why we should settle for > > > less functionality than is available in existing transport networks. > > > > > > DC > > > > > > -----Original Message----- > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > > Sent: Thursday, July 28, 2011 1:00 PM > > > To: Daniel Cohn > > > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > > Gerardo; mpls@ietf.org > > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > Hi Daniel, > > > I think that while we're building MPLS-TP to be suited for the > > > transport we need to remember that it, as Neil pointed out on number > > > of occasions, is not BOS layer and doesn't put bits on a wire. Thus it > > > has characteristic that makes it different from other layers of a > > > transport network and, I think, as result not all existing concepts of > > > transport are applicable to packet layer realized by MPLS-TP. > > > > > > Regards, > > > Greg > > > > > > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: > > > > Hi Eric, > > > > > > > > One of the reasons why we need SD in TP is because TP is supposed to > > > > provide the same "look and feel" of existing transport networks, as > > > > specified in the TP requirements document. > > > > Transport networks technologies have long supported the distinction > > > > between "degraded" and " faulty". In particular, protection > > > > technologies in use have this distinction built into the innermost > > > > recedes of their protocols. > > > > Even in the TP requirements didn't spell this out, I think it would > > > > be a mistake not to take advantage of years of experience in > > > > transport networks OAM. > > > > > > > > Regards, > > > > > > > > Daniel > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, July 28, 2011 11:12 AM > > > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > > > Gerardo; mpls@ietf.org > > > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > > > Hi Greg- > > > > There is a difference between SF and SD. Converting SD into Down > > > > means that it will be interpreted exactly the same as SF, and if > > > > that's the case why have SD at all? If SD is necessary it must be > > > > somehow different from SD. > > > > > > > > All- > > > > > > > > Having said that, I'm not sure I disagree with Greg. It seems that > > > > this idea of propagating server layer SD up into TP is being done > > > > because there's no good way to do SD entirely within the TP layer. > > > > I suspect that if there were a way to do SD within the TP layer that > > > > made everyone happy, we wouldn't have the approach propsed in > > > > draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > > > > draft is: > > > > > > > > - we must have SD in TP because it is possible to do in other > > > > technologies > > > > - it is not possible to SD entirely within TP > > > > - therefore we must get SD from somewhere else > > > > > > > > is a reasonable one. If we do that, where do we stop? Should we > > > > propagate information about signal quality up to TCP so it can > > > > adjust its windows according? (please note that this is intended to > > > > be a reductio ad absurdum question and not a serious one. :) ) > > > > > > > > > > > > > > > > eric > > > > > > > >> -----Original Message----- > > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > >> Behalf > > > > Of > > > >> Greg Mirsky > > > >> Sent: Wednesday, July 27, 2011 2:08 PM > > > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > > > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > > >> Alessandro Gerardo; mpls@ietf.org > > > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > >> > > > >> Dear Authors and All, > > > >> I think that it is function of the PHY layer to detect SD condition > > > > and > > > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > > > Physical > > > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > > > >> measurement, in my view, is addressing the issue. > > > >> > > > >> Regards, > > > >> Greg > > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf300fb1f1245bd404a9263361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that there is no defined way to detect "degradation" in a= n LSP or PW. =A0LM/DM is the closest thing that could measure something app= roximating "degradation" but several have already indicated that = they don't want to use LM/DM for this purpose. =A0The problem is that b= oth the Survivability framework and the Linear Protection draft expect us t= o handle "degraded" transport paths. =A0Well, if we're not in= terested in server-layer indications of degradation (as Daniel has proposed= ) and we're not interested in OAM providing some sort of degradation, t= hen there is no way for us have "degraded" transport paths. =A0Ei= ther we agree on what a degraded transport path means or we should delete i= t from the various documents that mention it.

Pablo

On Thu, Jul 28, 2011= at 2:21 PM, Eric Osborne (eosborne) <eosborne@cisco.com> wrote:
My point with ECN is that you need some sort of SD-detecting thingy at the = MPLS level in order to have SD in MPLS. =A0The only 'degradation' I= can think of at the packet level is sporadic loss for a reason *not* due t= o underlying transport issues, as that's handled by the server layer. = =A0And the only reason for these drops that comes to mind is for QoS during= congestion. =A0So I used ECN to mean "if you have packet drops which = originate at the TP layer, ECN=3D=3D1 else ECN=3D=3D0". =A0I may have = confused the issue by oversimpifying with ECN, I hope this clears it up.


eric


> -----Original Message-----
> From: Daniel Cohn [mailto:Daniel= C@orckit.com]
> Sent: Thursday, July 28, 2011 2:11 PM
> To: Eric Osborne (eosborne); Greg Mirsky
> Cc: Rafi Ram; ms-daikoku@kddi.c= om; ma.yuxia@zte.com.cn;
> yang.jian90@zte.com.cn; = D'Alessandro Alessandro Gerardo; mpls@= ietf.org
> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>
> Eric,
>
> I believe degradation is relevant to any technology where errors can o= ccur
> (i.e. all kinds). ECN reports congestion which is completely orthogona= l to
> the physical error condition we want to detect and correct via SD
> detection and report. So I don't think ECN-like proposals are rele= vant to
> the discussion.
>
> DC
>
> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> Sent: Thursday, July 28, 2011 2:05 PM
> To: Daniel Cohn; Greg Mirsky
> Cc: Rafi Ram; ms-daikoku@kddi.c= om; ma.yuxia@zte.com.cn;
> yang.jian90@zte.com.cn; = D'Alessandro Alessandro Gerardo; mpls@= ietf.org
> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>
> I don't quite buy "settle for less functionality". =A0Th= e point I made in my
> last email is that the SD functionality you want just isn't *relev= ant* to
> MPLS. =A0The concept of degradation at the packet level is pretty slip= pery.
> There've been ECN-type proposals over the years, but they never we= nt
> anywhere and certainly don't exist in MPLS. =A0If we had ECN in MP= LS then I
> would agree that it could be mapped to SD in some fashion, but we don&= #39;t.
> Deciding that you need an unapplicable technology and then shoehorning=
> something else into acting as a substitute is, IMO, a mistake.
>
>
>
> eric
>
> > -----Original Message-----
> > From: Daniel Cohn [mailto:D= anielC@orckit.com]
> > Sent: Thursday, July 28, 2011 1:15 PM
> > To: Greg Mirsky
> > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com;
> > ma.yuxia@zte.com.cn; <= a href=3D"mailto:yang.jian90@zte.com.cn">yang.jian90@zte.com.cn; D'= Alessandro Alessandro
> > Gerardo; mpls@ietf.org
> > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> >
> > True enough in general. But in this particular example, there is<= br> > > nothing suggested by this draft that requires huge implementation=
> > efforts or paradigm changes. So I fail to see why we should settl= e for
> > less functionality than is available in existing transport networ= ks.
> >
> > DC
> >
> > -----Original Message-----
> > From: Greg Mirsky [mailto:gregimirsky@gmail.com]
> > Sent: Thursday, July 28, 2011 1:00 PM
> > To: Daniel Cohn
> > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com;
> > ma.yuxia@zte.com.cn; <= a href=3D"mailto:yang.jian90@zte.com.cn">yang.jian90@zte.com.cn; D'= Alessandro Alessandro
> > Gerardo; mpls@ietf.org
> > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> >
> > Hi Daniel,
> > I think that while we're building MPLS-TP to be suited for th= e
> > transport we need to remember that it, as Neil pointed out on num= ber
> > of occasions, is not BOS layer and doesn't put bits on a wire= . Thus it
> > has characteristic that makes it different from other layers of a=
> > transport network and, I think, as result not all existing concep= ts of
> > transport are applicable to packet layer realized by MPLS-TP.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn <DanielC@orckit.com> wrote:
> > > Hi Eric,
> > >
> > > One of the reasons why we need SD in TP is because TP is sup= posed to
> > > provide the same "look and feel" of existing trans= port networks, as
> > > specified in the TP requirements document.
> > > Transport networks technologies have long supported the dist= inction
> > > between "degraded" and " faulty". In par= ticular, protection
> > > technologies in use have this distinction built into the inn= ermost
> > > recedes of their protocols.
> > > Even in the TP requirements didn't spell this out, I thi= nk it would
> > > be a mistake not to take advantage of years of experience in=
> > > transport networks OAM.
> > >
> > > Regards,
> > >
> > > Daniel
> > >
> > > -----Original Message-----
> > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > > Sent: Thursday, July 28, 2011 11:12 AM
> > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com;
> > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D= 'Alessandro Alessandro
> > > Gerardo; mpls@ietf.org<= br> > > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> > >
> > > Hi Greg-
> > > =A0There is a difference between SF and SD. =A0Converting SD= into Down
> > > means that it will be interpreted exactly the same as SF, an= d if
> > > that's the case why have SD at all? =A0If SD is necessar= y it must be
> > > somehow different from SD.
> > >
> > > All-
> > >
> > > =A0Having said that, I'm not sure I disagree with Greg. = =A0It seems that
> > > this idea of propagating server layer SD up into TP is being= done
> > > because there's no good way to do SD entirely within the= TP layer.
> > > I suspect that if there were a way to do SD within the TP la= yer that
> > > made everyone happy, we wouldn't have the approach props= ed in
> > > draft-rkhd-mpls-tp-sd. =A0And I think that if the motivation= for this
> > > draft is:
> > >
> > > =A0- we must have SD in TP because it is possible to do in o= ther
> > > technologies
> > > =A0- it is not possible to SD entirely within TP
> > > =A0- therefore we must get SD from somewhere else
> > >
> > > is a reasonable one. =A0If we do that, where do we stop? =A0= Should we
> > > propagate information about signal quality up to TCP so it c= an
> > > adjust its windows according? =A0(please note that this is i= ntended to
> > > be a reductio ad absurdum question and not a serious one. :)= )
> > >
> > >
> > >
> > > eric
> > >
> > >> -----Original Message-----
> > >> From: mpls-boun= ces@ietf.org [mailto:mpls-boun= ces@ietf.org] On
> > >> Behalf
> > > Of
> > >> Greg Mirsky
> > >> Sent: Wednesday, July 27, 2011 2:08 PM
> > >> To: Daniel Cohn; raf= ir@orckit.com; ms-daikoku@kddi.c= om;
> > >> ma.yuxia@zte.com.= cn; yang.jian90@zte.com.cn; D'Alessandro
> > >> Alessandro Gerardo; mpl= s@ietf.org
> > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> > >>
> > >> Dear Authors and All,
> > >> I think that it is function of the PHY layer to detect S= D condition
> > > and
> > >> convert it into Down for the MPLS-TP Layer 0 (what we re= fer as
> > > Physical
> > >> Section). In case of accumulating SD over LSP the e2e Pa= cket Loss
> > >> measurement, in my view, is addressing the issue.
> > >>
> > >> Regards,
> > >> Greg
> > >
> > >
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf300fb1f1245bd404a9263361-- From DanielC@orckit.com Thu Jul 28 12:50:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3111E8147 for ; Thu, 28 Jul 2011 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CC8SowP0cSi for ; Thu, 28 Jul 2011 12:50:55 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0FA11E814D for ; Thu, 28 Jul 2011 12:50:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 22:50:47 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82A6@tlvmail1> In-reply-to: <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNWZ/0oX8QNbl7R9eph6iQAOjkMgABXRSw References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> From: "Daniel Cohn" To: "Sam Aldrin" , "Shah, Himanshu" Cc: mpls@ietf.org, yang.jian90@zte.com.cn, ms-daikoku@kddi.com, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:50:56 -0000 Right - that's why the SD draft refers to "transport path" rather than to LSP.=20 This is in line with draft-ietf-mpls-tp-fault-05, "Fault OAM messages are applicable to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires (MS-PW)" DC -----Original Message----- From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 Sent: Thursday, July 28, 2011 3:05 PM To: Shah, Himanshu Cc: Shahram Davari; Daniel Cohn; Greg Mirsky; Rafi Ram; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right? Sam Sent from my iPhone On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike > during presentation. >=20 > /himanshu >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari > Sent: Thursday, July 28, 2011 2:30 PM > To: Daniel Cohn; Greg Mirsky > Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi, >=20 > I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn > Sent: Thursday, July 28, 2011 10:15 AM > To: Greg Mirsky > Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks. >=20 > DC >=20 > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, July 28, 2011 1:00 PM > To: Daniel Cohn > Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the > transport we need to remember that it, as Neil pointed out on number > of occasions, is not BOS layer and doesn't put bits on a wire. Thus it > has characteristic that makes it different from other layers of a > transport network and, I think, as result not all existing concepts of > transport are applicable to packet layer realized by MPLS-TP. >=20 > Regards, > Greg >=20 > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >> Hi Eric, >>=20 >> One of the reasons why we need SD in TP is because TP is supposed to >> provide the same "look and feel" of existing transport networks, as >> specified in the TP requirements document. >> Transport networks technologies have long supported the distinction >> between "degraded" and " faulty". In particular, protection technologies >> in use have this distinction built into the innermost recedes of their >> protocols. >> Even in the TP requirements didn't spell this out, I think it would be a >> mistake not to take advantage of years of experience in transport >> networks OAM. >>=20 >> Regards, >>=20 >> Daniel >>=20 >> -----Original Message----- >> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >> Sent: Thursday, July 28, 2011 11:12 AM >> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>=20 >> Hi Greg- >> There is a difference between SF and SD. Converting SD into Down >> means that it will be interpreted exactly the same as SF, and if that's >> the case why have SD at all? If SD is necessary it must be somehow >> different from SD. >>=20 >> All- >>=20 >> Having said that, I'm not sure I disagree with Greg. It seems that >> this idea of propagating server layer SD up into TP is being done >> because there's no good way to do SD entirely within the TP layer. I >> suspect that if there were a way to do SD within the TP layer that made >> everyone happy, we wouldn't have the approach propsed in >> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >> draft is: >>=20 >> - we must have SD in TP because it is possible to do in other >> technologies >> - it is not possible to SD entirely within TP >> - therefore we must get SD from somewhere else >>=20 >> is a reasonable one. If we do that, where do we stop? Should we >> propagate information about signal quality up to TCP so it can adjust >> its windows according? (please note that this is intended to be a >> reductio ad absurdum question and not a serious one. :) ) >>=20 >>=20 >>=20 >> eric >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Greg Mirsky >>> Sent: Wednesday, July 27, 2011 2:08 PM >>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>=20 >>> Dear Authors and All, >>> I think that it is function of the PHY layer to detect SD condition >> and >>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >> Physical >>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>> measurement, in my view, is addressing the issue. >>>=20 >>> Regards, >>> Greg >>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Jul 28 12:54:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9411E811A for ; Thu, 28 Jul 2011 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lvxp31Rdchk for ; Thu, 28 Jul 2011 12:54:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2373E11E8075 for ; Thu, 28 Jul 2011 12:54:15 -0700 (PDT) Received: by qwc23 with SMTP id 23so2021676qwc.31 for ; Thu, 28 Jul 2011 12:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:to:from:cc:subject:date:mime-version:content-type; bh=7OFXLIrWqEogsx46YrfDdpGEwbT/vA/pP4IpFjRG3ks=; b=PAtV9gBeGHTSZy9YdsvUxwFjRYM5ZfzYX8sD9KXbAPreuxCQzhiTTcDYE8um5h4BQn 21TjWMjoka0AS3O7R3gjGez7wVt6UjP61LPRuTVGjd3pNvbk6eGsZdamJ0l29ycQC5hp sCvkpcMULm2f3gxjxEuJMIsqiFqNtzFSRQEn4= Received: by 10.229.238.201 with SMTP id kt9mr376350qcb.27.1311882854033; Thu, 28 Jul 2011 12:54:14 -0700 (PDT) Received: from [2001:df8:0:16:66a7:69ff:feb3:3267] ([2001:df8:0:16:66a7:69ff:feb3:3267]) by mx.google.com with ESMTPS id k5sm901450qct.45.2011.07.28.12.54.12 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:54:13 -0700 (PDT) Message-ID: <4e31be65.c586e50a.505a.2ca4@mx.google.com> To: "=?utf-8?B?U2FtIEFsZHJpbg==?=" From: "=?utf-8?B?aHV1YmF0d29ya0BnbWFpbC5jb20=?=" Date: Thu, 28 Jul 2011 15:54:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1311882849209" Cc: =?utf-8?B?bXBsc0BpZXRmLm9yZw==?= Subject: Re: [mpls] =?utf-8?q?Comments_to_draft-rkhd-mpls-tp-sd-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:54:16 -0000 ------=_Part_1_1311882849209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QW5kIHByb3BhZ2F0ZSB0byB0aGUgVkMxMiBjYXJyaWVkIEJ5IHRoZSBQVz8gCgpIdWl2aQoKVmVy em9uZGVuIHZhbiBtaWpuIEhUQwoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpWYW46ICJTYW0g QWxkcmluIiA8YWxkcmluLmlldGZAZ21haWwuY29tPgpBYW46ICJTaGFoLCBIaW1hbnNodSIgPGhz aGFoQGNpZW5hLmNvbT4KQ0M6ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4sICJ5YW5n LmppYW45MEB6dGUuY29tLmNuIiA8eWFuZy5qaWFuOTBAenRlLmNvbS5jbj4sICJtcy1kYWlrb2t1 QGtkZGkuY29tIiA8bXMtZGFpa29rdUBrZGRpLmNvbT4sICJSYWZpIFJhbSIgPFJhZmlSQG9yY2tp dC5jb20+Ck9uZGVyd2VycDogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1z ZC0wMwpEYXR1bTogZG8sIGp1bC4gMjgsIDIwMTEgMTU6MDQKCgpBbHNvLCBpZiB3ZSB3ZXJlIHRv IHByb3BhZ2F0ZSB0byBUcCwgd2h5IHN0b3AgdGhlcmU/IEl0IHNob3VsZCBiZSBwcm9wYWdhdGVk IHRvIFBXIGFzIHdlbGwsIHJpZ2h0PwoKU2FtCgpTZW50IGZyb20gbXkgaVBob25lCgpPbiBKdWwg MjgsIDIwMTEsIGF0IDI6NDEgUE0sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNvbT4g d3JvdGU6Cgo+IEkgYWdyZWUgd2l0aCBFcmljLCBTaGFocmFtIGFuZCBhY3R1YWxseSByaWNoYXJk IGthbSAoYWxjYXRlbC9sdWNlbnQpIG1hZGUgdGhpcyBleGFjdCBwb2ludCBhdCB0aGUgbWlrZQo+ IGR1cmluZyBwcmVzZW50YXRpb24uCj4gCj4gL2hpbWFuc2h1Cj4gCj4gCj4gCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFyaQo+IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDI6MzAgUE0KPiBUbzogRGFuaWVsIENvaG47IEdyZWcg TWlyc2t5Cj4gQ2M6IFJhZmkgUmFtOyBtcGxzQGlldGYub3JnOyBtcy1kYWlrb2t1QGtkZGkuY29t OyB5YW5nLmppYW45MEB6dGUuY29tLmNuCj4gU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyB0 byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMKPiAKPiBIaSwKPiAKPiBJIGFsc28gZG9uJ3QgYmVs aWV2ZSBTRCBpcyBuZWVkZWQgZm9yIE1QTFMtVFAuIFN1Y2ggZGVmZWN0IGlzIG5vdCByZWxhdGVk IHRvIE1QTFMtVFAgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGluIHRoZSBzZXJ2ZXIgbGF5ZXIsIHN1 Y2ggYXMgY2hhbmdpbmcgdGhlIEZFQyB0eXBlIGluIE9UTiwgZXRjLgo+IAo+IFJlZ2FyZHMsCj4g U2hhaHJhbQo+IAo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RGFuaWVsIENvaG4KPiBTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxMSAxMDoxNSBBTQo+IFRv OiBHcmVnIE1pcnNreQo+IENjOiBtcGxzQGlldGYub3JnOyB5YW5nLmppYW45MEB6dGUuY29tLmNu OyBtcy1kYWlrb2t1QGtkZGkuY29tOyBSYWZpIFJhbQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29t bWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzCj4gCj4gVHJ1ZSBlbm91Z2ggaW4gZ2Vu ZXJhbC4gQnV0IGluIHRoaXMgcGFydGljdWxhciBleGFtcGxlLCB0aGVyZSBpcyBub3RoaW5nIHN1 Z2dlc3RlZCBieSB0aGlzIGRyYWZ0IHRoYXQgcmVxdWlyZXMgaHVnZSBpbXBsZW1lbnRhdGlvbiBl ZmZvcnRzIG9yIHBhcmFkaWdtIGNoYW5nZXMuIFNvIEkgZmFpbCB0byBzZWUgd2h5IHdlIHNob3Vs ZCBzZXR0bGUgZm9yIGxlc3MgZnVuY3Rpb25hbGl0eSB0aGFuIGlzIGF2YWlsYWJsZSBpbiBleGlz dGluZyB0cmFuc3BvcnQgbmV0d29ya3MuCj4gCj4gREMKPiAKPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQo+IEZyb206IEdyZWcgTWlyc2t5IFttYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t XQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDE6MDAgUE0KPiBUbzogRGFuaWVsIENv aG4KPiBDYzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IFJhZmkgUmFtOyBtcy1kYWlrb2t1QGtk ZGkuY29tOyBtYS55dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJ0Fs ZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBtcGxzQGlldGYub3JnCj4gU3ViamVjdDogUmU6 IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMKPiAKPiBIaSBEYW5p ZWwsCj4gSSB0aGluayB0aGF0IHdoaWxlIHdlJ3JlIGJ1aWxkaW5nIE1QTFMtVFAgdG8gYmUgc3Vp dGVkIGZvciB0aGUKPiB0cmFuc3BvcnQgd2UgbmVlZCB0byByZW1lbWJlciB0aGF0IGl0LCBhcyBO ZWlsIHBvaW50ZWQgb3V0IG9uIG51bWJlcgo+IG9mIG9jY2FzaW9ucywgaXMgbm90IEJPUyBsYXll ciBhbmQgZG9lc24ndCBwdXQgYml0cyBvbiBhIHdpcmUuIFRodXMgaXQKPiBoYXMgY2hhcmFjdGVy aXN0aWMgdGhhdCBtYWtlcyBpdCBkaWZmZXJlbnQgZnJvbSBvdGhlciBsYXllcnMgb2YgYQo+IHRy YW5zcG9ydCBuZXR3b3JrIGFuZCwgSSB0aGluaywgYXMgcmVzdWx0IG5vdCBhbGwgZXhpc3Rpbmcg Y29uY2VwdHMgb2YKPiB0cmFuc3BvcnQgYXJlIGFwcGxpY2FibGUgdG8gcGFja2V0IGxheWVyIHJl YWxpemVkIGJ5IE1QTFMtVFAuCj4gCj4gUmVnYXJkcywKPiBHcmVnCj4gCj4gT24gVGh1LCBKdWwg MjgsIDIwMTEgYXQgOTo1MSBBTSwgRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbT4gd3Jv dGU6Cj4+IEhpIEVyaWMsCj4+IAo+PiBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgU0Qg aW4gVFAgaXMgYmVjYXVzZSBUUCBpcyBzdXBwb3NlZCB0bwo+PiBwcm92aWRlIHRoZSBzYW1lICJs b29rIGFuZCBmZWVsIiBvZiBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MsIGFzCj4+IHNwZWNp ZmllZCBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lgo+PiBUcmFuc3BvcnQgbmV0d29y a3MgdGVjaG5vbG9naWVzIGhhdmUgbG9uZyBzdXBwb3J0ZWQgdGhlIGRpc3RpbmN0aW9uCj4+IGJl dHdlZW4gImRlZ3JhZGVkIiBhbmQgIiBmYXVsdHkiLiBJbiBwYXJ0aWN1bGFyLCBwcm90ZWN0aW9u IHRlY2hub2xvZ2llcwo+PiBpbiB1c2UgaGF2ZSB0aGlzIGRpc3RpbmN0aW9uIGJ1aWx0IGludG8g dGhlIGlubmVybW9zdCByZWNlZGVzIG9mIHRoZWlyCj4+IHByb3RvY29scy4KPj4gRXZlbiBpbiB0 aGUgVFAgcmVxdWlyZW1lbnRzIGRpZG4ndCBzcGVsbCB0aGlzIG91dCwgSSB0aGluayBpdCB3b3Vs ZCBiZSBhCj4+IG1pc3Rha2Ugbm90IHRvIHRha2UgYWR2YW50YWdlIG9mIHllYXJzIG9mIGV4cGVy aWVuY2UgaW4gdHJhbnNwb3J0Cj4+IG5ldHdvcmtzIE9BTS4KPj4gCj4+IFJlZ2FyZHMsCj4+IAo+ PiBEYW5pZWwKPj4gCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZyb206IEVyaWMg T3Nib3JuZSAoZW9zYm9ybmUpIFttYWlsdG86ZW9zYm9ybmVAY2lzY28uY29tXQo+PiBTZW50OiBU aHVyc2RheSwgSnVseSAyOCwgMjAxMSAxMToxMiBBTQo+PiBUbzogR3JlZyBNaXJza3k7IERhbmll bCBDb2huOyBSYWZpIFJhbTsgbXMtZGFpa29rdUBrZGRpLmNvbTsKPj4gbWEueXV4aWFAenRlLmNv bS5jbjsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8KPj4g R2VyYXJkbzsgbXBsc0BpZXRmLm9yZwo+PiBTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIHRv IGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMwo+PiAKPj4gSGkgR3JlZy0KPj4gVGhlcmUgaXMgYSBk aWZmZXJlbmNlIGJldHdlZW4gU0YgYW5kIFNELiAgQ29udmVydGluZyBTRCBpbnRvIERvd24KPj4g bWVhbnMgdGhhdCBpdCB3aWxsIGJlIGludGVycHJldGVkIGV4YWN0bHkgdGhlIHNhbWUgYXMgU0Ys IGFuZCBpZiB0aGF0J3MKPj4gdGhlIGNhc2Ugd2h5IGhhdmUgU0QgYXQgYWxsPyAgSWYgU0QgaXMg bmVjZXNzYXJ5IGl0IG11c3QgYmUgc29tZWhvdwo+PiBkaWZmZXJlbnQgZnJvbSBTRC4KPj4gCj4+ IEFsbC0KPj4gCj4+IEhhdmluZyBzYWlkIHRoYXQsIEknbSBub3Qgc3VyZSBJIGRpc2FncmVlIHdp dGggR3JlZy4gIEl0IHNlZW1zIHRoYXQKPj4gdGhpcyBpZGVhIG9mIHByb3BhZ2F0aW5nIHNlcnZl ciBsYXllciBTRCB1cCBpbnRvIFRQIGlzIGJlaW5nIGRvbmUKPj4gYmVjYXVzZSB0aGVyZSdzIG5v IGdvb2Qgd2F5IHRvIGRvIFNEIGVudGlyZWx5IHdpdGhpbiB0aGUgVFAgbGF5ZXIuICBJCj4+IHN1 c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbiB0aGUgVFAgbGF5 ZXIgdGhhdCBtYWRlCj4+IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3VsZG4ndCBoYXZlIHRoZSBhcHBy b2FjaCBwcm9wc2VkIGluCj4+IGRyYWZ0LXJraGQtbXBscy10cC1zZC4gIEFuZCBJIHRoaW5rIHRo YXQgaWYgdGhlIG1vdGl2YXRpb24gZm9yIHRoaXMKPj4gZHJhZnQgaXM6Cj4+IAo+PiAtIHdlIG11 c3QgaGF2ZSBTRCBpbiBUUCBiZWNhdXNlIGl0IGlzIHBvc3NpYmxlIHRvIGRvIGluIG90aGVyCj4+ IHRlY2hub2xvZ2llcwo+PiAtIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBTRCBlbnRpcmVseSB3aXRo aW4gVFAKPj4gLSB0aGVyZWZvcmUgd2UgbXVzdCBnZXQgU0QgZnJvbSBzb21ld2hlcmUgZWxzZQo+ PiAKPj4gaXMgYSByZWFzb25hYmxlIG9uZS4gIElmIHdlIGRvIHRoYXQsIHdoZXJlIGRvIHdlIHN0 b3A/ICBTaG91bGQgd2UKPj4gcHJvcGFnYXRlIGluZm9ybWF0aW9uIGFib3V0IHNpZ25hbCBxdWFs aXR5IHVwIHRvIFRDUCBzbyBpdCBjYW4gYWRqdXN0Cj4+IGl0cyB3aW5kb3dzIGFjY29yZGluZz8g IChwbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmUgYQo+PiByZWR1Y3RpbyBh ZCBhYnN1cmR1bSBxdWVzdGlvbiBhbmQgbm90IGEgc2VyaW91cyBvbmUuIDopICkKPj4gCj4+IAo+ PiAKPj4gZXJpYwo+PiAKPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+PiBGcm9tOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZgo+PiBPZgo+Pj4gR3JlZyBNaXJza3kKPj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyNywg MjAxMSAyOjA4IFBNCj4+PiBUbzogRGFuaWVsIENvaG47IHJhZmlyQG9yY2tpdC5jb207IG1zLWRh aWtva3VAa2RkaS5jb207Cj4+PiBtYS55dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUu Y29tLmNuOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybwo+Pj4gR2VyYXJkbzsgbXBsc0BpZXRmLm9y Zwo+Pj4gU3ViamVjdDogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0w Mwo+Pj4gCj4+PiBEZWFyIEF1dGhvcnMgYW5kIEFsbCwKPj4+IEkgdGhpbmsgdGhhdCBpdCBpcyBm dW5jdGlvbiBvZiB0aGUgUEhZIGxheWVyIHRvIGRldGVjdCBTRCBjb25kaXRpb24KPj4gYW5kCj4+ PiBjb252ZXJ0IGl0IGludG8gRG93biBmb3IgdGhlIE1QTFMtVFAgTGF5ZXIgMCAod2hhdCB3ZSBy ZWZlciBhcwo+PiBQaHlzaWNhbAo+Pj4gU2VjdGlvbikuIEluIGNhc2Ugb2YgYWNjdW11bGF0aW5n IFNEIG92ZXIgTFNQIHRoZSBlMmUgUGFja2V0IExvc3MKPj4+IG1lYXN1cmVtZW50LCBpbiBteSB2 aWV3LCBpcyBhZGRyZXNzaW5nIHRoZSBpc3N1ZS4KPj4+IAo+Pj4gUmVnYXJkcywKPj4+IEdyZWcK Pj4gCj4+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gbXBscyBtYWlsaW5nIGxpc3QKPiBtcGxzQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBtcGxzIG1haWxpbmcgbGlzdAo+IG1wbHNAaWV0Zi5vcmcK PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMKPiAKPiAKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG1wbHMgbWFpbGlu ZyBsaXN0Cj4gbXBsc0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwptcGxzIG1haWxpbmcgbGlzdAptcGxzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscwo= ------=_Part_1_1311882849209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QW5kIHByb3BhZ2F0ZSB0byB0aGUgVkMxMiBjYXJyaWVkIEJ5IHRoZSBQVz8gPGJyPjxicj5IdWl2 aTxicj48YnI+VmVyem9uZGVuIHZhbiBtaWpuIEhUQzxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2Fn ZSAtLS0tLTxicj5WYW46ICZxdW90O1NhbSBBbGRyaW4mcXVvdDsgJmx0O2FsZHJpbi5pZXRmQGdt YWlsLmNvbSZndDs8YnI+QWFuOiAmcXVvdDtTaGFoLCBIaW1hbnNodSZxdW90OyAmbHQ7aHNoYWhA Y2llbmEuY29tJmd0Ozxicj5DQzogJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0Bp ZXRmLm9yZyZndDssICZxdW90O3lhbmcuamlhbjkwQHp0ZS5jb20uY24mcXVvdDsgJmx0O3lhbmcu amlhbjkwQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDttcy1kYWlrb2t1QGtkZGkuY29tJnF1b3Q7ICZs dDttcy1kYWlrb2t1QGtkZGkuY29tJmd0OywgJnF1b3Q7UmFmaSBSYW0mcXVvdDsgJmx0O1JhZmlS QG9yY2tpdC5jb20mZ3Q7PGJyPk9uZGVyd2VycDogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJr aGQtbXBscy10cC1zZC0wMzxicj5EYXR1bTogZG8sIGp1bC4gMjgsIDIwMTEgMTU6MDQ8YnI+PGJy Pjxicj5BbHNvLCBpZiB3ZSB3ZXJlIHRvIHByb3BhZ2F0ZSB0byBUcCwgd2h5IHN0b3AgdGhlcmU/ IEl0IHNob3VsZCBiZSBwcm9wYWdhdGVkIHRvIFBXIGFzIHdlbGwsIHJpZ2h0Pzxicj48YnI+U2Ft PGJyPjxicj5TZW50IGZyb20gbXkgaVBob25lPGJyPjxicj5PbiBKdWwgMjgsIDIwMTEsIGF0IDI6 NDEgUE0sICZxdW90O1NoYWgsIEhpbWFuc2h1JnF1b3Q7ICZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7 IHdyb3RlOjxicj48YnI+Jmd0OyBJIGFncmVlIHdpdGggRXJpYywgU2hhaHJhbSBhbmQgYWN0dWFs bHkgcmljaGFyZCBrYW0gKGFsY2F0ZWwvbHVjZW50KSBtYWRlIHRoaXMgZXhhY3QgcG9pbnQgYXQg dGhlIG1pa2U8YnI+Jmd0OyBkdXJpbmcgcHJlc2VudGF0aW9uLjxicj4mZ3Q7IDxicj4mZ3Q7IC9o aW1hbnNodTxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hhaHJhbSBEYXZhcmk8YnI+Jmd0 OyBTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxMSAyOjMwIFBNPGJyPiZndDsgVG86IERhbmll bCBDb2huOyBHcmVnIE1pcnNreTxicj4mZ3Q7IENjOiBSYWZpIFJhbTsgbXBsc0BpZXRmLm9yZzsg bXMtZGFpa29rdUBrZGRpLmNvbTsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjxicj4mZ3Q7IFN1Ympl Y3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzPGJyPiZn dDsgPGJyPiZndDsgSGksPGJyPiZndDsgPGJyPiZndDsgSSBhbHNvIGRvbiYjMzk7dCBiZWxpZXZl IFNEIGlzIG5lZWRlZCBmb3IgTVBMUy1UUC4gU3VjaCBkZWZlY3QgaXMgbm90IHJlbGF0ZWQgdG8g TVBMUy1UUCBhbmQgc2hvdWxkIGJlIGhhbmRsZWQgaW4gdGhlIHNlcnZlciBsYXllciwgc3VjaCBh cyBjaGFuZ2luZyB0aGUgRkVDIHR5cGUgaW4gT1ROLCBldGMuPGJyPiZndDsgPGJyPiZndDsgUmVn YXJkcyw8YnI+Jmd0OyBTaGFocmFtPGJyPiZndDsgPGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgQ29objxicj4mZ3Q7IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDEwOjE1IEFNPGJyPiZndDsgVG86IEdyZWcgTWlyc2t5 PGJyPiZndDsgQ2M6IG1wbHNAaWV0Zi5vcmc7IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IG1zLWRh aWtva3VAa2RkaS5jb207IFJhZmkgUmFtPGJyPiZndDsgU3ViamVjdDogUmU6IFttcGxzXSBDb21t ZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+Jmd0OyA8YnI+Jmd0OyBUcnVlIGVu b3VnaCBpbiBnZW5lcmFsLiBCdXQgaW4gdGhpcyBwYXJ0aWN1bGFyIGV4YW1wbGUsIHRoZXJlIGlz IG5vdGhpbmcgc3VnZ2VzdGVkIGJ5IHRoaXMgZHJhZnQgdGhhdCByZXF1aXJlcyBodWdlIGltcGxl bWVudGF0aW9uIGVmZm9ydHMgb3IgcGFyYWRpZ20gY2hhbmdlcy4gU28gSSBmYWlsIHRvIHNlZSB3 aHkgd2Ugc2hvdWxkIHNldHRsZSBmb3IgbGVzcyBmdW5jdGlvbmFsaXR5IHRoYW4gaXMgYXZhaWxh YmxlIGluIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3Jrcy48YnI+Jmd0OyA8YnI+Jmd0OyBEQzxi cj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTog R3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dPGJyPiZndDsgU2VudDog VGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTowMCBQTTxicj4mZ3Q7IFRvOiBEYW5pZWwgQ29objxi cj4mZ3Q7IENjOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgUmFmaSBSYW07IG1zLWRhaWtva3VA a2RkaS5jb207IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQm IzM5O0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBtcGxzQGlldGYub3JnPGJyPiZndDsg U3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8 YnI+Jmd0OyA8YnI+Jmd0OyBIaSBEYW5pZWwsPGJyPiZndDsgSSB0aGluayB0aGF0IHdoaWxlIHdl JiMzOTtyZSBidWlsZGluZyBNUExTLVRQIHRvIGJlIHN1aXRlZCBmb3IgdGhlPGJyPiZndDsgdHJh bnNwb3J0IHdlIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2ludGVkIG91dCBv biBudW1iZXI8YnI+Jmd0OyBvZiBvY2Nhc2lvbnMsIGlzIG5vdCBCT1MgbGF5ZXIgYW5kIGRvZXNu JiMzOTt0IHB1dCBiaXRzIG9uIGEgd2lyZS4gVGh1cyBpdDxicj4mZ3Q7IGhhcyBjaGFyYWN0ZXJp c3RpYyB0aGF0IG1ha2VzIGl0IGRpZmZlcmVudCBmcm9tIG90aGVyIGxheWVycyBvZiBhPGJyPiZn dDsgdHJhbnNwb3J0IG5ldHdvcmsgYW5kLCBJIHRoaW5rLCBhcyByZXN1bHQgbm90IGFsbCBleGlz dGluZyBjb25jZXB0cyBvZjxicj4mZ3Q7IHRyYW5zcG9ydCBhcmUgYXBwbGljYWJsZSB0byBwYWNr ZXQgbGF5ZXIgcmVhbGl6ZWQgYnkgTVBMUy1UUC48YnI+Jmd0OyA8YnI+Jmd0OyBSZWdhcmRzLDxi cj4mZ3Q7IEdyZWc8YnI+Jmd0OyA8YnI+Jmd0OyBPbiBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUx IEFNLCBEYW5pZWwgQ29obiAmbHQ7RGFuaWVsQ0BvcmNraXQuY29tJmd0OyB3cm90ZTo8YnI+Jmd0 OyZndDsgSGkgRXJpYyw8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IE9uZSBvZiB0aGUgcmVhc29u cyB3aHkgd2UgbmVlZCBTRCBpbiBUUCBpcyBiZWNhdXNlIFRQIGlzIHN1cHBvc2VkIHRvPGJyPiZn dDsmZ3Q7IHByb3ZpZGUgdGhlIHNhbWUgJnF1b3Q7bG9vayBhbmQgZmVlbCZxdW90OyBvZiBleGlz dGluZyB0cmFuc3BvcnQgbmV0d29ya3MsIGFzPGJyPiZndDsmZ3Q7IHNwZWNpZmllZCBpbiB0aGUg VFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50Ljxicj4mZ3Q7Jmd0OyBUcmFuc3BvcnQgbmV0d29ya3Mg dGVjaG5vbG9naWVzIGhhdmUgbG9uZyBzdXBwb3J0ZWQgdGhlIGRpc3RpbmN0aW9uPGJyPiZndDsm Z3Q7IGJldHdlZW4gJnF1b3Q7ZGVncmFkZWQmcXVvdDsgYW5kICZxdW90OyBmYXVsdHkmcXVvdDsu IEluIHBhcnRpY3VsYXIsIHByb3RlY3Rpb24gdGVjaG5vbG9naWVzPGJyPiZndDsmZ3Q7IGluIHVz ZSBoYXZlIHRoaXMgZGlzdGluY3Rpb24gYnVpbHQgaW50byB0aGUgaW5uZXJtb3N0IHJlY2VkZXMg b2YgdGhlaXI8YnI+Jmd0OyZndDsgcHJvdG9jb2xzLjxicj4mZ3Q7Jmd0OyBFdmVuIGluIHRoZSBU UCByZXF1aXJlbWVudHMgZGlkbiYjMzk7dCBzcGVsbCB0aGlzIG91dCwgSSB0aGluayBpdCB3b3Vs ZCBiZSBhPGJyPiZndDsmZ3Q7IG1pc3Rha2Ugbm90IHRvIHRha2UgYWR2YW50YWdlIG9mIHllYXJz IG9mIGV4cGVyaWVuY2UgaW4gdHJhbnNwb3J0PGJyPiZndDsmZ3Q7IG5ldHdvcmtzIE9BTS48YnI+ Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBE YW5pZWw8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPiZndDsmZ3Q7IEZyb206IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIFttYWlsdG86ZW9zYm9y bmVAY2lzY28uY29tXTxicj4mZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxMSAx MToxMiBBTTxicj4mZ3Q7Jmd0OyBUbzogR3JlZyBNaXJza3k7IERhbmllbCBDb2huOyBSYWZpIFJh bTsgbXMtZGFpa29rdUBrZGRpLmNvbTs8YnI+Jmd0OyZndDsgbWEueXV4aWFAenRlLmNvbS5jbjsg eWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCYjMzk7QWxlc3NhbmRybyBBbGVzc2FuZHJvPGJyPiZn dDsmZ3Q7IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgU3ViamVjdDogUkU6IFtt cGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+Jmd0OyZndDsgPGJy PiZndDsmZ3Q7IEhpIEdyZWctPGJyPiZndDsmZ3Q7IFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3 ZWVuIFNGIGFuZCBTRC4gJm5ic3A7Q29udmVydGluZyBTRCBpbnRvIERvd248YnI+Jmd0OyZndDsg bWVhbnMgdGhhdCBpdCB3aWxsIGJlIGludGVycHJldGVkIGV4YWN0bHkgdGhlIHNhbWUgYXMgU0Ys IGFuZCBpZiB0aGF0JiMzOTtzPGJyPiZndDsmZ3Q7IHRoZSBjYXNlIHdoeSBoYXZlIFNEIGF0IGFs bD8gJm5ic3A7SWYgU0QgaXMgbmVjZXNzYXJ5IGl0IG11c3QgYmUgc29tZWhvdzxicj4mZ3Q7Jmd0 OyBkaWZmZXJlbnQgZnJvbSBTRC48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEFsbC08YnI+Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEkmIzM5O20gbm90IHN1cmUgSSBk aXNhZ3JlZSB3aXRoIEdyZWcuICZuYnNwO0l0IHNlZW1zIHRoYXQ8YnI+Jmd0OyZndDsgdGhpcyBp ZGVhIG9mIHByb3BhZ2F0aW5nIHNlcnZlciBsYXllciBTRCB1cCBpbnRvIFRQIGlzIGJlaW5nIGRv bmU8YnI+Jmd0OyZndDsgYmVjYXVzZSB0aGVyZSYjMzk7cyBubyBnb29kIHdheSB0byBkbyBTRCBl bnRpcmVseSB3aXRoaW4gdGhlIFRQIGxheWVyLiAmbmJzcDtJPGJyPiZndDsmZ3Q7IHN1c3BlY3Qg dGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbiB0aGUgVFAgbGF5ZXIgdGhh dCBtYWRlPGJyPiZndDsmZ3Q7IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3VsZG4mIzM5O3QgaGF2ZSB0 aGUgYXBwcm9hY2ggcHJvcHNlZCBpbjxicj4mZ3Q7Jmd0OyBkcmFmdC1ya2hkLW1wbHMtdHAtc2Qu ICZuYnNwO0FuZCBJIHRoaW5rIHRoYXQgaWYgdGhlIG1vdGl2YXRpb24gZm9yIHRoaXM8YnI+Jmd0 OyZndDsgZHJhZnQgaXM6PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAtIHdlIG11c3QgaGF2ZSBT RCBpbiBUUCBiZWNhdXNlIGl0IGlzIHBvc3NpYmxlIHRvIGRvIGluIG90aGVyPGJyPiZndDsmZ3Q7 IHRlY2hub2xvZ2llczxicj4mZ3Q7Jmd0OyAtIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBTRCBlbnRp cmVseSB3aXRoaW4gVFA8YnI+Jmd0OyZndDsgLSB0aGVyZWZvcmUgd2UgbXVzdCBnZXQgU0QgZnJv bSBzb21ld2hlcmUgZWxzZTxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgaXMgYSByZWFzb25hYmxl IG9uZS4gJm5ic3A7SWYgd2UgZG8gdGhhdCwgd2hlcmUgZG8gd2Ugc3RvcD8gJm5ic3A7U2hvdWxk IHdlPGJyPiZndDsmZ3Q7IHByb3BhZ2F0ZSBpbmZvcm1hdGlvbiBhYm91dCBzaWduYWwgcXVhbGl0 eSB1cCB0byBUQ1Agc28gaXQgY2FuIGFkanVzdDxicj4mZ3Q7Jmd0OyBpdHMgd2luZG93cyBhY2Nv cmRpbmc/ICZuYnNwOyhwbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmUgYTxi cj4mZ3Q7Jmd0OyByZWR1Y3RpbyBhZCBhYnN1cmR1bSBxdWVzdGlvbiBhbmQgbm90IGEgc2VyaW91 cyBvbmUuIDopICk8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsgZXJpYzxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZjxicj4mZ3Q7Jmd0OyBPZjxicj4m Z3Q7Jmd0OyZndDsgR3JlZyBNaXJza3k8YnI+Jmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg SnVseSAyNywgMjAxMSAyOjA4IFBNPGJyPiZndDsmZ3Q7Jmd0OyBUbzogRGFuaWVsIENvaG47IHJh ZmlyQG9yY2tpdC5jb207IG1zLWRhaWtva3VAa2RkaS5jb207PGJyPiZndDsmZ3Q7Jmd0OyBtYS55 dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJiMzOTtBbGVzc2FuZHJv IEFsZXNzYW5kcm88YnI+Jmd0OyZndDsmZ3Q7IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmc8YnI+Jmd0 OyZndDsmZ3Q7IFN1YmplY3Q6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAt c2QtMDM8YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgRGVhciBBdXRob3JzIGFuZCBB bGwsPGJyPiZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgaXQgaXMgZnVuY3Rpb24gb2YgdGhlIFBI WSBsYXllciB0byBkZXRlY3QgU0QgY29uZGl0aW9uPGJyPiZndDsmZ3Q7IGFuZDxicj4mZ3Q7Jmd0 OyZndDsgY29udmVydCBpdCBpbnRvIERvd24gZm9yIHRoZSBNUExTLVRQIExheWVyIDAgKHdoYXQg d2UgcmVmZXIgYXM8YnI+Jmd0OyZndDsgUGh5c2ljYWw8YnI+Jmd0OyZndDsmZ3Q7IFNlY3Rpb24p LiBJbiBjYXNlIG9mIGFjY3VtdWxhdGluZyBTRCBvdmVyIExTUCB0aGUgZTJlIFBhY2tldCBMb3Nz PGJyPiZndDsmZ3Q7Jmd0OyBtZWFzdXJlbWVudCwgaW4gbXkgdmlldywgaXMgYWRkcmVzc2luZyB0 aGUgaXNzdWUuPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPiZn dDsmZ3Q7Jmd0OyBHcmVnPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IG1wbHMgbWFp bGluZyBsaXN0PGJyPiZndDsgbXBsc0BpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgbXBscyBtYWlsaW5nIGxp c3Q8YnI+Jmd0OyBtcGxzQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBtcGxzIG1haWxpbmcg bGlzdDxicj4mZ3Q7IG1wbHNAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+bXBscyBtYWlsaW5nIGxpc3Q8YnI+bXBsc0BpZXRmLm9yZzxicj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+ ------=_Part_1_1311882849209-- From huubatwork@gmail.com Thu Jul 28 13:12:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6821F8A7B for ; Thu, 28 Jul 2011 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFtiAN94Qifr for ; Thu, 28 Jul 2011 13:12:18 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BE21F8A70 for ; Thu, 28 Jul 2011 13:12:17 -0700 (PDT) Received: by qyk9 with SMTP id 9so3359663qyk.10 for ; Thu, 28 Jul 2011 13:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tlP1wMRBsu5Sycbg/0Nt847tKxAat9YzA2+eY8CBGeY=; b=GHE3QcCD5AkXiMKT3HMIaPZ6jdi8aeSwfis14J1zTd5Np4LL0Yv4tlMwE7kxYtKTMF xap4Ebu7KE5H98QLfRmvL7j432L49YtchwZc4oXAFNrznAfXAw0K/T5eCI7mll59GGqy qeyqV4CdevSxsBezX424sJxLYmojhy6BK635M= Received: by 10.224.196.67 with SMTP id ef3mr384080qab.157.1311883936692; Thu, 28 Jul 2011 13:12:16 -0700 (PDT) Received: from dhcp-166c.meeting.ietf.org (dhcp-166c.meeting.ietf.org [130.129.22.108]) by mx.google.com with ESMTPS id w12sm917763qct.24.2011.07.28.13.12.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 13:12:16 -0700 (PDT) Message-ID: <4E31C29F.1010302@gmail.com> Date: Thu, 28 Jul 2011 22:12:15 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> In-Reply-To: <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:12:19 -0000 And propagate to the VC12 carried By the PW? and... Huub > Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right? > > Sam > > Sent from my iPhone > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike >> during presentation. >> >> /himanshu >> >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, July 28, 2011 2:30 PM >> To: Daniel Cohn; Greg Mirsky >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi, >> >> I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn >> Sent: Thursday, July 28, 2011 10:15 AM >> To: Greg Mirsky >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks. >> >> DC >> >> -----Original Message----- >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> Sent: Thursday, July 28, 2011 1:00 PM >> To: Daniel Cohn >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi Daniel, >> I think that while we're building MPLS-TP to be suited for the >> transport we need to remember that it, as Neil pointed out on number >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus it >> has characteristic that makes it different from other layers of a >> transport network and, I think, as result not all existing concepts of >> transport are applicable to packet layer realized by MPLS-TP. >> >> Regards, >> Greg >> >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >>> Hi Eric, >>> >>> One of the reasons why we need SD in TP is because TP is supposed to >>> provide the same "look and feel" of existing transport networks, as >>> specified in the TP requirements document. >>> Transport networks technologies have long supported the distinction >>> between "degraded" and " faulty". In particular, protection technologies >>> in use have this distinction built into the innermost recedes of their >>> protocols. >>> Even in the TP requirements didn't spell this out, I think it would be a >>> mistake not to take advantage of years of experience in transport >>> networks OAM. >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>> Sent: Thursday, July 28, 2011 11:12 AM >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi Greg- >>> There is a difference between SF and SD. Converting SD into Down >>> means that it will be interpreted exactly the same as SF, and if that's >>> the case why have SD at all? If SD is necessary it must be somehow >>> different from SD. >>> >>> All- >>> >>> Having said that, I'm not sure I disagree with Greg. It seems that >>> this idea of propagating server layer SD up into TP is being done >>> because there's no good way to do SD entirely within the TP layer. I >>> suspect that if there were a way to do SD within the TP layer that made >>> everyone happy, we wouldn't have the approach propsed in >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>> draft is: >>> >>> - we must have SD in TP because it is possible to do in other >>> technologies >>> - it is not possible to SD entirely within TP >>> - therefore we must get SD from somewhere else >>> >>> is a reasonable one. If we do that, where do we stop? Should we >>> propagate information about signal quality up to TCP so it can adjust >>> its windows according? (please note that this is intended to be a >>> reductio ad absurdum question and not a serious one. :) ) >>> >>> >>> >>> eric >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Greg Mirsky >>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>>> Gerardo; mpls@ietf.org >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Dear Authors and All, >>>> I think that it is function of the PHY layer to detect SD condition >>> and >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>> Physical >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>> measurement, in my view, is addressing the issue. >>>> >>>> Regards, >>>> Greg From DanielC@orckit.com Thu Jul 28 13:16:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29921F8B25 for ; Thu, 28 Jul 2011 13:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUf3AkaYPn-s for ; Thu, 28 Jul 2011 13:16:52 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F721F8AE1 for ; Thu, 28 Jul 2011 13:16:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 23:16:47 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> In-reply-to: <4E31C29F.1010302@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNYxI/UoJQXmKPTay9zsytRCDvAAAAFoUw References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> From: "Daniel Cohn" To: , Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:16:53 -0000 I don't think sending iterative e-mails referring to ever higher layer serves the point of this discussion. A similar argument can be made on e.g. other technologies sending AIS-like indications on all client layers. I think we should focus on what Pablo wrote, i.e. do we want to provide SD to MPLS layers, like existing transport networks, or not? And if we do, what is the best way to do it? DC PS: No need to, the VC12 has its own SD detection capabilities. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Thursday, July 28, 2011 4:12 PM To: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 And propagate to the VC12 carried By the PW? and... Huub > Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right? > > Sam > > Sent from my iPhone > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike >> during presentation. >> >> /himanshu >> >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, July 28, 2011 2:30 PM >> To: Daniel Cohn; Greg Mirsky >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi, >> >> I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn >> Sent: Thursday, July 28, 2011 10:15 AM >> To: Greg Mirsky >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks. >> >> DC >> >> -----Original Message----- >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> Sent: Thursday, July 28, 2011 1:00 PM >> To: Daniel Cohn >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi Daniel, >> I think that while we're building MPLS-TP to be suited for the >> transport we need to remember that it, as Neil pointed out on number >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus it >> has characteristic that makes it different from other layers of a >> transport network and, I think, as result not all existing concepts of >> transport are applicable to packet layer realized by MPLS-TP. >> >> Regards, >> Greg >> >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >>> Hi Eric, >>> >>> One of the reasons why we need SD in TP is because TP is supposed to >>> provide the same "look and feel" of existing transport networks, as >>> specified in the TP requirements document. >>> Transport networks technologies have long supported the distinction >>> between "degraded" and " faulty". In particular, protection technologies >>> in use have this distinction built into the innermost recedes of their >>> protocols. >>> Even in the TP requirements didn't spell this out, I think it would be a >>> mistake not to take advantage of years of experience in transport >>> networks OAM. >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>> Sent: Thursday, July 28, 2011 11:12 AM >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi Greg- >>> There is a difference between SF and SD. Converting SD into Down >>> means that it will be interpreted exactly the same as SF, and if that's >>> the case why have SD at all? If SD is necessary it must be somehow >>> different from SD. >>> >>> All- >>> >>> Having said that, I'm not sure I disagree with Greg. It seems that >>> this idea of propagating server layer SD up into TP is being done >>> because there's no good way to do SD entirely within the TP layer. I >>> suspect that if there were a way to do SD within the TP layer that made >>> everyone happy, we wouldn't have the approach propsed in >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>> draft is: >>> >>> - we must have SD in TP because it is possible to do in other >>> technologies >>> - it is not possible to SD entirely within TP >>> - therefore we must get SD from somewhere else >>> >>> is a reasonable one. If we do that, where do we stop? Should we >>> propagate information about signal quality up to TCP so it can adjust >>> its windows according? (please note that this is intended to be a >>> reductio ad absurdum question and not a serious one. :) ) >>> >>> >>> >>> eric >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Greg Mirsky >>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>>> Gerardo; mpls@ietf.org >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Dear Authors and All, >>>> I think that it is function of the PHY layer to detect SD condition >>> and >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>> Physical >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>> measurement, in my view, is addressing the issue. >>>> >>>> Regards, >>>> Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Jul 28 13:31:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F011E8091 for ; Thu, 28 Jul 2011 13:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9AUETUfAhtt for ; Thu, 28 Jul 2011 13:31:52 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4AD11E8081 for ; Thu, 28 Jul 2011 13:31:52 -0700 (PDT) Received: by qwc23 with SMTP id 23so2038884qwc.31 for ; Thu, 28 Jul 2011 13:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U03iqyOjeMy8g38K4udQgf69qALf7TVA6rjavoYrw1o=; b=sk0q10ZMGYk8kEdakM0K3b+jxMAGUKnA3ASwkerrEkpW5AWGcCKArppbJ3t7fdho5r 5HpQzxfEZsS6C/rnw1iCT46at2YPnEUpplEv8CY8p7EgyKsIq9IkpbKHvsdxT5u21muc B2cT3lMAuonKK4uB5DMQvRrILlFU93qmltiak= Received: by 10.224.191.201 with SMTP id dn9mr10886qab.95.1311885111624; Thu, 28 Jul 2011 13:31:51 -0700 (PDT) Received: from dhcp-166c.meeting.ietf.org (dhcp-166c.meeting.ietf.org [130.129.22.108]) by mx.google.com with ESMTPS id k5sm924321qct.45.2011.07.28.13.31.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 13:31:51 -0700 (PDT) Message-ID: <4E31C736.5040306@gmail.com> Date: Thu, 28 Jul 2011 22:31:50 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:31:53 -0000 Hi Daniel Cohn You wrote: > I don't think sending iterative e-mails referring to ever higher layer > serves the point of this discussion. OK, ---8<---snipped > PS: No need to, the VC12 has its own SD detection capabilities. So why don't we define SD (service degrade) defect detection criteria for MPLS-TP? In stead of relying on SD (signal degrade) defect detect mechanisms in other technologies. BR, Huub. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:12 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > And propagate to the VC12 carried By the PW? > and... > > Huub > > > >> Also, if we were to propagate to Tp, why stop there? It should be > propagated to PW as well, right? >> >> Sam >> >> Sent from my iPhone >> >> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: >> >>> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > made this exact point at the mike >>> during presentation. >>> >>> /himanshu >>> >>> >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Shahram Davari >>> Sent: Thursday, July 28, 2011 2:30 PM >>> To: Daniel Cohn; Greg Mirsky >>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > yang.jian90@zte.com.cn >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi, >>> >>> I also don't believe SD is needed for MPLS-TP. Such defect is not > related to MPLS-TP and should be handled in the server layer, such as > changing the FEC type in OTN, etc. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Daniel Cohn >>> Sent: Thursday, July 28, 2011 10:15 AM >>> To: Greg Mirsky >>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > Ram >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> True enough in general. But in this particular example, there is > nothing suggested by this draft that requires huge implementation > efforts or paradigm changes. So I fail to see why we should settle for > less functionality than is available in existing transport networks. >>> >>> DC >>> >>> -----Original Message----- >>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >>> Sent: Thursday, July 28, 2011 1:00 PM >>> To: Daniel Cohn >>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi Daniel, >>> I think that while we're building MPLS-TP to be suited for the >>> transport we need to remember that it, as Neil pointed out on number >>> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > it >>> has characteristic that makes it different from other layers of a >>> transport network and, I think, as result not all existing concepts > of >>> transport are applicable to packet layer realized by MPLS-TP. >>> >>> Regards, >>> Greg >>> >>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: >>>> Hi Eric, >>>> >>>> One of the reasons why we need SD in TP is because TP is supposed to >>>> provide the same "look and feel" of existing transport networks, as >>>> specified in the TP requirements document. >>>> Transport networks technologies have long supported the distinction >>>> between "degraded" and " faulty". In particular, protection > technologies >>>> in use have this distinction built into the innermost recedes of > their >>>> protocols. >>>> Even in the TP requirements didn't spell this out, I think it would > be a >>>> mistake not to take advantage of years of experience in transport >>>> networks OAM. >>>> >>>> Regards, >>>> >>>> Daniel >>>> >>>> -----Original Message----- >>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>>> Sent: Thursday, July 28, 2011 11:12 AM >>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>>> Gerardo; mpls@ietf.org >>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Hi Greg- >>>> There is a difference between SF and SD. Converting SD into Down >>>> means that it will be interpreted exactly the same as SF, and if > that's >>>> the case why have SD at all? If SD is necessary it must be somehow >>>> different from SD. >>>> >>>> All- >>>> >>>> Having said that, I'm not sure I disagree with Greg. It seems that >>>> this idea of propagating server layer SD up into TP is being done >>>> because there's no good way to do SD entirely within the TP layer. > I >>>> suspect that if there were a way to do SD within the TP layer that > made >>>> everyone happy, we wouldn't have the approach propsed in >>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>>> draft is: >>>> >>>> - we must have SD in TP because it is possible to do in other >>>> technologies >>>> - it is not possible to SD entirely within TP >>>> - therefore we must get SD from somewhere else >>>> >>>> is a reasonable one. If we do that, where do we stop? Should we >>>> propagate information about signal quality up to TCP so it can > adjust >>>> its windows according? (please note that this is intended to be a >>>> reductio ad absurdum question and not a serious one. :) ) >>>> >>>> >>>> >>>> eric >>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf >>>> Of >>>>> Greg Mirsky >>>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro >>>>> Gerardo; mpls@ietf.org >>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>> >>>>> Dear Authors and All, >>>>> I think that it is function of the PHY layer to detect SD condition >>>> and >>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>>> Physical >>>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>>> measurement, in my view, is addressing the issue. >>>>> >>>>> Regards, >>>>> Greg From DanielC@orckit.com Thu Jul 28 13:37:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F835E8009 for ; Thu, 28 Jul 2011 13:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPy3li0Zirew for ; Thu, 28 Jul 2011 13:37:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 874CF5E800E for ; Thu, 28 Jul 2011 13:37:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 23:36:49 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> In-reply-to: <4E31C736.5040306@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNZcsfFQ9/ZTLGSoWTU+bWqEaNiAAAEl4g References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com><4E31C29F.1010302@gmail.com><44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> <4E31C736.5040306@gmail.com> From: "Daniel Cohn" To: , Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:37:05 -0000 Hi Huub, Can propose a TP-based detection method that can detect only physical errors, i.e. without being influenced by non-physical conditions such as congestion, CPU overload, etc.? If you can, by all means do so, it would greatly serve the purpose of this discussion. Thanks, Daniel -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Thursday, July 28, 2011 4:32 PM To: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Hi Daniel Cohn You wrote: > I don't think sending iterative e-mails referring to ever higher layer > serves the point of this discussion. OK, ---8<---snipped > PS: No need to, the VC12 has its own SD detection capabilities. So why don't we define SD (service degrade) defect detection criteria for MPLS-TP? In stead of relying on SD (signal degrade) defect detect mechanisms in other technologies. BR, Huub. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:12 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > And propagate to the VC12 carried By the PW? > and... > > Huub > > > >> Also, if we were to propagate to Tp, why stop there? It should be > propagated to PW as well, right? >> >> Sam >> >> Sent from my iPhone >> >> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: >> >>> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > made this exact point at the mike >>> during presentation. >>> >>> /himanshu >>> >>> >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Shahram Davari >>> Sent: Thursday, July 28, 2011 2:30 PM >>> To: Daniel Cohn; Greg Mirsky >>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > yang.jian90@zte.com.cn >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi, >>> >>> I also don't believe SD is needed for MPLS-TP. Such defect is not > related to MPLS-TP and should be handled in the server layer, such as > changing the FEC type in OTN, etc. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Daniel Cohn >>> Sent: Thursday, July 28, 2011 10:15 AM >>> To: Greg Mirsky >>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > Ram >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> True enough in general. But in this particular example, there is > nothing suggested by this draft that requires huge implementation > efforts or paradigm changes. So I fail to see why we should settle for > less functionality than is available in existing transport networks. >>> >>> DC >>> >>> -----Original Message----- >>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >>> Sent: Thursday, July 28, 2011 1:00 PM >>> To: Daniel Cohn >>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi Daniel, >>> I think that while we're building MPLS-TP to be suited for the >>> transport we need to remember that it, as Neil pointed out on number >>> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > it >>> has characteristic that makes it different from other layers of a >>> transport network and, I think, as result not all existing concepts > of >>> transport are applicable to packet layer realized by MPLS-TP. >>> >>> Regards, >>> Greg >>> >>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: >>>> Hi Eric, >>>> >>>> One of the reasons why we need SD in TP is because TP is supposed to >>>> provide the same "look and feel" of existing transport networks, as >>>> specified in the TP requirements document. >>>> Transport networks technologies have long supported the distinction >>>> between "degraded" and " faulty". In particular, protection > technologies >>>> in use have this distinction built into the innermost recedes of > their >>>> protocols. >>>> Even in the TP requirements didn't spell this out, I think it would > be a >>>> mistake not to take advantage of years of experience in transport >>>> networks OAM. >>>> >>>> Regards, >>>> >>>> Daniel >>>> >>>> -----Original Message----- >>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>>> Sent: Thursday, July 28, 2011 11:12 AM >>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>>> Gerardo; mpls@ietf.org >>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Hi Greg- >>>> There is a difference between SF and SD. Converting SD into Down >>>> means that it will be interpreted exactly the same as SF, and if > that's >>>> the case why have SD at all? If SD is necessary it must be somehow >>>> different from SD. >>>> >>>> All- >>>> >>>> Having said that, I'm not sure I disagree with Greg. It seems that >>>> this idea of propagating server layer SD up into TP is being done >>>> because there's no good way to do SD entirely within the TP layer. > I >>>> suspect that if there were a way to do SD within the TP layer that > made >>>> everyone happy, we wouldn't have the approach propsed in >>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>>> draft is: >>>> >>>> - we must have SD in TP because it is possible to do in other >>>> technologies >>>> - it is not possible to SD entirely within TP >>>> - therefore we must get SD from somewhere else >>>> >>>> is a reasonable one. If we do that, where do we stop? Should we >>>> propagate information about signal quality up to TCP so it can > adjust >>>> its windows according? (please note that this is intended to be a >>>> reductio ad absurdum question and not a serious one. :) ) >>>> >>>> >>>> >>>> eric >>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf >>>> Of >>>>> Greg Mirsky >>>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro >>>>> Gerardo; mpls@ietf.org >>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>> >>>>> Dear Authors and All, >>>>> I think that it is function of the PHY layer to detect SD condition >>>> and >>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>>> Physical >>>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>>> measurement, in my view, is addressing the issue. >>>>> >>>>> Regards, >>>>> Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Thu Jul 28 13:37:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74311E817A for ; Thu, 28 Jul 2011 13:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZkGMejM0Hdi for ; Thu, 28 Jul 2011 13:37:53 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 346FF11E8169 for ; Thu, 28 Jul 2011 13:37:52 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 28 Jul 2011 21:37:51 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 28 Jul 2011 21:37:51 +0100 From: To: , , Date: Thu, 28 Jul 2011 21:37:46 +0100 Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNYxI/UoJQXmKPTay9zsytRCDvAAAAFoUwAABpX3A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D4312A0@EMV62-UKRD.domain1.systemhost.net> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:37:54 -0000 Daniel Cohn wrote 28 July 2011 21:17 > I don't think sending iterative e-mails referring to ever higher layer > serves the point of this discussion.=20 NH=3D> I thinks Huub's mail makes the point excellently..as have other befo= re him. =20 The general principle is that we should not be functionally coupling differ= ent layer networks....so in the case of OAM we should not be indicating upw= ards or (even worse) downwards specific OAM messages between pairs of layer= networks...each layer should be indepedent. The reality sadly is that we are not very good at doing this, eg "access ci= rcuit" (sic) <=3D> PW defect OAM mappings is about as wrong as you can get = it. However the principle of layer independence is correct. Indeed 'IP over ev= erything' is based on the requirement for strict adherence to this layer in= depedence principle (to protect IP). The 'common CP myth' is yet another example of where have gone wrong in try= ing to couple different layer networks....and it plain does not work. > A similar argument can be made on > e.g. other technologies sending AIS-like indications on all client > layers. NH=3D> Careful. AIS is very bad idea for all pkt-based layer networks. It= is only forced when we have regular-time slices of resource as in the co-c= s TDM layer networks and where we must fill the resource TS with something.= ...the traditional all-1s signature comes from how PDH layer network TTL lo= gic used would fail (to +5V). Life is not this in packet-based networks...= so carrying over this behaviour is not a good idea at all. =20 regards, Neil > I think we should focus on what Pablo wrote, i.e. do we want to provide > SD to MPLS layers, like existing transport networks, or not? And if we > do, what is the best way to do it? >=20 > DC >=20 > PS: No need to, the VC12 has its own SD detection capabilities. >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:12 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >=20 > And propagate to the VC12 carried By the PW? > and... >=20 > Huub >=20 >=20 >=20 > > Also, if we were to propagate to Tp, why stop there? It should be > propagated to PW as well, right? > > > > Sam > > > > Sent from my iPhone > > > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" > wrote: > > > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > made this exact point at the mike > >> during presentation. > >> > >> /himanshu > >> > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Shahram Davari > >> Sent: Thursday, July 28, 2011 2:30 PM > >> To: Daniel Cohn; Greg Mirsky > >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > yang.jian90@zte.com.cn > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi, > >> > >> I also don't believe SD is needed for MPLS-TP. Such defect is not > related to MPLS-TP and should be handled in the server layer, such as > changing the FEC type in OTN, etc. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Daniel Cohn > >> Sent: Thursday, July 28, 2011 10:15 AM > >> To: Greg Mirsky > >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > Ram > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> True enough in general. But in this particular example, there is > nothing suggested by this draft that requires huge implementation > efforts or paradigm changes. So I fail to see why we should settle for > less functionality than is available in existing transport networks. > >> > >> DC > >> > >> -----Original Message----- > >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> Sent: Thursday, July 28, 2011 1:00 PM > >> To: Daniel Cohn > >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi Daniel, > >> I think that while we're building MPLS-TP to be suited for the > >> transport we need to remember that it, as Neil pointed out on number > >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > it > >> has characteristic that makes it different from other layers of a > >> transport network and, I think, as result not all existing concepts > of > >> transport are applicable to packet layer realized by MPLS-TP. > >> > >> Regards, > >> Greg > >> > >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: > >>> Hi Eric, > >>> > >>> One of the reasons why we need SD in TP is because TP is supposed > to > >>> provide the same "look and feel" of existing transport networks, as > >>> specified in the TP requirements document. > >>> Transport networks technologies have long supported the distinction > >>> between "degraded" and " faulty". In particular, protection > technologies > >>> in use have this distinction built into the innermost recedes of > their > >>> protocols. > >>> Even in the TP requirements didn't spell this out, I think it would > be a > >>> mistake not to take advantage of years of experience in transport > >>> networks OAM. > >>> > >>> Regards, > >>> > >>> Daniel > >>> > >>> -----Original Message----- > >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > >>> Sent: Thursday, July 28, 2011 11:12 AM > >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > >>> Gerardo; mpls@ietf.org > >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> Hi Greg- > >>> There is a difference between SF and SD. Converting SD into Down > >>> means that it will be interpreted exactly the same as SF, and if > that's > >>> the case why have SD at all? If SD is necessary it must be somehow > >>> different from SD. > >>> > >>> All- > >>> > >>> Having said that, I'm not sure I disagree with Greg. It seems that > >>> this idea of propagating server layer SD up into TP is being done > >>> because there's no good way to do SD entirely within the TP layer. > I > >>> suspect that if there were a way to do SD within the TP layer that > made > >>> everyone happy, we wouldn't have the approach propsed in > >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > >>> draft is: > >>> > >>> - we must have SD in TP because it is possible to do in other > >>> technologies > >>> - it is not possible to SD entirely within TP > >>> - therefore we must get SD from somewhere else > >>> > >>> is a reasonable one. If we do that, where do we stop? Should we > >>> propagate information about signal quality up to TCP so it can > adjust > >>> its windows according? (please note that this is intended to be a > >>> reductio ad absurdum question and not a serious one. :) ) > >>> > >>> > >>> > >>> eric > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >>> Of > >>>> Greg Mirsky > >>>> Sent: Wednesday, July 27, 2011 2:08 PM > >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > >>>> Gerardo; mpls@ietf.org > >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Dear Authors and All, > >>>> I think that it is function of the PHY layer to detect SD > condition > >>> and > >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > >>> Physical > >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss > >>>> measurement, in my view, is addressing the issue. > >>>> > >>>> Regards, > >>>> Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Jul 28 13:48:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F69021F8ABE for ; Thu, 28 Jul 2011 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdZsEtXCLNGM for ; Thu, 28 Jul 2011 13:48:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1021F8ABD for ; Thu, 28 Jul 2011 13:48:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so2046523qwc.31 for ; Thu, 28 Jul 2011 13:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=M6w/tPE7KtW0PRVRv/CjW0/oLqNJDFsYoTr0XLgG+6k=; b=t8Q1DWg89gBKCf1WOqtKNrODHIxcOfkT8RGhicq8NRI17cHjQejcELpxYIieScLOzw +PKgiRsY+lw8+59sk6bnYgo+OVP57Xqt7nHoAZCZDRAgt0BUbPyjTKewzHUNl0u06P8W yoEiQkCffkaSW0VBPI58I2ZyVE5OLNPH6T6mQ= Received: by 10.224.193.72 with SMTP id dt8mr385814qab.331.1311886111841; Thu, 28 Jul 2011 13:48:31 -0700 (PDT) Received: from dhcp-166c.meeting.ietf.org (dhcp-166c.meeting.ietf.org [130.129.22.108]) by mx.google.com with ESMTPS id e10sm943601qcq.4.2011.07.28.13.48.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 13:48:31 -0700 (PDT) Message-ID: <4E31CB1E.7080004@gmail.com> Date: Thu, 28 Jul 2011 22:48:30 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com><4E31C29F.1010302@gmail.com><44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> <4E31C736.5040306@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:48:34 -0000 Hi Daniel, You replied: > Can propose a TP-based detection method that can detect only physical > errors, i.e. without being influenced by non-physical conditions such as > congestion, CPU overload, etc.? So as a customer I should only complain about degraded service if it is caused by physical errors... I have never seen SLAs with this restriction. We should use the characteristics of the technology to detect any issues with the transport of the characteristic information. Regards, Huub. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:32 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Daniel Cohn > > You wrote: > >> I don't think sending iterative e-mails referring to ever higher layer >> serves the point of this discussion. > > OK, ---8<---snipped > >> PS: No need to, the VC12 has its own SD detection capabilities. > > So why don't we define SD (service degrade) defect detection criteria > for MPLS-TP? > In stead of relying on SD (signal degrade) defect detect mechanisms in > other technologies. > > BR, Huub. > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Huub van Helvoort >> Sent: Thursday, July 28, 2011 4:12 PM >> To: mpls@ietf.org >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> And propagate to the VC12 carried By the PW? >> and... >> >> Huub >> >> >> >>> Also, if we were to propagate to Tp, why stop there? It should be >> propagated to PW as well, right? >>> >>> Sam >>> >>> Sent from my iPhone >>> >>> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" > wrote: >>> >>>> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) >> made this exact point at the mike >>>> during presentation. >>>> >>>> /himanshu >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Shahram Davari >>>> Sent: Thursday, July 28, 2011 2:30 PM >>>> To: Daniel Cohn; Greg Mirsky >>>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; >> yang.jian90@zte.com.cn >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Hi, >>>> >>>> I also don't believe SD is needed for MPLS-TP. Such defect is not >> related to MPLS-TP and should be handled in the server layer, such as >> changing the FEC type in OTN, etc. >>>> >>>> Regards, >>>> Shahram >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Daniel Cohn >>>> Sent: Thursday, July 28, 2011 10:15 AM >>>> To: Greg Mirsky >>>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi >> Ram >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> True enough in general. But in this particular example, there is >> nothing suggested by this draft that requires huge implementation >> efforts or paradigm changes. So I fail to see why we should settle for >> less functionality than is available in existing transport networks. >>>> >>>> DC >>>> >>>> -----Original Message----- >>>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >>>> Sent: Thursday, July 28, 2011 1:00 PM >>>> To: Daniel Cohn >>>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> Gerardo; mpls@ietf.org >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Hi Daniel, >>>> I think that while we're building MPLS-TP to be suited for the >>>> transport we need to remember that it, as Neil pointed out on number >>>> of occasions, is not BOS layer and doesn't put bits on a wire. Thus >> it >>>> has characteristic that makes it different from other layers of a >>>> transport network and, I think, as result not all existing concepts >> of >>>> transport are applicable to packet layer realized by MPLS-TP. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn >> wrote: >>>>> Hi Eric, >>>>> >>>>> One of the reasons why we need SD in TP is because TP is supposed > to >>>>> provide the same "look and feel" of existing transport networks, as >>>>> specified in the TP requirements document. >>>>> Transport networks technologies have long supported the distinction >>>>> between "degraded" and " faulty". In particular, protection >> technologies >>>>> in use have this distinction built into the innermost recedes of >> their >>>>> protocols. >>>>> Even in the TP requirements didn't spell this out, I think it would >> be a >>>>> mistake not to take advantage of years of experience in transport >>>>> networks OAM. >>>>> >>>>> Regards, >>>>> >>>>> Daniel >>>>> >>>>> -----Original Message----- >>>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>>>> Sent: Thursday, July 28, 2011 11:12 AM >>>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro >>>>> Gerardo; mpls@ietf.org >>>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>> >>>>> Hi Greg- >>>>> There is a difference between SF and SD. Converting SD into Down >>>>> means that it will be interpreted exactly the same as SF, and if >> that's >>>>> the case why have SD at all? If SD is necessary it must be somehow >>>>> different from SD. >>>>> >>>>> All- >>>>> >>>>> Having said that, I'm not sure I disagree with Greg. It seems that >>>>> this idea of propagating server layer SD up into TP is being done >>>>> because there's no good way to do SD entirely within the TP layer. >> I >>>>> suspect that if there were a way to do SD within the TP layer that >> made >>>>> everyone happy, we wouldn't have the approach propsed in >>>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>>>> draft is: >>>>> >>>>> - we must have SD in TP because it is possible to do in other >>>>> technologies >>>>> - it is not possible to SD entirely within TP >>>>> - therefore we must get SD from somewhere else >>>>> >>>>> is a reasonable one. If we do that, where do we stop? Should we >>>>> propagate information about signal quality up to TCP so it can >> adjust >>>>> its windows according? (please note that this is intended to be a >>>>> reductio ad absurdum question and not a serious one. :) ) >>>>> >>>>> >>>>> >>>>> eric >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf >>>>> Of >>>>>> Greg Mirsky >>>>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro >> Alessandro >>>>>> Gerardo; mpls@ietf.org >>>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>>> >>>>>> Dear Authors and All, >>>>>> I think that it is function of the PHY layer to detect SD > condition >>>>> and >>>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>>>> Physical >>>>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>>>> measurement, in my view, is addressing the issue. >>>>>> >>>>>> Regards, >>>>>> Greg From vivien.sterling@gmail.com Thu Jul 28 14:01:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1811E8081 for ; Thu, 28 Jul 2011 14:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO5xrhy0Y2Zp for ; Thu, 28 Jul 2011 14:01:13 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F911E80F2 for ; Thu, 28 Jul 2011 14:01:13 -0700 (PDT) Received: by pzk6 with SMTP id 6so4807679pzk.26 for ; Thu, 28 Jul 2011 14:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7PpWcFO/t1cbM7mz5oyrJALGVYlDGIzv9ok0eC7yuFQ=; b=wqYoj+hZthNISddJ/prK0oytOdDg6WtXCFahAqE9+WcoDRkD5Pb06HHxTMv9VPA+Jr +4D3ZuUg9OBCNXhpBganMvyQNMoTRIdS6Snwig2uQD09jMtUOWP//j0Q61UW2kXThi0y ldb/N8H+KzA29rCGo72N89nZLeZCsXEcoqENU= MIME-Version: 1.0 Received: by 10.68.6.36 with SMTP id x4mr970744pbx.219.1311886871712; Thu, 28 Jul 2011 14:01:11 -0700 (PDT) Received: by 10.68.59.9 with HTTP; Thu, 28 Jul 2011 14:01:11 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> Date: Fri, 29 Jul 2011 05:01:11 +0800 Message-ID: From: Vivien Sterling To: Daniel Cohn Content-Type: multipart/alternative; boundary=bcaec53967a8f952f104a9277685 Cc: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:01:14 -0000 --bcaec53967a8f952f104a9277685 Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, I think you might misunderstand several things: 1) AIS is used for alarm suppression; 2) SD is different from SF. SF in PHY must cause interruption of services (same impact) in LSP and PW. However, SD in PHY may have different impact on LSP and PW, e.g. the loss/delay status of packets on LSP is different from that on PW, etc. Besides, IMHO you are indeed talking about SD of PHY rather than SD of MPLS-TP transport path. Right? -- Cheers, Vivien On Fri, Jul 29, 2011 at 4:16 AM, Daniel Cohn wrote: > I don't think sending iterative e-mails referring to ever higher layer > serves the point of this discussion. A similar argument can be made on > e.g. other technologies sending AIS-like indications on all client > layers. > I think we should focus on what Pablo wrote, i.e. do we want to provide > SD to MPLS layers, like existing transport networks, or not? And if we > do, what is the best way to do it? > > DC > > PS: No need to, the VC12 has its own SD detection capabilities. > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:12 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > And propagate to the VC12 carried By the PW? > and... > > Huub > > > > > Also, if we were to propagate to Tp, why stop there? It should be > propagated to PW as well, right? > > > > Sam > > > > Sent from my iPhone > > > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > > > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > made this exact point at the mike > >> during presentation. > >> > >> /himanshu > >> > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Shahram Davari > >> Sent: Thursday, July 28, 2011 2:30 PM > >> To: Daniel Cohn; Greg Mirsky > >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > yang.jian90@zte.com.cn > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi, > >> > >> I also don't believe SD is needed for MPLS-TP. Such defect is not > related to MPLS-TP and should be handled in the server layer, such as > changing the FEC type in OTN, etc. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Daniel Cohn > >> Sent: Thursday, July 28, 2011 10:15 AM > >> To: Greg Mirsky > >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > Ram > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> True enough in general. But in this particular example, there is > nothing suggested by this draft that requires huge implementation > efforts or paradigm changes. So I fail to see why we should settle for > less functionality than is available in existing transport networks. > >> > >> DC > >> > >> -----Original Message----- > >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> Sent: Thursday, July 28, 2011 1:00 PM > >> To: Daniel Cohn > >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi Daniel, > >> I think that while we're building MPLS-TP to be suited for the > >> transport we need to remember that it, as Neil pointed out on number > >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > it > >> has characteristic that makes it different from other layers of a > >> transport network and, I think, as result not all existing concepts > of > >> transport are applicable to packet layer realized by MPLS-TP. > >> > >> Regards, > >> Greg > >> > >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: > >>> Hi Eric, > >>> > >>> One of the reasons why we need SD in TP is because TP is supposed to > >>> provide the same "look and feel" of existing transport networks, as > >>> specified in the TP requirements document. > >>> Transport networks technologies have long supported the distinction > >>> between "degraded" and " faulty". In particular, protection > technologies > >>> in use have this distinction built into the innermost recedes of > their > >>> protocols. > >>> Even in the TP requirements didn't spell this out, I think it would > be a > >>> mistake not to take advantage of years of experience in transport > >>> networks OAM. > >>> > >>> Regards, > >>> > >>> Daniel > >>> > >>> -----Original Message----- > >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > >>> Sent: Thursday, July 28, 2011 11:12 AM > >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > >>> Gerardo; mpls@ietf.org > >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> Hi Greg- > >>> There is a difference between SF and SD. Converting SD into Down > >>> means that it will be interpreted exactly the same as SF, and if > that's > >>> the case why have SD at all? If SD is necessary it must be somehow > >>> different from SD. > >>> > >>> All- > >>> > >>> Having said that, I'm not sure I disagree with Greg. It seems that > >>> this idea of propagating server layer SD up into TP is being done > >>> because there's no good way to do SD entirely within the TP layer. > I > >>> suspect that if there were a way to do SD within the TP layer that > made > >>> everyone happy, we wouldn't have the approach propsed in > >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > >>> draft is: > >>> > >>> - we must have SD in TP because it is possible to do in other > >>> technologies > >>> - it is not possible to SD entirely within TP > >>> - therefore we must get SD from somewhere else > >>> > >>> is a reasonable one. If we do that, where do we stop? Should we > >>> propagate information about signal quality up to TCP so it can > adjust > >>> its windows according? (please note that this is intended to be a > >>> reductio ad absurdum question and not a serious one. :) ) > >>> > >>> > >>> > >>> eric > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >>> Of > >>>> Greg Mirsky > >>>> Sent: Wednesday, July 27, 2011 2:08 PM > >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > >>>> Gerardo; mpls@ietf.org > >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Dear Authors and All, > >>>> I think that it is function of the PHY layer to detect SD condition > >>> and > >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > >>> Physical > >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss > >>>> measurement, in my view, is addressing the issue. > >>>> > >>>> Regards, > >>>> Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec53967a8f952f104a9277685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,
=A0
I think you might misunderstand several things:
1) AIS is used for alarm suppression;
2) SD is different from SF. SF=A0in=A0PHY must cause interruption of s= ervices (same impact)=A0in=A0LSP and PW. However, SD=A0in PHY may have diff= erent impact on LSP and PW, e.g. the loss/delay status of packets on LSP is= different from that=A0on PW,=A0=A0etc.
=A0
Besides, IMHO you are indeed talking about SD of PHY=A0rather than=A0S= D of MPLS-TP transport path. Right?=A0
=A0
--
Cheers,
Vivien


On Fri, Jul 29, 2011 at 4:16 AM, Daniel Cohn <DanielC@orckit.com= > wrote:
I don't think sending iterat= ive e-mails referring to ever higher layer
serves the point of this disc= ussion. A similar argument can be made on
e.g. other technologies sending AIS-like indications on all client
layer= s.
I think we should focus on what Pablo wrote, i.e. do we want to provi= de
SD to MPLS layers, like existing transport networks, or not? And if w= e
do, what is the best way to do it?

DC

PS: No need to, the VC1= 2 has its own SD detection capabilities.


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
Huub van Helvoort
Sent: Thursday, July 28, 2011 4:12 PM
To: mpls@ietf.org
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03<= br>
And propagate to the VC12 carried By the PW?
and...

Huub


> Also, if we were to propagate to Tp, why stop there? It = should be
propagated to PW as well, right?
>
> Sam
>
> Sent f= rom my iPhone
>
> On Jul 28, 2011, at 2:41 PM, "Shah, Hima= nshu"<hshah@ciena.com> = =A0wrote:
>
>> I agree with Eric, Shahram and actually richard kam (alcat= el/lucent)
made this exact point at the mike
>> during presenta= tion.
>>
>> /himanshu
>>
>>
>>=
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
Of Shahram Dava= ri
>> Sent: Thursday, July 28, 2011 2:30 PM
>> To: Daniel Cohn;= Greg Mirsky
>> Cc: Rafi Ram; mpl= s@ietf.org; ms-daikoku@kddi.com<= /a>;
yang.jian90@zte.com.cn
>= ;> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>><= br>>> Hi,
>>
>> I also don't believe SD is need= ed for MPLS-TP. Such defect is not
related to MPLS-TP and should be handled in the server layer, such as
ch= anging the FEC type in OTN, etc.
>>
>> Regards,
>&g= t; Shahram
>>
>> -----Original Message-----
>> F= rom: mpls-bounces@ietf.org [ma= ilto:mpls-bounces@ietf.org] On= Behalf
Of Daniel Cohn
>> Sent: Thursday, July 28, 2011 10:15 AM
>&g= t; To: Greg Mirsky
>> Cc: mpls@ie= tf.org; yang.jian90@zte.com.c= n; ms-daikoku@kddi.com; Rafi=
Ram
>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03>>
>> True enough in general. But in this particular exampl= e, there is
nothing suggested by this draft that requires huge implement= ation
efforts or paradigm changes. So I fail to see why we should settle for
l= ess functionality than is available in existing transport networks.
>= >
>> DC
>>
>> -----Original Message-----
>> From: Greg Mirsky [mailto:gregimirsky@gmail.com]
>> Sent: Thursday, July 28, 2011 1:00 = PM
>> To: Daniel Cohn
>> Cc: Eric Osborne (eosborne); Raf= i Ram; ms-daikoku@kddi.com;
ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro= Alessandro
Gerardo; mpls@ietf.org<= br> >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>&g= t;
>> Hi Daniel,
>> I think that while we're building= MPLS-TP to be suited for the
>> transport we need to remember tha= t it, as Neil pointed out on number
>> of occasions, is not BOS layer and doesn't put bits on a wire.= Thus
it
>> has characteristic that makes it different from oth= er layers of a
>> transport network and, I think, as result not al= l existing concepts
of
>> transport are applicable to packet layer realized by MPLS-TP= .
>>
>> Regards,
>> Greg
>>
>>= On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn<DanielC@orckit.com>
wrote:
>>> Hi Eric,
>>>
>>> One of the = reasons why we need SD in TP is because TP is supposed to
>>> p= rovide the same "look and feel" of existing transport networks, a= s
>>> specified in the TP requirements document.
>>> Tra= nsport networks technologies have long supported the distinction
>>= ;> between "degraded" and " faulty". In particular, = protection
technologies
>>> in use have this distinction built into the in= nermost recedes of
their
>>> protocols.
>>> Even= in the TP requirements didn't spell this out, I think it would
be a
>>> mistake not to take advantage of years of experience i= n transport
>>> networks OAM.
>>>
>>> R= egards,
>>>
>>> Daniel
>>>
>>&= gt; -----Original Message-----
>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
>>> Sent: Thursday, July = 28, 2011 11:12 AM
>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; <= a href=3D"mailto:ms-daikoku@kddi.com">ms-daikoku@kddi.com;
>>> ma.yuxia@zte.com.cn= ; yang.jian90@zte.com.cn; D&#= 39;Alessandro Alessandro
>>> Gerardo; mpls@ietf.org
>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
&g= t;>>
>>> Hi Greg-
>>> There is a difference b= etween SF and SD. =A0Converting SD into Down
>>> means that it = will be interpreted exactly the same as SF, and if
that's
>>> the case why have SD at all? =A0If SD is necessa= ry it must be somehow
>>> different from SD.
>>>>>> All-
>>>
>>> Having said that, I'= m not sure I disagree with Greg. =A0It seems that
>>> this idea of propagating server layer SD up into TP is being d= one
>>> because there's no good way to do SD entirely withi= n the TP layer.
I
>>> suspect that if there were a way to do= SD within the TP layer that
made
>>> everyone happy, we wouldn't have the approach prop= sed in
>>> draft-rkhd-mpls-tp-sd. =A0And I think that if the mo= tivation for this
>>> draft is:
>>>
>>>= - we must have SD in TP because it is possible to do in other
>>> technologies
>>> - it is not possible to SD entire= ly within TP
>>> - therefore we must get SD from somewhere else=
>>>
>>> is a reasonable one. =A0If we do that, whe= re do we stop? =A0Should we
>>> propagate information about signal quality up to TCP so it can=
adjust
>>> its windows according? =A0(please note that this= is intended to be a
>>> reductio ad absurdum question and not = a serious one. :) )
>>>
>>>
>>>
>>> eric
>&g= t;>
>>>> -----Original Message-----
>>>> F= rom: mpls-bounces@ietf.org [ma= ilto:mpls-bounces@ietf.org] On=
Behalf
>>> Of
>>>> Greg Mirsky
>>>&g= t; Sent: Wednesday, July 27, 2011 2:08 PM
>>>> To: Daniel Co= hn; rafir@orckit.com; ms-daikoku@kddi.com;
>>>> ma.yuxia@zte.com.cn= ; yang.jian90@zte.com.cn;= D'Alessandro
Alessandro
>>>> Gerardo; mpls@ietf.org
>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
&g= t;>>>
>>>> Dear Authors and All,
>>>>= ; I think that it is function of the PHY layer to detect SD condition
>>> and
>>>> convert it into Down for the MPLS-TP L= ayer 0 (what we refer as
>>> Physical
>>>> Secti= on). In case of accumulating SD over LSP the e2e Packet Loss
>>>= ;> measurement, in my view, is addressing the issue.
>>>>
>>>> Regards,
>>>> Greg
_= ______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailma= n/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailm= an/listinfo/mpls



--bcaec53967a8f952f104a9277685-- From DanielC@orckit.com Thu Jul 28 14:09:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1939F21F8AF8 for ; Thu, 28 Jul 2011 14:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu3KZv+hqc6v for ; Thu, 28 Jul 2011 14:09:41 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAD121F8B13 for ; Thu, 28 Jul 2011 14:09:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D6B.0A9879E6" Date: Fri, 29 Jul 2011 00:09:34 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED82B1@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AcxNad+BjCRvk59dS+KNbjzXDynyywAADDSg References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1><44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1><2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com><7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com><4E31C29F.1010302@gmail.com><44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> From: "Daniel Cohn" To: "Vivien Sterling" Cc: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:09:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4D6B.0A9879E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline =20 From: Vivien Sterling [mailto:vivien.sterling@gmail.com]=20 Sent: Thursday, July 28, 2011 5:01 PM To: Daniel Cohn Cc: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 =20 Hi Daniel, =20 I think you might misunderstand several things: 1) AIS is used for alarm suppression; =20 [DC] I'm aware of that, I just mentioned AIS as an example. As an aside, pls note that draft-ietf-mpls-tp-fault uses AIS LDI flag for more than just alarm supression =20 2) SD is different from SF. SF in PHY must cause interruption of services (same impact) in LSP and PW. However, SD in PHY may have different impact on LSP and PW, e.g. the loss/delay status of packets on LSP is different from that on PW, etc. [DC] Fully agreed. SD OAM message on LSP and PW is supposed to be a notification of SD detected in server layer Besides, IMHO you are indeed talking about SD of PHY rather than SD of MPLS-TP transport path. Right?=20 [DC] Right. --=20 Cheers, Vivien On Fri, Jul 29, 2011 at 4:16 AM, Daniel Cohn wrote: I don't think sending iterative e-mails referring to ever higher layer serves the point of this discussion. A similar argument can be made on e.g. other technologies sending AIS-like indications on all client layers. I think we should focus on what Pablo wrote, i.e. do we want to provide SD to MPLS layers, like existing transport networks, or not? And if we do, what is the best way to do it? DC PS: No need to, the VC12 has its own SD detection capabilities. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Thursday, July 28, 2011 4:12 PM To: mpls@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 And propagate to the VC12 carried By the PW? and... Huub > Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right? > > Sam > > Sent from my iPhone > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike >> during presentation. >> >> /himanshu >> >> >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari >> Sent: Thursday, July 28, 2011 2:30 PM >> To: Daniel Cohn; Greg Mirsky >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; yang.jian90@zte.com.cn >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi, >> >> I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Daniel Cohn >> Sent: Thursday, July 28, 2011 10:15 AM >> To: Greg Mirsky >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi Ram >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks. >> >> DC >> >> -----Original Message----- >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] >> Sent: Thursday, July 28, 2011 1:00 PM >> To: Daniel Cohn >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro Gerardo; mpls@ietf.org >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> Hi Daniel, >> I think that while we're building MPLS-TP to be suited for the >> transport we need to remember that it, as Neil pointed out on number >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus it >> has characteristic that makes it different from other layers of a >> transport network and, I think, as result not all existing concepts of >> transport are applicable to packet layer realized by MPLS-TP. >> >> Regards, >> Greg >> >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >>> Hi Eric, >>> >>> One of the reasons why we need SD in TP is because TP is supposed to >>> provide the same "look and feel" of existing transport networks, as >>> specified in the TP requirements document. >>> Transport networks technologies have long supported the distinction >>> between "degraded" and " faulty". In particular, protection technologies >>> in use have this distinction built into the innermost recedes of their >>> protocols. >>> Even in the TP requirements didn't spell this out, I think it would be a >>> mistake not to take advantage of years of experience in transport >>> networks OAM. >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >>> Sent: Thursday, July 28, 2011 11:12 AM >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>> Gerardo; mpls@ietf.org >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>> >>> Hi Greg- >>> There is a difference between SF and SD. Converting SD into Down >>> means that it will be interpreted exactly the same as SF, and if that's >>> the case why have SD at all? If SD is necessary it must be somehow >>> different from SD. >>> >>> All- >>> >>> Having said that, I'm not sure I disagree with Greg. It seems that >>> this idea of propagating server layer SD up into TP is being done >>> because there's no good way to do SD entirely within the TP layer. I >>> suspect that if there were a way to do SD within the TP layer that made >>> everyone happy, we wouldn't have the approach propsed in >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >>> draft is: >>> >>> - we must have SD in TP because it is possible to do in other >>> technologies >>> - it is not possible to SD entirely within TP >>> - therefore we must get SD from somewhere else >>> >>> is a reasonable one. If we do that, where do we stop? Should we >>> propagate information about signal quality up to TCP so it can adjust >>> its windows according? (please note that this is intended to be a >>> reductio ad absurdum question and not a serious one. :) ) >>> >>> >>> >>> eric >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Greg Mirsky >>>> Sent: Wednesday, July 27, 2011 2:08 PM >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >>>> Gerardo; mpls@ietf.org >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>> >>>> Dear Authors and All, >>>> I think that it is function of the PHY layer to detect SD condition >>> and >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as >>> Physical >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss >>>> measurement, in my view, is addressing the issue. >>>> >>>> Regards, >>>> Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01CC4D6B.0A9879E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline

 

From:= = Vivien Sterling [mailto:vivien.sterling@gmail.com]
Sent: = Thursday, July 28, 2011 5:01 PM
To: Daniel Cohn
Cc: = mpls@ietf.org
Subject: Re: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03

 

Hi = Daniel,

 

I = think you might misunderstand several = things:

1)      = AIS is used for alarm = suppression;

 

[DC] I’m aware of that, I just mentioned AIS as an example. As = an aside, pls note that draft-ietf-mpls-tp-fault uses AIS LDI flag for = more than just alarm supression

 

2)      = SD is different from SF. = SF in PHY must cause interruption of services (same = impact) in LSP and PW. However, SD in PHY may have = different impact on LSP and PW, e.g. the loss/delay status of packets on = LSP is different from that on = PW,  etc.

[DC] Fully agreed. SD OAM message on LSP and PW is supposed to be a = notification of SD detected in server = layer

Besides, IMHO = you are indeed talking about SD of PHY rather than SD of = MPLS-TP transport path. Right? 

 [DC] Right.

-- =
Cheers,
Vivien

On Fri, Jul 29, 2011 at 4:16 AM, Daniel Cohn <DanielC@orckit.com> = wrote:

I don't think sending = iterative e-mails referring to ever higher layer
serves the point of = this discussion. A similar argument can be made on
e.g. other = technologies sending AIS-like indications on all client
layers.
I = think we should focus on what Pablo wrote, i.e. do we want to = provide
SD to MPLS layers, like existing transport networks, or not? = And if we
do, what is the best way to do it?

DC

PS: No = need to, the VC12 has its own SD detection = capabilities.



-----Original Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On = Behalf Of

Huub van = Helvoort
Sent: Thursday, July 28, 2011 4:12 PM
To: mpls@ietf.org

<= p class=3DMsoNormal>Subject: Re: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03

And propagate to the VC12 carried By the = PW?
and...

Huub



> Also, if we were to = propagate to Tp, why stop there? It should be
propagated to PW as = well, right?
>
> Sam
>
> Sent from my = iPhone
>
> On Jul 28, 2011, at 2:41 PM, "Shah, = Himanshu"<hshah@ciena.com> =  wrote:
>
>> I agree with Eric, Shahram and actually = richard kam (alcatel/lucent)
made this exact point at the = mike
>> during presentation.
>>
>> = /himanshu
>>
>>
>>
>> -----Original = Message-----
>> From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On = Behalf
Of Shahram Davari
>> Sent: Thursday, July 28, 2011 = 2:30 PM
>> To: Daniel Cohn; Greg Mirsky
>> Cc: Rafi = Ram; mpls@ietf.org; ms-daikoku@kddi.com;
yang.jian90@zte.com.cn
>= > Subject: Re: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03
>>
>> = Hi,
>>
>> I also don't believe SD is needed for = MPLS-TP. Such defect is not
related to MPLS-TP and should be handled = in the server layer, such as
changing the FEC type in OTN, = etc.
>>
>> Regards,
>> = Shahram
>>
>> -----Original Message-----
>> = From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On = Behalf
Of Daniel Cohn
>> Sent: Thursday, July 28, 2011 10:15 = AM
>> To: Greg Mirsky
>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; = Rafi
Ram
>> Subject: Re: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03
>>
>> True enough in general. = But in this particular example, there is
nothing suggested by this = draft that requires huge implementation
efforts or paradigm changes. = So I fail to see why we should settle for
less functionality than is = available in existing transport networks.
>>
>> = DC
>>
>> -----Original Message-----
>> From: = Greg Mirsky [mailto:gregimirsky@gmail.com]
>&= gt; Sent: Thursday, July 28, 2011 1:00 PM
>> To: Daniel = Cohn
>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com;
ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; = D'Alessandro Alessandro
Gerardo; mpls@ietf.org
>> Subject: Re: = [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>>
>> Hi = Daniel,
>> I think that while we're building MPLS-TP to be = suited for the
>> transport we need to remember that it, as = Neil pointed out on number
>> of occasions, is not BOS layer = and doesn't put bits on a wire. Thus
it
>> has = characteristic that makes it different from other layers of = a
>> transport network and, I think, as result not all existing = concepts
of
>> transport are applicable to packet layer = realized by MPLS-TP.
>>
>> Regards,
>> = Greg
>>
>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel = Cohn<DanielC@orckit.com>
wrote:>>> Hi Eric,
>>>
>>> One of the = reasons why we need SD in TP is because TP is supposed = to
>>> provide the same "look and feel" of = existing transport networks, as
>>> specified in the TP = requirements document.
>>> Transport networks technologies = have long supported the distinction
>>> between = "degraded" and " faulty". In particular, = protection
technologies
>>> in use have this distinction = built into the innermost recedes of
their
>>> = protocols.
>>> Even in the TP requirements didn't spell this = out, I think it would
be a
>>> mistake not to take = advantage of years of experience in transport
>>> networks = OAM.
>>>
>>> = Regards,
>>>
>>> = Daniel
>>>
>>> -----Original = Message-----
>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
>>>= ; Sent: Thursday, July 28, 2011 11:12 AM
>>> To: Greg = Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com;
>>&= gt; ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; = D'Alessandro Alessandro
>>> Gerardo; mpls@ietf.org
>>> Subject: = RE: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03
>>>
>>> Hi = Greg-
>>> There is a difference between SF and SD. =  Converting SD into Down
>>> means that it will be = interpreted exactly the same as SF, and if
that's
>>> the = case why have SD at all?  If SD is necessary it must be = somehow
>>> different from = SD.
>>>
>>> All-
>>>
>>> = Having said that, I'm not sure I disagree with Greg.  It seems = that
>>> this idea of propagating server layer SD up into TP = is being done
>>> because there's no good way to do SD = entirely within the TP layer.
I
>>> suspect that if there = were a way to do SD within the TP layer that
made
>>> = everyone happy, we wouldn't have the approach propsed in
>>> = draft-rkhd-mpls-tp-sd.  And I think that if the motivation for = this
>>> draft is:
>>>
>>> - we must = have SD in TP because it is possible to do in other
>>> = technologies
>>> - it is not possible to SD entirely within = TP
>>> - therefore we must get SD from somewhere = else
>>>
>>> is a reasonable one.  If we do = that, where do we stop?  Should we
>>> propagate = information about signal quality up to TCP so it = can
adjust
>>> its windows according?  (please note = that this is intended to be a
>>> reductio ad absurdum = question and not a serious one. :) = )
>>>
>>>
>>>
>>> = eric
>>>
>>>> -----Original = Message-----
>>>> From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] = On
Behalf
>>> Of
>>>> Greg = Mirsky
>>>> Sent: Wednesday, July 27, 2011 2:08 = PM
>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com;
>>&= gt;> ma.yuxia@zte.com.cn; = yang.jian90@zte.com.cn; = D'Alessandro
Alessandro
>>>> Gerardo; mpls@ietf.org
>>>> = Subject: [mpls] Comments to = draft-rkhd-mpls-tp-sd-03
>>>>
>>>> Dear = Authors and All,
>>>> I think that it is function of the = PHY layer to detect SD condition
>>> and
>>>> = convert it into Down for the MPLS-TP Layer 0 (what we refer = as
>>> Physical
>>>> Section). In case of = accumulating SD over LSP the e2e Packet Loss
>>>> = measurement, in my view, is addressing the = issue.
>>>>
>>>> = Regards,
>>>> = Greg
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_____= __________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls



------_=_NextPart_001_01CC4D6B.0A9879E6-- From pabloisnot@gmail.com Thu Jul 28 15:37:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2C411E80B6 for ; Thu, 28 Jul 2011 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB71ude-Apuh for ; Thu, 28 Jul 2011 15:37:29 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F40C411E80AF for ; Thu, 28 Jul 2011 15:37:28 -0700 (PDT) Received: by qyk9 with SMTP id 9so3420509qyk.10 for ; Thu, 28 Jul 2011 15:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c11ho6ahWvTJRnXqKuEuqQkHSViYbWMqFxuRGwYBiyA=; b=ObkxnhSnDqOYFWST6gh91zR/LEQBWJe2WiwdVAZCaN2w39be5lAtYb3zwCYA44g8WD eH3u9EGbV5S+aTDVVD4y6tblIciEdu6bxeIJBkckVWnLQsXkm+wPQApHkQZMYk5kfAPO oxSmP9tUiOdajVKamVgQwceGk8W/85hwUZILY= MIME-Version: 1.0 Received: by 10.224.194.68 with SMTP id dx4mr502109qab.31.1311892648261; Thu, 28 Jul 2011 15:37:28 -0700 (PDT) Received: by 10.224.28.67 with HTTP; Thu, 28 Jul 2011 15:37:28 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> <4E31C736.5040306@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> Date: Thu, 28 Jul 2011 18:37:28 -0400 Message-ID: From: Pablo Frank To: Daniel Cohn Content-Type: multipart/alternative; boundary=20cf300fb1ad4877d804a928cf2f Cc: mpls@ietf.org, huubatwork@gmail.com Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:37:30 -0000 --20cf300fb1ad4877d804a928cf2f Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, Whether we get SD from the server layer or from a TP-based mechanism (such as OAM) is not necessarily in conflict with one another. The current Linear Protection draft has place-holders for getting SD indications from the server layer (what I think you are trying to address), from OAM (this is less clear-- is it FM/DM or something else?), and from the management plane (I have no idea what this is). The PSC takes care of reacting to and propagating the SD state so I don't think you need to use FM to do this. I also don't think it's a good idea to propagate server-layer SD indications to the next layer up automatically. If we do this, some undefined entity probably wants to take into account both server-layer and local indications (from OAM and/or management plane) before deciding if an SD is propagated up (as a server-layer indication to the next layer up). cheers, Pablo On Thu, Jul 28, 2011 at 4:36 PM, Daniel Cohn wrote: > Hi Huub, > > Can propose a TP-based detection method that can detect only physical > errors, i.e. without being influenced by non-physical conditions such as > congestion, CPU overload, etc.? > If you can, by all means do so, it would greatly serve the purpose of > this discussion. > > Thanks, > > Daniel > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:32 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Daniel Cohn > > You wrote: > > > I don't think sending iterative e-mails referring to ever higher layer > > serves the point of this discussion. > > OK, ---8<---snipped > > > PS: No need to, the VC12 has its own SD detection capabilities. > > So why don't we define SD (service degrade) defect detection criteria > for MPLS-TP? > In stead of relying on SD (signal degrade) defect detect mechanisms in > other technologies. > > BR, Huub. > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Huub van Helvoort > > Sent: Thursday, July 28, 2011 4:12 PM > > To: mpls@ietf.org > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > And propagate to the VC12 carried By the PW? > > and... > > > > Huub > > > > > > > >> Also, if we were to propagate to Tp, why stop there? It should be > > propagated to PW as well, right? > >> > >> Sam > >> > >> Sent from my iPhone > >> > >> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" > wrote: > >> > >>> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > > made this exact point at the mike > >>> during presentation. > >>> > >>> /himanshu > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Shahram Davari > >>> Sent: Thursday, July 28, 2011 2:30 PM > >>> To: Daniel Cohn; Greg Mirsky > >>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > > yang.jian90@zte.com.cn > >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> Hi, > >>> > >>> I also don't believe SD is needed for MPLS-TP. Such defect is not > > related to MPLS-TP and should be handled in the server layer, such as > > changing the FEC type in OTN, etc. > >>> > >>> Regards, > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Daniel Cohn > >>> Sent: Thursday, July 28, 2011 10:15 AM > >>> To: Greg Mirsky > >>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > > Ram > >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> True enough in general. But in this particular example, there is > > nothing suggested by this draft that requires huge implementation > > efforts or paradigm changes. So I fail to see why we should settle for > > less functionality than is available in existing transport networks. > >>> > >>> DC > >>> > >>> -----Original Message----- > >>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >>> Sent: Thursday, July 28, 2011 1:00 PM > >>> To: Daniel Cohn > >>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> Hi Daniel, > >>> I think that while we're building MPLS-TP to be suited for the > >>> transport we need to remember that it, as Neil pointed out on number > >>> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > > it > >>> has characteristic that makes it different from other layers of a > >>> transport network and, I think, as result not all existing concepts > > of > >>> transport are applicable to packet layer realized by MPLS-TP. > >>> > >>> Regards, > >>> Greg > >>> > >>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > > wrote: > >>>> Hi Eric, > >>>> > >>>> One of the reasons why we need SD in TP is because TP is supposed > to > >>>> provide the same "look and feel" of existing transport networks, as > >>>> specified in the TP requirements document. > >>>> Transport networks technologies have long supported the distinction > >>>> between "degraded" and " faulty". In particular, protection > > technologies > >>>> in use have this distinction built into the innermost recedes of > > their > >>>> protocols. > >>>> Even in the TP requirements didn't spell this out, I think it would > > be a > >>>> mistake not to take advantage of years of experience in transport > >>>> networks OAM. > >>>> > >>>> Regards, > >>>> > >>>> Daniel > >>>> > >>>> -----Original Message----- > >>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > >>>> Sent: Thursday, July 28, 2011 11:12 AM > >>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > >>>> Gerardo; mpls@ietf.org > >>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Hi Greg- > >>>> There is a difference between SF and SD. Converting SD into Down > >>>> means that it will be interpreted exactly the same as SF, and if > > that's > >>>> the case why have SD at all? If SD is necessary it must be somehow > >>>> different from SD. > >>>> > >>>> All- > >>>> > >>>> Having said that, I'm not sure I disagree with Greg. It seems that > >>>> this idea of propagating server layer SD up into TP is being done > >>>> because there's no good way to do SD entirely within the TP layer. > > I > >>>> suspect that if there were a way to do SD within the TP layer that > > made > >>>> everyone happy, we wouldn't have the approach propsed in > >>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > >>>> draft is: > >>>> > >>>> - we must have SD in TP because it is possible to do in other > >>>> technologies > >>>> - it is not possible to SD entirely within TP > >>>> - therefore we must get SD from somewhere else > >>>> > >>>> is a reasonable one. If we do that, where do we stop? Should we > >>>> propagate information about signal quality up to TCP so it can > > adjust > >>>> its windows according? (please note that this is intended to be a > >>>> reductio ad absurdum question and not a serious one. :) ) > >>>> > >>>> > >>>> > >>>> eric > >>>> > >>>>> -----Original Message----- > >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > >>>> Of > >>>>> Greg Mirsky > >>>>> Sent: Wednesday, July 27, 2011 2:08 PM > >>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > Alessandro > >>>>> Gerardo; mpls@ietf.org > >>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>>> > >>>>> Dear Authors and All, > >>>>> I think that it is function of the PHY layer to detect SD > condition > >>>> and > >>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > >>>> Physical > >>>>> Section). In case of accumulating SD over LSP the e2e Packet Loss > >>>>> measurement, in my view, is addressing the issue. > >>>>> > >>>>> Regards, > >>>>> Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf300fb1ad4877d804a928cf2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Daniel,

Whether we get SD from the server layer or fr= om a TP-based mechanism (such as OAM) is not necessarily in conflict with o= ne another. =A0The current Linear Protection draft has place-holders for ge= tting SD indications from the server layer (what I think you are trying to = address), from OAM (this is less clear-- is it FM/DM or something else?), a= nd from the management plane (I have no idea what this is). =A0The PSC take= s care of reacting to and propagating the SD state so I don't think you= need to use FM to do this.

I also don't think it's a good idea to propagat= e server-layer SD indications to the next layer up automatically. =A0If we = do this, some undefined entity probably wants to take into account both ser= ver-layer and local indications (from OAM and/or management plane) before d= eciding if an SD is propagated up (as a server-layer indication to the next= layer up).

cheers,
Pablo

On Thu, Jul 28, 2011 at 4:36 PM, Daniel Cohn &l= t;DanielC@orckit.com> w= rote:
Hi Huub,

Can propose a TP-based detection method that can detect only physical
errors, i.e. without being influenced by non-physical conditions such as congestion, CPU overload, etc.?
If you can, by all means do so, it would greatly serve the purpose of
this discussion.

Thanks,

Daniel

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of
Huub van Helvoort
Sent: Thursday, July 28, 2011 4:32 PM
To: mpls@ietf.org
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel Cohn

You wrote:

> I don't think sending iterative e-mails referring to ever higher l= ayer
> serves the point of this discussion.

OK, ---8<---snipped

> PS: No need to, the VC12 has its own SD detection capabilities.

So why don't we define SD (service degrade) defect detection criteria for MPLS-TP?
In stead of relying on SD (signal degrade) defect detect mechanisms in
other technologies.

BR, Huub.

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
Of
> Huub van Helvoort
> Sent: Thursday, July 28, 2011 4:12 PM
> To: mpls@ietf.org
> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>
> And propagate to the VC12 carried By the PW?
> and...
>
> Huub
>
>
>
>> Also, if we were to propagate to Tp, why stop there? It should be<= br> > propagated to PW as well, right?
>>
>> Sam
>>
>> Sent from my iPhone
>>
>> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu"<hshah@ciena.com>
wrote:
>>
>>> I agree with Eric, Shahram and actually richard kam (alcatel/l= ucent)
> made this exact point at the mike
>>> during presentation.
>>>
>>> /himanshu
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: mpls-bounces@ie= tf.org [mailto:mpls-bounces@ie= tf.org] On Behalf
> Of Shahram Davari
>>> Sent: Thursday, July 28, 2011 2:30 PM
>>> To: Daniel Cohn; Greg Mirsky
>>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com;
> yang.jian90@zte.com.cn >>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>>>
>>> Hi,
>>>
>>> I also don't believe SD is needed for MPLS-TP. Such defect= is not
> related to MPLS-TP and should be handled in the server layer, such as<= br> > changing the FEC type in OTN, etc.
>>>
>>> Regards,
>>> Shahram
>>>
>>> -----Original Message-----
>>> From: mpls-bounces@ie= tf.org [mailto:mpls-bounces@ie= tf.org] On Behalf
> Of Daniel Cohn
>>> Sent: Thursday, July 28, 2011 10:15 AM
>>> To: Greg Mirsky
>>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi
> Ram
>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>>>
>>> True enough in general. But in this particular example, there = is
> nothing suggested by this draft that requires huge implementation
> efforts or paradigm changes. So I fail to see why we should settle for=
> less functionality than is available in existing transport networks. >>>
>>> DC
>>>
>>> -----Original Message-----
>>> From: Greg Mirsky [mailto:gregimirsky@gmail.com]
>>> Sent: Thursday, July 28, 2011 1:00 PM
>>> To: Daniel Cohn
>>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com;
> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Aless= andro Alessandro
> Gerardo; mpls@ietf.org
>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>>>
>>> Hi Daniel,
>>> I think that while we're building MPLS-TP to be suited for= the
>>> transport we need to remember that it, as Neil pointed out on = number
>>> of occasions, is not BOS layer and doesn't put bits on a w= ire. Thus
> it
>>> has characteristic that makes it different from other layers o= f a
>>> transport network and, I think, as result not all existing con= cepts
> of
>>> transport are applicable to packet layer realized by MPLS-TP.<= br> >>>
>>> Regards,
>>> Greg
>>>
>>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn<DanielC@orckit.com>
> wrote:
>>>> Hi Eric,
>>>>
>>>> One of the reasons why we need SD in TP is because TP is s= upposed
to
>>>> provide the same "look and feel" of existing tra= nsport networks, as
>>>> specified in the TP requirements document.
>>>> Transport networks technologies have long supported the di= stinction
>>>> between "degraded" and " faulty". In p= articular, protection
> technologies
>>>> in use have this distinction built into the innermost rece= des of
> their
>>>> protocols.
>>>> Even in the TP requirements didn't spell this out, I t= hink it would
> be a
>>>> mistake not to take advantage of years of experience in tr= ansport
>>>> networks OAM.
>>>>
>>>> Regards,
>>>>
>>>> Daniel
>>>>
>>>> -----Original Message-----
>>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
>>>> Sent: Thursday, July 28, 2011 11:12 AM
>>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com;
>>>> ma.yuxia@zte.com.cn= ; yang.jian90@zte.com.cn;= D'Alessandro
Alessandro
>>>> Gerardo; mpls@ietf.org
>>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>
>>>> Hi Greg-
>>>> There is a difference between SF and SD. =A0Converting SD = into Down
>>>> means that it will be interpreted exactly the same as SF, = and if
> that's
>>>> the case why have SD at all? =A0If SD is necessary it must= be somehow
>>>> different from SD.
>>>>
>>>> All-
>>>>
>>>> Having said that, I'm not sure I disagree with Greg. = =A0It seems that
>>>> this idea of propagating server layer SD up into TP is bei= ng done
>>>> because there's no good way to do SD entirely within t= he TP layer.
> I
>>>> suspect that if there were a way to do SD within the TP la= yer that
> made
>>>> everyone happy, we wouldn't have the approach propsed = in
>>>> draft-rkhd-mpls-tp-sd. =A0And I think that if the motivati= on for this
>>>> draft is:
>>>>
>>>> - we must have SD in TP because it is possible to do in ot= her
>>>> technologies
>>>> - it is not possible to SD entirely within TP
>>>> - therefore we must get SD from somewhere else
>>>>
>>>> is a reasonable one. =A0If we do that, where do we stop? = =A0Should we
>>>> propagate information about signal quality up to TCP so it= can
> adjust
>>>> its windows according? =A0(please note that this is intend= ed to be a
>>>> reductio ad absurdum question and not a serious one. :) )<= br> >>>>
>>>>
>>>>
>>>> eric
>>>>
>>>>> -----Original Message-----
>>>>> From: mpls-bo= unces@ietf.org [mailto:mpls-bo= unces@ietf.org] On
> Behalf
>>>> Of
>>>>> Greg Mirsky
>>>>> Sent: Wednesday, July 27, 2011 2:08 PM
>>>>> To: Daniel Cohn; r= afir@orckit.com; ms-daikoku@kddi= .com;
>>>>> ma.yuxia@zte.co= m.cn; yang.jian90@zte.com.cn<= /a>; D'Alessandro
> Alessandro
>>>>> Gerardo; mpls@ietf.or= g
>>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >>>>>
>>>>> Dear Authors and All,
>>>>> I think that it is function of the PHY layer to detect= SD
condition
>>>> and
>>>>> convert it into Down for the MPLS-TP Layer 0 (what we = refer as
>>>> Physical
>>>>> Section). In case of accumulating SD over LSP the e2e = Packet Loss
>>>>> measurement, in my view, is addressing the issue.
>>>>>
>>>>> Regards,
>>>>> Greg
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf300fb1ad4877d804a928cf2f-- From ma.yuxia@zte.com.cn Thu Jul 28 18:50:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2F21F876F for ; Thu, 28 Jul 2011 18:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.86 X-Spam-Level: X-Spam-Status: No, score=-91.86 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf-UDX1BBKdd for ; Thu, 28 Jul 2011 18:50:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0F21F85B2 for ; Thu, 28 Jul 2011 18:50:06 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 4864806486374; Fri, 29 Jul 2011 09:47:13 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 83350.6294169031; Fri, 29 Jul 2011 09:49:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6T1npET016064; Fri, 29 Jul 2011 09:49:51 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) In-Reply-To: To: Greg Mirsky MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Fri, 29 Jul 2011 09:49:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-29 09:49:52, Serialize complete at 2011-07-29 09:49:52 Content-Type: multipart/alternative; boundary="=_alternative 000A2161482578DC_=" X-MAIL: mse02.zte.com.cn p6T1npET016064 Cc: mpls@ietf.org, ms-daikoku@kddi.com, yang.jian90@zte.com.cn, Rafi Ram Subject: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:50:09 -0000 This is a multipart message in MIME format. --=_alternative 000A2161482578DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR3JlZyBhbmQgYWxsLA0KDQpJIHdhbnQgdG8gY2xhcmlmeSBzZXZlcmFsIHRoaW5nczoNCg0K MSkgV2h5IHNvbWUgdmVuZG9ycyBkbyB0aGUgcmVzZWFyY2ggYW5kIGRldmVsb3BtZW50IG9uIFNE IG9mIE1QTFMtVFA/ICChqg0KoaogIFJlcXVpcmVtZW50cyBmcm9tIHNlcnZpY2UgcHJvdmlkZXJz LiAgU0Qgc2hvdWxkIGJlIHJlcG9ydGVkIGFuZCANCnRyaWdnZXIgdG8gcHJvdGVjdGlvbi4NCg0K MikgV2h5IHByb3BhZ2F0ZSBzZXJ2ZXIgbGF5ZXIgaW5mb3IgdG8gVFA/ICChqqGqIElNTywgU2ln bmFsIGRlZ3JhZGUgb25seSANCnJlZmVycyB0byB0aGUgYml0IGVycm9yIGhhcHBlbmluZyBvbiB0 aGUgcGh5c2ljYWwgbGF5ZXIuIFBhY2tldCBsb3NzIA0KaW5kdWNlZCBieSBjb25nZXN0aW9uIG9y IENQVSBvdmVybG9hZCBpcyBub3QgdGhlIGZhY3RvciB0byBTRC4gSW4gb3JkZXIgdG8gDQphdm9p ZCB0aGVzZSBpbXBhY3RzLCB3ZSB1c2UgdGhlIGluZm9ybWF0aW9uIGRldGVjdGVkIGJ5IHBoeXNp Y2FsIGxheWVyLg0KDQozKSBXaHkgb25seSBwcm9wYWdhdGUgdG8gVFA/IKGqoaogV2UgdGhpbmsg aXQgaXMgbm90IG9ubHkgVFAsIGJ1dCBhbHNvIFBXLiANCkluIGZhY3QsIHByb3BhZ2F0ZSB0byB0 cmFuc3BvcnQgcGF0aC4gSXQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCg0KNCkgV2h5IG5v dCBwcm9wYWdhdGUgdG8gdGhlIGhpZ2hlciBsYXllciBhYm92ZSB0aGFuc3BvcnQgcGF0aD8goaqh qiBOb3csIA0Kd2UgYXJlIGRpc2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50IGFuZCBzb2x1dGlvbiBy ZWZlcnJpbmcgdG8gdHJhbnNwb3J0IA0KcGF0aC4gV2hldGhlciBwcm9wYWdhdGUgdG8gaGlnaGVy IGxheWVyIGlzIG5vdCB0aGUgdG9waWMgd2UgY2FyZSBhYm91dC4gDQoNCg0KUmVnYXJkcywNCll1 eGlhDQoNCg0KDQoNCg0KR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4gDQoyMDEx LTA3LTI5IDAxOjAwDQoNCsrVvP7Iyw0KRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbT4N CrOty80NCiJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4sIFJh ZmkgUmFtIA0KPFJhZmlSQG9yY2tpdC5jb20+LCBtcy1kYWlrb2t1QGtkZGkuY29tLCBtYS55dXhp YUB6dGUuY29tLmNuLCANCnlhbmcuamlhbjkwQHp0ZS5jb20uY24sICJEJ0FsZXNzYW5kcm8gQWxl c3NhbmRybyBHZXJhcmRvIiANCjxhbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEu aXQ+LCBtcGxzQGlldGYub3JnDQrW98ziDQpSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJr aGQtbXBscy10cC1zZC0wMw0KDQoNCg0KDQoNCg0KSGkgRGFuaWVsLA0KSSB0aGluayB0aGF0IHdo aWxlIHdlJ3JlIGJ1aWxkaW5nIE1QTFMtVFAgdG8gYmUgc3VpdGVkIGZvciB0aGUNCnRyYW5zcG9y dCB3ZSBuZWVkIHRvIHJlbWVtYmVyIHRoYXQgaXQsIGFzIE5laWwgcG9pbnRlZCBvdXQgb24gbnVt YmVyDQpvZiBvY2Nhc2lvbnMsIGlzIG5vdCBCT1MgbGF5ZXIgYW5kIGRvZXNuJ3QgcHV0IGJpdHMg b24gYSB3aXJlLiBUaHVzIGl0DQpoYXMgY2hhcmFjdGVyaXN0aWMgdGhhdCBtYWtlcyBpdCBkaWZm ZXJlbnQgZnJvbSBvdGhlciBsYXllcnMgb2YgYQ0KdHJhbnNwb3J0IG5ldHdvcmsgYW5kLCBJIHRo aW5rLCBhcyByZXN1bHQgbm90IGFsbCBleGlzdGluZyBjb25jZXB0cyBvZg0KdHJhbnNwb3J0IGFy ZSBhcHBsaWNhYmxlIHRvIHBhY2tldCBsYXllciByZWFsaXplZCBieSBNUExTLVRQLg0KDQpSZWdh cmRzLA0KR3JlZw0KDQpPbiBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUxIEFNLCBEYW5pZWwgQ29o biA8RGFuaWVsQ0BvcmNraXQuY29tPiB3cm90ZToNCj4gSGkgRXJpYywNCj4NCj4gT25lIG9mIHRo ZSByZWFzb25zIHdoeSB3ZSBuZWVkIFNEIGluIFRQIGlzIGJlY2F1c2UgVFAgaXMgc3VwcG9zZWQg dG8NCj4gcHJvdmlkZSB0aGUgc2FtZSAibG9vayBhbmQgZmVlbCIgb2YgZXhpc3RpbmcgdHJhbnNw b3J0IG5ldHdvcmtzLCBhcw0KPiBzcGVjaWZpZWQgaW4gdGhlIFRQIHJlcXVpcmVtZW50cyBkb2N1 bWVudC4NCj4gVHJhbnNwb3J0IG5ldHdvcmtzIHRlY2hub2xvZ2llcyBoYXZlIGxvbmcgc3VwcG9y dGVkIHRoZSBkaXN0aW5jdGlvbg0KPiBiZXR3ZWVuICJkZWdyYWRlZCIgYW5kICIgZmF1bHR5Ii4g SW4gcGFydGljdWxhciwgcHJvdGVjdGlvbiB0ZWNobm9sb2dpZXMNCj4gaW4gdXNlIGhhdmUgdGhp cyBkaXN0aW5jdGlvbiBidWlsdCBpbnRvIHRoZSBpbm5lcm1vc3QgcmVjZWRlcyBvZiB0aGVpcg0K PiBwcm90b2NvbHMuDQo+IEV2ZW4gaW4gdGhlIFRQIHJlcXVpcmVtZW50cyBkaWRuJ3Qgc3BlbGwg dGhpcyBvdXQsIEkgdGhpbmsgaXQgd291bGQgYmUgYQ0KPiBtaXN0YWtlIG5vdCB0byB0YWtlIGFk dmFudGFnZSBvZiB5ZWFycyBvZiBleHBlcmllbmNlIGluIHRyYW5zcG9ydA0KPiBuZXR3b3JrcyBP QU0uDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IERhbmllbA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5l QGNpc2NvLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTE6MTIgQU0NCj4g VG86IEdyZWcgTWlyc2t5OyBEYW5pZWwgQ29objsgUmFmaSBSYW07IG1zLWRhaWtva3VAa2RkaS5j b207DQo+IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxl c3NhbmRybyBBbGVzc2FuZHJvDQo+IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCj4NCj4gSGkg R3JlZy0NCj4gIFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIGFuZCBTRC4gIENvbnZl cnRpbmcgU0QgaW50byBEb3duDQo+IG1lYW5zIHRoYXQgaXQgd2lsbCBiZSBpbnRlcnByZXRlZCBl eGFjdGx5IHRoZSBzYW1lIGFzIFNGLCBhbmQgaWYgdGhhdCdzDQo+IHRoZSBjYXNlIHdoeSBoYXZl IFNEIGF0IGFsbD8gIElmIFNEIGlzIG5lY2Vzc2FyeSBpdCBtdXN0IGJlIHNvbWVob3cNCj4gZGlm ZmVyZW50IGZyb20gU0QuDQo+DQo+IEFsbC0NCj4NCj4gIEhhdmluZyBzYWlkIHRoYXQsIEknbSBu b3Qgc3VyZSBJIGRpc2FncmVlIHdpdGggR3JlZy4gIEl0IHNlZW1zIHRoYXQNCj4gdGhpcyBpZGVh IG9mIHByb3BhZ2F0aW5nIHNlcnZlciBsYXllciBTRCB1cCBpbnRvIFRQIGlzIGJlaW5nIGRvbmUN Cj4gYmVjYXVzZSB0aGVyZSdzIG5vIGdvb2Qgd2F5IHRvIGRvIFNEIGVudGlyZWx5IHdpdGhpbiB0 aGUgVFAgbGF5ZXIuICBJDQo+IHN1c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRv IFNEIHdpdGhpbiB0aGUgVFAgbGF5ZXIgdGhhdCBtYWRlDQo+IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3 b3VsZG4ndCBoYXZlIHRoZSBhcHByb2FjaCBwcm9wc2VkIGluDQo+IGRyYWZ0LXJraGQtbXBscy10 cC1zZC4gIEFuZCBJIHRoaW5rIHRoYXQgaWYgdGhlIG1vdGl2YXRpb24gZm9yIHRoaXMNCj4gZHJh ZnQgaXM6DQo+DQo+ICAtIHdlIG11c3QgaGF2ZSBTRCBpbiBUUCBiZWNhdXNlIGl0IGlzIHBvc3Np YmxlIHRvIGRvIGluIG90aGVyDQo+IHRlY2hub2xvZ2llcw0KPiAgLSBpdCBpcyBub3QgcG9zc2li bGUgdG8gU0QgZW50aXJlbHkgd2l0aGluIFRQDQo+ICAtIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBT RCBmcm9tIHNvbWV3aGVyZSBlbHNlDQo+DQo+IGlzIGEgcmVhc29uYWJsZSBvbmUuICBJZiB3ZSBk byB0aGF0LCB3aGVyZSBkbyB3ZSBzdG9wPyAgU2hvdWxkIHdlDQo+IHByb3BhZ2F0ZSBpbmZvcm1h dGlvbiBhYm91dCBzaWduYWwgcXVhbGl0eSB1cCB0byBUQ1Agc28gaXQgY2FuIGFkanVzdA0KPiBp dHMgd2luZG93cyBhY2NvcmRpbmc/ICAocGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGludGVuZGVk IHRvIGJlIGENCj4gcmVkdWN0aW8gYWQgYWJzdXJkdW0gcXVlc3Rpb24gYW5kIG5vdCBhIHNlcmlv dXMgb25lLiA6KSApDQo+DQo+DQo+DQo+IGVyaWMNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPj4gR3JlZyBNaXJza3kNCj4+IFNlbnQ6IFdl ZG5lc2RheSwgSnVseSAyNywgMjAxMSAyOjA4IFBNDQo+PiBUbzogRGFuaWVsIENvaG47IHJhZmly QG9yY2tpdC5jb207IG1zLWRhaWtva3VAa2RkaS5jb207DQo+PiBtYS55dXhpYUB6dGUuY29tLmNu OyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybw0KPj4gR2Vy YXJkbzsgbXBsc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0 LXJraGQtbXBscy10cC1zZC0wMw0KPj4NCj4+IERlYXIgQXV0aG9ycyBhbmQgQWxsLA0KPj4gSSB0 aGluayB0aGF0IGl0IGlzIGZ1bmN0aW9uIG9mIHRoZSBQSFkgbGF5ZXIgdG8gZGV0ZWN0IFNEIGNv bmRpdGlvbg0KPiBhbmQNCj4+IGNvbnZlcnQgaXQgaW50byBEb3duIGZvciB0aGUgTVBMUy1UUCBM YXllciAwICh3aGF0IHdlIHJlZmVyIGFzDQo+IFBoeXNpY2FsDQo+PiBTZWN0aW9uKS4gSW4gY2Fz ZSBvZiBhY2N1bXVsYXRpbmcgU0Qgb3ZlciBMU1AgdGhlIGUyZSBQYWNrZXQgTG9zcw0KPj4gbWVh c3VyZW1lbnQsIGluIG15IHZpZXcsIGlzIGFkZHJlc3NpbmcgdGhlIGlzc3VlLg0KPj4NCj4+IFJl Z2FyZHMsDQo+PiBHcmVnDQo+DQo+DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGln YXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1h aWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000A2161482578DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWcgYW5kIGFsbCw8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgd2FudCB0byBj bGFyaWZ5IHNldmVyYWwgdGhpbmdzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+MSkgV2h5IHNvbWUgdmVuZG9ycyBkbyB0aGUgcmVzZWFyY2gNCmFuZCBk ZXZlbG9wbWVudCBvbiBTRCBvZiBNUExTLVRQPyAmbmJzcDuhqqGqICZuYnNwO1JlcXVpcmVtZW50 cyBmcm9tDQpzZXJ2aWNlIHByb3ZpZGVycy4gJm5ic3A7U0Qgc2hvdWxkIGJlIHJlcG9ydGVkIGFu ZCB0cmlnZ2VyIHRvIHByb3RlY3Rpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4yKSBXaHkgcHJvcGFnYXRlIHNlcnZlciBsYXllciBpbmZvcg0KdG8g VFA/ICZuYnNwO6GqoaogSU1PLCBTaWduYWwgZGVncmFkZSBvbmx5IHJlZmVycyB0byB0aGUgYml0 IGVycm9yIGhhcHBlbmluZw0Kb24gdGhlIHBoeXNpY2FsIGxheWVyLiBQYWNrZXQgbG9zcyBpbmR1 Y2VkIGJ5IGNvbmdlc3Rpb24gb3IgQ1BVIG92ZXJsb2FkDQppcyBub3QgdGhlIGZhY3RvciB0byBT RC4gSW4gb3JkZXIgdG8gYXZvaWQgdGhlc2UgaW1wYWN0cywgd2UgdXNlIHRoZSBpbmZvcm1hdGlv bg0KZGV0ZWN0ZWQgYnkgcGh5c2ljYWwgbGF5ZXIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4zKSBXaHkgb25seSBwcm9wYWdhdGUgdG8gVFA/IKGqoaoN CldlIHRoaW5rIGl0IGlzIG5vdCBvbmx5IFRQLCBidXQgYWxzbyBQVy4gSW4gZmFjdCwgcHJvcGFn YXRlIHRvIHRyYW5zcG9ydA0KcGF0aC4gSXQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjQpIFdoeSBub3Qg cHJvcGFnYXRlIHRvIHRoZSBoaWdoZXIgbGF5ZXINCmFib3ZlIHRoYW5zcG9ydCBwYXRoPyChqqGq IE5vdywgd2UgYXJlIGRpc2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50IGFuZA0Kc29sdXRpb24gcmVm ZXJyaW5nIHRvIHRyYW5zcG9ydCBwYXRoLiBXaGV0aGVyIHByb3BhZ2F0ZSB0byBoaWdoZXIgbGF5 ZXINCmlzIG5vdCB0aGUgdG9waWMgd2UgY2FyZSBhYm91dC4gPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+UmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+WXV4aWE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R3JlZyBNaXJza3kgJmx0O2dyZWdp bWlyc2t5QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMS0wNy0yOSAwMTowMDwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5EYW5pZWwgQ29obiAmbHQ7RGFuaWVsQ0BvcmNr aXQuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkmcXVvdDsNCiZsdDtlb3Nib3JuZUBjaXNjby5jb20mZ3Q7LCBSYWZpIFJhbSAmbHQ7UmFmaVJA b3Jja2l0LmNvbSZndDssIG1zLWRhaWtva3VAa2RkaS5jb20sDQptYS55dXhpYUB6dGUuY29tLmNu LCB5YW5nLmppYW45MEB6dGUuY29tLmNuLCAmcXVvdDtEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybw0K R2VyYXJkbyZxdW90OyAmbHQ7YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0 Jmd0OywgbXBsc0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzXSBDb21tZW50 cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJs ZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpIERhbmllbCw8YnI+DQpJIHRoaW5rIHRo YXQgd2hpbGUgd2UncmUgYnVpbGRpbmcgTVBMUy1UUCB0byBiZSBzdWl0ZWQgZm9yIHRoZTxicj4N CnRyYW5zcG9ydCB3ZSBuZWVkIHRvIHJlbWVtYmVyIHRoYXQgaXQsIGFzIE5laWwgcG9pbnRlZCBv dXQgb24gbnVtYmVyPGJyPg0Kb2Ygb2NjYXNpb25zLCBpcyBub3QgQk9TIGxheWVyIGFuZCBkb2Vz bid0IHB1dCBiaXRzIG9uIGEgd2lyZS4gVGh1cyBpdDxicj4NCmhhcyBjaGFyYWN0ZXJpc3RpYyB0 aGF0IG1ha2VzIGl0IGRpZmZlcmVudCBmcm9tIG90aGVyIGxheWVycyBvZiBhPGJyPg0KdHJhbnNw b3J0IG5ldHdvcmsgYW5kLCBJIHRoaW5rLCBhcyByZXN1bHQgbm90IGFsbCBleGlzdGluZyBjb25j ZXB0cyBvZjxicj4NCnRyYW5zcG9ydCBhcmUgYXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVh bGl6ZWQgYnkgTVBMUy1UUC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkdyZWc8YnI+DQo8YnI+ DQpPbiBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUxIEFNLCBEYW5pZWwgQ29obiAmbHQ7RGFuaWVs Q0BvcmNraXQuY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyBIaSBFcmljLDxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uZSBvZiB0aGUgcmVhc29ucyB3aHkgd2UgbmVlZCBTRCBpbiBUUCBpcyBiZWNhdXNl IFRQIGlzIHN1cHBvc2VkDQp0bzxicj4NCiZndDsgcHJvdmlkZSB0aGUgc2FtZSAmcXVvdDtsb29r IGFuZCBmZWVsJnF1b3Q7IG9mIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3JrcywNCmFzPGJyPg0K Jmd0OyBzcGVjaWZpZWQgaW4gdGhlIFRQIHJlcXVpcmVtZW50cyBkb2N1bWVudC48YnI+DQomZ3Q7 IFRyYW5zcG9ydCBuZXR3b3JrcyB0ZWNobm9sb2dpZXMgaGF2ZSBsb25nIHN1cHBvcnRlZCB0aGUg ZGlzdGluY3Rpb248YnI+DQomZ3Q7IGJldHdlZW4gJnF1b3Q7ZGVncmFkZWQmcXVvdDsgYW5kICZx dW90OyBmYXVsdHkmcXVvdDsuIEluIHBhcnRpY3VsYXIsDQpwcm90ZWN0aW9uIHRlY2hub2xvZ2ll czxicj4NCiZndDsgaW4gdXNlIGhhdmUgdGhpcyBkaXN0aW5jdGlvbiBidWlsdCBpbnRvIHRoZSBp bm5lcm1vc3QgcmVjZWRlcyBvZiB0aGVpcjxicj4NCiZndDsgcHJvdG9jb2xzLjxicj4NCiZndDsg RXZlbiBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRpZG4ndCBzcGVsbCB0aGlzIG91dCwgSSB0aGlu ayBpdCB3b3VsZA0KYmUgYTxicj4NCiZndDsgbWlzdGFrZSBub3QgdG8gdGFrZSBhZHZhbnRhZ2Ug b2YgeWVhcnMgb2YgZXhwZXJpZW5jZSBpbiB0cmFuc3BvcnQ8YnI+DQomZ3Q7IG5ldHdvcmtzIE9B TS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDs8YnI+DQomZ3Q7IERhbmll bDxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNv bV08YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDExOjEyIEFNPGJyPg0K Jmd0OyBUbzogR3JlZyBNaXJza3k7IERhbmllbCBDb2huOyBSYWZpIFJhbTsgbXMtZGFpa29rdUBr ZGRpLmNvbTs8YnI+DQomZ3Q7IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5j b20uY247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvPGJyPg0KJmd0OyBHZXJhcmRvOyBtcGxzQGll dGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJr aGQtbXBscy10cC1zZC0wMzxicj4NCiZndDs8YnI+DQomZ3Q7IEhpIEdyZWctPGJyPg0KJmd0OyAm bmJzcDtUaGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBhbmQgU0QuICZuYnNwO0NvbnZl cnRpbmcgU0QNCmludG8gRG93bjxicj4NCiZndDsgbWVhbnMgdGhhdCBpdCB3aWxsIGJlIGludGVy cHJldGVkIGV4YWN0bHkgdGhlIHNhbWUgYXMgU0YsIGFuZCBpZiB0aGF0J3M8YnI+DQomZ3Q7IHRo ZSBjYXNlIHdoeSBoYXZlIFNEIGF0IGFsbD8gJm5ic3A7SWYgU0QgaXMgbmVjZXNzYXJ5IGl0IG11 c3QgYmUgc29tZWhvdzxicj4NCiZndDsgZGlmZmVyZW50IGZyb20gU0QuPGJyPg0KJmd0Ozxicj4N CiZndDsgQWxsLTxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwO0hhdmluZyBzYWlkIHRoYXQsIEkn bSBub3Qgc3VyZSBJIGRpc2FncmVlIHdpdGggR3JlZy4gJm5ic3A7SXQNCnNlZW1zIHRoYXQ8YnI+ DQomZ3Q7IHRoaXMgaWRlYSBvZiBwcm9wYWdhdGluZyBzZXJ2ZXIgbGF5ZXIgU0QgdXAgaW50byBU UCBpcyBiZWluZyBkb25lPGJyPg0KJmd0OyBiZWNhdXNlIHRoZXJlJ3Mgbm8gZ29vZCB3YXkgdG8g ZG8gU0QgZW50aXJlbHkgd2l0aGluIHRoZSBUUCBsYXllci4NCiZuYnNwO0k8YnI+DQomZ3Q7IHN1 c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbiB0aGUgVFAgbGF5 ZXIgdGhhdA0KbWFkZTxicj4NCiZndDsgZXZlcnlvbmUgaGFwcHksIHdlIHdvdWxkbid0IGhhdmUg dGhlIGFwcHJvYWNoIHByb3BzZWQgaW48YnI+DQomZ3Q7IGRyYWZ0LXJraGQtbXBscy10cC1zZC4g Jm5ic3A7QW5kIEkgdGhpbmsgdGhhdCBpZiB0aGUgbW90aXZhdGlvbiBmb3INCnRoaXM8YnI+DQom Z3Q7IGRyYWZ0IGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOy0gd2UgbXVzdCBoYXZlIFNE IGluIFRQIGJlY2F1c2UgaXQgaXMgcG9zc2libGUgdG8gZG8gaW4gb3RoZXI8YnI+DQomZ3Q7IHRl Y2hub2xvZ2llczxicj4NCiZndDsgJm5ic3A7LSBpdCBpcyBub3QgcG9zc2libGUgdG8gU0QgZW50 aXJlbHkgd2l0aGluIFRQPGJyPg0KJmd0OyAmbmJzcDstIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBT RCBmcm9tIHNvbWV3aGVyZSBlbHNlPGJyPg0KJmd0Ozxicj4NCiZndDsgaXMgYSByZWFzb25hYmxl IG9uZS4gJm5ic3A7SWYgd2UgZG8gdGhhdCwgd2hlcmUgZG8gd2Ugc3RvcD8gJm5ic3A7U2hvdWxk DQp3ZTxicj4NCiZndDsgcHJvcGFnYXRlIGluZm9ybWF0aW9uIGFib3V0IHNpZ25hbCBxdWFsaXR5 IHVwIHRvIFRDUCBzbyBpdCBjYW4gYWRqdXN0PGJyPg0KJmd0OyBpdHMgd2luZG93cyBhY2NvcmRp bmc/ICZuYnNwOyhwbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8NCmJlIGE8YnI+ DQomZ3Q7IHJlZHVjdGlvIGFkIGFic3VyZHVtIHF1ZXN0aW9uIGFuZCBub3QgYSBzZXJpb3VzIG9u ZS4gOikgKTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgZXJpYzxicj4N CiZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsm Z3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24NCkJlaGFsZjxicj4NCiZndDsgT2Y8YnI+DQomZ3Q7Jmd0OyBHcmVnIE1pcnNreTxi cj4NCiZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyNywgMjAxMSAyOjA4IFBNPGJyPg0K Jmd0OyZndDsgVG86IERhbmllbCBDb2huOyByYWZpckBvcmNraXQuY29tOyBtcy1kYWlrb2t1QGtk ZGkuY29tOzxicj4NCiZndDsmZ3Q7IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0 ZS5jb20uY247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvPGJyPg0KJmd0OyZndDsgR2VyYXJkbzsg bXBsc0BpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFttcGxzXSBDb21tZW50cyB0byBk cmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IERlYXIg QXV0aG9ycyBhbmQgQWxsLDxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhhdCBpdCBpcyBmdW5jdGlv biBvZiB0aGUgUEhZIGxheWVyIHRvIGRldGVjdCBTRCBjb25kaXRpb248YnI+DQomZ3Q7IGFuZDxi cj4NCiZndDsmZ3Q7IGNvbnZlcnQgaXQgaW50byBEb3duIGZvciB0aGUgTVBMUy1UUCBMYXllciAw ICh3aGF0IHdlIHJlZmVyIGFzPGJyPg0KJmd0OyBQaHlzaWNhbDxicj4NCiZndDsmZ3Q7IFNlY3Rp b24pLiBJbiBjYXNlIG9mIGFjY3VtdWxhdGluZyBTRCBvdmVyIExTUCB0aGUgZTJlIFBhY2tldCBM b3NzPGJyPg0KJmd0OyZndDsgbWVhc3VyZW1lbnQsIGluIG15IHZpZXcsIGlzIGFkZHJlc3Npbmcg dGhlIGlzc3VlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7 Jmd0OyBHcmVnPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000A2161482578DC_=-- From su.hui@zte.com.cn Thu Jul 28 19:50:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2821F85A0; Thu, 28 Jul 2011 19:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klCerY9HHcfO; Thu, 28 Jul 2011 19:50:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 317E121F855B; Thu, 28 Jul 2011 19:50:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321784411434; Fri, 29 Jul 2011 10:41:55 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 83350.2742739136; Fri, 29 Jul 2011 10:50:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6T2oJvF079084; Fri, 29 Jul 2011 10:50:20 +0800 (GMT-8) (envelope-from su.hui@zte.com.cn) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> To: "Daniel Cohn" MIME-Version: 1.0 X-KeepSent: 02957AA9:86BD7A6D-482578DC:000F6213; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: su.hui@zte.com.cn Date: Fri, 29 Jul 2011 10:50:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-29 10:50:21, Serialize complete at 2011-07-29 10:50:21 Content-Type: multipart/alternative; boundary="=_alternative 000F9C2F482578DC_=" X-MAIL: mse02.zte.com.cn p6T2oJvF079084 Cc: mpls@ietf.org, mpls-bounces@ietf.org, huubatwork@gmail.com Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 02:50:39 -0000 This is a multipart message in MIME format. --=_alternative 000F9C2F482578DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBEYW5pZWwgYW5kIFBhYmxvLg0KU2V2ZXJhbCBjYXJyaWVycyBoYXZlIHRoZSBy ZXF1aXJlbWVudCBvZiBTRCBwcm90ZWN0aW9uLCBhbmQgdGhpcyANCnJlcXVpcmVtZW50IGlzIGFs cmVhZHkgaW5jbHVkZWQgaW4gdGhlIGRyYWZ0IG9mIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIA0K YW5kIGxpbmVhciBwcm90ZWN0aW9uLiBTbyB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIGFjaGll dmUgdGhlIA0KcmVxdWlyZW1lbnQuIA0KSSB0aGluayB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlIGlu IGRyYWZ0LXJraGQtbXBscy10cC1zZCBpcyBhIGdvb2Qgd2F5IHRvIA0KYWNoaWV2ZSB0aGUgcmVx dWlyZW1lbnQuDQoNClN1SHVpDQoNCg0KDQoNCg0KIkRhbmllbCBDb2huIiA8RGFuaWVsQ0BvcmNr aXQuY29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wNy0yOSAwNDox Ng0KDQrK1bz+yMsNCjxodXViYXR3b3JrQGdtYWlsLmNvbT4sIDxtcGxzQGlldGYub3JnPg0Ks63L zQ0KDQrW98ziDQpSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0w Mw0KDQoNCg0KDQoNCg0KSSBkb24ndCB0aGluayBzZW5kaW5nIGl0ZXJhdGl2ZSBlLW1haWxzIHJl ZmVycmluZyB0byBldmVyIGhpZ2hlciBsYXllcg0Kc2VydmVzIHRoZSBwb2ludCBvZiB0aGlzIGRp c2N1c3Npb24uIEEgc2ltaWxhciBhcmd1bWVudCBjYW4gYmUgbWFkZSBvbg0KZS5nLiBvdGhlciB0 ZWNobm9sb2dpZXMgc2VuZGluZyBBSVMtbGlrZSBpbmRpY2F0aW9ucyBvbiBhbGwgY2xpZW50DQps YXllcnMuDQpJIHRoaW5rIHdlIHNob3VsZCBmb2N1cyBvbiB3aGF0IFBhYmxvIHdyb3RlLCBpLmUu IGRvIHdlIHdhbnQgdG8gcHJvdmlkZQ0KU0QgdG8gTVBMUyBsYXllcnMsIGxpa2UgZXhpc3Rpbmcg dHJhbnNwb3J0IG5ldHdvcmtzLCBvciBub3Q/IEFuZCBpZiB3ZQ0KZG8sIHdoYXQgaXMgdGhlIGJl c3Qgd2F5IHRvIGRvIGl0Pw0KDQpEQw0KDQpQUzogTm8gbmVlZCB0bywgdGhlIFZDMTIgaGFzIGl0 cyBvd24gU0QgZGV0ZWN0aW9uIGNhcGFiaWxpdGllcy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCkh1dWIgdmFuIEhlbHZvb3J0DQpTZW50OiBUaHVyc2Rh eSwgSnVseSAyOCwgMjAxMSA0OjEyIFBNDQpUbzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCg0KQW5kIHByb3Bh Z2F0ZSB0byB0aGUgVkMxMiBjYXJyaWVkIEJ5IHRoZSBQVz8NCmFuZC4uLg0KDQpIdXViDQoNCg0K DQo+IEFsc28sIGlmIHdlIHdlcmUgdG8gcHJvcGFnYXRlIHRvIFRwLCB3aHkgc3RvcCB0aGVyZT8g SXQgc2hvdWxkIGJlDQpwcm9wYWdhdGVkIHRvIFBXIGFzIHdlbGwsIHJpZ2h0Pw0KPg0KPiBTYW0N Cj4NCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPg0KPiBPbiBKdWwgMjgsIDIwMTEsIGF0IDI6NDEg UE0sICJTaGFoLCBIaW1hbnNodSI8aHNoYWhAY2llbmEuY29tPiAgd3JvdGU6DQo+DQo+PiBJIGFn cmVlIHdpdGggRXJpYywgU2hhaHJhbSBhbmQgYWN0dWFsbHkgcmljaGFyZCBrYW0gKGFsY2F0ZWwv bHVjZW50KQ0KbWFkZSB0aGlzIGV4YWN0IHBvaW50IGF0IHRoZSBtaWtlDQo+PiBkdXJpbmcgcHJl c2VudGF0aW9uLg0KPj4NCj4+IC9oaW1hbnNodQ0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpPZiBTaGFocmFtIERhdmFyaQ0KPj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMjozMCBQTQ0KPj4gVG86IERhbmllbCBDb2huOyBH cmVnIE1pcnNreQ0KPj4gQ2M6IFJhZmkgUmFtOyBtcGxzQGlldGYub3JnOyBtcy1kYWlrb2t1QGtk ZGkuY29tOw0KeWFuZy5qaWFuOTBAenRlLmNvbS5jbg0KPj4gU3ViamVjdDogUmU6IFttcGxzXSBD b21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCj4+DQo+PiBIaSwNCj4+DQo+PiBJ IGFsc28gZG9uJ3QgYmVsaWV2ZSBTRCBpcyBuZWVkZWQgZm9yIE1QTFMtVFAuIFN1Y2ggZGVmZWN0 IGlzIG5vdA0KcmVsYXRlZCB0byBNUExTLVRQIGFuZCBzaG91bGQgYmUgaGFuZGxlZCBpbiB0aGUg c2VydmVyIGxheWVyLCBzdWNoIGFzDQpjaGFuZ2luZyB0aGUgRkVDIHR5cGUgaW4gT1ROLCBldGMu DQo+Pg0KPj4gUmVnYXJkcywNCj4+IFNoYWhyYW0NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIERhbmllbCBDb2huDQo+PiBTZW50OiBUaHVyc2Rh eSwgSnVseSAyOCwgMjAxMSAxMDoxNSBBTQ0KPj4gVG86IEdyZWcgTWlyc2t5DQo+PiBDYzogbXBs c0BpZXRmLm9yZzsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgbXMtZGFpa29rdUBrZGRpLmNvbTsg UmFmaQ0KUmFtDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQt bXBscy10cC1zZC0wMw0KPj4NCj4+IFRydWUgZW5vdWdoIGluIGdlbmVyYWwuIEJ1dCBpbiB0aGlz IHBhcnRpY3VsYXIgZXhhbXBsZSwgdGhlcmUgaXMNCm5vdGhpbmcgc3VnZ2VzdGVkIGJ5IHRoaXMg ZHJhZnQgdGhhdCByZXF1aXJlcyBodWdlIGltcGxlbWVudGF0aW9uDQplZmZvcnRzIG9yIHBhcmFk aWdtIGNoYW5nZXMuIFNvIEkgZmFpbCB0byBzZWUgd2h5IHdlIHNob3VsZCBzZXR0bGUgZm9yDQps ZXNzIGZ1bmN0aW9uYWxpdHkgdGhhbiBpcyBhdmFpbGFibGUgaW4gZXhpc3RpbmcgdHJhbnNwb3J0 IG5ldHdvcmtzLg0KPj4NCj4+IERDDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+IEZyb206IEdyZWcgTWlyc2t5IFttYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tXQ0KPj4g U2VudDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTowMCBQTQ0KPj4gVG86IERhbmllbCBDb2hu DQo+PiBDYzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IFJhZmkgUmFtOyBtcy1kYWlrb2t1QGtk ZGkuY29tOw0KbWEueXV4aWFAenRlLmNvbS5jbjsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8NCkdlcmFyZG87IG1wbHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+Pg0KPj4g SGkgRGFuaWVsLA0KPj4gSSB0aGluayB0aGF0IHdoaWxlIHdlJ3JlIGJ1aWxkaW5nIE1QTFMtVFAg dG8gYmUgc3VpdGVkIGZvciB0aGUNCj4+IHRyYW5zcG9ydCB3ZSBuZWVkIHRvIHJlbWVtYmVyIHRo YXQgaXQsIGFzIE5laWwgcG9pbnRlZCBvdXQgb24gbnVtYmVyDQo+PiBvZiBvY2Nhc2lvbnMsIGlz IG5vdCBCT1MgbGF5ZXIgYW5kIGRvZXNuJ3QgcHV0IGJpdHMgb24gYSB3aXJlLiBUaHVzDQppdA0K Pj4gaGFzIGNoYXJhY3RlcmlzdGljIHRoYXQgbWFrZXMgaXQgZGlmZmVyZW50IGZyb20gb3RoZXIg bGF5ZXJzIG9mIGENCj4+IHRyYW5zcG9ydCBuZXR3b3JrIGFuZCwgSSB0aGluaywgYXMgcmVzdWx0 IG5vdCBhbGwgZXhpc3RpbmcgY29uY2VwdHMNCm9mDQo+PiB0cmFuc3BvcnQgYXJlIGFwcGxpY2Fi bGUgdG8gcGFja2V0IGxheWVyIHJlYWxpemVkIGJ5IE1QTFMtVFAuDQo+Pg0KPj4gUmVnYXJkcywN Cj4+IEdyZWcNCj4+DQo+PiBPbiBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUxIEFNLCBEYW5pZWwg Q29objxEYW5pZWxDQG9yY2tpdC5jb20+DQp3cm90ZToNCj4+PiBIaSBFcmljLA0KPj4+DQo+Pj4g T25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIFNEIGluIFRQIGlzIGJlY2F1c2UgVFAgaXMg c3VwcG9zZWQgdG8NCj4+PiBwcm92aWRlIHRoZSBzYW1lICJsb29rIGFuZCBmZWVsIiBvZiBleGlz dGluZyB0cmFuc3BvcnQgbmV0d29ya3MsIGFzDQo+Pj4gc3BlY2lmaWVkIGluIHRoZSBUUCByZXF1 aXJlbWVudHMgZG9jdW1lbnQuDQo+Pj4gVHJhbnNwb3J0IG5ldHdvcmtzIHRlY2hub2xvZ2llcyBo YXZlIGxvbmcgc3VwcG9ydGVkIHRoZSBkaXN0aW5jdGlvbg0KPj4+IGJldHdlZW4gImRlZ3JhZGVk IiBhbmQgIiBmYXVsdHkiLiBJbiBwYXJ0aWN1bGFyLCBwcm90ZWN0aW9uDQp0ZWNobm9sb2dpZXMN Cj4+PiBpbiB1c2UgaGF2ZSB0aGlzIGRpc3RpbmN0aW9uIGJ1aWx0IGludG8gdGhlIGlubmVybW9z dCByZWNlZGVzIG9mDQp0aGVpcg0KPj4+IHByb3RvY29scy4NCj4+PiBFdmVuIGluIHRoZSBUUCBy ZXF1aXJlbWVudHMgZGlkbid0IHNwZWxsIHRoaXMgb3V0LCBJIHRoaW5rIGl0IHdvdWxkDQpiZSBh DQo+Pj4gbWlzdGFrZSBub3QgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgeWVhcnMgb2YgZXhwZXJpZW5j ZSBpbiB0cmFuc3BvcnQNCj4+PiBuZXR3b3JrcyBPQU0uDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+ DQo+Pj4gRGFuaWVsDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZy b206IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIFttYWlsdG86ZW9zYm9ybmVAY2lzY28uY29tXQ0K Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDExOjEyIEFNDQo+Pj4gVG86IEdyZWcg TWlyc2t5OyBEYW5pZWwgQ29objsgUmFmaSBSYW07IG1zLWRhaWtva3VAa2RkaS5jb207DQo+Pj4g bWEueXV4aWFAenRlLmNvbS5jbjsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCdBbGVzc2FuZHJv IEFsZXNzYW5kcm8NCj4+PiBHZXJhcmRvOyBtcGxzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6 IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCj4+Pg0KPj4+IEhp IEdyZWctDQo+Pj4gVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gU0YgYW5kIFNELiAgQ29u dmVydGluZyBTRCBpbnRvIERvd24NCj4+PiBtZWFucyB0aGF0IGl0IHdpbGwgYmUgaW50ZXJwcmV0 ZWQgZXhhY3RseSB0aGUgc2FtZSBhcyBTRiwgYW5kIGlmDQp0aGF0J3MNCj4+PiB0aGUgY2FzZSB3 aHkgaGF2ZSBTRCBhdCBhbGw/ICBJZiBTRCBpcyBuZWNlc3NhcnkgaXQgbXVzdCBiZSBzb21laG93 DQo+Pj4gZGlmZmVyZW50IGZyb20gU0QuDQo+Pj4NCj4+PiBBbGwtDQo+Pj4NCj4+PiBIYXZpbmcg c2FpZCB0aGF0LCBJJ20gbm90IHN1cmUgSSBkaXNhZ3JlZSB3aXRoIEdyZWcuICBJdCBzZWVtcyB0 aGF0DQo+Pj4gdGhpcyBpZGVhIG9mIHByb3BhZ2F0aW5nIHNlcnZlciBsYXllciBTRCB1cCBpbnRv IFRQIGlzIGJlaW5nIGRvbmUNCj4+PiBiZWNhdXNlIHRoZXJlJ3Mgbm8gZ29vZCB3YXkgdG8gZG8g U0QgZW50aXJlbHkgd2l0aGluIHRoZSBUUCBsYXllci4NCkkNCj4+PiBzdXNwZWN0IHRoYXQgaWYg dGhlcmUgd2VyZSBhIHdheSB0byBkbyBTRCB3aXRoaW4gdGhlIFRQIGxheWVyIHRoYXQNCm1hZGUN Cj4+PiBldmVyeW9uZSBoYXBweSwgd2Ugd291bGRuJ3QgaGF2ZSB0aGUgYXBwcm9hY2ggcHJvcHNl ZCBpbg0KPj4+IGRyYWZ0LXJraGQtbXBscy10cC1zZC4gIEFuZCBJIHRoaW5rIHRoYXQgaWYgdGhl IG1vdGl2YXRpb24gZm9yIHRoaXMNCj4+PiBkcmFmdCBpczoNCj4+Pg0KPj4+IC0gd2UgbXVzdCBo YXZlIFNEIGluIFRQIGJlY2F1c2UgaXQgaXMgcG9zc2libGUgdG8gZG8gaW4gb3RoZXINCj4+PiB0 ZWNobm9sb2dpZXMNCj4+PiAtIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBTRCBlbnRpcmVseSB3aXRo aW4gVFANCj4+PiAtIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBTRCBmcm9tIHNvbWV3aGVyZSBlbHNl DQo+Pj4NCj4+PiBpcyBhIHJlYXNvbmFibGUgb25lLiAgSWYgd2UgZG8gdGhhdCwgd2hlcmUgZG8g d2Ugc3RvcD8gIFNob3VsZCB3ZQ0KPj4+IHByb3BhZ2F0ZSBpbmZvcm1hdGlvbiBhYm91dCBzaWdu YWwgcXVhbGl0eSB1cCB0byBUQ1Agc28gaXQgY2FuDQphZGp1c3QNCj4+PiBpdHMgd2luZG93cyBh Y2NvcmRpbmc/ICAocGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGludGVuZGVkIHRvIGJlIGENCj4+ PiByZWR1Y3RpbyBhZCBhYnN1cmR1bSBxdWVzdGlvbiBhbmQgbm90IGEgc2VyaW91cyBvbmUuIDop ICkNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBlcmljDQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmDQo+Pj4gT2YNCj4+Pj4gR3JlZyBNaXJza3kNCj4+ Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDI6MDggUE0NCj4+Pj4gVG86IERhbmll bCBDb2huOyByYWZpckBvcmNraXQuY29tOyBtcy1kYWlrb2t1QGtkZGkuY29tOw0KPj4+PiBtYS55 dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8NCkFs ZXNzYW5kcm8NCj4+Pj4gR2VyYXJkbzsgbXBsc0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBbbXBs c10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+Pj4+DQo+Pj4+IERlYXIg QXV0aG9ycyBhbmQgQWxsLA0KPj4+PiBJIHRoaW5rIHRoYXQgaXQgaXMgZnVuY3Rpb24gb2YgdGhl IFBIWSBsYXllciB0byBkZXRlY3QgU0QgY29uZGl0aW9uDQo+Pj4gYW5kDQo+Pj4+IGNvbnZlcnQg aXQgaW50byBEb3duIGZvciB0aGUgTVBMUy1UUCBMYXllciAwICh3aGF0IHdlIHJlZmVyIGFzDQo+ Pj4gUGh5c2ljYWwNCj4+Pj4gU2VjdGlvbikuIEluIGNhc2Ugb2YgYWNjdW11bGF0aW5nIFNEIG92 ZXIgTFNQIHRoZSBlMmUgUGFja2V0IExvc3MNCj4+Pj4gbWVhc3VyZW1lbnQsIGluIG15IHZpZXcs IGlzIGFkZHJlc3NpbmcgdGhlIGlzc3VlLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBHcmVn DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000F9C2F482578DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkFncmVlIHdp dGggRGFuaWVsIGFuZCBQYWJsby48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+U2V2ZXJhbCBjYXJyaWVycyBoYXZlIHRoZSByZXF1aXJlbWVudA0Kb2YgU0Qg cHJvdGVjdGlvbiwgYW5kIHRoaXMgcmVxdWlyZW1lbnQgaXMgYWxyZWFkeSBpbmNsdWRlZCBpbiB0 aGUgZHJhZnQNCm9mIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGFuZCBsaW5lYXIgcHJvdGVjdGlv bi4gU28gd2Ugc2hvdWxkIGZvY3VzIG9uDQpob3cgdG8gYWNoaWV2ZSB0aGUgcmVxdWlyZW1lbnQu IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHRoaW5r IHRoZSBtZWNoYW5pc20gZGVzY3JpYmUNCmluIGRyYWZ0LXJraGQtbXBscy10cC1zZCBpcyBhIGdv b2Qgd2F5IHRvIGFjaGlldmUgdGhlIHJlcXVpcmVtZW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TdUh1aTwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtEYW5p ZWwgQ29obiZxdW90Ow0KJmx0O0RhbmllbENAb3Jja2l0LmNvbSZndDs8L2I+IDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx MS0wNy0yOSAwNDoxNjwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20mZ3Q7LCAmbHQ7bXBsc0BpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAz PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5JIGRvbid0IHRoaW5rIHNlbmRpbmcgaXRlcmF0aXZlIGUtbWFpbHMgcmVmZXJyaW5nDQp0byBl dmVyIGhpZ2hlciBsYXllcjxicj4NCnNlcnZlcyB0aGUgcG9pbnQgb2YgdGhpcyBkaXNjdXNzaW9u LiBBIHNpbWlsYXIgYXJndW1lbnQgY2FuIGJlIG1hZGUgb248YnI+DQplLmcuIG90aGVyIHRlY2hu b2xvZ2llcyBzZW5kaW5nIEFJUy1saWtlIGluZGljYXRpb25zIG9uIGFsbCBjbGllbnQ8YnI+DQps YXllcnMuPGJyPg0KSSB0aGluayB3ZSBzaG91bGQgZm9jdXMgb24gd2hhdCBQYWJsbyB3cm90ZSwg aS5lLiBkbyB3ZSB3YW50IHRvIHByb3ZpZGU8YnI+DQpTRCB0byBNUExTIGxheWVycywgbGlrZSBl eGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MsIG9yIG5vdD8gQW5kIGlmIHdlPGJyPg0KZG8sIHdo YXQgaXMgdGhlIGJlc3Qgd2F5IHRvIGRvIGl0Pzxicj4NCjxicj4NCkRDPGJyPg0KPGJyPg0KUFM6 IE5vIG5lZWQgdG8sIHRoZSBWQzEyIGhhcyBpdHMgb3duIFNEIGRldGVjdGlvbiBjYXBhYmlsaXRp ZXMuPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZjxicj4NCkh1dWIgdmFuIEhlbHZvb3J0PGJyPg0KU2VudDogVGh1cnNkYXksIEp1 bHkgMjgsIDIwMTEgNDoxMiBQTTxicj4NClRvOiBtcGxzQGlldGYub3JnPGJyPg0KU3ViamVjdDog UmU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+DQo8YnI+ DQpBbmQgcHJvcGFnYXRlIHRvIHRoZSBWQzEyIGNhcnJpZWQgQnkgdGhlIFBXPzxicj4NCmFuZC4u Ljxicj4NCjxicj4NCkh1dWI8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEFsc28sIGlmIHdl IHdlcmUgdG8gcHJvcGFnYXRlIHRvIFRwLCB3aHkgc3RvcCB0aGVyZT8gSXQgc2hvdWxkIGJlPGJy Pg0KcHJvcGFnYXRlZCB0byBQVyBhcyB3ZWxsLCByaWdodD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBT YW08YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZW50IGZyb20gbXkgaVBob25lPGJyPg0KJmd0Ozxicj4N CiZndDsgT24gSnVsIDI4LCAyMDExLCBhdCAyOjQxIFBNLCAmcXVvdDtTaGFoLCBIaW1hbnNodSZx dW90OyZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7DQombmJzcDt3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIEVyaWMsIFNoYWhyYW0gYW5kIGFjdHVhbGx5IHJpY2hhcmQg a2FtIChhbGNhdGVsL2x1Y2VudCk8YnI+DQptYWRlIHRoaXMgZXhhY3QgcG9pbnQgYXQgdGhlIG1p a2U8YnI+DQomZ3Q7Jmd0OyBkdXJpbmcgcHJlc2VudGF0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgL2hpbWFuc2h1PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0 OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uDQpCZWhhbGY8YnI+DQpPZiBTaGFocmFtIERhdmFyaTxicj4NCiZndDsmZ3Q7IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDI6MzAgUE08YnI+DQomZ3Q7Jmd0OyBUbzogRGFuaWVs IENvaG47IEdyZWcgTWlyc2t5PGJyPg0KJmd0OyZndDsgQ2M6IFJhZmkgUmFtOyBtcGxzQGlldGYu b3JnOyBtcy1kYWlrb2t1QGtkZGkuY29tOzxicj4NCnlhbmcuamlhbjkwQHp0ZS5jb20uY248YnI+ DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBs cy10cC1zZC0wMzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGksPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBJIGFsc28gZG9uJ3QgYmVsaWV2ZSBTRCBpcyBuZWVkZWQgZm9yIE1QTFMt VFAuIFN1Y2ggZGVmZWN0IGlzDQpub3Q8YnI+DQpyZWxhdGVkIHRvIE1QTFMtVFAgYW5kIHNob3Vs ZCBiZSBoYW5kbGVkIGluIHRoZSBzZXJ2ZXIgbGF5ZXIsIHN1Y2ggYXM8YnI+DQpjaGFuZ2luZyB0 aGUgRkVDIHR5cGUgaW4gT1ROLCBldGMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSZWdh cmRzLDxicj4NCiZndDsmZ3Q7IFNoYWhyYW08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmPGJyPg0K T2YgRGFuaWVsIENvaG48YnI+DQomZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAx MSAxMDoxNSBBTTxicj4NCiZndDsmZ3Q7IFRvOiBHcmVnIE1pcnNreTxicj4NCiZndDsmZ3Q7IENj OiBtcGxzQGlldGYub3JnOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBtcy1kYWlrb2t1QGtkZGku Y29tOw0KUmFmaTxicj4NClJhbTxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29t bWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBUcnVlIGVub3VnaCBpbiBnZW5lcmFsLiBCdXQgaW4gdGhpcyBwYXJ0aWN1bGFyIGV4YW1w bGUsIHRoZXJlDQppczxicj4NCm5vdGhpbmcgc3VnZ2VzdGVkIGJ5IHRoaXMgZHJhZnQgdGhhdCBy ZXF1aXJlcyBodWdlIGltcGxlbWVudGF0aW9uPGJyPg0KZWZmb3J0cyBvciBwYXJhZGlnbSBjaGFu Z2VzLiBTbyBJIGZhaWwgdG8gc2VlIHdoeSB3ZSBzaG91bGQgc2V0dGxlIGZvcjxicj4NCmxlc3Mg ZnVuY3Rpb25hbGl0eSB0aGFuIGlzIGF2YWlsYWJsZSBpbiBleGlzdGluZyB0cmFuc3BvcnQgbmV0 d29ya3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEQzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBH cmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbV08YnI+DQomZ3Q7Jmd0OyBT ZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAxMSAxOjAwIFBNPGJyPg0KJmd0OyZndDsgVG86IERh bmllbCBDb2huPGJyPg0KJmd0OyZndDsgQ2M6IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBSYWZp IFJhbTsgbXMtZGFpa29rdUBrZGRpLmNvbTs8YnI+DQptYS55dXhpYUB6dGUuY29tLmNuOyB5YW5n LmppYW45MEB6dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybzxicj4NCkdlcmFyZG87 IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRz IHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg SGkgRGFuaWVsLDxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhhdCB3aGlsZSB3ZSdyZSBidWlsZGlu ZyBNUExTLVRQIHRvIGJlIHN1aXRlZCBmb3IgdGhlPGJyPg0KJmd0OyZndDsgdHJhbnNwb3J0IHdl IG5lZWQgdG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2ludGVkIG91dCBvbg0KbnVtYmVy PGJyPg0KJmd0OyZndDsgb2Ygb2NjYXNpb25zLCBpcyBub3QgQk9TIGxheWVyIGFuZCBkb2Vzbid0 IHB1dCBiaXRzIG9uIGEgd2lyZS4NClRodXM8YnI+DQppdDxicj4NCiZndDsmZ3Q7IGhhcyBjaGFy YWN0ZXJpc3RpYyB0aGF0IG1ha2VzIGl0IGRpZmZlcmVudCBmcm9tIG90aGVyIGxheWVycyBvZg0K YTxicj4NCiZndDsmZ3Q7IHRyYW5zcG9ydCBuZXR3b3JrIGFuZCwgSSB0aGluaywgYXMgcmVzdWx0 IG5vdCBhbGwgZXhpc3RpbmcgY29uY2VwdHM8YnI+DQpvZjxicj4NCiZndDsmZ3Q7IHRyYW5zcG9y dCBhcmUgYXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVhbGl6ZWQgYnkgTVBMUy1UUC48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsgR3JlZzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gVGh1LCBKdWwgMjgsIDIwMTEgYXQgOTo1MSBBTSwg RGFuaWVsIENvaG4mbHQ7RGFuaWVsQ0BvcmNraXQuY29tJmd0Ozxicj4NCndyb3RlOjxicj4NCiZn dDsmZ3Q7Jmd0OyBIaSBFcmljLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBP bmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgU0QgaW4gVFAgaXMgYmVjYXVzZSBUUCBpcyBz dXBwb3NlZA0KdG88YnI+DQomZ3Q7Jmd0OyZndDsgcHJvdmlkZSB0aGUgc2FtZSAmcXVvdDtsb29r IGFuZCBmZWVsJnF1b3Q7IG9mIGV4aXN0aW5nIHRyYW5zcG9ydA0KbmV0d29ya3MsIGFzPGJyPg0K Jmd0OyZndDsmZ3Q7IHNwZWNpZmllZCBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50Ljxi cj4NCiZndDsmZ3Q7Jmd0OyBUcmFuc3BvcnQgbmV0d29ya3MgdGVjaG5vbG9naWVzIGhhdmUgbG9u ZyBzdXBwb3J0ZWQgdGhlIGRpc3RpbmN0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7IGJldHdlZW4gJnF1 b3Q7ZGVncmFkZWQmcXVvdDsgYW5kICZxdW90OyBmYXVsdHkmcXVvdDsuIEluIHBhcnRpY3VsYXIs DQpwcm90ZWN0aW9uPGJyPg0KdGVjaG5vbG9naWVzPGJyPg0KJmd0OyZndDsmZ3Q7IGluIHVzZSBo YXZlIHRoaXMgZGlzdGluY3Rpb24gYnVpbHQgaW50byB0aGUgaW5uZXJtb3N0IHJlY2VkZXMNCm9m PGJyPg0KdGhlaXI8YnI+DQomZ3Q7Jmd0OyZndDsgcHJvdG9jb2xzLjxicj4NCiZndDsmZ3Q7Jmd0 OyBFdmVuIGluIHRoZSBUUCByZXF1aXJlbWVudHMgZGlkbid0IHNwZWxsIHRoaXMgb3V0LCBJIHRo aW5rDQppdCB3b3VsZDxicj4NCmJlIGE8YnI+DQomZ3Q7Jmd0OyZndDsgbWlzdGFrZSBub3QgdG8g dGFrZSBhZHZhbnRhZ2Ugb2YgeWVhcnMgb2YgZXhwZXJpZW5jZSBpbiB0cmFuc3BvcnQ8YnI+DQom Z3Q7Jmd0OyZndDsgbmV0d29ya3MgT0FNLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBEYW5pZWw8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkgW21h aWx0bzplb3Nib3JuZUBjaXNjby5jb21dPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDI4LCAyMDExIDExOjEyIEFNPGJyPg0KJmd0OyZndDsmZ3Q7IFRvOiBHcmVnIE1pcnNr eTsgRGFuaWVsIENvaG47IFJhZmkgUmFtOyBtcy1kYWlrb2t1QGtkZGkuY29tOzxicj4NCiZndDsm Z3Q7Jmd0OyBtYS55dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJ0Fs ZXNzYW5kcm8NCkFsZXNzYW5kcm88YnI+DQomZ3Q7Jmd0OyZndDsgR2VyYXJkbzsgbXBsc0BpZXRm Lm9yZzxicj4NCiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIHRvIGRy YWZ0LXJraGQtbXBscy10cC1zZC0wMzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBIaSBHcmVnLTxicj4NCiZndDsmZ3Q7Jmd0OyBUaGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2Vl biBTRiBhbmQgU0QuICZuYnNwO0NvbnZlcnRpbmcNClNEIGludG8gRG93bjxicj4NCiZndDsmZ3Q7 Jmd0OyBtZWFucyB0aGF0IGl0IHdpbGwgYmUgaW50ZXJwcmV0ZWQgZXhhY3RseSB0aGUgc2FtZSBh cyBTRiwNCmFuZCBpZjxicj4NCnRoYXQnczxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgY2FzZSB3aHkg aGF2ZSBTRCBhdCBhbGw/ICZuYnNwO0lmIFNEIGlzIG5lY2Vzc2FyeSBpdCBtdXN0DQpiZSBzb21l aG93PGJyPg0KJmd0OyZndDsmZ3Q7IGRpZmZlcmVudCBmcm9tIFNELjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBbGwtPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IEhhdmluZyBzYWlkIHRoYXQsIEknbSBub3Qgc3VyZSBJIGRpc2FncmVlIHdpdGggR3JlZy4g Jm5ic3A7SXQNCnNlZW1zIHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsgdGhpcyBpZGVhIG9mIHByb3Bh Z2F0aW5nIHNlcnZlciBsYXllciBTRCB1cCBpbnRvIFRQIGlzIGJlaW5nDQpkb25lPGJyPg0KJmd0 OyZndDsmZ3Q7IGJlY2F1c2UgdGhlcmUncyBubyBnb29kIHdheSB0byBkbyBTRCBlbnRpcmVseSB3 aXRoaW4gdGhlIFRQDQpsYXllci48YnI+DQpJPGJyPg0KJmd0OyZndDsmZ3Q7IHN1c3BlY3QgdGhh dCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbiB0aGUgVFAgbGF5ZXINCnRoYXQ8 YnI+DQptYWRlPGJyPg0KJmd0OyZndDsmZ3Q7IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3VsZG4ndCBo YXZlIHRoZSBhcHByb2FjaCBwcm9wc2VkIGluPGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LXJraGQt bXBscy10cC1zZC4gJm5ic3A7QW5kIEkgdGhpbmsgdGhhdCBpZiB0aGUgbW90aXZhdGlvbg0KZm9y IHRoaXM8YnI+DQomZ3Q7Jmd0OyZndDsgZHJhZnQgaXM6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7IC0gd2UgbXVzdCBoYXZlIFNEIGluIFRQIGJlY2F1c2UgaXQgaXMgcG9zc2li bGUgdG8gZG8gaW4gb3RoZXI8YnI+DQomZ3Q7Jmd0OyZndDsgdGVjaG5vbG9naWVzPGJyPg0KJmd0 OyZndDsmZ3Q7IC0gaXQgaXMgbm90IHBvc3NpYmxlIHRvIFNEIGVudGlyZWx5IHdpdGhpbiBUUDxi cj4NCiZndDsmZ3Q7Jmd0OyAtIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBTRCBmcm9tIHNvbWV3aGVy ZSBlbHNlPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGlzIGEgcmVhc29uYWJs ZSBvbmUuICZuYnNwO0lmIHdlIGRvIHRoYXQsIHdoZXJlIGRvIHdlIHN0b3A/DQombmJzcDtTaG91 bGQgd2U8YnI+DQomZ3Q7Jmd0OyZndDsgcHJvcGFnYXRlIGluZm9ybWF0aW9uIGFib3V0IHNpZ25h bCBxdWFsaXR5IHVwIHRvIFRDUCBzbyBpdA0KY2FuPGJyPg0KYWRqdXN0PGJyPg0KJmd0OyZndDsm Z3Q7IGl0cyB3aW5kb3dzIGFjY29yZGluZz8gJm5ic3A7KHBsZWFzZSBub3RlIHRoYXQgdGhpcyBp cyBpbnRlbmRlZA0KdG8gYmUgYTxicj4NCiZndDsmZ3Q7Jmd0OyByZWR1Y3RpbyBhZCBhYnN1cmR1 bSBxdWVzdGlvbiBhbmQgbm90IGEgc2VyaW91cyBvbmUuIDopICk8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgZXJp Yzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCk9uPGJyPg0KQmVoYWxmPGJyPg0K Jmd0OyZndDsmZ3Q7IE9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBHcmVnIE1pcnNreTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDI6MDggUE08YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBEYW5pZWwgQ29objsgcmFmaXJAb3Jja2l0LmNvbTsgbXMt ZGFpa29rdUBrZGRpLmNvbTs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG1hLnl1eGlhQHp0ZS5jb20u Y247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxlc3NhbmRybzxicj4NCkFsZXNzYW5kcm88 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IFN1YmplY3Q6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAt c2QtMDM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBEZWFyIEF1 dGhvcnMgYW5kIEFsbCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhhdCBpdCBpcyBm dW5jdGlvbiBvZiB0aGUgUEhZIGxheWVyIHRvIGRldGVjdA0KU0QgY29uZGl0aW9uPGJyPg0KJmd0 OyZndDsmZ3Q7IGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgY29udmVydCBpdCBpbnRvIERvd24g Zm9yIHRoZSBNUExTLVRQIExheWVyIDAgKHdoYXQgd2UNCnJlZmVyIGFzPGJyPg0KJmd0OyZndDsm Z3Q7IFBoeXNpY2FsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTZWN0aW9uKS4gSW4gY2FzZSBvZiBh Y2N1bXVsYXRpbmcgU0Qgb3ZlciBMU1AgdGhlIGUyZQ0KUGFja2V0IExvc3M8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IG1lYXN1cmVtZW50LCBpbiBteSB2aWV3LCBpcyBhZGRyZXNzaW5nIHRoZSBpc3N1 ZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgR3JlZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGll dGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt cGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48 L2Rpdj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJz cDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhp cyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwu Jm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxp Z2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2Fy ZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUm bmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0 byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2Zp bGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25m aWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNw O3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5i c3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJl c3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMm bmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJz cDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNw O0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVz c2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFs Jm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7 c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7Ynkm bmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000F9C2F482578DC_=-- From huubatwork@gmail.com Thu Jul 28 20:55:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1B11E8075 for ; Thu, 28 Jul 2011 20:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[AWL=-2.747, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FdUA6ZFOzb2 for ; Thu, 28 Jul 2011 20:55:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7932321F85AA for ; Thu, 28 Jul 2011 20:55:53 -0700 (PDT) Received: by iye7 with SMTP id 7so4309079iye.31 for ; Thu, 28 Jul 2011 20:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=to8OFc1N0tmVjEF0jG22L0B3Ta6lNtVYl2J3DD9zEBM=; b=xuMY0mLJ140DcNkZdULOq6aPsDWAcV6widzhvRvsyASqb+jCC/9R8vS6kAHG5o3KDY t2ZeYuauFAvYasHMpo0gr1hEScY/NYYCJ+Gm11WndP4bKl26RJfXBED4/aqqKesmfEB7 5ESRAhjoEiI1xEDbxHabGvFjX1q8sPkADFgQg= Received: by 10.42.151.67 with SMTP id d3mr567324icw.390.1311911752952; Thu, 28 Jul 2011 20:55:52 -0700 (PDT) Received: from McAsterix.local ([207.96.251.20]) by mx.google.com with ESMTPS id hq1sm2180383icc.14.2011.07.28.20.55.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 20:55:52 -0700 (PDT) Message-ID: <4E322F44.60301@gmail.com> Date: Fri, 29 Jul 2011 05:55:48 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 03:55:56 -0000 Dear Yuxia, You wrote: > I want to clarify several things: OK. > 1) Why some vendors do the research and development on SD of MPLS-TP? > Requirements from service providers. SD should be reported and trigger > to protection. There is no issue with that requirement. > 2) Why propagate server layer infor to TP? IMO, Signal degrade only > refers to the bit error happening on the physical layer. Packet loss > induced by congestion or CPU overload is not the factor to SD. In order > to avoid these impacts, we use the information detected by physical layer. I respect your opinion. However, the Signal/Service degrade detection shall be based on the characteristic information of the layer that requires SD detection. According to G.8110.1 clause 6.1.2 : "The MPLS TP layer network characteristic information is a flow of MT_CI Data (MT_CI_D) traffic units". The (SD) defect detection should never rely on defect detection mechanisms in lower layers with possibly oher technologies. In transport networks congestion should not occur under normal operating conditions and neither should CPU overload. > 3) Why only propagate to TP? We think it is not only TP, but also PW. > In fact, propagate to transport path. It is described in the draft. Propagation to higher layers is useless, it only adds complexity. > 4) Why not propagate to the higher layer above thansport path? Now, > we are discussing the requirement and solution referring to transport > path. Whether propagate to higher layer is not the topic we care about. This contradicts what you write in your item 3). Best regards, Huub. > *Greg Mirsky * > > 2011-07-29 01:00 > > > ռ > Daniel Cohn > > "Eric Osborne (eosborne)" , Rafi Ram > , ms-daikoku@kddi.com, ma.yuxia@zte.com.cn, > yang.jian90@zte.com.cn, "D'Alessandro Alessandro Gerardo" > , mpls@ietf.org > > Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > > > > Hi Daniel, > I think that while we're building MPLS-TP to be suited for the > transport we need to remember that it, as Neil pointed out on number > of occasions, is not BOS layer and doesn't put bits on a wire. Thus it > has characteristic that makes it different from other layers of a > transport network and, I think, as result not all existing concepts of > transport are applicable to packet layer realized by MPLS-TP. > > Regards, > Greg > > On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: > > Hi Eric, > > > > One of the reasons why we need SD in TP is because TP is supposed to > > provide the same "look and feel" of existing transport networks, as > > specified in the TP requirements document. > > Transport networks technologies have long supported the distinction > > between "degraded" and " faulty". In particular, protection technologies > > in use have this distinction built into the innermost recedes of their > > protocols. > > Even in the TP requirements didn't spell this out, I think it would be a > > mistake not to take advantage of years of experience in transport > > networks OAM. > > > > Regards, > > > > Daniel > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, July 28, 2011 11:12 AM > > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > > Gerardo; mpls@ietf.org > > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Greg- > > There is a difference between SF and SD. Converting SD into Down > > means that it will be interpreted exactly the same as SF, and if that's > > the case why have SD at all? If SD is necessary it must be somehow > > different from SD. > > > > All- > > > > Having said that, I'm not sure I disagree with Greg. It seems that > > this idea of propagating server layer SD up into TP is being done > > because there's no good way to do SD entirely within the TP layer. I > > suspect that if there were a way to do SD within the TP layer that made > > everyone happy, we wouldn't have the approach propsed in > > draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > > draft is: > > > > - we must have SD in TP because it is possible to do in other > > technologies > > - it is not possible to SD entirely within TP > > - therefore we must get SD from somewhere else > > > > is a reasonable one. If we do that, where do we stop? Should we > > propagate information about signal quality up to TCP so it can adjust > > its windows according? (please note that this is intended to be a > > reductio ad absurdum question and not a serious one. :) ) > > > > > > > > eric > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > >> Greg Mirsky > >> Sent: Wednesday, July 27, 2011 2:08 PM > >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > >> Gerardo; mpls@ietf.org > >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Dear Authors and All, > >> I think that it is function of the PHY layer to detect SD condition > > and > >> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > Physical > >> Section). In case of accumulating SD over LSP the e2e Packet Loss > >> measurement, in my view, is addressing the issue. > >> > >> Regards, > >> Greg From huubatwork@gmail.com Thu Jul 28 21:01:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99AE11E8075 for ; Thu, 28 Jul 2011 21:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knzpWU5KXlwT for ; Thu, 28 Jul 2011 21:01:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB11F0C3C for ; Thu, 28 Jul 2011 21:01:51 -0700 (PDT) Received: by iye7 with SMTP id 7so4314824iye.31 for ; Thu, 28 Jul 2011 21:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=h0phYZVsnN9i6uOlkVfgoeotxBU7RrEIqVTt9GILWOI=; b=LAlul+LBIxzOqBxM9eU7TtUjN5M339jh4Mly4TEB2jzTHmLJg4iiNEiLXYQac8xaXZ o3Sjjk2O5AGQQpyQizjDxSUjxQoaPOJcRYjymrfUPlLSbgwMGK0kOxJHQi9Xjv+6GpnD E/U3AauhJrLW1lWv+yt+w2Jgp9OEliWjM4jFU= Received: by 10.42.151.198 with SMTP id f6mr603603icw.410.1311912111349; Thu, 28 Jul 2011 21:01:51 -0700 (PDT) Received: from McAsterix.local ([207.96.251.20]) by mx.google.com with ESMTPS id q13sm1083795ibi.26.2011.07.28.21.01.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 21:01:50 -0700 (PDT) Message-ID: <4E3230AC.8030306@gmail.com> Date: Fri, 29 Jul 2011 06:01:48 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "mpls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 04:01:52 -0000 Hello SuHui, Please read my reply to Yuxia. Regards, Huub. > Agree with Daniel and Pablo. > Several carriers have the requirement of SD protection, and this > requirement is already included in the draft of survivability framework > and linear protection. So we should focus on how to achieve the > requirement. > I think the mechanism describe in draft-rkhd-mpls-tp-sd is a good way to > achieve the requirement. > > SuHui > > > > > *"Daniel Cohn" * > : mpls-bounces@ietf.org > > 2011-07-29 04:16 > > > ռ > , > > > > Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > > > > I don't think sending iterative e-mails referring to ever higher layer > serves the point of this discussion. A similar argument can be made on > e.g. other technologies sending AIS-like indications on all client > layers. > I think we should focus on what Pablo wrote, i.e. do we want to provide > SD to MPLS layers, like existing transport networks, or not? And if we > do, what is the best way to do it? > > DC > > PS: No need to, the VC12 has its own SD detection capabilities. > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Thursday, July 28, 2011 4:12 PM > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > And propagate to the VC12 carried By the PW? > and... > > Huub > > > > > Also, if we were to propagate to Tp, why stop there? It should be > propagated to PW as well, right? > > > > Sam > > > > Sent from my iPhone > > > > On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" wrote: > > > >> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) > made this exact point at the mike > >> during presentation. > >> > >> /himanshu > >> > >> > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Shahram Davari > >> Sent: Thursday, July 28, 2011 2:30 PM > >> To: Daniel Cohn; Greg Mirsky > >> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > yang.jian90@zte.com.cn > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi, > >> > >> I also don't believe SD is needed for MPLS-TP. Such defect is not > related to MPLS-TP and should be handled in the server layer, such as > changing the FEC type in OTN, etc. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Daniel Cohn > >> Sent: Thursday, July 28, 2011 10:15 AM > >> To: Greg Mirsky > >> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; Rafi > Ram > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> True enough in general. But in this particular example, there is > nothing suggested by this draft that requires huge implementation > efforts or paradigm changes. So I fail to see why we should settle for > less functionality than is available in existing transport networks. > >> > >> DC > >> > >> -----Original Message----- > >> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >> Sent: Thursday, July 28, 2011 1:00 PM > >> To: Daniel Cohn > >> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > Gerardo; mpls@ietf.org > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> Hi Daniel, > >> I think that while we're building MPLS-TP to be suited for the > >> transport we need to remember that it, as Neil pointed out on number > >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus > it > >> has characteristic that makes it different from other layers of a > >> transport network and, I think, as result not all existing concepts > of > >> transport are applicable to packet layer realized by MPLS-TP. > >> > >> Regards, > >> Greg > >> > >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > wrote: > >>> Hi Eric, > >>> > >>> One of the reasons why we need SD in TP is because TP is supposed to > >>> provide the same "look and feel" of existing transport networks, as > >>> specified in the TP requirements document. > >>> Transport networks technologies have long supported the distinction > >>> between "degraded" and " faulty". In particular, protection > technologies > >>> in use have this distinction built into the innermost recedes of > their > >>> protocols. > >>> Even in the TP requirements didn't spell this out, I think it would > be a > >>> mistake not to take advantage of years of experience in transport > >>> networks OAM. > >>> > >>> Regards, > >>> > >>> Daniel > >>> > >>> -----Original Message----- > >>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > >>> Sent: Thursday, July 28, 2011 11:12 AM > >>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > >>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > >>> Gerardo; mpls@ietf.org > >>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>> > >>> Hi Greg- > >>> There is a difference between SF and SD. Converting SD into Down > >>> means that it will be interpreted exactly the same as SF, and if > that's > >>> the case why have SD at all? If SD is necessary it must be somehow > >>> different from SD. > >>> > >>> All- > >>> > >>> Having said that, I'm not sure I disagree with Greg. It seems that > >>> this idea of propagating server layer SD up into TP is being done > >>> because there's no good way to do SD entirely within the TP layer. > I > >>> suspect that if there were a way to do SD within the TP layer that > made > >>> everyone happy, we wouldn't have the approach propsed in > >>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for this > >>> draft is: > >>> > >>> - we must have SD in TP because it is possible to do in other > >>> technologies > >>> - it is not possible to SD entirely within TP > >>> - therefore we must get SD from somewhere else > >>> > >>> is a reasonable one. If we do that, where do we stop? Should we > >>> propagate information about signal quality up to TCP so it can > adjust > >>> its windows according? (please note that this is intended to be a > >>> reductio ad absurdum question and not a serious one. :) ) > >>> > >>> > >>> > >>> eric > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >>> Of > >>>> Greg Mirsky > >>>> Sent: Wednesday, July 27, 2011 2:08 PM > >>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > >>>> Gerardo; mpls@ietf.org > >>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Dear Authors and All, > >>>> I think that it is function of the PHY layer to detect SD condition > >>> and > >>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > >>> Physical > >>>> Section). In case of accumulating SD over LSP the e2e Packet Loss > >>>> measurement, in my view, is addressing the issue. > >>>> > >>>> Regards, > >>>> Greg From maarten.vissers@huawei.com Thu Jul 28 23:27:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91A21F863C for ; Thu, 28 Jul 2011 23:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oySenmNc33zl for ; Thu, 28 Jul 2011 23:27:19 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2840621F863A for ; Thu, 28 Jul 2011 23:27:19 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP300HT80LH2R@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 29 Jul 2011 07:27:17 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LP300AS10LHO2@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 29 Jul 2011 07:27:17 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 07:27:06 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 07:27:16 +0100 Date: Fri, 29 Jul 2011 06:27:16 +0000 From: Maarten vissers In-reply-to: <4E31CB1E.7080004@gmail.com> X-Originating-IP: [10.202.112.227] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-index: AQHMTIh/NwvKYIFUjUmDOYVxYYyuaZUBx6yAgAAbw4CAAAJfAIAABCmAgAAU8wCAAAMigIAABokAgAAS34CAAAFEgIAABDUAgAABZICAAANEAIAAqR7w X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> <4E31C736.5040306@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> <4E31CB1E.7080004@gmail.com> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 06:27:21 -0000 The detection of a Degraded defect and associated raising of a Degraded failure condition is required to send a warning to the maintenance people that the connection is suffering from a persistent CIR packet loss which is exceeding the packet loss value in the SLA (case of transport service layer connection) or the value set for infrastructure connections (transport path or section layer connections). The detection of a Degraded defect condition and associated raising of the Signal Degrade (SD) consequent action is required to prevent that a protected connection (Section, LSP, PW, PSME) enters UnAvailable Time (UAT). The SD should cause that the signal is switched to protection so that UAT will not be entered (default Degraded defect detection time is 7 seconds (see G.7710)). Degraded defect threshold is based on packet loss value in SLA. It is a primary requirement in transport networks to prevent that a transport service layer connection (PW, service-LSP) enters UAT. A customer will be upset when his/her protected service enters UAT on CIR packet loss in the working connection and does not switch to protection to restore it. A customer does not care what is causing the unacceptable packet loss (bit errors on fiber, bit errors in equipment, congestion, packet buffer errors, switch fabric faults, other). Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: 28 July 2011 22:49 > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > Hi Daniel, > > You replied: > > > Can propose a TP-based detection method that can detect only physical > > errors, i.e. without being influenced by non-physical conditions such > as > > congestion, CPU overload, etc.? > > So as a customer I should only complain about degraded service > if it is caused by physical errors... > I have never seen SLAs with this restriction. > > We should use the characteristics of the technology to detect > any issues with the transport of the characteristic information. > > Regards, Huub. > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Huub van Helvoort > > Sent: Thursday, July 28, 2011 4:32 PM > > To: mpls@ietf.org > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Daniel Cohn > > > > You wrote: > > > >> I don't think sending iterative e-mails referring to ever higher > layer > >> serves the point of this discussion. > > > > OK, ---8<---snipped > > > >> PS: No need to, the VC12 has its own SD detection capabilities. > > > > So why don't we define SD (service degrade) defect detection criteria > > for MPLS-TP? > > In stead of relying on SD (signal degrade) defect detect mechanisms > in > > other technologies. > > > > BR, Huub. > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > >> Huub van Helvoort > >> Sent: Thursday, July 28, 2011 4:12 PM > >> To: mpls@ietf.org > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >> > >> And propagate to the VC12 carried By the PW? > >> and... > >> > >> Huub > >> > >> > >> > >>> Also, if we were to propagate to Tp, why stop there? It should be > >> propagated to PW as well, right? > >>> > >>> Sam > >>> > >>> Sent from my iPhone > >>> > >>> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" > > wrote: > >>> > >>>> I agree with Eric, Shahram and actually richard kam > (alcatel/lucent) > >> made this exact point at the mike > >>>> during presentation. > >>>> > >>>> /himanshu > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >> Of Shahram Davari > >>>> Sent: Thursday, July 28, 2011 2:30 PM > >>>> To: Daniel Cohn; Greg Mirsky > >>>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > >> yang.jian90@zte.com.cn > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Hi, > >>>> > >>>> I also don't believe SD is needed for MPLS-TP. Such defect is not > >> related to MPLS-TP and should be handled in the server layer, such > as > >> changing the FEC type in OTN, etc. > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >> Of Daniel Cohn > >>>> Sent: Thursday, July 28, 2011 10:15 AM > >>>> To: Greg Mirsky > >>>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; > Rafi > >> Ram > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> True enough in general. But in this particular example, there is > >> nothing suggested by this draft that requires huge implementation > >> efforts or paradigm changes. So I fail to see why we should settle > for > >> less functionality than is available in existing transport networks. > >>>> > >>>> DC > >>>> > >>>> -----Original Message----- > >>>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > >>>> Sent: Thursday, July 28, 2011 1:00 PM > >>>> To: Daniel Cohn > >>>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro > >> Gerardo; mpls@ietf.org > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>> > >>>> Hi Daniel, > >>>> I think that while we're building MPLS-TP to be suited for the > >>>> transport we need to remember that it, as Neil pointed out on > number > >>>> of occasions, is not BOS layer and doesn't put bits on a wire. > Thus > >> it > >>>> has characteristic that makes it different from other layers of a > >>>> transport network and, I think, as result not all existing > concepts > >> of > >>>> transport are applicable to packet layer realized by MPLS-TP. > >>>> > >>>> Regards, > >>>> Greg > >>>> > >>>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > >> wrote: > >>>>> Hi Eric, > >>>>> > >>>>> One of the reasons why we need SD in TP is because TP is supposed > > to > >>>>> provide the same "look and feel" of existing transport networks, > as > >>>>> specified in the TP requirements document. > >>>>> Transport networks technologies have long supported the > distinction > >>>>> between "degraded" and " faulty". In particular, protection > >> technologies > >>>>> in use have this distinction built into the innermost recedes of > >> their > >>>>> protocols. > >>>>> Even in the TP requirements didn't spell this out, I think it > would > >> be a > >>>>> mistake not to take advantage of years of experience in transport > >>>>> networks OAM. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Daniel > >>>>> > >>>>> -----Original Message----- > >>>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > >>>>> Sent: Thursday, July 28, 2011 11:12 AM > >>>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > Alessandro > >>>>> Gerardo; mpls@ietf.org > >>>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>>> > >>>>> Hi Greg- > >>>>> There is a difference between SF and SD. Converting SD into Down > >>>>> means that it will be interpreted exactly the same as SF, and if > >> that's > >>>>> the case why have SD at all? If SD is necessary it must be > somehow > >>>>> different from SD. > >>>>> > >>>>> All- > >>>>> > >>>>> Having said that, I'm not sure I disagree with Greg. It seems > that > >>>>> this idea of propagating server layer SD up into TP is being done > >>>>> because there's no good way to do SD entirely within the TP > layer. > >> I > >>>>> suspect that if there were a way to do SD within the TP layer > that > >> made > >>>>> everyone happy, we wouldn't have the approach propsed in > >>>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for > this > >>>>> draft is: > >>>>> > >>>>> - we must have SD in TP because it is possible to do in other > >>>>> technologies > >>>>> - it is not possible to SD entirely within TP > >>>>> - therefore we must get SD from somewhere else > >>>>> > >>>>> is a reasonable one. If we do that, where do we stop? Should we > >>>>> propagate information about signal quality up to TCP so it can > >> adjust > >>>>> its windows according? (please note that this is intended to be > a > >>>>> reductio ad absurdum question and not a serious one. :) ) > >>>>> > >>>>> > >>>>> > >>>>> eric > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf > >>>>> Of > >>>>>> Greg Mirsky > >>>>>> Sent: Wednesday, July 27, 2011 2:08 PM > >>>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > >>>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > >> Alessandro > >>>>>> Gerardo; mpls@ietf.org > >>>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > >>>>>> > >>>>>> Dear Authors and All, > >>>>>> I think that it is function of the PHY layer to detect SD > > condition > >>>>> and > >>>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > >>>>> Physical > >>>>>> Section). In case of accumulating SD over LSP the e2e Packet > Loss > >>>>>> measurement, in my view, is addressing the issue. > >>>>>> > >>>>>> Regards, > >>>>>> Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From ms-daikoku@auone.jp Thu Jul 28 21:08:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9544B21F8658 for ; Thu, 28 Jul 2011 21:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPZoUhko3k-O for ; Thu, 28 Jul 2011 21:08:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8540F21F8640 for ; Thu, 28 Jul 2011 21:08:22 -0700 (PDT) Received: by qyk9 with SMTP id 9so3514564qyk.10 for ; Thu, 28 Jul 2011 21:08:22 -0700 (PDT) Received: by 10.224.201.134 with SMTP id fa6mr679156qab.141.1311912501610; Thu, 28 Jul 2011 21:08:21 -0700 (PDT) Received: from [192.168.200.104] (modemcable114.145-70-69.static.videotron.ca [69.70.145.114]) by mx.google.com with ESMTPS id s14sm1159705qct.42.2011.07.28.21.08.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 21:08:20 -0700 (PDT) Sender: Masahiro DAIKOKU Message-ID: <4E323240.30607@kddi.com> Date: Fri, 29 Jul 2011 13:08:32 +0900 From: Masahiro DAIKOKU User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ma.yuxia@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org, yang.jian90@zte.com.cn, Rafi Ram Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ms-daikoku@kddi.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 06:33:41 -0000 Hi all, In case that bit error rate gets incrementally worse, linear protection is expected to keep prioritized customers traffic before occurring frame loss on server layer. So, signals degrade becomes one of the good candidate for monitoring transport path state and fault indication trigger from lower layer. Of course, in case of frame congestion, CPU overloading and the other physical failure mode (e.g. loss of light, fiber cut, etc.), frame loss is use for fault indication trigger from lower layer. Although OTN has Forward Error Correction feature to monitor transport path state, MPLS-TP frame is not always encapsulated by OTN, especially access line portion. Masa > Agree with Daniel and Pablo. > Several carriers have the requirement of SD protection, and this > requirement is already included in the draft of survivability framework > and linear protection. So we should focus on how to achieve the > requirement. > I think the mechanism describe in draft-rkhd-mpls-tp-sd is a good way to > achieve the requirement. > > SuHui > > >> >> Hi Greg and all, >> >> I want to clarify several things: >> >> 1) Why some vendors do the research and development on SD of MPLS-TP? >> Requirements from service providers. SD should be reported and >> trigger to protection. >> >> 2) Why propagate server layer infor to TP? IMO, Signal degrade >> only refers to the bit error happening on the physical layer. Packet >> loss induced by congestion or CPU overload is not the factor to SD. >> In order to avoid these impacts, we use the information detected by >> physical layer. >> >> 3) Why only propagate to TP? We think it is not only TP, but also >> PW. In fact, propagate to transport path. It is described in the draft. >> >> 4) Why not propagate to the higher layer above thansport path? >> Now, we are discussing the requirement and solution referring to >> transport path. Whether propagate to higher layer is not the topic we >> care about. >> >> >> Regards, >> Yuxia >> >> >> >> >> *Greg Mirsky * >> >> 2011-07-29 01:00 >> >> >> ռ >> Daniel Cohn >> >> "Eric Osborne (eosborne)" , Rafi Ram >> , ms-daikoku@kddi.com, ma.yuxia@zte.com.cn, >> yang.jian90@zte.com.cn, "D'Alessandro Alessandro Gerardo" >> , mpls@ietf.org >> >> Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> >> >> >> >> >> >> >> >> Hi Daniel, >> I think that while we're building MPLS-TP to be suited for the >> transport we need to remember that it, as Neil pointed out on number >> of occasions, is not BOS layer and doesn't put bits on a wire. Thus it >> has characteristic that makes it different from other layers of a >> transport network and, I think, as result not all existing concepts of >> transport are applicable to packet layer realized by MPLS-TP. >> >> Regards, >> Greg >> >> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn wrote: >> > Hi Eric, >> > >> > One of the reasons why we need SD in TP is because TP is supposed to >> > provide the same "look and feel" of existing transport networks, as >> > specified in the TP requirements document. >> > Transport networks technologies have long supported the distinction >> > between "degraded" and " faulty". In particular, protection >> technologies >> > in use have this distinction built into the innermost recedes of their >> > protocols. >> > Even in the TP requirements didn't spell this out, I think it would >> be a >> > mistake not to take advantage of years of experience in transport >> > networks OAM. >> > >> > Regards, >> > >> > Daniel >> > >> > -----Original Message----- >> > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] >> > Sent: Thursday, July 28, 2011 11:12 AM >> > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; >> > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> > Gerardo; mpls@ietf.org >> > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> > >> > Hi Greg- >> > There is a difference between SF and SD. Converting SD into Down >> > means that it will be interpreted exactly the same as SF, and if that's >> > the case why have SD at all? If SD is necessary it must be somehow >> > different from SD. >> > >> > All- >> > >> > Having said that, I'm not sure I disagree with Greg. It seems that >> > this idea of propagating server layer SD up into TP is being done >> > because there's no good way to do SD entirely within the TP layer. I >> > suspect that if there were a way to do SD within the TP layer that made >> > everyone happy, we wouldn't have the approach propsed in >> > draft-rkhd-mpls-tp-sd. And I think that if the motivation for this >> > draft is: >> > >> > - we must have SD in TP because it is possible to do in other >> > technologies >> > - it is not possible to SD entirely within TP >> > - therefore we must get SD from somewhere else >> > >> > is a reasonable one. If we do that, where do we stop? Should we >> > propagate information about signal quality up to TCP so it can adjust >> > its windows according? (please note that this is intended to be a >> > reductio ad absurdum question and not a serious one. :) ) >> > >> > >> > >> > eric >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> > Of >> >> Greg Mirsky >> >> Sent: Wednesday, July 27, 2011 2:08 PM >> >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; >> >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro >> >> Gerardo; mpls@ietf.org >> >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 >> >> >> >> Dear Authors and All, >> >> I think that it is function of the PHY layer to detect SD condition >> > and >> >> convert it into Down for the MPLS-TP Layer 0 (what we refer as >> > Physical >> >> Section). In case of accumulating SD over LSP the e2e Packet Loss >> >> measurement, in my view, is addressing the issue. >> >> >> >> Regards, >> >> Greg >> > >> > >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam system. >> From su.hui@zte.com.cn Fri Jul 29 00:41:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E0721F8B15; Fri, 29 Jul 2011 00:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLYOSo19sPzO; Fri, 29 Jul 2011 00:41:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A9C1D21F8B12; Fri, 29 Jul 2011 00:41:54 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641784411434; Fri, 29 Jul 2011 15:35:52 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.2676494875; Fri, 29 Jul 2011 15:31:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6T7V1qi048749; Fri, 29 Jul 2011 15:31:01 +0800 (GMT-8) (envelope-from su.hui@zte.com.cn) In-Reply-To: <4E322F44.60301@gmail.com> To: huubatwork@gmail.com MIME-Version: 1.0 X-KeepSent: 078D3764:3205F04B-482578DC:00278609; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: su.hui@zte.com.cn Date: Fri, 29 Jul 2011 15:31:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-29 15:31:02, Serialize complete at 2011-07-29 15:31:02 Content-Type: multipart/alternative; boundary="=_alternative 00295017482578DC_=" X-MAIL: mse01.zte.com.cn p6T7V1qi048749 Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:41:57 -0000 This is a multipart message in MIME format. --=_alternative 00295017482578DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSHV1YiwNCg0KPlByb3BhZ2F0aW9uIHRvIGhpZ2hlciBsYXllcnMgaXMgdXNlbGVzcywgaXQg b25seSBhZGRzIGNvbXBsZXhpdHkuDQpJIGRpc2FncmVlIHdpdGggdGhhdC4gVGhlIGFkdmFudGFn ZXMgb2YgdGhpcyBtZWNoYW5pc20gYXJlIHN0YXRlZCBpbiANCmRyYWZ0LXJraGQtbXBscy10cC1z ZCBjaGFwdGVyIDQuMSwgaXQgaXMgbm90IHVzZWxlc3MuICBTaW5jZSBGREkgaGF2ZSBiZWVuIA0K ZGVmaW5lZCwgIEZFSSBvbmx5IGFkZCBhIHR5cGUgb2YgcGFja2V0LCBGRUkgcHJvcGFnYXRpb24g aXMganVzdCB0aGUgc2FtZSANCmFzIEZESSBQcm9wYWdhdGlvbiwgaXQgZG9lc26hr3QgYWRkIG11 Y2ggY29tcGxleGl0eQ0KDQpTdWh1aQ0KDQoNCg0KSHV1YiB2YW4gSGVsdm9vcnQgPGh1dWJhdHdv cmtAZ21haWwuY29tPiANCreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wNy0y OSAxMTo1NQ0Kx+u08Li0ILj4DQpodXViYXR3b3JrQGdtYWlsLmNvbQ0KDQoNCsrVvP7Iyw0KbXBs c0BpZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpSZTogW21wbHNdILTwuLQ6IFJlOiAgQ29tbWVudHMg dG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQoNCg0KDQoNCg0KDQpEZWFyIFl1eGlhLA0KDQpZ b3Ugd3JvdGU6DQoNCj4gSSB3YW50IHRvIGNsYXJpZnkgc2V2ZXJhbCB0aGluZ3M6DQoNCk9LLg0K DQo+IDEpIFdoeSBzb21lIHZlbmRvcnMgZG8gdGhlIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVudCBv biBTRCBvZiBNUExTLVRQPyChqg0KoaogDQo+IFJlcXVpcmVtZW50cyBmcm9tIHNlcnZpY2UgcHJv dmlkZXJzLiBTRCBzaG91bGQgYmUgcmVwb3J0ZWQgYW5kIHRyaWdnZXIgDQo+IHRvIHByb3RlY3Rp b24uDQoNClRoZXJlIGlzIG5vIGlzc3VlIHdpdGggdGhhdCByZXF1aXJlbWVudC4NCg0KPiAyKSBX aHkgcHJvcGFnYXRlIHNlcnZlciBsYXllciBpbmZvciB0byBUUD8goaqhqiBJTU8sIFNpZ25hbCBk ZWdyYWRlIG9ubHkgDQoNCj4gcmVmZXJzIHRvIHRoZSBiaXQgZXJyb3IgaGFwcGVuaW5nIG9uIHRo ZSBwaHlzaWNhbCBsYXllci4gUGFja2V0IGxvc3MgDQo+IGluZHVjZWQgYnkgY29uZ2VzdGlvbiBv ciBDUFUgb3ZlcmxvYWQgaXMgbm90IHRoZSBmYWN0b3IgdG8gU0QuIEluIG9yZGVyIA0KPiB0byBh dm9pZCB0aGVzZSBpbXBhY3RzLCB3ZSB1c2UgdGhlIGluZm9ybWF0aW9uIGRldGVjdGVkIGJ5IHBo eXNpY2FsIA0KbGF5ZXIuDQoNCkkgcmVzcGVjdCB5b3VyIG9waW5pb24uDQoNCkhvd2V2ZXIsIHRo ZSBTaWduYWwvU2VydmljZSBkZWdyYWRlIGRldGVjdGlvbiBzaGFsbCBiZSBiYXNlZCBvbiB0aGUN CmNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uIG9mIHRoZSBsYXllciB0aGF0IHJlcXVpcmVzIFNE IGRldGVjdGlvbi4NCg0KQWNjb3JkaW5nIHRvIEcuODExMC4xIGNsYXVzZSA2LjEuMiA6DQoiVGhl IE1QTFMgVFAgbGF5ZXIgbmV0d29yayBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiBpcyBhIGZs b3cgb2YNCiBNVF9DSSBEYXRhIChNVF9DSV9EKSB0cmFmZmljIHVuaXRzIi4NCg0KVGhlIChTRCkg ZGVmZWN0IGRldGVjdGlvbiBzaG91bGQgbmV2ZXIgcmVseSBvbiBkZWZlY3QgZGV0ZWN0aW9uIG1l Y2hhbmlzbXMNCmluIGxvd2VyIGxheWVycyB3aXRoIHBvc3NpYmx5IG9oZXIgdGVjaG5vbG9naWVz Lg0KDQpJbiB0cmFuc3BvcnQgbmV0d29ya3MgY29uZ2VzdGlvbiBzaG91bGQgbm90IG9jY3VyIHVu ZGVyIG5vcm1hbCBvcGVyYXRpbmcNCmNvbmRpdGlvbnMgYW5kIG5laXRoZXIgc2hvdWxkIENQVSBv dmVybG9hZC4NCg0KPiAzKSBXaHkgb25seSBwcm9wYWdhdGUgdG8gVFA/IKGqoaogV2UgdGhpbmsg aXQgaXMgbm90IG9ubHkgVFAsIGJ1dCBhbHNvIA0KUFcuIA0KPiBJbiBmYWN0LCBwcm9wYWdhdGUg dG8gdHJhbnNwb3J0IHBhdGguIEl0IGlzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuDQoNClByb3Bh Z2F0aW9uIHRvIGhpZ2hlciBsYXllcnMgaXMgdXNlbGVzcywgaXQgb25seSBhZGRzIGNvbXBsZXhp dHkuDQoNCg0KPiA0KSBXaHkgbm90IHByb3BhZ2F0ZSB0byB0aGUgaGlnaGVyIGxheWVyIGFib3Zl IHRoYW5zcG9ydCBwYXRoPyChqqGqIE5vdywgDQoNCj4gd2UgYXJlIGRpc2N1c3NpbmcgdGhlIHJl cXVpcmVtZW50IGFuZCBzb2x1dGlvbiByZWZlcnJpbmcgdG8gdHJhbnNwb3J0IA0KPiBwYXRoLiBX aGV0aGVyIHByb3BhZ2F0ZSB0byBoaWdoZXIgbGF5ZXIgaXMgbm90IHRoZSB0b3BpYyB3ZSBjYXJl IGFib3V0Lg0KDQpUaGlzIGNvbnRyYWRpY3RzIHdoYXQgeW91IHdyaXRlIGluIHlvdXIgaXRlbSAz KS4NCg0KQmVzdCByZWdhcmRzLCBIdXViLg0KDQoNCg0KPiAqR3JlZyBNaXJza3kgPGdyZWdpbWly c2t5QGdtYWlsLmNvbT4qDQo+IA0KPiAyMDExLTA3LTI5IDAxOjAwDQo+IA0KPiANCj4gytW8/sjL DQo+ICAgICAgICAgICAgICAgIERhbmllbCBDb2huIDxEYW5pZWxDQG9yY2tpdC5jb20+DQo+ILOt y80NCj4gICAgICAgICAgICAgICAgIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVA Y2lzY28uY29tPiwgUmFmaSBSYW0gDQo+IDxSYWZpUkBvcmNraXQuY29tPiwgbXMtZGFpa29rdUBr ZGRpLmNvbSwgbWEueXV4aWFAenRlLmNvbS5jbiwgDQo+IHlhbmcuamlhbjkwQHp0ZS5jb20uY24s ICJEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIiANCj4gPGFsZXNzYW5kcm8uZGFsZXNz YW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4sIG1wbHNAaWV0Zi5vcmcNCj4g1vfM4g0KPiAgICAgICAg ICAgICAgICBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMw0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhpIERhbmllbCwNCj4gSSB0aGluayB0 aGF0IHdoaWxlIHdlJ3JlIGJ1aWxkaW5nIE1QTFMtVFAgdG8gYmUgc3VpdGVkIGZvciB0aGUNCj4g dHJhbnNwb3J0IHdlIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2ludGVkIG91 dCBvbiBudW1iZXINCj4gb2Ygb2NjYXNpb25zLCBpcyBub3QgQk9TIGxheWVyIGFuZCBkb2Vzbid0 IHB1dCBiaXRzIG9uIGEgd2lyZS4gVGh1cyBpdA0KPiBoYXMgY2hhcmFjdGVyaXN0aWMgdGhhdCBt YWtlcyBpdCBkaWZmZXJlbnQgZnJvbSBvdGhlciBsYXllcnMgb2YgYQ0KPiB0cmFuc3BvcnQgbmV0 d29yayBhbmQsIEkgdGhpbmssIGFzIHJlc3VsdCBub3QgYWxsIGV4aXN0aW5nIGNvbmNlcHRzIG9m DQo+IHRyYW5zcG9ydCBhcmUgYXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVhbGl6ZWQgYnkg TVBMUy1UUC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEdyZWcNCj4gDQo+IE9uIFRodSwgSnVsIDI4LCAy MDExIGF0IDk6NTEgQU0sIERhbmllbCBDb2huIDxEYW5pZWxDQG9yY2tpdC5jb20+IHdyb3RlOg0K PiAgPiBIaSBFcmljLA0KPiAgPg0KPiAgPiBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQg U0QgaW4gVFAgaXMgYmVjYXVzZSBUUCBpcyBzdXBwb3NlZCB0bw0KPiAgPiBwcm92aWRlIHRoZSBz YW1lICJsb29rIGFuZCBmZWVsIiBvZiBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MsIGFzDQo+ ICA+IHNwZWNpZmllZCBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KPiAgPiBUcmFu c3BvcnQgbmV0d29ya3MgdGVjaG5vbG9naWVzIGhhdmUgbG9uZyBzdXBwb3J0ZWQgdGhlIGRpc3Rp bmN0aW9uDQo+ICA+IGJldHdlZW4gImRlZ3JhZGVkIiBhbmQgIiBmYXVsdHkiLiBJbiBwYXJ0aWN1 bGFyLCBwcm90ZWN0aW9uIA0KdGVjaG5vbG9naWVzDQo+ICA+IGluIHVzZSBoYXZlIHRoaXMgZGlz dGluY3Rpb24gYnVpbHQgaW50byB0aGUgaW5uZXJtb3N0IHJlY2VkZXMgb2YgDQp0aGVpcg0KPiAg PiBwcm90b2NvbHMuDQo+ICA+IEV2ZW4gaW4gdGhlIFRQIHJlcXVpcmVtZW50cyBkaWRuJ3Qgc3Bl bGwgdGhpcyBvdXQsIEkgdGhpbmsgaXQgd291bGQgDQpiZSBhDQo+ICA+IG1pc3Rha2Ugbm90IHRv IHRha2UgYWR2YW50YWdlIG9mIHllYXJzIG9mIGV4cGVyaWVuY2UgaW4gdHJhbnNwb3J0DQo+ICA+ IG5ldHdvcmtzIE9BTS4NCj4gID4NCj4gID4gUmVnYXJkcywNCj4gID4NCj4gID4gRGFuaWVsDQo+ ICA+DQo+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICA+IEZyb206IEVyaWMgT3Ni b3JuZSAoZW9zYm9ybmUpIFttYWlsdG86ZW9zYm9ybmVAY2lzY28uY29tXQ0KPiAgPiBTZW50OiBU aHVyc2RheSwgSnVseSAyOCwgMjAxMSAxMToxMiBBTQ0KPiAgPiBUbzogR3JlZyBNaXJza3k7IERh bmllbCBDb2huOyBSYWZpIFJhbTsgbXMtZGFpa29rdUBrZGRpLmNvbTsNCj4gID4gbWEueXV4aWFA enRlLmNvbS5jbjsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCdBbGVzc2FuZHJvIEFsZXNzYW5k cm8NCj4gID4gR2VyYXJkbzsgbXBsc0BpZXRmLm9yZw0KPiAgPiBTdWJqZWN0OiBSRTogW21wbHNd IENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMw0KPiAgPg0KPiAgPiBIaSBHcmVn LQ0KPiAgPiBUaGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBhbmQgU0QuIENvbnZlcnRp bmcgU0QgaW50byBEb3duDQo+ICA+IG1lYW5zIHRoYXQgaXQgd2lsbCBiZSBpbnRlcnByZXRlZCBl eGFjdGx5IHRoZSBzYW1lIGFzIFNGLCBhbmQgaWYgDQp0aGF0J3MNCj4gID4gdGhlIGNhc2Ugd2h5 IGhhdmUgU0QgYXQgYWxsPyBJZiBTRCBpcyBuZWNlc3NhcnkgaXQgbXVzdCBiZSBzb21laG93DQo+ ICA+IGRpZmZlcmVudCBmcm9tIFNELg0KPiAgPg0KPiAgPiBBbGwtDQo+ICA+DQo+ICA+IEhhdmlu ZyBzYWlkIHRoYXQsIEknbSBub3Qgc3VyZSBJIGRpc2FncmVlIHdpdGggR3JlZy4gSXQgc2VlbXMg dGhhdA0KPiAgPiB0aGlzIGlkZWEgb2YgcHJvcGFnYXRpbmcgc2VydmVyIGxheWVyIFNEIHVwIGlu dG8gVFAgaXMgYmVpbmcgZG9uZQ0KPiAgPiBiZWNhdXNlIHRoZXJlJ3Mgbm8gZ29vZCB3YXkgdG8g ZG8gU0QgZW50aXJlbHkgd2l0aGluIHRoZSBUUCBsYXllci4gSQ0KPiAgPiBzdXNwZWN0IHRoYXQg aWYgdGhlcmUgd2VyZSBhIHdheSB0byBkbyBTRCB3aXRoaW4gdGhlIFRQIGxheWVyIHRoYXQgDQpt YWRlDQo+ICA+IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3VsZG4ndCBoYXZlIHRoZSBhcHByb2FjaCBw cm9wc2VkIGluDQo+ICA+IGRyYWZ0LXJraGQtbXBscy10cC1zZC4gQW5kIEkgdGhpbmsgdGhhdCBp ZiB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcw0KPiAgPiBkcmFmdCBpczoNCj4gID4NCj4gID4gLSB3 ZSBtdXN0IGhhdmUgU0QgaW4gVFAgYmVjYXVzZSBpdCBpcyBwb3NzaWJsZSB0byBkbyBpbiBvdGhl cg0KPiAgPiB0ZWNobm9sb2dpZXMNCj4gID4gLSBpdCBpcyBub3QgcG9zc2libGUgdG8gU0QgZW50 aXJlbHkgd2l0aGluIFRQDQo+ICA+IC0gdGhlcmVmb3JlIHdlIG11c3QgZ2V0IFNEIGZyb20gc29t ZXdoZXJlIGVsc2UNCj4gID4NCj4gID4gaXMgYSByZWFzb25hYmxlIG9uZS4gSWYgd2UgZG8gdGhh dCwgd2hlcmUgZG8gd2Ugc3RvcD8gU2hvdWxkIHdlDQo+ICA+IHByb3BhZ2F0ZSBpbmZvcm1hdGlv biBhYm91dCBzaWduYWwgcXVhbGl0eSB1cCB0byBUQ1Agc28gaXQgY2FuIGFkanVzdA0KPiAgPiBp dHMgd2luZG93cyBhY2NvcmRpbmc/IChwbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQg dG8gYmUgYQ0KPiAgPiByZWR1Y3RpbyBhZCBhYnN1cmR1bSBxdWVzdGlvbiBhbmQgbm90IGEgc2Vy aW91cyBvbmUuIDopICkNCj4gID4NCj4gID4NCj4gID4NCj4gID4gZXJpYw0KPiAgPg0KPiAgPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ICA+IE9mDQo+ ICA+PiBHcmVnIE1pcnNreQ0KPiAgPj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDI6 MDggUE0NCj4gID4+IFRvOiBEYW5pZWwgQ29objsgcmFmaXJAb3Jja2l0LmNvbTsgbXMtZGFpa29r dUBrZGRpLmNvbTsNCj4gID4+IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5j b20uY247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+ICA+PiBHZXJhcmRvOyBtcGxzQGlldGYu b3JnDQo+ICA+PiBTdWJqZWN0OiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRw LXNkLTAzDQo+ICA+Pg0KPiAgPj4gRGVhciBBdXRob3JzIGFuZCBBbGwsDQo+ICA+PiBJIHRoaW5r IHRoYXQgaXQgaXMgZnVuY3Rpb24gb2YgdGhlIFBIWSBsYXllciB0byBkZXRlY3QgU0QgY29uZGl0 aW9uDQo+ICA+IGFuZA0KPiAgPj4gY29udmVydCBpdCBpbnRvIERvd24gZm9yIHRoZSBNUExTLVRQ IExheWVyIDAgKHdoYXQgd2UgcmVmZXIgYXMNCj4gID4gUGh5c2ljYWwNCj4gID4+IFNlY3Rpb24p LiBJbiBjYXNlIG9mIGFjY3VtdWxhdGluZyBTRCBvdmVyIExTUCB0aGUgZTJlIFBhY2tldCBMb3Nz DQo+ICA+PiBtZWFzdXJlbWVudCwgaW4gbXkgdmlldywgaXMgYWRkcmVzc2luZyB0aGUgaXNzdWUu DQo+ICA+Pg0KPiAgPj4gUmVnYXJkcywNCj4gID4+IEdyZWcNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3Rl bS4NCg== --=_alternative 00295017482578DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIEh1dWIsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZndDs8L2ZvbnQ+PHR0 Pjxmb250IHNpemU9Mj5Qcm9wYWdhdGlvbg0KdG8gaGlnaGVyIGxheWVycyBpcyB1c2VsZXNzLCBp dCBvbmx5IGFkZHMgY29tcGxleGl0eS48L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5JIGRpc2FncmVlIHdpdGggdGhhdC4gVGhlIGFkdmFudGFnZXMN Cm9mIHRoaXMgbWVjaGFuaXNtIGFyZSBzdGF0ZWQgaW4gZHJhZnQtcmtoZC1tcGxzLXRwLXNkIGNo YXB0ZXIgNC4xLCBpdCBpcw0Kbm90IHVzZWxlc3MuICZuYnNwO1NpbmNlIEZESSBoYXZlIGJlZW4g ZGVmaW5lZCwgJm5ic3A7RkVJIG9ubHkgYWRkIGEgdHlwZQ0Kb2YgcGFja2V0LCBGRUkgcHJvcGFn YXRpb24gaXMganVzdCB0aGUgc2FtZSBhcyBGREkgUHJvcGFnYXRpb24sIGl0IGRvZXNuoa90DQph ZGQgbXVjaCBjb21wbGV4aXR5PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj5TdWh1aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5IdXViIHZhbiBIZWx2b29ydCAmbHQ7aHV1YmF0d29ya0BnbWFpbC5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3LTI5IDExOjU1PC9mb250Pg0KPHRhYmxlIGJvcmRlcj4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0KaHV1YmF0d29ya0Bn bWFpbC5jb208L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxicj4NCjx0ZCB3aWR0aD02NCU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5tcGxzQGlldGYub3JnPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHNdILTw uLQ6IFJlOiAmbmJzcDtDb21tZW50cw0KdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzPC9mb250 PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFy IFl1eGlhLDxicj4NCjxicj4NCllvdSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEkgd2FudCB0byBj bGFyaWZ5IHNldmVyYWwgdGhpbmdzOjxicj4NCjxicj4NCk9LLjxicj4NCjxicj4NCiZndDsgMSkg V2h5IHNvbWUgdmVuZG9ycyBkbyB0aGUgcmVzZWFyY2ggYW5kIGRldmVsb3BtZW50IG9uIFNEIG9m IE1QTFMtVFA/DQqhqqGqIDxicj4NCiZndDsgUmVxdWlyZW1lbnRzIGZyb20gc2VydmljZSBwcm92 aWRlcnMuIFNEIHNob3VsZCBiZSByZXBvcnRlZCBhbmQgdHJpZ2dlcg0KPGJyPg0KJmd0OyB0byBw cm90ZWN0aW9uLjxicj4NCjxicj4NClRoZXJlIGlzIG5vIGlzc3VlIHdpdGggdGhhdCByZXF1aXJl bWVudC48YnI+DQo8YnI+DQomZ3Q7IDIpIFdoeSBwcm9wYWdhdGUgc2VydmVyIGxheWVyIGluZm9y IHRvIFRQPyChqqGqIElNTywgU2lnbmFsIGRlZ3JhZGUNCm9ubHkgPGJyPg0KJmd0OyByZWZlcnMg dG8gdGhlIGJpdCBlcnJvciBoYXBwZW5pbmcgb24gdGhlIHBoeXNpY2FsIGxheWVyLiBQYWNrZXQg bG9zcw0KPGJyPg0KJmd0OyBpbmR1Y2VkIGJ5IGNvbmdlc3Rpb24gb3IgQ1BVIG92ZXJsb2FkIGlz IG5vdCB0aGUgZmFjdG9yIHRvIFNELiBJbg0Kb3JkZXIgPGJyPg0KJmd0OyB0byBhdm9pZCB0aGVz ZSBpbXBhY3RzLCB3ZSB1c2UgdGhlIGluZm9ybWF0aW9uIGRldGVjdGVkIGJ5IHBoeXNpY2FsDQps YXllci48YnI+DQo8YnI+DQpJIHJlc3BlY3QgeW91ciBvcGluaW9uLjxicj4NCjxicj4NCkhvd2V2 ZXIsIHRoZSBTaWduYWwvU2VydmljZSBkZWdyYWRlIGRldGVjdGlvbiBzaGFsbCBiZSBiYXNlZCBv biB0aGU8YnI+DQpjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiBvZiB0aGUgbGF5ZXIgdGhhdCBy ZXF1aXJlcyBTRCBkZXRlY3Rpb24uPGJyPg0KPGJyPg0KQWNjb3JkaW5nIHRvIEcuODExMC4xIGNs YXVzZSA2LjEuMiA6PGJyPg0KJnF1b3Q7VGhlIE1QTFMgVFAgbGF5ZXIgbmV0d29yayBjaGFyYWN0 ZXJpc3RpYyBpbmZvcm1hdGlvbiBpcyBhIGZsb3cgb2Y8YnI+DQogTVRfQ0kgRGF0YSAoTVRfQ0lf RCkgdHJhZmZpYyB1bml0cyZxdW90Oy48YnI+DQo8YnI+DQpUaGUgKFNEKSBkZWZlY3QgZGV0ZWN0 aW9uIHNob3VsZCBuZXZlciByZWx5IG9uIGRlZmVjdCBkZXRlY3Rpb24gbWVjaGFuaXNtczxicj4N CmluIGxvd2VyIGxheWVycyB3aXRoIHBvc3NpYmx5IG9oZXIgdGVjaG5vbG9naWVzLjxicj4NCjxi cj4NCkluIHRyYW5zcG9ydCBuZXR3b3JrcyBjb25nZXN0aW9uIHNob3VsZCBub3Qgb2NjdXIgdW5k ZXIgbm9ybWFsIG9wZXJhdGluZzxicj4NCmNvbmRpdGlvbnMgYW5kIG5laXRoZXIgc2hvdWxkIENQ VSBvdmVybG9hZC48YnI+DQo8YnI+DQomZ3Q7IDMpIFdoeSBvbmx5IHByb3BhZ2F0ZSB0byBUUD8g oaqhqiBXZSB0aGluayBpdCBpcyBub3Qgb25seSBUUCwgYnV0DQphbHNvIFBXLiA8YnI+DQomZ3Q7 IEluIGZhY3QsIHByb3BhZ2F0ZSB0byB0cmFuc3BvcnQgcGF0aC4gSXQgaXMgZGVzY3JpYmVkIGlu IHRoZSBkcmFmdC48YnI+DQo8YnI+DQpQcm9wYWdhdGlvbiB0byBoaWdoZXIgbGF5ZXJzIGlzIHVz ZWxlc3MsIGl0IG9ubHkgYWRkcyBjb21wbGV4aXR5Ljxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA0KSBXaHkgbm90IHByb3BhZ2F0ZSB0byB0aGUgaGln aGVyIGxheWVyIGFib3ZlIHRoYW5zcG9ydCBwYXRoPyChqqGqDQpOb3csIDxicj4NCiZndDsgd2Ug YXJlIGRpc2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50IGFuZCBzb2x1dGlvbiByZWZlcnJpbmcgdG8g dHJhbnNwb3J0DQo8YnI+DQomZ3Q7IHBhdGguIFdoZXRoZXIgcHJvcGFnYXRlIHRvIGhpZ2hlciBs YXllciBpcyBub3QgdGhlIHRvcGljIHdlIGNhcmUgYWJvdXQuPGJyPg0KPGJyPg0KVGhpcyBjb250 cmFkaWN0cyB3aGF0IHlvdSB3cml0ZSBpbiB5b3VyIGl0ZW0gMykuPGJyPg0KPGJyPg0KQmVzdCBy ZWdhcmRzLCBIdXViLjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgKkdyZWcgTWlyc2t5ICZs dDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7Kjxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDExLTA3 LTI5IDAxOjAwPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyDK1bz+yMs8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RGFuaWVsDQpDb2huICZsdDtEYW5pZWxDQG9yY2tpdC5jb20mZ3Q7PGJyPg0K Jmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0VyaWMNCk9zYm9ybmUgKGVvc2Jvcm5lKSZx dW90OyAmbHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0OywgUmFmaSBSYW0gPGJyPg0KJmd0OyAmbHQ7 UmFmaVJAb3Jja2l0LmNvbSZndDssIG1zLWRhaWtva3VAa2RkaS5jb20sIG1hLnl1eGlhQHp0ZS5j b20uY24sDQo8YnI+DQomZ3Q7IHlhbmcuamlhbjkwQHp0ZS5jb20uY24sICZxdW90O0QnQWxlc3Nh bmRybyBBbGVzc2FuZHJvIEdlcmFyZG8mcXVvdDsNCjxicj4NCiZndDsgJmx0O2FsZXNzYW5kcm8u ZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCZndDssIG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7 INb3zOI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmU6DQpbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1t cGxzLXRwLXNkLTAzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBIaSBEYW5pZWwsPGJyPg0KJmd0OyBJIHRoaW5rIHRoYXQgd2hpbGUgd2UncmUgYnVpbGRpbmcg TVBMUy1UUCB0byBiZSBzdWl0ZWQgZm9yIHRoZTxicj4NCiZndDsgdHJhbnNwb3J0IHdlIG5lZWQg dG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2ludGVkIG91dCBvbiBudW1iZXI8YnI+DQom Z3Q7IG9mIG9jY2FzaW9ucywgaXMgbm90IEJPUyBsYXllciBhbmQgZG9lc24ndCBwdXQgYml0cyBv biBhIHdpcmUuIFRodXMNCml0PGJyPg0KJmd0OyBoYXMgY2hhcmFjdGVyaXN0aWMgdGhhdCBtYWtl cyBpdCBkaWZmZXJlbnQgZnJvbSBvdGhlciBsYXllcnMgb2YgYTxicj4NCiZndDsgdHJhbnNwb3J0 IG5ldHdvcmsgYW5kLCBJIHRoaW5rLCBhcyByZXN1bHQgbm90IGFsbCBleGlzdGluZyBjb25jZXB0 cw0Kb2Y8YnI+DQomZ3Q7IHRyYW5zcG9ydCBhcmUgYXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIg cmVhbGl6ZWQgYnkgTVBMUy1UUC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQom Z3Q7IEdyZWc8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVGh1LCBKdWwgMjgsIDIwMTEgYXQgOTo1 MSBBTSwgRGFuaWVsIENvaG4gJmx0O0RhbmllbENAb3Jja2l0LmNvbSZndDsNCndyb3RlOjxicj4N CiZndDsgJm5ic3A7Jmd0OyBIaSBFcmljLDxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsg Jm5ic3A7Jmd0OyBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgU0QgaW4gVFAgaXMgYmVj YXVzZSBUUCBpcw0Kc3VwcG9zZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyZndDsgcHJvdmlkZSB0aGUg c2FtZSAmcXVvdDtsb29rIGFuZCBmZWVsJnF1b3Q7IG9mIGV4aXN0aW5nDQp0cmFuc3BvcnQgbmV0 d29ya3MsIGFzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHNwZWNpZmllZCBpbiB0aGUgVFAgcmVxdWly ZW1lbnRzIGRvY3VtZW50Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyBUcmFuc3BvcnQgbmV0d29ya3Mg dGVjaG5vbG9naWVzIGhhdmUgbG9uZyBzdXBwb3J0ZWQgdGhlDQpkaXN0aW5jdGlvbjxicj4NCiZn dDsgJm5ic3A7Jmd0OyBiZXR3ZWVuICZxdW90O2RlZ3JhZGVkJnF1b3Q7IGFuZCAmcXVvdDsgZmF1 bHR5JnF1b3Q7LiBJbg0KcGFydGljdWxhciwgcHJvdGVjdGlvbiB0ZWNobm9sb2dpZXM8YnI+DQom Z3Q7ICZuYnNwOyZndDsgaW4gdXNlIGhhdmUgdGhpcyBkaXN0aW5jdGlvbiBidWlsdCBpbnRvIHRo ZSBpbm5lcm1vc3QgcmVjZWRlcw0Kb2YgdGhlaXI8YnI+DQomZ3Q7ICZuYnNwOyZndDsgcHJvdG9j b2xzLjxicj4NCiZndDsgJm5ic3A7Jmd0OyBFdmVuIGluIHRoZSBUUCByZXF1aXJlbWVudHMgZGlk bid0IHNwZWxsIHRoaXMgb3V0LCBJIHRoaW5rDQppdCB3b3VsZCBiZSBhPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IG1pc3Rha2Ugbm90IHRvIHRha2UgYWR2YW50YWdlIG9mIHllYXJzIG9mIGV4cGVyaWVu Y2UgaW4NCnRyYW5zcG9ydDxicj4NCiZndDsgJm5ic3A7Jmd0OyBuZXR3b3JrcyBPQU0uPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IERhbmllbDxicj4NCiZndDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJm5ic3A7Jmd0OyBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jv cm5lQGNpc2NvLmNvbV08YnI+DQomZ3Q7ICZuYnNwOyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkg MjgsIDIwMTEgMTE6MTIgQU08YnI+DQomZ3Q7ICZuYnNwOyZndDsgVG86IEdyZWcgTWlyc2t5OyBE YW5pZWwgQ29objsgUmFmaSBSYW07IG1zLWRhaWtva3VAa2RkaS5jb207PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxl c3NhbmRybw0KQWxlc3NhbmRybzxicj4NCiZndDsgJm5ic3A7Jmd0OyBHZXJhcmRvOyBtcGxzQGll dGYub3JnPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFN1YmplY3Q6IFJFOiBbbXBsc10gQ29tbWVudHMg dG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7IEhpIEdyZWctPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFRoZXJlIGlzIGEgZGlm ZmVyZW5jZSBiZXR3ZWVuIFNGIGFuZCBTRC4gQ29udmVydGluZyBTRA0KaW50byBEb3duPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7IG1lYW5zIHRoYXQgaXQgd2lsbCBiZSBpbnRlcnByZXRlZCBleGFjdGx5 IHRoZSBzYW1lIGFzIFNGLA0KYW5kIGlmIHRoYXQnczxicj4NCiZndDsgJm5ic3A7Jmd0OyB0aGUg Y2FzZSB3aHkgaGF2ZSBTRCBhdCBhbGw/IElmIFNEIGlzIG5lY2Vzc2FyeSBpdCBtdXN0DQpiZSBz b21laG93PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGRpZmZlcmVudCBmcm9tIFNELjxicj4NCiZndDsg Jm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBBbGwtPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIEknbSBub3Qgc3VyZSBJIGRp c2FncmVlIHdpdGggR3JlZy4gSXQNCnNlZW1zIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsgdGhp cyBpZGVhIG9mIHByb3BhZ2F0aW5nIHNlcnZlciBsYXllciBTRCB1cCBpbnRvIFRQIGlzDQpiZWlu ZyBkb25lPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGJlY2F1c2UgdGhlcmUncyBubyBnb29kIHdheSB0 byBkbyBTRCBlbnRpcmVseSB3aXRoaW4gdGhlDQpUUCBsYXllci4gSTxicj4NCiZndDsgJm5ic3A7 Jmd0OyBzdXNwZWN0IHRoYXQgaWYgdGhlcmUgd2VyZSBhIHdheSB0byBkbyBTRCB3aXRoaW4gdGhl IFRQDQpsYXllciB0aGF0IG1hZGU8YnI+DQomZ3Q7ICZuYnNwOyZndDsgZXZlcnlvbmUgaGFwcHks IHdlIHdvdWxkbid0IGhhdmUgdGhlIGFwcHJvYWNoIHByb3BzZWQgaW48YnI+DQomZ3Q7ICZuYnNw OyZndDsgZHJhZnQtcmtoZC1tcGxzLXRwLXNkLiBBbmQgSSB0aGluayB0aGF0IGlmIHRoZSBtb3Rp dmF0aW9uDQpmb3IgdGhpczxicj4NCiZndDsgJm5ic3A7Jmd0OyBkcmFmdCBpczo8YnI+DQomZ3Q7 ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgLSB3ZSBtdXN0IGhhdmUgU0QgaW4gVFAg YmVjYXVzZSBpdCBpcyBwb3NzaWJsZSB0byBkbyBpbg0Kb3RoZXI8YnI+DQomZ3Q7ICZuYnNwOyZn dDsgdGVjaG5vbG9naWVzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IC0gaXQgaXMgbm90IHBvc3NpYmxl IHRvIFNEIGVudGlyZWx5IHdpdGhpbiBUUDxicj4NCiZndDsgJm5ic3A7Jmd0OyAtIHRoZXJlZm9y ZSB3ZSBtdXN0IGdldCBTRCBmcm9tIHNvbWV3aGVyZSBlbHNlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGlzIGEgcmVhc29uYWJsZSBvbmUuIElmIHdlIGRvIHRoYXQs IHdoZXJlIGRvIHdlIHN0b3A/IFNob3VsZA0Kd2U8YnI+DQomZ3Q7ICZuYnNwOyZndDsgcHJvcGFn YXRlIGluZm9ybWF0aW9uIGFib3V0IHNpZ25hbCBxdWFsaXR5IHVwIHRvIFRDUCBzbw0KaXQgY2Fu IGFkanVzdDxicj4NCiZndDsgJm5ic3A7Jmd0OyBpdHMgd2luZG93cyBhY2NvcmRpbmc/IChwbGVh c2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQNCnRvIGJlIGE8YnI+DQomZ3Q7ICZuYnNwOyZn dDsgcmVkdWN0aW8gYWQgYWJzdXJkdW0gcXVlc3Rpb24gYW5kIG5vdCBhIHNlcmlvdXMgb25lLiA6 KQ0KKTxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsg Jm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBlcmljPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsgJm5ic3A7Jmd0OyZndDsgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KT24gQmVoYWxmPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IE9m PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBHcmVnIE1pcnNreTxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsgU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDI6MDggUE08YnI+DQomZ3Q7ICZu YnNwOyZndDsmZ3Q7IFRvOiBEYW5pZWwgQ29objsgcmFmaXJAb3Jja2l0LmNvbTsgbXMtZGFpa29r dUBrZGRpLmNvbTs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IG1hLnl1eGlhQHp0ZS5jb20uY247 IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxlc3NhbmRybw0KQWxlc3NhbmRybzxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsgR2VyYXJkbzsgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsgU3ViamVjdDogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1z ZC0wMzxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IERl YXIgQXV0aG9ycyBhbmQgQWxsLDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgSSB0aGluayB0aGF0 IGl0IGlzIGZ1bmN0aW9uIG9mIHRoZSBQSFkgbGF5ZXIgdG8gZGV0ZWN0DQpTRCBjb25kaXRpb248 YnI+DQomZ3Q7ICZuYnNwOyZndDsgYW5kPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBjb252ZXJ0 IGl0IGludG8gRG93biBmb3IgdGhlIE1QTFMtVFAgTGF5ZXIgMCAod2hhdA0Kd2UgcmVmZXIgYXM8 YnI+DQomZ3Q7ICZuYnNwOyZndDsgUGh5c2ljYWw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFNl Y3Rpb24pLiBJbiBjYXNlIG9mIGFjY3VtdWxhdGluZyBTRCBvdmVyIExTUCB0aGUgZTJlDQpQYWNr ZXQgTG9zczxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgbWVhc3VyZW1lbnQsIGluIG15IHZpZXcs IGlzIGFkZHJlc3NpbmcgdGhlIGlzc3VlLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBHcmVn PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6 Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3Ro aXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21h aWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVj aXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJz cDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25v dCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250 ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290 aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7 dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwm bmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNw O3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5 Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJz cDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFp bCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJz cDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNw O3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNw O2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2Vu ZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZu YnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUm bmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00295017482578DC_=-- From neil.2.harrison@bt.com Fri Jul 29 00:42:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403F321F8B1C for ; Fri, 29 Jul 2011 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.128 X-Spam-Level: ** X-Spam-Status: No, score=2.128 tagged_above=-999 required=5 tests=[AWL=-4.474, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpPj05JQcRxq for ; Fri, 29 Jul 2011 00:42:09 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 204D121F8B12 for ; Fri, 29 Jul 2011 00:42:09 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 08:42:07 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 29 Jul 2011 08:42:07 +0100 From: To: , Date: Fri, 29 Jul 2011 08:42:07 +0100 Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6IFJlOiAgQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxz?= =?gb2312?B?LXRwLXNkLTAz?= Thread-Index: AcxNo3BPB9PCKsD8SYuopAqTnkU4aQAGOqbQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D431315@EMV62-UKRD.domain1.systemhost.net> References: <4E322F44.60301@gmail.com> In-Reply-To: <4E322F44.60301@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:42:10 -0000 SSBhZ3JlZSB3aXRoIEh1dWIuICBFYWNoIGxheWVyIG5ldHdvcmsgbXVzdCBiZSBmdW5jdGlvbmFs bHkgaW5kZXBlbmRlbnQgKHRoaXMgaXMgbW9yZSB0aGFuIE9BTSBwbGVhc2Ugbm90ZSkgd3J0IGFu eSBjbGllbnQgb3Igc2VydmVyIGxheWVyIG5ldHdvcmtzLiAgQW5kIGZvciB0cmFuc3BvcnQgbmV0 d29ya3MgdGhpcyBpcyBhIE1VU1QgYmVjYXVzZSB0aGV5IGhhdmUgdG8gcHJvdmlkZSBhIHRyYW5z cGFyZW50IHRyYW5zcG9ydCBzZXJ2aWNlIHRvIHRoZWlyIGNsaWVudHMuICAgDQoNCnJlZ2FyZHMu IE5laWwNCg0KVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLg0KSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5k aXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVu ZGVkDQpyZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRp bmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbg0KaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVs eQ0Kb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCldlIG1vbml0b3Igb3Vy IGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMuDQpCcml0aXNoIFRlbGVj b21tdW5pY2F0aW9ucyBwbGMNClJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBM b25kb24gRUMxQSA3QUoNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBIdXViIHZh biBIZWx2b29ydA0KPiBTZW50OiAyOSBKdWx5IDIwMTEgMDQ6NTYNCj4gVG86IG1wbHNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSC08Li0OiBSZTogQ29tbWVudHMgdG8gZHJhZnQtcmto ZC1tcGxzLXRwLXNkLTAzDQo+IA0KPiBEZWFyIFl1eGlhLA0KPiANCj4gWW91IHdyb3RlOg0KPiAN Cj4gPiBJIHdhbnQgdG8gY2xhcmlmeSBzZXZlcmFsIHRoaW5nczoNCj4gDQo+IE9LLg0KPiANCj4g PiAxKSBXaHkgc29tZSB2ZW5kb3JzIGRvIHRoZSByZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQgb24g U0Qgb2YgTVBMUy1UUD8NCj4goaqhqg0KPiA+IFJlcXVpcmVtZW50cyBmcm9tIHNlcnZpY2UgcHJv dmlkZXJzLiBTRCBzaG91bGQgYmUgcmVwb3J0ZWQgYW5kDQo+IHRyaWdnZXINCj4gPiB0byBwcm90 ZWN0aW9uLg0KPiANCj4gVGhlcmUgaXMgbm8gaXNzdWUgd2l0aCB0aGF0IHJlcXVpcmVtZW50Lg0K PiANCj4gPiAyKSBXaHkgcHJvcGFnYXRlIHNlcnZlciBsYXllciBpbmZvciB0byBUUD8goaqhqiBJ TU8sIFNpZ25hbCBkZWdyYWRlDQo+IG9ubHkNCj4gPiByZWZlcnMgdG8gdGhlIGJpdCBlcnJvciBo YXBwZW5pbmcgb24gdGhlIHBoeXNpY2FsIGxheWVyLiBQYWNrZXQgbG9zcw0KPiA+IGluZHVjZWQg YnkgY29uZ2VzdGlvbiBvciBDUFUgb3ZlcmxvYWQgaXMgbm90IHRoZSBmYWN0b3IgdG8gU0QuIElu DQo+IG9yZGVyDQo+ID4gdG8gYXZvaWQgdGhlc2UgaW1wYWN0cywgd2UgdXNlIHRoZSBpbmZvcm1h dGlvbiBkZXRlY3RlZCBieSBwaHlzaWNhbA0KPiBsYXllci4NCj4gDQo+IEkgcmVzcGVjdCB5b3Vy IG9waW5pb24uDQo+IA0KPiBIb3dldmVyLCB0aGUgU2lnbmFsL1NlcnZpY2UgZGVncmFkZSBkZXRl Y3Rpb24gc2hhbGwgYmUgYmFzZWQgb24gdGhlDQo+IGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9u IG9mIHRoZSBsYXllciB0aGF0IHJlcXVpcmVzIFNEIGRldGVjdGlvbi4NCj4gDQo+IEFjY29yZGlu ZyB0byBHLjgxMTAuMSBjbGF1c2UgNi4xLjIgOg0KPiAiVGhlIE1QTFMgVFAgbGF5ZXIgbmV0d29y ayBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiBpcyBhIGZsb3cgb2YNCj4gIE1UX0NJIERhdGEg KE1UX0NJX0QpIHRyYWZmaWMgdW5pdHMiLg0KPiANCj4gVGhlIChTRCkgZGVmZWN0IGRldGVjdGlv biBzaG91bGQgbmV2ZXIgcmVseSBvbiBkZWZlY3QgZGV0ZWN0aW9uDQo+IG1lY2hhbmlzbXMNCj4g aW4gbG93ZXIgbGF5ZXJzIHdpdGggcG9zc2libHkgb2hlciB0ZWNobm9sb2dpZXMuDQo+IA0KPiBJ biB0cmFuc3BvcnQgbmV0d29ya3MgY29uZ2VzdGlvbiBzaG91bGQgbm90IG9jY3VyIHVuZGVyIG5v cm1hbA0KPiBvcGVyYXRpbmcNCj4gY29uZGl0aW9ucyBhbmQgbmVpdGhlciBzaG91bGQgQ1BVIG92 ZXJsb2FkLg0KPiANCj4gPiAzKSBXaHkgb25seSBwcm9wYWdhdGUgdG8gVFA/IKGqoaogV2UgdGhp bmsgaXQgaXMgbm90IG9ubHkgVFAsIGJ1dCBhbHNvDQo+IFBXLg0KPiA+IEluIGZhY3QsIHByb3Bh Z2F0ZSB0byB0cmFuc3BvcnQgcGF0aC4gSXQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCj4g DQo+IFByb3BhZ2F0aW9uIHRvIGhpZ2hlciBsYXllcnMgaXMgdXNlbGVzcywgaXQgb25seSBhZGRz IGNvbXBsZXhpdHkuDQo+IA0KPiA+IDQpIFdoeSBub3QgcHJvcGFnYXRlIHRvIHRoZSBoaWdoZXIg bGF5ZXIgYWJvdmUgdGhhbnNwb3J0IHBhdGg/IKGqoaoNCj4gTm93LA0KPiA+IHdlIGFyZSBkaXNj dXNzaW5nIHRoZSByZXF1aXJlbWVudCBhbmQgc29sdXRpb24gcmVmZXJyaW5nIHRvIHRyYW5zcG9y dA0KPiA+IHBhdGguIFdoZXRoZXIgcHJvcGFnYXRlIHRvIGhpZ2hlciBsYXllciBpcyBub3QgdGhl IHRvcGljIHdlIGNhcmUNCj4gYWJvdXQuDQo+IA0KPiBUaGlzIGNvbnRyYWRpY3RzIHdoYXQgeW91 IHdyaXRlIGluIHlvdXIgaXRlbSAzKS4NCj4gDQo+IEJlc3QgcmVnYXJkcywgSHV1Yi4NCj4gDQo+ IA0KPiANCj4gPiAqR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4qDQo+ID4NCj4g PiAyMDExLTA3LTI5IDAxOjAwDQo+ID4NCj4gPg0KPiA+IMrVvP7Iyw0KPiA+IAlEYW5pZWwgQ29o biA8RGFuaWVsQ0BvcmNraXQuY29tPg0KPiA+ILOty80NCj4gPiAJIkVyaWMgT3Nib3JuZSAoZW9z Ym9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiwgUmFmaSBSYW0NCj4gPiA8UmFmaVJAb3Jja2l0 LmNvbT4sIG1zLWRhaWtva3VAa2RkaS5jb20sIG1hLnl1eGlhQHp0ZS5jb20uY24sDQo+ID4geWFu Zy5qaWFuOTBAenRlLmNvbS5jbiwgIkQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8iDQo+ ID4gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4sIG1wbHNAaWV0Zi5v cmcNCj4gPiDW98ziDQo+ID4gCVJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxz LXRwLXNkLTAzDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEhp IERhbmllbCwNCj4gPiBJIHRoaW5rIHRoYXQgd2hpbGUgd2UncmUgYnVpbGRpbmcgTVBMUy1UUCB0 byBiZSBzdWl0ZWQgZm9yIHRoZQ0KPiA+IHRyYW5zcG9ydCB3ZSBuZWVkIHRvIHJlbWVtYmVyIHRo YXQgaXQsIGFzIE5laWwgcG9pbnRlZCBvdXQgb24gbnVtYmVyDQo+ID4gb2Ygb2NjYXNpb25zLCBp cyBub3QgQk9TIGxheWVyIGFuZCBkb2Vzbid0IHB1dCBiaXRzIG9uIGEgd2lyZS4gVGh1cw0KPiBp dA0KPiA+IGhhcyBjaGFyYWN0ZXJpc3RpYyB0aGF0IG1ha2VzIGl0IGRpZmZlcmVudCBmcm9tIG90 aGVyIGxheWVycyBvZiBhDQo+ID4gdHJhbnNwb3J0IG5ldHdvcmsgYW5kLCBJIHRoaW5rLCBhcyBy ZXN1bHQgbm90IGFsbCBleGlzdGluZyBjb25jZXB0cw0KPiBvZg0KPiA+IHRyYW5zcG9ydCBhcmUg YXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVhbGl6ZWQgYnkgTVBMUy1UUC4NCj4gPg0KPiA+ IFJlZ2FyZHMsDQo+ID4gR3JlZw0KPiA+DQo+ID4gT24gVGh1LCBKdWwgMjgsIDIwMTEgYXQgOTo1 MSBBTSwgRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbT4NCj4gd3JvdGU6DQo+ID4gID4g SGkgRXJpYywNCj4gPiAgPg0KPiA+ICA+IE9uZSBvZiB0aGUgcmVhc29ucyB3aHkgd2UgbmVlZCBT RCBpbiBUUCBpcyBiZWNhdXNlIFRQIGlzIHN1cHBvc2VkDQo+IHRvDQo+ID4gID4gcHJvdmlkZSB0 aGUgc2FtZSAibG9vayBhbmQgZmVlbCIgb2YgZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzLA0K PiBhcw0KPiA+ICA+IHNwZWNpZmllZCBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0K PiA+ICA+IFRyYW5zcG9ydCBuZXR3b3JrcyB0ZWNobm9sb2dpZXMgaGF2ZSBsb25nIHN1cHBvcnRl ZCB0aGUNCj4gZGlzdGluY3Rpb24NCj4gPiAgPiBiZXR3ZWVuICJkZWdyYWRlZCIgYW5kICIgZmF1 bHR5Ii4gSW4gcGFydGljdWxhciwgcHJvdGVjdGlvbg0KPiB0ZWNobm9sb2dpZXMNCj4gPiAgPiBp biB1c2UgaGF2ZSB0aGlzIGRpc3RpbmN0aW9uIGJ1aWx0IGludG8gdGhlIGlubmVybW9zdCByZWNl ZGVzIG9mDQo+IHRoZWlyDQo+ID4gID4gcHJvdG9jb2xzLg0KPiA+ICA+IEV2ZW4gaW4gdGhlIFRQ IHJlcXVpcmVtZW50cyBkaWRuJ3Qgc3BlbGwgdGhpcyBvdXQsIEkgdGhpbmsgaXQNCj4gd291bGQg YmUgYQ0KPiA+ICA+IG1pc3Rha2Ugbm90IHRvIHRha2UgYWR2YW50YWdlIG9mIHllYXJzIG9mIGV4 cGVyaWVuY2UgaW4gdHJhbnNwb3J0DQo+ID4gID4gbmV0d29ya3MgT0FNLg0KPiA+ICA+DQo+ID4g ID4gUmVnYXJkcywNCj4gPiAgPg0KPiA+ICA+IERhbmllbA0KPiA+ICA+DQo+ID4gID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAgPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5l KSBbbWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbV0NCj4gPiAgPiBTZW50OiBUaHVyc2RheSwgSnVs eSAyOCwgMjAxMSAxMToxMiBBTQ0KPiA+ICA+IFRvOiBHcmVnIE1pcnNreTsgRGFuaWVsIENvaG47 IFJhZmkgUmFtOyBtcy1kYWlrb2t1QGtkZGkuY29tOw0KPiA+ICA+IG1hLnl1eGlhQHp0ZS5jb20u Y247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxlc3NhbmRybw0KPiBBbGVzc2FuZHJvDQo+ ID4gID4gR2VyYXJkbzsgbXBsc0BpZXRmLm9yZw0KPiA+ICA+IFN1YmplY3Q6IFJFOiBbbXBsc10g Q29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+ID4gID4NCj4gPiAgPiBIaSBH cmVnLQ0KPiA+ICA+IFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIGFuZCBTRC4gQ29u dmVydGluZyBTRCBpbnRvIERvd24NCj4gPiAgPiBtZWFucyB0aGF0IGl0IHdpbGwgYmUgaW50ZXJw cmV0ZWQgZXhhY3RseSB0aGUgc2FtZSBhcyBTRiwgYW5kIGlmDQo+IHRoYXQncw0KPiA+ICA+IHRo ZSBjYXNlIHdoeSBoYXZlIFNEIGF0IGFsbD8gSWYgU0QgaXMgbmVjZXNzYXJ5IGl0IG11c3QgYmUg c29tZWhvdw0KPiA+ICA+IGRpZmZlcmVudCBmcm9tIFNELg0KPiA+ICA+DQo+ID4gID4gQWxsLQ0K PiA+ICA+DQo+ID4gID4gSGF2aW5nIHNhaWQgdGhhdCwgSSdtIG5vdCBzdXJlIEkgZGlzYWdyZWUg d2l0aCBHcmVnLiBJdCBzZWVtcyB0aGF0DQo+ID4gID4gdGhpcyBpZGVhIG9mIHByb3BhZ2F0aW5n IHNlcnZlciBsYXllciBTRCB1cCBpbnRvIFRQIGlzIGJlaW5nIGRvbmUNCj4gPiAgPiBiZWNhdXNl IHRoZXJlJ3Mgbm8gZ29vZCB3YXkgdG8gZG8gU0QgZW50aXJlbHkgd2l0aGluIHRoZSBUUCBsYXll ci4NCj4gSQ0KPiA+ICA+IHN1c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNE IHdpdGhpbiB0aGUgVFAgbGF5ZXIgdGhhdA0KPiBtYWRlDQo+ID4gID4gZXZlcnlvbmUgaGFwcHks IHdlIHdvdWxkbid0IGhhdmUgdGhlIGFwcHJvYWNoIHByb3BzZWQgaW4NCj4gPiAgPiBkcmFmdC1y a2hkLW1wbHMtdHAtc2QuIEFuZCBJIHRoaW5rIHRoYXQgaWYgdGhlIG1vdGl2YXRpb24gZm9yIHRo aXMNCj4gPiAgPiBkcmFmdCBpczoNCj4gPiAgPg0KPiA+ICA+IC0gd2UgbXVzdCBoYXZlIFNEIGlu IFRQIGJlY2F1c2UgaXQgaXMgcG9zc2libGUgdG8gZG8gaW4gb3RoZXINCj4gPiAgPiB0ZWNobm9s b2dpZXMNCj4gPiAgPiAtIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBTRCBlbnRpcmVseSB3aXRoaW4g VFANCj4gPiAgPiAtIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBTRCBmcm9tIHNvbWV3aGVyZSBlbHNl DQo+ID4gID4NCj4gPiAgPiBpcyBhIHJlYXNvbmFibGUgb25lLiBJZiB3ZSBkbyB0aGF0LCB3aGVy ZSBkbyB3ZSBzdG9wPyBTaG91bGQgd2UNCj4gPiAgPiBwcm9wYWdhdGUgaW5mb3JtYXRpb24gYWJv dXQgc2lnbmFsIHF1YWxpdHkgdXAgdG8gVENQIHNvIGl0IGNhbg0KPiBhZGp1c3QNCj4gPiAgPiBp dHMgd2luZG93cyBhY2NvcmRpbmc/IChwbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgaW50ZW5kZWQg dG8gYmUgYQ0KPiA+ICA+IHJlZHVjdGlvIGFkIGFic3VyZHVtIHF1ZXN0aW9uIGFuZCBub3QgYSBz ZXJpb3VzIG9uZS4gOikgKQ0KPiA+ICA+DQo+ID4gID4NCj4gPiAgPg0KPiA+ICA+IGVyaWMNCj4g PiAgPg0KPiA+ICA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ICA+PiBGcm9tOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ IEJlaGFsZg0KPiA+ICA+IE9mDQo+ID4gID4+IEdyZWcgTWlyc2t5DQo+ID4gID4+IFNlbnQ6IFdl ZG5lc2RheSwgSnVseSAyNywgMjAxMSAyOjA4IFBNDQo+ID4gID4+IFRvOiBEYW5pZWwgQ29objsg cmFmaXJAb3Jja2l0LmNvbTsgbXMtZGFpa29rdUBrZGRpLmNvbTsNCj4gPiAgPj4gbWEueXV4aWFA enRlLmNvbS5jbjsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbjsgRCdBbGVzc2FuZHJvDQo+IEFsZXNz YW5kcm8NCj4gPiAgPj4gR2VyYXJkbzsgbXBsc0BpZXRmLm9yZw0KPiA+ICA+PiBTdWJqZWN0OiBb bXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+ID4gID4+DQo+ID4g ID4+IERlYXIgQXV0aG9ycyBhbmQgQWxsLA0KPiA+ICA+PiBJIHRoaW5rIHRoYXQgaXQgaXMgZnVu Y3Rpb24gb2YgdGhlIFBIWSBsYXllciB0byBkZXRlY3QgU0QNCj4gY29uZGl0aW9uDQo+ID4gID4g YW5kDQo+ID4gID4+IGNvbnZlcnQgaXQgaW50byBEb3duIGZvciB0aGUgTVBMUy1UUCBMYXllciAw ICh3aGF0IHdlIHJlZmVyIGFzDQo+ID4gID4gUGh5c2ljYWwNCj4gPiAgPj4gU2VjdGlvbikuIElu IGNhc2Ugb2YgYWNjdW11bGF0aW5nIFNEIG92ZXIgTFNQIHRoZSBlMmUgUGFja2V0IExvc3MNCj4g PiAgPj4gbWVhc3VyZW1lbnQsIGluIG15IHZpZXcsIGlzIGFkZHJlc3NpbmcgdGhlIGlzc3VlLg0K PiA+ICA+Pg0KPiA+ICA+PiBSZWdhcmRzLA0KPiA+ICA+PiBHcmVnDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+ IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo= From neil.2.harrison@bt.com Fri Jul 29 00:42:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A47C21F8B32 for ; Fri, 29 Jul 2011 00:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy5tOasLtPlb for ; Fri, 29 Jul 2011 00:42:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 889BE21F8B12 for ; Fri, 29 Jul 2011 00:42:10 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 08:42:09 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 29 Jul 2011 08:42:09 +0100 From: To: , Date: Fri, 29 Jul 2011 08:42:02 +0100 Thread-Topic: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 Thread-Index: AQHMTIh/NwvKYIFUjUmDOYVxYYyuaZUBx6yAgAAbw4CAAAJfAIAABCmAgAAU8wCAAAMigIAABokAgAAS34CAAAFEgIAABDUAgAABZICAAANEAIAAqR7wgAATxsA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D431316@EMV62-UKRD.domain1.systemhost.net> References: <44F4E579A764584EA9BDFD07D0CA081306ED827C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306ED8284@tlvmail1> <2C2F1EBA8050E74EA81502D5740B4BD6A932615A9A@SJEXCHCCR02.corp.ad.broadcom.com> <7A5F44B6-E4B7-4C31-A743-A201C70AC9F9@gmail.com> <4E31C29F.1010302@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82A8@tlvmail1> <4E31C736.5040306@gmail.com> <44F4E579A764584EA9BDFD07D0CA081306ED82AC@tlvmail1> <4E31CB1E.7080004@gmail.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:42:12 -0000 Maarten I agree with you wrt the layer and causal independence principle at= play here. This is the situation architecturally: A layer N path is composed of layer N nodes and layer N links. The layer N= links are in turn provided by paths at layer N-1.....and so on downwards a= s we recurse to the duct. Hence the impairments seen at layer N are a sum (to a good 1st~) of - the impairments introduced in the layer N nodes - the impairments inherited (from all the lower layer networks down t= o the duct) by the layer N links This is a complex impairment inheritance/aggregation case. However, the cl= ient of layer N cares nothing about what the actual layered arch is that su= pports his/her (external message/file/stream) applications....he/she just c= ares about the impact on his/her applications...and the perceived impact wi= ll vary from application to application. Down at the EM guided wave layer is where we most generally associate 'SD' = impairments wrt q'ary symbol errors (that become bits errors at higher laye= rs). These are generally not Poisson in nature but bursty...I spent much o= f 90s measuring these events and their distributions. They are very comple= x and based on self-similar/chaotic characteristics (which have some intere= sting consequences for how folks quantify these wrt metrics and set mainten= ance thresholds that I will not go into here). Above the BOS guided EM wave level impairments are either due to (i) rogue = equipment components or (ii) congestion due to overbooked resources. The former case is rare....and we don't need complex OAM with lots of QoS c= lasses to identify these. In a transport network the latter case should be non-existent, ie overbooki= ng of resources violates a requirement of transparency. Note carefully thi= s also implies there cannot be any QoS classes in transport networks. This= is esp true if we also observe that a transport network often carries an a= ggregate (often temporally varying in mix) of ultimate message/file/stream = applications which can have widely different QoS and survivability importan= ce requirements...so we have to treat each bit in a transport connection eq= ually...this is part of transparency. Of course with the co-cs mode based on regular time-slices one can't overbo= ok resources so we get transparency without thinking about it. In the co-ps mode we don't get transparency for free but have to consciousl= y engineer it. Note that QoS is largely a nonsense anyway (irrespective of= a transport role) for many reasons...that is, because real co-ps mode netw= orks have to run far to the LHS of a their congestion knee for nearly all t= ime it makes the topic of QoS (which is very different to 'survivability im= portance') of little value in the real world. So, what we conclude from the above is that 'SD-like' impairments in the co= -ps mode are largely a function of network design and how much an operator = wants to overbook their resources. Looking ahead it my view that operators = that subscribe to gross overbooking (and by inference also probably like lo= ts of QoS classes) are backing the wrong strategy. Though if one is *suppo= sed* to be building a transport network anyway this should be a non-existen= t argument. Aside=3D> We make things way too complex...esp OAM and much of the QoS nons= ense.....most of it is simply not necessary. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Maarten vissers > Sent: 29 July 2011 07:27 > To: mpls@ietf.org > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > The detection of a Degraded defect and associated raising of a Degraded > failure condition is required to send a warning to the maintenance > people that the connection is suffering from a persistent CIR packet > loss which is exceeding the packet loss value in the SLA (case of > transport service layer connection) or the value set for infrastructure > connections (transport path or section layer connections). > > The detection of a Degraded defect condition and associated raising of > the Signal Degrade (SD) consequent action is required to prevent that a > protected connection (Section, LSP, PW, PSME) enters UnAvailable Time > (UAT). The SD should cause that the signal is switched to protection so > that UAT will not be entered (default Degraded defect detection time is > 7 seconds (see G.7710)). Degraded defect threshold is based on packet > loss value in SLA. > > It is a primary requirement in transport networks to prevent that a > transport service layer connection (PW, service-LSP) enters UAT. A > customer will be upset when his/her protected service enters UAT on CIR > packet loss in the working connection and does not switch to protection > to restore it. A customer does not care what is causing the > unacceptable packet loss (bit errors on fiber, bit errors in equipment, > congestion, packet buffer errors, switch fabric faults, other). > > Regards, > Maarten > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Huub van Helvoort > > Sent: 28 July 2011 22:49 > > To: mpls@ietf.org > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > Hi Daniel, > > > > You replied: > > > > > Can propose a TP-based detection method that can detect only > physical > > > errors, i.e. without being influenced by non-physical conditions > such > > as > > > congestion, CPU overload, etc.? > > > > So as a customer I should only complain about degraded service > > if it is caused by physical errors... > > I have never seen SLAs with this restriction. > > > > We should use the characteristics of the technology to detect > > any issues with the transport of the characteristic information. > > > > Regards, Huub. > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Huub van Helvoort > > > Sent: Thursday, July 28, 2011 4:32 PM > > > To: mpls@ietf.org > > > Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > > > > > Hi Daniel Cohn > > > > > > You wrote: > > > > > >> I don't think sending iterative e-mails referring to ever higher > > layer > > >> serves the point of this discussion. > > > > > > OK, ---8<---snipped > > > > > >> PS: No need to, the VC12 has its own SD detection capabilities. > > > > > > So why don't we define SD (service degrade) defect detection > criteria > > > for MPLS-TP? > > > In stead of relying on SD (signal degrade) defect detect mechanisms > > in > > > other technologies. > > > > > > BR, Huub. > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > >> Huub van Helvoort > > >> Sent: Thursday, July 28, 2011 4:12 PM > > >> To: mpls@ietf.org > > >> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >> > > >> And propagate to the VC12 carried By the PW? > > >> and... > > >> > > >> Huub > > >> > > >> > > >> > > >>> Also, if we were to propagate to Tp, why stop there? It should be > > >> propagated to PW as well, right? > > >>> > > >>> Sam > > >>> > > >>> Sent from my iPhone > > >>> > > >>> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" > > > wrote: > > >>> > > >>>> I agree with Eric, Shahram and actually richard kam > > (alcatel/lucent) > > >> made this exact point at the mike > > >>>> during presentation. > > >>>> > > >>>> /himanshu > > >>>> > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > >> Of Shahram Davari > > >>>> Sent: Thursday, July 28, 2011 2:30 PM > > >>>> To: Daniel Cohn; Greg Mirsky > > >>>> Cc: Rafi Ram; mpls@ietf.org; ms-daikoku@kddi.com; > > >> yang.jian90@zte.com.cn > > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >>>> > > >>>> Hi, > > >>>> > > >>>> I also don't believe SD is needed for MPLS-TP. Such defect is > not > > >> related to MPLS-TP and should be handled in the server layer, such > > as > > >> changing the FEC type in OTN, etc. > > >>>> > > >>>> Regards, > > >>>> Shahram > > >>>> > > >>>> -----Original Message----- > > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > >> Of Daniel Cohn > > >>>> Sent: Thursday, July 28, 2011 10:15 AM > > >>>> To: Greg Mirsky > > >>>> Cc: mpls@ietf.org; yang.jian90@zte.com.cn; ms-daikoku@kddi.com; > > Rafi > > >> Ram > > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >>>> > > >>>> True enough in general. But in this particular example, there is > > >> nothing suggested by this draft that requires huge implementation > > >> efforts or paradigm changes. So I fail to see why we should settle > > for > > >> less functionality than is available in existing transport > networks. > > >>>> > > >>>> DC > > >>>> > > >>>> -----Original Message----- > > >>>> From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > >>>> Sent: Thursday, July 28, 2011 1:00 PM > > >>>> To: Daniel Cohn > > >>>> Cc: Eric Osborne (eosborne); Rafi Ram; ms-daikoku@kddi.com; > > >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > Alessandro > > >> Gerardo; mpls@ietf.org > > >>>> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >>>> > > >>>> Hi Daniel, > > >>>> I think that while we're building MPLS-TP to be suited for the > > >>>> transport we need to remember that it, as Neil pointed out on > > number > > >>>> of occasions, is not BOS layer and doesn't put bits on a wire. > > Thus > > >> it > > >>>> has characteristic that makes it different from other layers of > a > > >>>> transport network and, I think, as result not all existing > > concepts > > >> of > > >>>> transport are applicable to packet layer realized by MPLS-TP. > > >>>> > > >>>> Regards, > > >>>> Greg > > >>>> > > >>>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn > > >> wrote: > > >>>>> Hi Eric, > > >>>>> > > >>>>> One of the reasons why we need SD in TP is because TP is > supposed > > > to > > >>>>> provide the same "look and feel" of existing transport > networks, > > as > > >>>>> specified in the TP requirements document. > > >>>>> Transport networks technologies have long supported the > > distinction > > >>>>> between "degraded" and " faulty". In particular, protection > > >> technologies > > >>>>> in use have this distinction built into the innermost recedes > of > > >> their > > >>>>> protocols. > > >>>>> Even in the TP requirements didn't spell this out, I think it > > would > > >> be a > > >>>>> mistake not to take advantage of years of experience in > transport > > >>>>> networks OAM. > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Daniel > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > >>>>> Sent: Thursday, July 28, 2011 11:12 AM > > >>>>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com; > > >>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > > Alessandro > > >>>>> Gerardo; mpls@ietf.org > > >>>>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >>>>> > > >>>>> Hi Greg- > > >>>>> There is a difference between SF and SD. Converting SD into > Down > > >>>>> means that it will be interpreted exactly the same as SF, and > if > > >> that's > > >>>>> the case why have SD at all? If SD is necessary it must be > > somehow > > >>>>> different from SD. > > >>>>> > > >>>>> All- > > >>>>> > > >>>>> Having said that, I'm not sure I disagree with Greg. It seems > > that > > >>>>> this idea of propagating server layer SD up into TP is being > done > > >>>>> because there's no good way to do SD entirely within the TP > > layer. > > >> I > > >>>>> suspect that if there were a way to do SD within the TP layer > > that > > >> made > > >>>>> everyone happy, we wouldn't have the approach propsed in > > >>>>> draft-rkhd-mpls-tp-sd. And I think that if the motivation for > > this > > >>>>> draft is: > > >>>>> > > >>>>> - we must have SD in TP because it is possible to do in other > > >>>>> technologies > > >>>>> - it is not possible to SD entirely within TP > > >>>>> - therefore we must get SD from somewhere else > > >>>>> > > >>>>> is a reasonable one. If we do that, where do we stop? Should > we > > >>>>> propagate information about signal quality up to TCP so it can > > >> adjust > > >>>>> its windows according? (please note that this is intended to > be > > a > > >>>>> reductio ad absurdum question and not a serious one. :) ) > > >>>>> > > >>>>> > > >>>>> > > >>>>> eric > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf > > >>>>> Of > > >>>>>> Greg Mirsky > > >>>>>> Sent: Wednesday, July 27, 2011 2:08 PM > > >>>>>> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.com; > > >>>>>> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro > > >> Alessandro > > >>>>>> Gerardo; mpls@ietf.org > > >>>>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 > > >>>>>> > > >>>>>> Dear Authors and All, > > >>>>>> I think that it is function of the PHY layer to detect SD > > > condition > > >>>>> and > > >>>>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as > > >>>>> Physical > > >>>>>> Section). In case of accumulating SD over LSP the e2e Packet > > Loss > > >>>>>> measurement, in my view, is addressing the issue. > > >>>>>> > > >>>>>> Regards, > > >>>>>> Greg > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From su.hui@zte.com.cn Fri Jul 29 00:46:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F021F86C7; Fri, 29 Jul 2011 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDRVhFhPNNWQ; Fri, 29 Jul 2011 00:46:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70921F86BC; Fri, 29 Jul 2011 00:46:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321784411434; Fri, 29 Jul 2011 15:38:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 2819.2420051341; Fri, 29 Jul 2011 15:46:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6T7kMRK068284; Fri, 29 Jul 2011 15:46:22 +0800 (GMT-8) (envelope-from su.hui@zte.com.cn) In-Reply-To: To: Maarten vissers MIME-Version: 1.0 X-KeepSent: 4746BDA6:697ABFA6-482578DC:002AA44A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: su.hui@zte.com.cn Date: Fri, 29 Jul 2011 15:46:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-29 15:46:23, Serialize complete at 2011-07-29 15:46:23 Content-Type: multipart/alternative; boundary="=_alternative 002AB7E0482578DC_=" X-MAIL: mse01.zte.com.cn p6T7kMRK068284 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:46:47 -0000 This is a multipart message in MIME format. --=_alternative 002AB7E0482578DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWFhcnRlbqOsDQoNCkl0IGxvb2tzIGxpa2Ugd2UgYWdyZWUgd2l0aCB0aGUgU0QgcHJvdGVj dGlvbiByZXF1aXJlbWVudC4gVGhlIGRpZmZlcmVuY2UgDQpiZXR3ZWVuIHVzIGlzIGRldGVjdCBp biBzZXJ2ZXIgbGF5ZXIgb3IgZGV0ZWN0IGluIE1QTFMtVFAgbGF5ZXIsIGlzIG15IA0KdW5kZXJz dGFuZGluZyByaWdodD8NCiBPbmUgYWR2YW50YWdlIG9mIGRldGVjdCBpbiBzZXJ2ZXIgbGF5ZXIg aXMgaXQgY2FuIHdvcmsgY29ycmVjdGx5IGV2ZW4gaW4gDQp0aGUgY2FzZSB0aGF0IG5vIHBhY2tl dCBpcyB0cmFuc3BvcnRpbmcuIFRoaXMgaXMgaW1wb3J0YW50IHRvIHVzZSBTRCBhcyBhIA0KdHJp Z2dlciBvZiBwcm90ZWN0aW9uLCBiZWNhdXNlIHRoZXJlIGlzIG5vIHBhY2tldCBpbiBzdGFuZGJ5 IHBhdGguDQoNClN1aHVpIA0KDQoNCg0KTWFhcnRlbiB2aXNzZXJzIDxtYWFydGVuLnZpc3NlcnNA aHVhd2VpLmNvbT4gDQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDctMjkg MTQ6MjcNCg0KytW8/sjLDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQqzrcvNDQoN Ctb3zOINClJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQoN Cg0KDQoNCg0KDQpUaGUgZGV0ZWN0aW9uIG9mIGEgRGVncmFkZWQgZGVmZWN0IGFuZCBhc3NvY2lh dGVkIHJhaXNpbmcgb2YgYSBEZWdyYWRlZCANCmZhaWx1cmUgY29uZGl0aW9uIGlzIHJlcXVpcmVk IHRvIHNlbmQgYSB3YXJuaW5nIHRvIHRoZSBtYWludGVuYW5jZSBwZW9wbGUgDQp0aGF0IHRoZSBj b25uZWN0aW9uIGlzIHN1ZmZlcmluZyBmcm9tIGEgcGVyc2lzdGVudCBDSVIgcGFja2V0IGxvc3Mg d2hpY2ggDQppcyBleGNlZWRpbmcgdGhlIHBhY2tldCBsb3NzIHZhbHVlIGluIHRoZSBTTEEgKGNh c2Ugb2YgdHJhbnNwb3J0IHNlcnZpY2UgDQpsYXllciBjb25uZWN0aW9uKSBvciB0aGUgdmFsdWUg c2V0IGZvciBpbmZyYXN0cnVjdHVyZSBjb25uZWN0aW9ucyANCih0cmFuc3BvcnQgcGF0aCBvciBz ZWN0aW9uIGxheWVyIGNvbm5lY3Rpb25zKS4NCg0KVGhlIGRldGVjdGlvbiBvZiBhIERlZ3JhZGVk IGRlZmVjdCBjb25kaXRpb24gYW5kIGFzc29jaWF0ZWQgcmFpc2luZyBvZiB0aGUgDQpTaWduYWwg RGVncmFkZSAoU0QpIGNvbnNlcXVlbnQgYWN0aW9uIGlzIHJlcXVpcmVkIHRvIHByZXZlbnQgdGhh dCBhIA0KcHJvdGVjdGVkIGNvbm5lY3Rpb24gKFNlY3Rpb24sIExTUCwgUFcsIFBTTUUpIGVudGVy cyBVbkF2YWlsYWJsZSBUaW1lIA0KKFVBVCkuIFRoZSBTRCBzaG91bGQgY2F1c2UgdGhhdCB0aGUg c2lnbmFsIGlzIHN3aXRjaGVkIHRvIHByb3RlY3Rpb24gc28gDQp0aGF0IFVBVCB3aWxsIG5vdCBi ZSBlbnRlcmVkIChkZWZhdWx0IERlZ3JhZGVkIGRlZmVjdCBkZXRlY3Rpb24gdGltZSBpcyA3IA0K c2Vjb25kcyAoc2VlIEcuNzcxMCkpLiBEZWdyYWRlZCBkZWZlY3QgdGhyZXNob2xkIGlzIGJhc2Vk IG9uIHBhY2tldCBsb3NzIA0KdmFsdWUgaW4gU0xBLg0KDQpJdCBpcyBhIHByaW1hcnkgcmVxdWly ZW1lbnQgaW4gdHJhbnNwb3J0IG5ldHdvcmtzIHRvIHByZXZlbnQgdGhhdCBhIA0KdHJhbnNwb3J0 IHNlcnZpY2UgbGF5ZXIgY29ubmVjdGlvbiAoUFcsIHNlcnZpY2UtTFNQKSBlbnRlcnMgVUFULiBB IA0KY3VzdG9tZXIgd2lsbCBiZSB1cHNldCB3aGVuIGhpcy9oZXIgcHJvdGVjdGVkIHNlcnZpY2Ug ZW50ZXJzIFVBVCBvbiBDSVIgDQpwYWNrZXQgbG9zcyBpbiB0aGUgd29ya2luZyBjb25uZWN0aW9u IGFuZCBkb2VzIG5vdCBzd2l0Y2ggdG8gcHJvdGVjdGlvbiB0byANCnJlc3RvcmUgaXQuIEEgY3Vz dG9tZXIgZG9lcyBub3QgY2FyZSB3aGF0IGlzIGNhdXNpbmcgdGhlIHVuYWNjZXB0YWJsZSANCnBh Y2tldCBsb3NzIChiaXQgZXJyb3JzIG9uIGZpYmVyLCBiaXQgZXJyb3JzIGluIGVxdWlwbWVudCwg Y29uZ2VzdGlvbiwgDQpwYWNrZXQgYnVmZmVyIGVycm9ycywgc3dpdGNoIGZhYnJpYyBmYXVsdHMs IG90aGVyKS4NCg0KUmVnYXJkcywNCk1hYXJ0ZW4NCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gU2VudDog MjggSnVseSAyMDExIDIyOjQ5DQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb bXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+IA0KPiBIaSBEYW5p ZWwsDQo+IA0KPiBZb3UgcmVwbGllZDoNCj4gDQo+ID4gQ2FuIHByb3Bvc2UgYSBUUC1iYXNlZCBk ZXRlY3Rpb24gbWV0aG9kIHRoYXQgY2FuIGRldGVjdCBvbmx5IHBoeXNpY2FsDQo+ID4gZXJyb3Jz LCBpLmUuIHdpdGhvdXQgYmVpbmcgaW5mbHVlbmNlZCBieSBub24tcGh5c2ljYWwgY29uZGl0aW9u cyBzdWNoDQo+IGFzDQo+ID4gY29uZ2VzdGlvbiwgQ1BVIG92ZXJsb2FkLCBldGMuPw0KPiANCj4g U28gYXMgYSBjdXN0b21lciBJIHNob3VsZCBvbmx5IGNvbXBsYWluIGFib3V0IGRlZ3JhZGVkIHNl cnZpY2UNCj4gaWYgaXQgaXMgY2F1c2VkIGJ5IHBoeXNpY2FsIGVycm9ycy4uLg0KPiBJIGhhdmUg bmV2ZXIgc2VlbiBTTEFzIHdpdGggdGhpcyByZXN0cmljdGlvbi4NCj4gDQo+IFdlIHNob3VsZCB1 c2UgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgdGVjaG5vbG9neSB0byBkZXRlY3QNCj4gYW55 IGlzc3VlcyB3aXRoIHRoZSB0cmFuc3BvcnQgb2YgdGhlIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0 aW9uLg0KPiANCj4gUmVnYXJkcywgSHV1Yi4NCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YNCj4gPiBIdXViIHZhbiBIZWx2b29ydA0K PiA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDQ6MzIgUE0NCj4gPiBUbzogbXBsc0Bp ZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1t cGxzLXRwLXNkLTAzDQo+ID4NCj4gPiBIaSBEYW5pZWwgQ29obg0KPiA+DQo+ID4gWW91IHdyb3Rl Og0KPiA+DQo+ID4+IEkgZG9uJ3QgdGhpbmsgc2VuZGluZyBpdGVyYXRpdmUgZS1tYWlscyByZWZl cnJpbmcgdG8gZXZlciBoaWdoZXINCj4gbGF5ZXINCj4gPj4gc2VydmVzIHRoZSBwb2ludCBvZiB0 aGlzIGRpc2N1c3Npb24uDQo+ID4NCj4gPiBPSywgLS0tODwtLS1zbmlwcGVkDQo+ID4NCj4gPj4g UFM6IE5vIG5lZWQgdG8sIHRoZSBWQzEyIGhhcyBpdHMgb3duIFNEIGRldGVjdGlvbiBjYXBhYmls aXRpZXMuDQo+ID4NCj4gPiBTbyB3aHkgZG9uJ3Qgd2UgZGVmaW5lIFNEIChzZXJ2aWNlIGRlZ3Jh ZGUpIGRlZmVjdCBkZXRlY3Rpb24gY3JpdGVyaWENCj4gPiBmb3IgTVBMUy1UUD8NCj4gPiBJbiBz dGVhZCBvZiByZWx5aW5nIG9uIFNEIChzaWduYWwgZGVncmFkZSkgZGVmZWN0IGRldGVjdCBtZWNo YW5pc21zDQo+IGluDQo+ID4gb3RoZXIgdGVjaG5vbG9naWVzLg0KPiA+DQo+ID4gQlIsIEh1dWIu DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbXBscy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4gPiBPZg0KPiA+PiBIdXViIHZhbiBIZWx2b29ydA0KPiA+PiBTZW50OiBUaHVyc2RheSwgSnVs eSAyOCwgMjAxMSA0OjEyIFBNDQo+ID4+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6 IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+ID4+DQo+ ID4+IEFuZCBwcm9wYWdhdGUgdG8gdGhlIFZDMTIgY2FycmllZCBCeSB0aGUgUFc/DQo+ID4+IGFu ZC4uLg0KPiA+Pg0KPiA+PiBIdXViDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiBBbHNvLCBpZiB3 ZSB3ZXJlIHRvIHByb3BhZ2F0ZSB0byBUcCwgd2h5IHN0b3AgdGhlcmU/IEl0IHNob3VsZCBiZQ0K PiA+PiBwcm9wYWdhdGVkIHRvIFBXIGFzIHdlbGwsIHJpZ2h0Pw0KPiA+Pj4NCj4gPj4+IFNhbQ0K PiA+Pj4NCj4gPj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gPj4+DQo+ID4+PiBPbiBKdWwgMjgs IDIwMTEsIGF0IDI6NDEgUE0sICJTaGFoLCBIaW1hbnNodSI8aHNoYWhAY2llbmEuY29tPg0KPiA+ IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBJIGFncmVlIHdpdGggRXJpYywgU2hhaHJhbSBhbmQgYWN0 dWFsbHkgcmljaGFyZCBrYW0NCj4gKGFsY2F0ZWwvbHVjZW50KQ0KPiA+PiBtYWRlIHRoaXMgZXhh Y3QgcG9pbnQgYXQgdGhlIG1pa2UNCj4gPj4+PiBkdXJpbmcgcHJlc2VudGF0aW9uLg0KPiA+Pj4+ DQo+ID4+Pj4gL2hpbWFuc2h1DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+PiBPZiBTaGFo cmFtIERhdmFyaQ0KPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDI6MzAgUE0N Cj4gPj4+PiBUbzogRGFuaWVsIENvaG47IEdyZWcgTWlyc2t5DQo+ID4+Pj4gQ2M6IFJhZmkgUmFt OyBtcGxzQGlldGYub3JnOyBtcy1kYWlrb2t1QGtkZGkuY29tOw0KPiA+PiB5YW5nLmppYW45MEB6 dGUuY29tLmNuDQo+ID4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1y a2hkLW1wbHMtdHAtc2QtMDMNCj4gPj4+Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+DQo+ID4+Pj4gSSBh bHNvIGRvbid0IGJlbGlldmUgU0QgaXMgbmVlZGVkIGZvciBNUExTLVRQLiBTdWNoIGRlZmVjdCBp cyBub3QNCj4gPj4gcmVsYXRlZCB0byBNUExTLVRQIGFuZCBzaG91bGQgYmUgaGFuZGxlZCBpbiB0 aGUgc2VydmVyIGxheWVyLCBzdWNoDQo+IGFzDQo+ID4+IGNoYW5naW5nIHRoZSBGRUMgdHlwZSBp biBPVE4sIGV0Yy4NCj4gPj4+Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4gU2hhaHJhbQ0KPiA+ Pj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJl aGFsZg0KPiA+PiBPZiBEYW5pZWwgQ29obg0KPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4 LCAyMDExIDEwOjE1IEFNDQo+ID4+Pj4gVG86IEdyZWcgTWlyc2t5DQo+ID4+Pj4gQ2M6IG1wbHNA aWV0Zi5vcmc7IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IG1zLWRhaWtva3VAa2RkaS5jb207DQo+ IFJhZmkNCj4gPj4gUmFtDQo+ID4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyB0byBk cmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCj4gPj4+Pg0KPiA+Pj4+IFRydWUgZW5vdWdoIGluIGdl bmVyYWwuIEJ1dCBpbiB0aGlzIHBhcnRpY3VsYXIgZXhhbXBsZSwgdGhlcmUgaXMNCj4gPj4gbm90 aGluZyBzdWdnZXN0ZWQgYnkgdGhpcyBkcmFmdCB0aGF0IHJlcXVpcmVzIGh1Z2UgaW1wbGVtZW50 YXRpb24NCj4gPj4gZWZmb3J0cyBvciBwYXJhZGlnbSBjaGFuZ2VzLiBTbyBJIGZhaWwgdG8gc2Vl IHdoeSB3ZSBzaG91bGQgc2V0dGxlDQo+IGZvcg0KPiA+PiBsZXNzIGZ1bmN0aW9uYWxpdHkgdGhh biBpcyBhdmFpbGFibGUgaW4gZXhpc3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzLg0KPiA+Pj4+DQo+ ID4+Pj4gREMNCj4gPj4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ Pj4gRnJvbTogR3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQo+ID4+ Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTowMCBQTQ0KPiA+Pj4+IFRvOiBEYW5p ZWwgQ29obg0KPiA+Pj4+IENjOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgUmFmaSBSYW07IG1z LWRhaWtva3VAa2RkaS5jb207DQo+ID4+IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkw QHp0ZS5jb20uY247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+ID4+IEdlcmFyZG87IG1wbHNA aWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRyYWZ0LXJr aGQtbXBscy10cC1zZC0wMw0KPiA+Pj4+DQo+ID4+Pj4gSGkgRGFuaWVsLA0KPiA+Pj4+IEkgdGhp bmsgdGhhdCB3aGlsZSB3ZSdyZSBidWlsZGluZyBNUExTLVRQIHRvIGJlIHN1aXRlZCBmb3IgdGhl DQo+ID4+Pj4gdHJhbnNwb3J0IHdlIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBw b2ludGVkIG91dCBvbg0KPiBudW1iZXINCj4gPj4+PiBvZiBvY2Nhc2lvbnMsIGlzIG5vdCBCT1Mg bGF5ZXIgYW5kIGRvZXNuJ3QgcHV0IGJpdHMgb24gYSB3aXJlLg0KPiBUaHVzDQo+ID4+IGl0DQo+ ID4+Pj4gaGFzIGNoYXJhY3RlcmlzdGljIHRoYXQgbWFrZXMgaXQgZGlmZmVyZW50IGZyb20gb3Ro ZXIgbGF5ZXJzIG9mIGENCj4gPj4+PiB0cmFuc3BvcnQgbmV0d29yayBhbmQsIEkgdGhpbmssIGFz IHJlc3VsdCBub3QgYWxsIGV4aXN0aW5nDQo+IGNvbmNlcHRzDQo+ID4+IG9mDQo+ID4+Pj4gdHJh bnNwb3J0IGFyZSBhcHBsaWNhYmxlIHRvIHBhY2tldCBsYXllciByZWFsaXplZCBieSBNUExTLVRQ Lg0KPiA+Pj4+DQo+ID4+Pj4gUmVnYXJkcywNCj4gPj4+PiBHcmVnDQo+ID4+Pj4NCj4gPj4+PiBP biBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUxIEFNLCBEYW5pZWwgQ29objxEYW5pZWxDQG9yY2tp dC5jb20+DQo+ID4+IHdyb3RlOg0KPiA+Pj4+PiBIaSBFcmljLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBP bmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgU0QgaW4gVFAgaXMgYmVjYXVzZSBUUCBpcyBz dXBwb3NlZA0KPiA+IHRvDQo+ID4+Pj4+IHByb3ZpZGUgdGhlIHNhbWUgImxvb2sgYW5kIGZlZWwi IG9mIGV4aXN0aW5nIHRyYW5zcG9ydCBuZXR3b3JrcywNCj4gYXMNCj4gPj4+Pj4gc3BlY2lmaWVk IGluIHRoZSBUUCByZXF1aXJlbWVudHMgZG9jdW1lbnQuDQo+ID4+Pj4+IFRyYW5zcG9ydCBuZXR3 b3JrcyB0ZWNobm9sb2dpZXMgaGF2ZSBsb25nIHN1cHBvcnRlZCB0aGUNCj4gZGlzdGluY3Rpb24N Cj4gPj4+Pj4gYmV0d2VlbiAiZGVncmFkZWQiIGFuZCAiIGZhdWx0eSIuIEluIHBhcnRpY3VsYXIs IHByb3RlY3Rpb24NCj4gPj4gdGVjaG5vbG9naWVzDQo+ID4+Pj4+IGluIHVzZSBoYXZlIHRoaXMg ZGlzdGluY3Rpb24gYnVpbHQgaW50byB0aGUgaW5uZXJtb3N0IHJlY2VkZXMgb2YNCj4gPj4gdGhl aXINCj4gPj4+Pj4gcHJvdG9jb2xzLg0KPiA+Pj4+PiBFdmVuIGluIHRoZSBUUCByZXF1aXJlbWVu dHMgZGlkbid0IHNwZWxsIHRoaXMgb3V0LCBJIHRoaW5rIGl0DQo+IHdvdWxkDQo+ID4+IGJlIGEN Cj4gPj4+Pj4gbWlzdGFrZSBub3QgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgeWVhcnMgb2YgZXhwZXJp ZW5jZSBpbiB0cmFuc3BvcnQNCj4gPj4+Pj4gbmV0d29ya3MgT0FNLg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBSZWdhcmRzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBEYW5pZWwNCj4gPj4+Pj4NCj4gPj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTogRXJpYyBPc2Jvcm5lIChlb3Ni b3JuZSkgW21haWx0bzplb3Nib3JuZUBjaXNjby5jb21dDQo+ID4+Pj4+IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDI4LCAyMDExIDExOjEyIEFNDQo+ID4+Pj4+IFRvOiBHcmVnIE1pcnNreTsgRGFuaWVs IENvaG47IFJhZmkgUmFtOyBtcy1kYWlrb2t1QGtkZGkuY29tOw0KPiA+Pj4+PiBtYS55dXhpYUB6 dGUuY29tLmNuOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8NCj4gPiBBbGVz c2FuZHJvDQo+ID4+Pj4+IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4gU3ViamVjdDog UkU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDMNCj4gPj4+Pj4N Cj4gPj4+Pj4gSGkgR3JlZy0NCj4gPj4+Pj4gVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4g U0YgYW5kIFNELiAgQ29udmVydGluZyBTRCBpbnRvIERvd24NCj4gPj4+Pj4gbWVhbnMgdGhhdCBp dCB3aWxsIGJlIGludGVycHJldGVkIGV4YWN0bHkgdGhlIHNhbWUgYXMgU0YsIGFuZCBpZg0KPiA+ PiB0aGF0J3MNCj4gPj4+Pj4gdGhlIGNhc2Ugd2h5IGhhdmUgU0QgYXQgYWxsPyAgSWYgU0QgaXMg bmVjZXNzYXJ5IGl0IG11c3QgYmUNCj4gc29tZWhvdw0KPiA+Pj4+PiBkaWZmZXJlbnQgZnJvbSBT RC4NCj4gPj4+Pj4NCj4gPj4+Pj4gQWxsLQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBIYXZpbmcgc2FpZCB0 aGF0LCBJJ20gbm90IHN1cmUgSSBkaXNhZ3JlZSB3aXRoIEdyZWcuICBJdCBzZWVtcw0KPiB0aGF0 DQo+ID4+Pj4+IHRoaXMgaWRlYSBvZiBwcm9wYWdhdGluZyBzZXJ2ZXIgbGF5ZXIgU0QgdXAgaW50 byBUUCBpcyBiZWluZyBkb25lDQo+ID4+Pj4+IGJlY2F1c2UgdGhlcmUncyBubyBnb29kIHdheSB0 byBkbyBTRCBlbnRpcmVseSB3aXRoaW4gdGhlIFRQDQo+IGxheWVyLg0KPiA+PiBJDQo+ID4+Pj4+ IHN1c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbiB0aGUgVFAg bGF5ZXINCj4gdGhhdA0KPiA+PiBtYWRlDQo+ID4+Pj4+IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3Vs ZG4ndCBoYXZlIHRoZSBhcHByb2FjaCBwcm9wc2VkIGluDQo+ID4+Pj4+IGRyYWZ0LXJraGQtbXBs cy10cC1zZC4gIEFuZCBJIHRoaW5rIHRoYXQgaWYgdGhlIG1vdGl2YXRpb24gZm9yDQo+IHRoaXMN Cj4gPj4+Pj4gZHJhZnQgaXM6DQo+ID4+Pj4+DQo+ID4+Pj4+IC0gd2UgbXVzdCBoYXZlIFNEIGlu IFRQIGJlY2F1c2UgaXQgaXMgcG9zc2libGUgdG8gZG8gaW4gb3RoZXINCj4gPj4+Pj4gdGVjaG5v bG9naWVzDQo+ID4+Pj4+IC0gaXQgaXMgbm90IHBvc3NpYmxlIHRvIFNEIGVudGlyZWx5IHdpdGhp biBUUA0KPiA+Pj4+PiAtIHRoZXJlZm9yZSB3ZSBtdXN0IGdldCBTRCBmcm9tIHNvbWV3aGVyZSBl bHNlDQo+ID4+Pj4+DQo+ID4+Pj4+IGlzIGEgcmVhc29uYWJsZSBvbmUuICBJZiB3ZSBkbyB0aGF0 LCB3aGVyZSBkbyB3ZSBzdG9wPyAgU2hvdWxkIHdlDQo+ID4+Pj4+IHByb3BhZ2F0ZSBpbmZvcm1h dGlvbiBhYm91dCBzaWduYWwgcXVhbGl0eSB1cCB0byBUQ1Agc28gaXQgY2FuDQo+ID4+IGFkanVz dA0KPiA+Pj4+PiBpdHMgd2luZG93cyBhY2NvcmRpbmc/ICAocGxlYXNlIG5vdGUgdGhhdCB0aGlz IGlzIGludGVuZGVkIHRvIGJlDQo+IGENCj4gPj4+Pj4gcmVkdWN0aW8gYWQgYWJzdXJkdW0gcXVl c3Rpb24gYW5kIG5vdCBhIHNlcmlvdXMgb25lLiA6KSApDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4+IGVyaWMNCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+Pj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+IEJlaGFsZg0KPiA+Pj4+PiBPZg0KPiA+Pj4+Pj4g R3JlZyBNaXJza3kNCj4gPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyNywgMjAxMSAyOjA4 IFBNDQo+ID4+Pj4+PiBUbzogRGFuaWVsIENvaG47IHJhZmlyQG9yY2tpdC5jb207IG1zLWRhaWtv a3VAa2RkaS5jb207DQo+ID4+Pj4+PiBtYS55dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45MEB6 dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8NCj4gPj4gQWxlc3NhbmRybw0KPiA+Pj4+Pj4gR2VyYXJk bzsgbXBsc0BpZXRmLm9yZw0KPiA+Pj4+Pj4gU3ViamVjdDogW21wbHNdIENvbW1lbnRzIHRvIGRy YWZ0LXJraGQtbXBscy10cC1zZC0wMw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IERlYXIgQXV0aG9ycyBh bmQgQWxsLA0KPiA+Pj4+Pj4gSSB0aGluayB0aGF0IGl0IGlzIGZ1bmN0aW9uIG9mIHRoZSBQSFkg bGF5ZXIgdG8gZGV0ZWN0IFNEDQo+ID4gY29uZGl0aW9uDQo+ID4+Pj4+IGFuZA0KPiA+Pj4+Pj4g Y29udmVydCBpdCBpbnRvIERvd24gZm9yIHRoZSBNUExTLVRQIExheWVyIDAgKHdoYXQgd2UgcmVm ZXIgYXMNCj4gPj4+Pj4gUGh5c2ljYWwNCj4gPj4+Pj4+IFNlY3Rpb24pLiBJbiBjYXNlIG9mIGFj Y3VtdWxhdGluZyBTRCBvdmVyIExTUCB0aGUgZTJlIFBhY2tldA0KPiBMb3NzDQo+ID4+Pj4+PiBt ZWFzdXJlbWVudCwgaW4gbXkgdmlldywgaXMgYWRkcmVzc2luZyB0aGUgaXNzdWUuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+IEdyZWcNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBs c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1h aWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002AB7E0482578DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhpIE1hYXJ0 ZW48L2ZvbnQ+PGZvbnQgc2l6ZT0yPqOsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkl0IGxvb2tzIGxpa2Ugd2UgYWdyZWUgd2l0aCB0aGUNClNE IHByb3RlY3Rpb24gcmVxdWlyZW1lbnQuIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdXMgaXMgZGV0 ZWN0IGluIHNlcnZlcg0KbGF5ZXIgb3IgZGV0ZWN0IGluIE1QTFMtVFAgbGF5ZXIsIGlzIG15IHVu ZGVyc3RhbmRpbmcgcmlnaHQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwO09uZSBhZHZhbnRhZ2Ugb2YgZGV0ZWN0IGluDQpzZXJ2ZXIgbGF5ZXIg aXMgaXQgY2FuIHdvcmsgY29ycmVjdGx5IGV2ZW4gaW4gdGhlIGNhc2UgdGhhdCBubyBwYWNrZXQg aXMNCnRyYW5zcG9ydGluZy4gVGhpcyBpcyBpbXBvcnRhbnQgdG8gdXNlIFNEIGFzIGEgdHJpZ2dl ciBvZiBwcm90ZWN0aW9uLCBiZWNhdXNlDQp0aGVyZSBpcyBubyBwYWNrZXQgaW4gc3RhbmRieSBw YXRoLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5TdWh1aSAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+TWFhcnRlbiB2aXNzZXJzICZsdDttYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNv bSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrei vP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDctMjkgMTQ6Mjc8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQl Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZx dW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2Zv bnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQt cmtoZC1tcGxzLXRwLXNkLTAzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgZGV0ZWN0aW9uIG9mIGEgRGVncmFkZWQgZGVmZWN0IGFu ZCBhc3NvY2lhdGVkDQpyYWlzaW5nIG9mIGEgRGVncmFkZWQgZmFpbHVyZSBjb25kaXRpb24gaXMg cmVxdWlyZWQgdG8gc2VuZCBhIHdhcm5pbmcgdG8NCnRoZSBtYWludGVuYW5jZSBwZW9wbGUgdGhh dCB0aGUgY29ubmVjdGlvbiBpcyBzdWZmZXJpbmcgZnJvbSBhIHBlcnNpc3RlbnQNCkNJUiBwYWNr ZXQgbG9zcyB3aGljaCBpcyBleGNlZWRpbmcgdGhlIHBhY2tldCBsb3NzIHZhbHVlIGluIHRoZSBT TEEgKGNhc2UNCm9mIHRyYW5zcG9ydCBzZXJ2aWNlIGxheWVyIGNvbm5lY3Rpb24pIG9yIHRoZSB2 YWx1ZSBzZXQgZm9yIGluZnJhc3RydWN0dXJlDQpjb25uZWN0aW9ucyAodHJhbnNwb3J0IHBhdGgg b3Igc2VjdGlvbiBsYXllciBjb25uZWN0aW9ucykuPGJyPg0KPGJyPg0KVGhlIGRldGVjdGlvbiBv ZiBhIERlZ3JhZGVkIGRlZmVjdCBjb25kaXRpb24gYW5kIGFzc29jaWF0ZWQgcmFpc2luZyBvZg0K dGhlIFNpZ25hbCBEZWdyYWRlIChTRCkgY29uc2VxdWVudCBhY3Rpb24gaXMgcmVxdWlyZWQgdG8g cHJldmVudCB0aGF0IGENCnByb3RlY3RlZCBjb25uZWN0aW9uIChTZWN0aW9uLCBMU1AsIFBXLCBQ U01FKSBlbnRlcnMgVW5BdmFpbGFibGUgVGltZSAoVUFUKS4NClRoZSBTRCBzaG91bGQgY2F1c2Ug dGhhdCB0aGUgc2lnbmFsIGlzIHN3aXRjaGVkIHRvIHByb3RlY3Rpb24gc28gdGhhdCBVQVQNCndp bGwgbm90IGJlIGVudGVyZWQgKGRlZmF1bHQgRGVncmFkZWQgZGVmZWN0IGRldGVjdGlvbiB0aW1l IGlzIDcgc2Vjb25kcw0KKHNlZSBHLjc3MTApKS4gRGVncmFkZWQgZGVmZWN0IHRocmVzaG9sZCBp cyBiYXNlZCBvbiBwYWNrZXQgbG9zcyB2YWx1ZQ0KaW4gU0xBLjxicj4NCjxicj4NCkl0IGlzIGEg cHJpbWFyeSByZXF1aXJlbWVudCBpbiB0cmFuc3BvcnQgbmV0d29ya3MgdG8gcHJldmVudCB0aGF0 IGEgdHJhbnNwb3J0DQpzZXJ2aWNlIGxheWVyIGNvbm5lY3Rpb24gKFBXLCBzZXJ2aWNlLUxTUCkg ZW50ZXJzIFVBVC4gQSBjdXN0b21lciB3aWxsDQpiZSB1cHNldCB3aGVuIGhpcy9oZXIgcHJvdGVj dGVkIHNlcnZpY2UgZW50ZXJzIFVBVCBvbiBDSVIgcGFja2V0IGxvc3MgaW4NCnRoZSB3b3JraW5n IGNvbm5lY3Rpb24gYW5kIGRvZXMgbm90IHN3aXRjaCB0byBwcm90ZWN0aW9uIHRvIHJlc3RvcmUg aXQuDQpBIGN1c3RvbWVyIGRvZXMgbm90IGNhcmUgd2hhdCBpcyBjYXVzaW5nIHRoZSB1bmFjY2Vw dGFibGUgcGFja2V0IGxvc3MgKGJpdA0KZXJyb3JzIG9uIGZpYmVyLCBiaXQgZXJyb3JzIGluIGVx dWlwbWVudCwgY29uZ2VzdGlvbiwgcGFja2V0IGJ1ZmZlciBlcnJvcnMsDQpzd2l0Y2ggZmFicmlj IGZhdWx0cywgb3RoZXIpLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTWFhcnRlbjxicj4NCjxi cj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQpPZjxicj4NCiZndDsgSHV1YiB2YW4gSGVsdm9vcnQ8YnI+DQomZ3Q7IFNl bnQ6IDI4IEp1bHkgMjAxMSAyMjo0OTxicj4NCiZndDsgVG86IG1wbHNAaWV0Zi5vcmc8YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNk LTAzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIERhbmllbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsg WW91IHJlcGxpZWQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQ2FuIHByb3Bvc2UgYSBUUC1i YXNlZCBkZXRlY3Rpb24gbWV0aG9kIHRoYXQgY2FuIGRldGVjdCBvbmx5DQpwaHlzaWNhbDxicj4N CiZndDsgJmd0OyBlcnJvcnMsIGkuZS4gd2l0aG91dCBiZWluZyBpbmZsdWVuY2VkIGJ5IG5vbi1w aHlzaWNhbCBjb25kaXRpb25zDQpzdWNoPGJyPg0KJmd0OyBhczxicj4NCiZndDsgJmd0OyBjb25n ZXN0aW9uLCBDUFUgb3ZlcmxvYWQsIGV0Yy4/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIGFzIGEg Y3VzdG9tZXIgSSBzaG91bGQgb25seSBjb21wbGFpbiBhYm91dCBkZWdyYWRlZCBzZXJ2aWNlPGJy Pg0KJmd0OyBpZiBpdCBpcyBjYXVzZWQgYnkgcGh5c2ljYWwgZXJyb3JzLi4uPGJyPg0KJmd0OyBJ IGhhdmUgbmV2ZXIgc2VlbiBTTEFzIHdpdGggdGhpcyByZXN0cmljdGlvbi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgV2Ugc2hvdWxkIHVzZSB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSB0ZWNobm9s b2d5IHRvIGRldGVjdDxicj4NCiZndDsgYW55IGlzc3VlcyB3aXRoIHRoZSB0cmFuc3BvcnQgb2Yg dGhlIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdh cmRzLCBIdXViLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogbXBscy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmPGJyPg0KJmd0OyBP Zjxicj4NCiZndDsgJmd0OyBIdXViIHZhbiBIZWx2b29ydDxicj4NCiZndDsgJmd0OyBTZW50OiBU aHVyc2RheSwgSnVseSAyOCwgMjAxMSA0OjMyIFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBtcGxzQGll dGYub3JnPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJh ZnQtcmtoZC1tcGxzLXRwLXNkLTAzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIERh bmllbCBDb2huPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlvdSB3cm90ZTo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgc2VuZGluZyBpdGVyYXRp dmUgZS1tYWlscyByZWZlcnJpbmcgdG8gZXZlcg0KaGlnaGVyPGJyPg0KJmd0OyBsYXllcjxicj4N CiZndDsgJmd0OyZndDsgc2VydmVzIHRoZSBwb2ludCBvZiB0aGlzIGRpc2N1c3Npb24uPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9LLCAtLS04Jmx0Oy0tLXNuaXBwZWQ8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFBTOiBObyBuZWVkIHRvLCB0aGUgVkMxMiBoYXMgaXRz IG93biBTRCBkZXRlY3Rpb24gY2FwYWJpbGl0aWVzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBTbyB3aHkgZG9uJ3Qgd2UgZGVmaW5lIFNEIChzZXJ2aWNlIGRlZ3JhZGUpIGRlZmVjdCBk ZXRlY3Rpb24NCmNyaXRlcmlhPGJyPg0KJmd0OyAmZ3Q7IGZvciBNUExTLVRQPzxicj4NCiZndDsg Jmd0OyBJbiBzdGVhZCBvZiByZWx5aW5nIG9uIFNEIChzaWduYWwgZGVncmFkZSkgZGVmZWN0IGRl dGVjdCBtZWNoYW5pc21zPGJyPg0KJmd0OyBpbjxicj4NCiZndDsgJmd0OyBvdGhlciB0ZWNobm9s b2dpZXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJSLCBIdXViLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7ICZndDsmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZjxicj4NCiZndDsgJmd0OyBPZjxicj4NCiZndDsgJmd0 OyZndDsgSHV1YiB2YW4gSGVsdm9vcnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDI4LCAyMDExIDQ6MTIgUE08YnI+DQomZ3Q7ICZndDsmZ3Q7IFRvOiBtcGxzQGlldGYu b3JnPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIHRvIGRy YWZ0LXJraGQtbXBscy10cC1zZC0wMzxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7IEFuZCBwcm9wYWdhdGUgdG8gdGhlIFZDMTIgY2FycmllZCBCeSB0aGUgUFc/PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBhbmQuLi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBI dXViPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQWxzbywgaWYgd2Ugd2VyZSB0byBwcm9wYWdhdGUg dG8gVHAsIHdoeSBzdG9wIHRoZXJlPw0KSXQgc2hvdWxkIGJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBw cm9wYWdhdGVkIHRvIFBXIGFzIHdlbGwsIHJpZ2h0Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgU2FtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBTZW50IGZyb20gbXkgaVBob25lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjgsIDIwMTEsIGF0IDI6NDEgUE0sICZxdW90 O1NoYWgsIEhpbWFuc2h1JnF1b3Q7Jmx0O2hzaGFoQGNpZW5hLmNvbSZndDs8YnI+DQomZ3Q7ICZn dDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgSSBhZ3JlZSB3aXRoIEVyaWMsIFNoYWhyYW0gYW5kIGFjdHVhbGx5IHJpY2hhcmQga2FtPGJy Pg0KJmd0OyAoYWxjYXRlbC9sdWNlbnQpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtYWRlIHRoaXMgZXhh Y3QgcG9pbnQgYXQgdGhlIG1pa2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZHVyaW5nIHBy ZXNlbnRhdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgL2hpbWFuc2h1PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0OyBCZWhhbGY8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9mIFNo YWhyYW0gRGF2YXJpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBK dWx5IDI4LCAyMDExIDI6MzAgUE08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVG86IERhbmll bCBDb2huOyBHcmVnIE1pcnNreTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDYzogUmFmaSBS YW07IG1wbHNAaWV0Zi5vcmc7IG1zLWRhaWtva3VAa2RkaS5jb207PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyB5YW5nLmppYW45MEB6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFN1Ympl Y3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhpLDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIGFsc28g ZG9uJ3QgYmVsaWV2ZSBTRCBpcyBuZWVkZWQgZm9yIE1QTFMtVFAuIFN1Y2gNCmRlZmVjdCBpcyBu b3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IHJlbGF0ZWQgdG8gTVBMUy1UUCBhbmQgc2hvdWxkIGJlIGhh bmRsZWQgaW4gdGhlIHNlcnZlciBsYXllciwNCnN1Y2g8YnI+DQomZ3Q7IGFzPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBjaGFuZ2luZyB0aGUgRkVDIHR5cGUgaW4gT1ROLCBldGMuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNoYWhyYW08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KT248YnI+DQomZ3Q7IEJlaGFsZjxicj4NCiZndDsgJmd0 OyZndDsgT2YgRGFuaWVsIENvaG48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1 cnNkYXksIEp1bHkgMjgsIDIwMTEgMTA6MTUgQU08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg VG86IEdyZWcgTWlyc2t5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiBtcGxzQGlldGYu b3JnOyB5YW5nLmppYW45MEB6dGUuY29tLmNuOyBtcy1kYWlrb2t1QGtkZGkuY29tOzxicj4NCiZn dDsgUmFmaTxicj4NCiZndDsgJmd0OyZndDsgUmFtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRy dWUgZW5vdWdoIGluIGdlbmVyYWwuIEJ1dCBpbiB0aGlzIHBhcnRpY3VsYXIgZXhhbXBsZSwNCnRo ZXJlIGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBub3RoaW5nIHN1Z2dlc3RlZCBieSB0aGlzIGRyYWZ0 IHRoYXQgcmVxdWlyZXMgaHVnZSBpbXBsZW1lbnRhdGlvbjxicj4NCiZndDsgJmd0OyZndDsgZWZm b3J0cyBvciBwYXJhZGlnbSBjaGFuZ2VzLiBTbyBJIGZhaWwgdG8gc2VlIHdoeSB3ZSBzaG91bGQN CnNldHRsZTxicj4NCiZndDsgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBsZXNzIGZ1bmN0aW9uYWxp dHkgdGhhbiBpcyBhdmFpbGFibGUgaW4gZXhpc3RpbmcgdHJhbnNwb3J0DQpuZXR3b3Jrcy48YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgREM8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogR3Jl ZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDE6MDAgUE08YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgVG86IERhbmllbCBDb2huPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IENjOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgUmFmaSBSYW07IG1zLWRhaWtva3VAa2Rk aS5jb207PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtYS55dXhpYUB6dGUuY29tLmNuOyB5YW5nLmppYW45 MEB6dGUuY29tLmNuOyBEJ0FsZXNzYW5kcm8NCkFsZXNzYW5kcm88YnI+DQomZ3Q7ICZndDsmZ3Q7 IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU3ViamVj dDogUmU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSGkgRGFuaWVs LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgd2hpbGUgd2UncmUgYnVp bGRpbmcgTVBMUy1UUCB0byBiZSBzdWl0ZWQNCmZvciB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgdHJhbnNwb3J0IHdlIG5lZWQgdG8gcmVtZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2lu dGVkDQpvdXQgb248YnI+DQomZ3Q7IG51bWJlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBv ZiBvY2Nhc2lvbnMsIGlzIG5vdCBCT1MgbGF5ZXIgYW5kIGRvZXNuJ3QgcHV0IGJpdHMNCm9uIGEg d2lyZS48YnI+DQomZ3Q7IFRodXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGhhcyBjaGFyYWN0ZXJpc3RpYyB0aGF0IG1ha2VzIGl0IGRpZmZlcmVudCBm cm9tIG90aGVyDQpsYXllcnMgb2YgYTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3Bv cnQgbmV0d29yayBhbmQsIEkgdGhpbmssIGFzIHJlc3VsdCBub3QgYWxsDQpleGlzdGluZzxicj4N CiZndDsgY29uY2VwdHM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IHRyYW5zcG9ydCBhcmUgYXBwbGljYWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVhbGl6ZWQN CmJ5IE1QTFMtVFAuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEdyZWc8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT24gVGh1LCBK dWwgMjgsIDIwMTEgYXQgOTo1MSBBTSwgRGFuaWVsIENvaG4mbHQ7RGFuaWVsQ0BvcmNraXQuY29t Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBIaSBFcmljLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBvZiB0aGUgcmVhc29ucyB3aHkgd2UgbmVlZCBTRCBpbiBU UCBpcyBiZWNhdXNlDQpUUCBpcyBzdXBwb3NlZDxicj4NCiZndDsgJmd0OyB0bzxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZSB0aGUgc2FtZSAmcXVvdDtsb29rIGFuZCBmZWVs JnF1b3Q7IG9mDQpleGlzdGluZyB0cmFuc3BvcnQgbmV0d29ya3MsPGJyPg0KJmd0OyBhczxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BlY2lmaWVkIGluIHRoZSBUUCByZXF1aXJlbWVu dHMgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUcmFuc3BvcnQgbmV0 d29ya3MgdGVjaG5vbG9naWVzIGhhdmUgbG9uZyBzdXBwb3J0ZWQNCnRoZTxicj4NCiZndDsgZGlz dGluY3Rpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJldHdlZW4gJnF1b3Q7ZGVn cmFkZWQmcXVvdDsgYW5kICZxdW90OyBmYXVsdHkmcXVvdDsuDQpJbiBwYXJ0aWN1bGFyLCBwcm90 ZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0ZWNobm9sb2dpZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGluIHVzZSBoYXZlIHRoaXMgZGlzdGluY3Rpb24gYnVpbHQgaW50byB0aGUg aW5uZXJtb3N0DQpyZWNlZGVzIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGVpcjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdG9jb2xzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgRXZlbiBpbiB0aGUgVFAgcmVxdWlyZW1lbnRzIGRpZG4ndCBzcGVsbCB0aGlzDQpvdXQs IEkgdGhpbmsgaXQ8YnI+DQomZ3Q7IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBiZSBhPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtaXN0YWtlIG5vdCB0byB0YWtlIGFkdmFudGFnZSBv ZiB5ZWFycyBvZiBleHBlcmllbmNlDQppbiB0cmFuc3BvcnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG5ldHdvcmtzIE9BTS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERhbmllbDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBG cm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbV08 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDI4LCAy MDExIDExOjEyIEFNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogR3JlZyBNaXJz a3k7IERhbmllbCBDb2huOyBSYWZpIFJhbTsgbXMtZGFpa29rdUBrZGRpLmNvbTs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0 ZS5jb20uY247DQpEJ0FsZXNzYW5kcm88YnI+DQomZ3Q7ICZndDsgQWxlc3NhbmRybzxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgR2VyYXJkbzsgbXBsc0BpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyB0byBkcmFm dC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBHcmVnLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gU0YgYW5kIFNELiAmbmJzcDtD b252ZXJ0aW5nDQpTRCBpbnRvIERvd248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1l YW5zIHRoYXQgaXQgd2lsbCBiZSBpbnRlcnByZXRlZCBleGFjdGx5IHRoZQ0Kc2FtZSBhcyBTRiwg YW5kIGlmPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGF0J3M8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoZSBjYXNlIHdoeSBoYXZlIFNEIGF0IGFsbD8gJm5ic3A7SWYgU0QgaXMgbmVjZXNz YXJ5DQppdCBtdXN0IGJlPGJyPg0KJmd0OyBzb21laG93PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkaWZmZXJlbnQgZnJvbSBTRC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbGwtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGF2aW5nIHNhaWQgdGhh dCwgSSdtIG5vdCBzdXJlIEkgZGlzYWdyZWUgd2l0aA0KR3JlZy4gJm5ic3A7SXQgc2VlbXM8YnI+ DQomZ3Q7IHRoYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgaWRlYSBvZiBw cm9wYWdhdGluZyBzZXJ2ZXIgbGF5ZXIgU0QgdXAgaW50bw0KVFAgaXMgYmVpbmcgZG9uZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVjYXVzZSB0aGVyZSdzIG5vIGdvb2Qgd2F5IHRv IGRvIFNEIGVudGlyZWx5DQp3aXRoaW4gdGhlIFRQPGJyPg0KJmd0OyBsYXllci48YnI+DQomZ3Q7 ICZndDsmZ3Q7IEk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1c3BlY3QgdGhhdCBp ZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhpbg0KdGhlIFRQIGxheWVyPGJyPg0KJmd0 OyB0aGF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtYWRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBldmVyeW9uZSBoYXBweSwgd2Ugd291bGRuJ3QgaGF2ZSB0aGUgYXBwcm9hY2gNCnByb3Bz ZWQgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LXJraGQtbXBscy10cC1z ZC4gJm5ic3A7QW5kIEkgdGhpbmsgdGhhdA0KaWYgdGhlIG1vdGl2YXRpb24gZm9yPGJyPg0KJmd0 OyB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdCBpczo8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIHdl IG11c3QgaGF2ZSBTRCBpbiBUUCBiZWNhdXNlIGl0IGlzIHBvc3NpYmxlDQp0byBkbyBpbiBvdGhl cjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGVjaG5vbG9naWVzPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBTRCBlbnRpcmVseSB3 aXRoaW4gVFA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gdGhlcmVmb3JlIHdlIG11 c3QgZ2V0IFNEIGZyb20gc29tZXdoZXJlIGVsc2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBhIHJlYXNvbmFibGUgb25lLiAm bmJzcDtJZiB3ZSBkbyB0aGF0LCB3aGVyZQ0KZG8gd2Ugc3RvcD8gJm5ic3A7U2hvdWxkIHdlPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9wYWdhdGUgaW5mb3JtYXRpb24gYWJvdXQg c2lnbmFsIHF1YWxpdHkgdXANCnRvIFRDUCBzbyBpdCBjYW48YnI+DQomZ3Q7ICZndDsmZ3Q7IGFk anVzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXRzIHdpbmRvd3MgYWNjb3JkaW5n PyAmbmJzcDsocGxlYXNlIG5vdGUgdGhhdA0KdGhpcyBpcyBpbnRlbmRlZCB0byBiZTxicj4NCiZn dDsgYTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVkdWN0aW8gYWQgYWJzdXJkdW0g cXVlc3Rpb24gYW5kIG5vdCBhIHNlcmlvdXMNCm9uZS4gOikgKTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXJpYzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCZWhhbGY8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgR3Jl ZyBNaXJza3k8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBXZWRuZXNk YXksIEp1bHkgMjcsIDIwMTEgMjowOCBQTTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRvOiBEYW5pZWwgQ29objsgcmFmaXJAb3Jja2l0LmNvbTsgbXMtZGFpa29rdUBrZGRpLmNv bTs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYS55dXhpYUB6dGUuY29tLmNu OyB5YW5nLmppYW45MEB6dGUuY29tLmNuOw0KRCdBbGVzc2FuZHJvPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBBbGVzc2FuZHJvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgR2VyYXJkbzsg bXBsc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6 IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAtc2QtMDM8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IERlYXIgQXV0aG9ycyBhbmQgQWxsLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IEkgdGhpbmsgdGhhdCBpdCBpcyBmdW5jdGlvbiBvZiB0aGUgUEhZIGxheWVyDQp0byBkZXRlY3Qg U0Q8YnI+DQomZ3Q7ICZndDsgY29uZGl0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXJ0IGl0IGludG8g RG93biBmb3IgdGhlIE1QTFMtVFAgTGF5ZXINCjAgKHdoYXQgd2UgcmVmZXIgYXM8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBoeXNpY2FsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgU2VjdGlvbikuIEluIGNhc2Ugb2YgYWNjdW11bGF0aW5nIFNEIG92ZXINCkxTUCB0 aGUgZTJlIFBhY2tldDxicj4NCiZndDsgTG9zczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG1lYXN1cmVtZW50LCBpbiBteSB2aWV3LCBpcyBhZGRyZXNzaW5nIHRoZQ0KaXNzdWUu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IEdyZWc8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgbXBsc0BpZXRmLm9y Zzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt cGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48 L2Rpdj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJz cDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhp cyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwu Jm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxp Z2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2Fy ZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUm bmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0 byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2Zp bGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25m aWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNw O3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5i c3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJl c3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMm bmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJz cDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNw O0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVz c2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFs Jm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7 c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7Ynkm bmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002AB7E0482578DC_=-- From neil.2.harrison@bt.com Fri Jul 29 00:58:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B3321F884F for ; Fri, 29 Jul 2011 00:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.391 X-Spam-Level: ** X-Spam-Status: No, score=2.391 tagged_above=-999 required=5 tests=[AWL=-4.212, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrTpsOBOg8bG for ; Fri, 29 Jul 2011 00:58:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2D421F8834 for ; Fri, 29 Jul 2011 00:58:25 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 08:58:23 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.65]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 29 Jul 2011 08:58:23 +0100 From: To: , Date: Fri, 29 Jul 2011 08:58:20 +0100 Thread-Topic: =?gb2312?B?W21wbHNdILTwuLQ6IFJlOiAgQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxz?= =?gb2312?B?LXRwLXNkLTAz?= Thread-Index: AcxNwwuoT1NEOZP+Rl+LcM/gs4lSsgAAPCLw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405D43134B@EMV62-UKRD.domain1.systemhost.net> References: <4E322F44.60301@gmail.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E4405D43134BEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] =?gb2312?b?tPC4tDogUmU6ICBDb21tZW50cyB0byBkcmFmdC1ya2hk?= =?gb2312?b?LW1wbHMtdHAtc2QtMDM=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:58:27 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E4405D43134BEMV62UKRDdoma_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VodWksDQoNCllvdSBhc3N1bWUgYSBwZXJtYW5lbnQgYmluZGluZyByZWxhdGlvbnNoaXAgb2Yg Y2xpZW50IGxheWVyIGxpbmsgY29ubmVjdGlvbiAoYW5kIGZyb20gaGVyZSByaWdodCB1cCB0aGUg c3RhY2sgdG8gdGhlIHVsdGltYXRlIFRPUyBtZXNzYWdlL2ZpbGUvc3RyZWFtIGFwcGxpY2F0aW9u cykgdG8gc2VydmVyIGxheWVyIHBhdGguICBXaGF0IGlmIHRoZSBjbGllbnQgbW92ZXMgaXRzIHJv dXRpbmcgKGFueSBvZiB0aGUgaGlnaGVyIGxheWVycyB1cCB0byB0aGUgdWx0aW1hdGUgVE9TIGNh c2UpPyAgV2hvIGFyZSB5b3Ugc2VuZGluZyBGREkgdG8gdGhlbj8NCg0KQlRXIKhDIEkgY29pbmVk IHRoZSB0ZXJtIEZESSB3YXkgYmFjayB0byB0cnkgYW5kIGRpZmZlcmVudGlhdGUgdGhlIGNvLXBz IG1vZGUgY2FzZSBmcm9tIHRoZSBjby1jcyBtb2RlIEFJUyBjYXNlLiAgSW4gdGhlIGNvLWNzIG1v ZGUgQUlTIGlzIHJlcXVpcmVkLi4udGhlcmUgaXMgYSBmaXhlZC9yZXNlcnZlZCByZXNvdXJjZSBw YXJ0aXRpb24gKGllIGEgcmVndWxhcmx5IG9jY3VycmluZyB0aW1lIHNsaWNlIG9mIGZpeGVkIGR1 cmF0aW9uKSB0aGF0IE1VU1QgYmUgZmlsbGVkIHdpdGggc29tZXRoaW5nLiAgVGhlIGFsbC0xcyBB SVMgc2lnbmF0dXJlIGhlcmUgY2FtZSBmcm9tIGhvdyBUVEwgbG9naWMgZmFpbGVkIHRvIGEgKzVW IHN0YXRlIGluIGVhcmx5IFBESCBsYXllciBuZXR3b3Jrcy4gIEkgdXNlZCB0byB0aGluayBGREkv QUlTIHdhcyBhIGdvb2QgaWRlYSBpbiBjby1wcyBtb2RlIHBhY2tldCBuZXR3b3JrcyB1bnRpbCBh IGZldyB5ZWFycyBhZ28uICBJIGhhdmUgc2luY2UgcmVhbGlzZWQgaXRzIGFkZHMgbm8gaW5mb3Jt YXRpb24gdmFsdWUgYW5kIHNpbXBseSBjcmVhdGVzIHNvbWV0aGluZyBlbHNlIHRvIGdlbmVyYXRl IGFuZCBwb3NzaWJseSBnbyB3cm9uZyAod2l0aCByZWFsbHkgYmFkIGNvbnNlcXVlbmNlcyBpZiBp dCBkb2VzKS4gIEZESS9BSVMgaXMgc2hvdWxkIHRoZXJlZm9yZSBub3QgYmUgdXNlZCBpbiBhbnkg cGFja2V0LWJhc2VkIG5ldHdvcmtzLg0KDQpyZWdhcmRzLCBOZWlsDQpUaGlzIGVtYWlsIGNvbnRh aW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRp YWwuDQpJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1l ZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwgbm90ZSB0aGF0 IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0 aW9uDQppcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIGxldCBtZSBrbm93IGltbWVkaWF0ZWx5DQpvbiB0aGUgZW1haWwgYWRkcmVzcyBh Ym92ZS4gVGhhbmsgeW91Lg0KV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJl Y29yZCB5b3VyIGVtYWlscy4NCkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KUmVnaXN0 ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIG5vOiAxODAwMDAwDQoNCg0KDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzdS5odWlAenRl LmNvbS5jbg0KU2VudDogMjkgSnVseSAyMDExIDA4OjMxDQpUbzogaHV1YmF0d29ya0BnbWFpbC5j b20NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbXBsc10gtPC4tDogUmU6IENvbW1lbnRzIHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMw0K DQoNCkhpIEh1dWIsDQoNCj5Qcm9wYWdhdGlvbiB0byBoaWdoZXIgbGF5ZXJzIGlzIHVzZWxlc3Ms IGl0IG9ubHkgYWRkcyBjb21wbGV4aXR5Lg0KSSBkaXNhZ3JlZSB3aXRoIHRoYXQuIFRoZSBhZHZh bnRhZ2VzIG9mIHRoaXMgbWVjaGFuaXNtIGFyZSBzdGF0ZWQgaW4gZHJhZnQtcmtoZC1tcGxzLXRw LXNkIGNoYXB0ZXIgNC4xLCBpdCBpcyBub3QgdXNlbGVzcy4gIFNpbmNlIEZESSBoYXZlIGJlZW4g ZGVmaW5lZCwgIEZFSSBvbmx5IGFkZCBhIHR5cGUgb2YgcGFja2V0LCBGRUkgcHJvcGFnYXRpb24g aXMganVzdCB0aGUgc2FtZSBhcyBGREkgUHJvcGFnYXRpb24sIGl0IGRvZXNuoa90IGFkZCBtdWNo IGNvbXBsZXhpdHkNCg0KU3VodWkNCg0KSHV1YiB2YW4gSGVsdm9vcnQgPGh1dWJhdHdvcmtAZ21h aWwuY29tPg0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoNCjIwMTEtMDctMjkgMTE6 NTUNCsfrtPC4tCC4+A0KaHV1YmF0d29ya0BnbWFpbC5jb20NCg0KDQrK1bz+yMsNCg0KbXBsc0Bp ZXRmLm9yZw0KDQqzrcvNDQoNCtb3zOINCg0KUmU6IFttcGxzXSC08Li0OiBSZTogIENvbW1lbnRz IHRvIGRyYWZ0LXJraGQtbXBscy10cC1zZC0wMw0KDQoNCg0KDQoNCg0KDQpEZWFyIFl1eGlhLA0K DQpZb3Ugd3JvdGU6DQoNCj4gSSB3YW50IHRvIGNsYXJpZnkgc2V2ZXJhbCB0aGluZ3M6DQoNCk9L Lg0KDQo+IDEpIFdoeSBzb21lIHZlbmRvcnMgZG8gdGhlIHJlc2VhcmNoIGFuZCBkZXZlbG9wbWVu dCBvbiBTRCBvZiBNUExTLVRQPyChqqGqDQo+IFJlcXVpcmVtZW50cyBmcm9tIHNlcnZpY2UgcHJv dmlkZXJzLiBTRCBzaG91bGQgYmUgcmVwb3J0ZWQgYW5kIHRyaWdnZXINCj4gdG8gcHJvdGVjdGlv bi4NCg0KVGhlcmUgaXMgbm8gaXNzdWUgd2l0aCB0aGF0IHJlcXVpcmVtZW50Lg0KDQo+IDIpIFdo eSBwcm9wYWdhdGUgc2VydmVyIGxheWVyIGluZm9yIHRvIFRQPyChqqGqIElNTywgU2lnbmFsIGRl Z3JhZGUgb25seQ0KPiByZWZlcnMgdG8gdGhlIGJpdCBlcnJvciBoYXBwZW5pbmcgb24gdGhlIHBo eXNpY2FsIGxheWVyLiBQYWNrZXQgbG9zcw0KPiBpbmR1Y2VkIGJ5IGNvbmdlc3Rpb24gb3IgQ1BV IG92ZXJsb2FkIGlzIG5vdCB0aGUgZmFjdG9yIHRvIFNELiBJbiBvcmRlcg0KPiB0byBhdm9pZCB0 aGVzZSBpbXBhY3RzLCB3ZSB1c2UgdGhlIGluZm9ybWF0aW9uIGRldGVjdGVkIGJ5IHBoeXNpY2Fs IGxheWVyLg0KDQpJIHJlc3BlY3QgeW91ciBvcGluaW9uLg0KDQpIb3dldmVyLCB0aGUgU2lnbmFs L1NlcnZpY2UgZGVncmFkZSBkZXRlY3Rpb24gc2hhbGwgYmUgYmFzZWQgb24gdGhlDQpjaGFyYWN0 ZXJpc3RpYyBpbmZvcm1hdGlvbiBvZiB0aGUgbGF5ZXIgdGhhdCByZXF1aXJlcyBTRCBkZXRlY3Rp b24uDQoNCkFjY29yZGluZyB0byBHLjgxMTAuMSBjbGF1c2UgNi4xLjIgOg0KIlRoZSBNUExTIFRQ IGxheWVyIG5ldHdvcmsgY2hhcmFjdGVyaXN0aWMgaW5mb3JtYXRpb24gaXMgYSBmbG93IG9mDQpN VF9DSSBEYXRhIChNVF9DSV9EKSB0cmFmZmljIHVuaXRzIi4NCg0KVGhlIChTRCkgZGVmZWN0IGRl dGVjdGlvbiBzaG91bGQgbmV2ZXIgcmVseSBvbiBkZWZlY3QgZGV0ZWN0aW9uIG1lY2hhbmlzbXMN CmluIGxvd2VyIGxheWVycyB3aXRoIHBvc3NpYmx5IG9oZXIgdGVjaG5vbG9naWVzLg0KDQpJbiB0 cmFuc3BvcnQgbmV0d29ya3MgY29uZ2VzdGlvbiBzaG91bGQgbm90IG9jY3VyIHVuZGVyIG5vcm1h bCBvcGVyYXRpbmcNCmNvbmRpdGlvbnMgYW5kIG5laXRoZXIgc2hvdWxkIENQVSBvdmVybG9hZC4N Cg0KPiAzKSBXaHkgb25seSBwcm9wYWdhdGUgdG8gVFA/IKGqoaogV2UgdGhpbmsgaXQgaXMgbm90 IG9ubHkgVFAsIGJ1dCBhbHNvIFBXLg0KPiBJbiBmYWN0LCBwcm9wYWdhdGUgdG8gdHJhbnNwb3J0 IHBhdGguIEl0IGlzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuDQoNClByb3BhZ2F0aW9uIHRvIGhp Z2hlciBsYXllcnMgaXMgdXNlbGVzcywgaXQgb25seSBhZGRzIGNvbXBsZXhpdHkuDQoNCg0KPiA0 KSBXaHkgbm90IHByb3BhZ2F0ZSB0byB0aGUgaGlnaGVyIGxheWVyIGFib3ZlIHRoYW5zcG9ydCBw YXRoPyChqqGqIE5vdywNCj4gd2UgYXJlIGRpc2N1c3NpbmcgdGhlIHJlcXVpcmVtZW50IGFuZCBz b2x1dGlvbiByZWZlcnJpbmcgdG8gdHJhbnNwb3J0DQo+IHBhdGguIFdoZXRoZXIgcHJvcGFnYXRl IHRvIGhpZ2hlciBsYXllciBpcyBub3QgdGhlIHRvcGljIHdlIGNhcmUgYWJvdXQuDQoNClRoaXMg Y29udHJhZGljdHMgd2hhdCB5b3Ugd3JpdGUgaW4geW91ciBpdGVtIDMpLg0KDQpCZXN0IHJlZ2Fy ZHMsIEh1dWIuDQoNCg0KDQo+ICpHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPioN Cj4NCj4gMjAxMS0wNy0yOSAwMTowMA0KPg0KPg0KPiDK1bz+yMsNCj4gICAgICAgICAgICAgICAg ICBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNraXQuY29tPg0KPiCzrcvNDQo+ICAgICAgICAgICAg ICAgICAgIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiwgUmFm aSBSYW0NCj4gPFJhZmlSQG9yY2tpdC5jb20+LCBtcy1kYWlrb2t1QGtkZGkuY29tLCBtYS55dXhp YUB6dGUuY29tLmNuLA0KPiB5YW5nLmppYW45MEB6dGUuY29tLmNuLCAiRCdBbGVzc2FuZHJvIEFs ZXNzYW5kcm8gR2VyYXJkbyINCj4gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxp YS5pdD4sIG1wbHNAaWV0Zi5vcmcNCj4g1vfM4g0KPiAgICAgICAgICAgICAgICAgIFJlOiBbbXBs c10gQ29tbWVudHMgdG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+DQo+DQo+DQo+DQo+DQo+ DQo+DQo+DQo+IEhpIERhbmllbCwNCj4gSSB0aGluayB0aGF0IHdoaWxlIHdlJ3JlIGJ1aWxkaW5n IE1QTFMtVFAgdG8gYmUgc3VpdGVkIGZvciB0aGUNCj4gdHJhbnNwb3J0IHdlIG5lZWQgdG8gcmVt ZW1iZXIgdGhhdCBpdCwgYXMgTmVpbCBwb2ludGVkIG91dCBvbiBudW1iZXINCj4gb2Ygb2NjYXNp b25zLCBpcyBub3QgQk9TIGxheWVyIGFuZCBkb2Vzbid0IHB1dCBiaXRzIG9uIGEgd2lyZS4gVGh1 cyBpdA0KPiBoYXMgY2hhcmFjdGVyaXN0aWMgdGhhdCBtYWtlcyBpdCBkaWZmZXJlbnQgZnJvbSBv dGhlciBsYXllcnMgb2YgYQ0KPiB0cmFuc3BvcnQgbmV0d29yayBhbmQsIEkgdGhpbmssIGFzIHJl c3VsdCBub3QgYWxsIGV4aXN0aW5nIGNvbmNlcHRzIG9mDQo+IHRyYW5zcG9ydCBhcmUgYXBwbGlj YWJsZSB0byBwYWNrZXQgbGF5ZXIgcmVhbGl6ZWQgYnkgTVBMUy1UUC4NCj4NCj4gUmVnYXJkcywN Cj4gR3JlZw0KPg0KPiBPbiBUaHUsIEp1bCAyOCwgMjAxMSBhdCA5OjUxIEFNLCBEYW5pZWwgQ29o biA8RGFuaWVsQ0BvcmNraXQuY29tPiB3cm90ZToNCj4gID4gSGkgRXJpYywNCj4gID4NCj4gID4g T25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIFNEIGluIFRQIGlzIGJlY2F1c2UgVFAgaXMg c3VwcG9zZWQgdG8NCj4gID4gcHJvdmlkZSB0aGUgc2FtZSAibG9vayBhbmQgZmVlbCIgb2YgZXhp c3RpbmcgdHJhbnNwb3J0IG5ldHdvcmtzLCBhcw0KPiAgPiBzcGVjaWZpZWQgaW4gdGhlIFRQIHJl cXVpcmVtZW50cyBkb2N1bWVudC4NCj4gID4gVHJhbnNwb3J0IG5ldHdvcmtzIHRlY2hub2xvZ2ll cyBoYXZlIGxvbmcgc3VwcG9ydGVkIHRoZSBkaXN0aW5jdGlvbg0KPiAgPiBiZXR3ZWVuICJkZWdy YWRlZCIgYW5kICIgZmF1bHR5Ii4gSW4gcGFydGljdWxhciwgcHJvdGVjdGlvbiB0ZWNobm9sb2dp ZXMNCj4gID4gaW4gdXNlIGhhdmUgdGhpcyBkaXN0aW5jdGlvbiBidWlsdCBpbnRvIHRoZSBpbm5l cm1vc3QgcmVjZWRlcyBvZiB0aGVpcg0KPiAgPiBwcm90b2NvbHMuDQo+ICA+IEV2ZW4gaW4gdGhl IFRQIHJlcXVpcmVtZW50cyBkaWRuJ3Qgc3BlbGwgdGhpcyBvdXQsIEkgdGhpbmsgaXQgd291bGQg YmUgYQ0KPiAgPiBtaXN0YWtlIG5vdCB0byB0YWtlIGFkdmFudGFnZSBvZiB5ZWFycyBvZiBleHBl cmllbmNlIGluIHRyYW5zcG9ydA0KPiAgPiBuZXR3b3JrcyBPQU0uDQo+ICA+DQo+ICA+IFJlZ2Fy ZHMsDQo+ICA+DQo+ICA+IERhbmllbA0KPiAgPg0KPiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiAgPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5l QGNpc2NvLmNvbV0NCj4gID4gU2VudDogVGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgMTE6MTIgQU0N Cj4gID4gVG86IEdyZWcgTWlyc2t5OyBEYW5pZWwgQ29objsgUmFmaSBSYW07IG1zLWRhaWtva3VA a2RkaS5jb207DQo+ICA+IG1hLnl1eGlhQHp0ZS5jb20uY247IHlhbmcuamlhbjkwQHp0ZS5jb20u Y247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+ICA+IEdlcmFyZG87IG1wbHNAaWV0Zi5vcmcN Cj4gID4gU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyB0byBkcmFmdC1ya2hkLW1wbHMtdHAt c2QtMDMNCj4gID4NCj4gID4gSGkgR3JlZy0NCj4gID4gVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJl dHdlZW4gU0YgYW5kIFNELiBDb252ZXJ0aW5nIFNEIGludG8gRG93bg0KPiAgPiBtZWFucyB0aGF0 IGl0IHdpbGwgYmUgaW50ZXJwcmV0ZWQgZXhhY3RseSB0aGUgc2FtZSBhcyBTRiwgYW5kIGlmIHRo YXQncw0KPiAgPiB0aGUgY2FzZSB3aHkgaGF2ZSBTRCBhdCBhbGw/IElmIFNEIGlzIG5lY2Vzc2Fy eSBpdCBtdXN0IGJlIHNvbWVob3cNCj4gID4gZGlmZmVyZW50IGZyb20gU0QuDQo+ICA+DQo+ICA+ IEFsbC0NCj4gID4NCj4gID4gSGF2aW5nIHNhaWQgdGhhdCwgSSdtIG5vdCBzdXJlIEkgZGlzYWdy ZWUgd2l0aCBHcmVnLiBJdCBzZWVtcyB0aGF0DQo+ICA+IHRoaXMgaWRlYSBvZiBwcm9wYWdhdGlu ZyBzZXJ2ZXIgbGF5ZXIgU0QgdXAgaW50byBUUCBpcyBiZWluZyBkb25lDQo+ICA+IGJlY2F1c2Ug dGhlcmUncyBubyBnb29kIHdheSB0byBkbyBTRCBlbnRpcmVseSB3aXRoaW4gdGhlIFRQIGxheWVy LiBJDQo+ICA+IHN1c3BlY3QgdGhhdCBpZiB0aGVyZSB3ZXJlIGEgd2F5IHRvIGRvIFNEIHdpdGhp biB0aGUgVFAgbGF5ZXIgdGhhdCBtYWRlDQo+ICA+IGV2ZXJ5b25lIGhhcHB5LCB3ZSB3b3VsZG4n dCBoYXZlIHRoZSBhcHByb2FjaCBwcm9wc2VkIGluDQo+ICA+IGRyYWZ0LXJraGQtbXBscy10cC1z ZC4gQW5kIEkgdGhpbmsgdGhhdCBpZiB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcw0KPiAgPiBkcmFm dCBpczoNCj4gID4NCj4gID4gLSB3ZSBtdXN0IGhhdmUgU0QgaW4gVFAgYmVjYXVzZSBpdCBpcyBw b3NzaWJsZSB0byBkbyBpbiBvdGhlcg0KPiAgPiB0ZWNobm9sb2dpZXMNCj4gID4gLSBpdCBpcyBu b3QgcG9zc2libGUgdG8gU0QgZW50aXJlbHkgd2l0aGluIFRQDQo+ICA+IC0gdGhlcmVmb3JlIHdl IG11c3QgZ2V0IFNEIGZyb20gc29tZXdoZXJlIGVsc2UNCj4gID4NCj4gID4gaXMgYSByZWFzb25h YmxlIG9uZS4gSWYgd2UgZG8gdGhhdCwgd2hlcmUgZG8gd2Ugc3RvcD8gU2hvdWxkIHdlDQo+ICA+ IHByb3BhZ2F0ZSBpbmZvcm1hdGlvbiBhYm91dCBzaWduYWwgcXVhbGl0eSB1cCB0byBUQ1Agc28g aXQgY2FuIGFkanVzdA0KPiAgPiBpdHMgd2luZG93cyBhY2NvcmRpbmc/IChwbGVhc2Ugbm90ZSB0 aGF0IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmUgYQ0KPiAgPiByZWR1Y3RpbyBhZCBhYnN1cmR1bSBx dWVzdGlvbiBhbmQgbm90IGEgc2VyaW91cyBvbmUuIDopICkNCj4gID4NCj4gID4NCj4gID4NCj4g ID4gZXJpYw0KPiAgPg0KPiAgPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4+IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+ICA+IE9mDQo+ICA+PiBHcmVnIE1pcnNreQ0KPiAgPj4gU2VudDogV2VkbmVz ZGF5LCBKdWx5IDI3LCAyMDExIDI6MDggUE0NCj4gID4+IFRvOiBEYW5pZWwgQ29objsgcmFmaXJA b3Jja2l0LmNvbTsgbXMtZGFpa29rdUBrZGRpLmNvbTsNCj4gID4+IG1hLnl1eGlhQHp0ZS5jb20u Y247IHlhbmcuamlhbjkwQHp0ZS5jb20uY247IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvDQo+ICA+ PiBHZXJhcmRvOyBtcGxzQGlldGYub3JnDQo+ICA+PiBTdWJqZWN0OiBbbXBsc10gQ29tbWVudHMg dG8gZHJhZnQtcmtoZC1tcGxzLXRwLXNkLTAzDQo+ICA+Pg0KPiAgPj4gRGVhciBBdXRob3JzIGFu ZCBBbGwsDQo+ICA+PiBJIHRoaW5rIHRoYXQgaXQgaXMgZnVuY3Rpb24gb2YgdGhlIFBIWSBsYXll ciB0byBkZXRlY3QgU0QgY29uZGl0aW9uDQo+ICA+IGFuZA0KPiAgPj4gY29udmVydCBpdCBpbnRv IERvd24gZm9yIHRoZSBNUExTLVRQIExheWVyIDAgKHdoYXQgd2UgcmVmZXIgYXMNCj4gID4gUGh5 c2ljYWwNCj4gID4+IFNlY3Rpb24pLiBJbiBjYXNlIG9mIGFjY3VtdWxhdGluZyBTRCBvdmVyIExT UCB0aGUgZTJlIFBhY2tldCBMb3NzDQo+ICA+PiBtZWFzdXJlbWVudCwgaW4gbXkgdmlldywgaXMg YWRkcmVzc2luZyB0aGUgaXNzdWUuDQo+ICA+Pg0KPiAgPj4gUmVnYXJkcywNCj4gID4+IEdyZWcN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1h aWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29u dGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --_000_6D3D47CB84BDE349BC23BF1C94E316E4405D43134BEMV62UKRDdoma_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Suhui,

 

You assume a permanent binding relationship of client layer link connection (an= d from here right up the stack to the ultimate TOS message/file/stream application= s) to server layer path.  What if the client moves its routing (any of the higher layers up to the ultimate TOS case)?  Who are you sending FDI t= o then?

 

BTW =A8C I coined the term FDI way back to try and differentiate the co-ps mode= case from the co-cs mode AIS case.  In the co-cs mode AIS is required...the= re is a fixed/reserved resource partition (ie a regularly occurring time slice= of fixed duration) that MUST be filled with something.  The all-1s AIS signature here came from how TTL logic failed to a +5V state in early PDH l= ayer networks.  I used to think FDI/AIS was a good idea in co-ps mode packe= t networks until a few years ago.  I have since realised its adds no inf= ormation value and simply creates something else to generate and possibly go wrong (= with really bad consequences if it does).  FDI/AIS is should therefore not = be used in any packet-based networks.

 

regards, Neil

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

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of su.hui@zte.com.cn
Sent: 29 July 2011 08:31
To: huubatwork@gmail.com
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] =B4=F0=B8=B4:= Re: Comments to draft-rkhd-mpls-tp-sd-03

 


Hi Huub,

>= Propagation to higher layers is useless, it only= adds complexity.
I disagree with that.= The advantages of this mechanism are stated in draft-rkhd-mpls-tp-sd chapter 4.= 1, it is not useless.  Since FDI have been defined,  FEI only add a = type of packet, FEI propagation is just the same as FDI Propagation, it doesn=A1= =AFt add much complexity

Suhui

Huub van Helvoort <huubatwork@gmail.com>
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org

2011-= 07-29 11:55

=C7=EB=B4=F0=B8=B4 =B8=F8
huubatwork@gmail.com

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

mpls@ietf.org

=B3=AD=CB=CD

=D6=F7=CC=E2

Re: [mpls] =B4=F0=B8=B4= : Re:  Comments to draft-rkhd-mpls-tp-sd-03

 




Dear Yuxia,

You wrote:

> I want to clarify several things:

OK.

> 1) Why some vendors do the research and development on SD of MPLS-= TP? =A1=AA=A1=AA
> Requirements from service providers. SD should be reported and tri= gger
> to protection.

There is no issue with that requirement.

> 2) Why propagate server layer infor to TP? =A1=AA=A1=AA IMO, Signa= l degrade only
> refers to the bit error happening on the physical layer. Packet lo= ss
> induced by congestion or CPU overload is not the factor to SD. In order
> to avoid these impacts, we use the information detected by physica= l layer.

I respect your opinion.

However, the Signal/Service degrade detection shall be based on the
characteristic information of the layer that requires SD detection.

According to G.8110.1 clause 6.1.2 :
"The MPLS TP layer network characteristic information is a flow of=
MT_CI Data (MT_CI_D) traffic units".

The (SD) defect detection should never rely on defect detection mechani= sms
in lower layers with possibly oher technologies.

In transport networks congestion should not occur under normal operatin= g
conditions and neither should CPU overload.

> 3) Why only propagate to TP? =A1=AA=A1=AA We think it is not only = TP, but also PW.
> In fact, propagate to transport path. It is described in the draft= .

Propagation to higher layers is useless, it only adds complexity.<= br>

> 4) Why not propagate to the higher layer above thansport path? =A1= =AA=A1=AA Now,
> we are discussing the requirement and solution referring to transp= ort
> path. Whether propagate to higher layer is not the topic we care about.

This contradicts what you write in your item 3).

Best regards, Huub.



> *Greg Mirsky <gregimirsky@gmail.com>*
>
> 2011-07-29 01:00
>
>                  
> =CA=D5=BC=FE=C8=CB
>                  Dani= el Cohn <DanielC@orckit.com>
> =B3=AD=CB=CD
>                  "Eric Osborne (eosborne)" <eosborne@cisco.com>, Rafi = Ram
> <RafiR@orckit.com>, ms-daikoku@kddi.com, ma.yuxia@zte.com.cn= ,
> yang.jian90@zte.com.cn, "D'Alessandro Alessandro Gerardo"= ;
> <alessandro.dalessandro@telecomitalia.it>, mpls@ietf.org
> =D6=F7=CC=E2
>                  Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>
>
>                  
>
>
>
>
>
> Hi Daniel,
> I think that while we're building MPLS-TP to be suited for the
> transport we need to remember that it, as Neil pointed out on numb= er
> of occasions, is not BOS layer and doesn't put bits on a wire. Thu= s it
> has characteristic that makes it different from other layers of a<= /tt>
> transport network and, I think, as result not all existing concept= s of
> transport are applicable to packet layer realized by MPLS-TP.=
>
> Regards,
> Greg
>
> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn <DanielC@orckit.com> wrote:
>  > Hi Eric,
>  >
>  > One of the reasons why we need SD in TP is because TP i= s supposed to
>  > provide the same "look and feel" of existing transport networks, as
>  > specified in the TP requirements document.
>  > Transport networks technologies have long supported the distinction
>  > between "degraded" and " faulty". I= n particular, protection technologies
>  > in use have this distinction built into the innermost recedes of their
>  > protocols.
>  > Even in the TP requirements didn't spell this out, I th= ink it would be a
>  > mistake not to take advantage of years of experience in transport
>  > networks OAM.
>  >
>  > Regards,
>  >
>  > Daniel
>  >
>  > -----Original Message-----
>  > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.co= m]
>  > Sent: Thursday, July 28, 2011 11:12 AM
>  > To: Greg Mirsky; Daniel Cohn; Rafi Ram; ms-daikoku@kddi.com;
>  > ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessand= ro Alessandro
>  > Gerardo; mpls@ietf.org
>  > Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-0= 3
>  >
>  > Hi Greg-
>  > There is a difference between SF and SD. Converting SD = into Down
>  > means that it will be interpreted exactly the same as S= F, and if that's
>  > the case why have SD at all? If SD is necessary it must= be somehow
>  > different from SD.
>  >
>  > All-
>  >
>  > Having said that, I'm not sure I disagree with Greg. It seems that
>  > this idea of propagating server layer SD up into TP is being done
>  > because there's no good way to do SD entirely within th= e TP layer. I
>  > suspect that if there were a way to do SD within the TP layer that made
>  > everyone happy, we wouldn't have the approach propsed i= n
>  > draft-rkhd-mpls-tp-sd. And I think that if the motivati= on for this
>  > draft is:
>  >
>  > - we must have SD in TP because it is possible to do in other
>  > technologies
>  > - it is not possible to SD entirely within TP
>  > - therefore we must get SD from somewhere else
>  >
>  > is a reasonable one. If we do that, where do we stop? Should we
>  > propagate information about signal quality up to TCP so= it can adjust
>  > its windows according? (please note that this is intend= ed to be a
>  > reductio ad absurdum question and not a serious one. :)= )
>  >
>  >
>  >
>  > eric
>  >
>  >> -----Original Message-----
>  >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
>  > Of
>  >> Greg Mirsky
>  >> Sent: Wednesday, July 27, 2011 2:08 PM
>  >> To: Daniel Cohn; rafir@orckit.com; ms-daikoku@kddi.= com;
>  >> ma.yuxia@zte.com.cn; yang.jian90@zte.com.cn; D'Alessandro Alessandro
>  >> Gerardo; mpls@ietf.org
>  >> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-0= 3
>  >>
>  >> Dear Authors and All,
>  >> I think that it is function of the PHY layer to det= ect SD condition
>  > and
>  >> convert it into Down for the MPLS-TP Layer 0 (what = we refer as
>  > Physical
>  >> Section). In case of accumulating SD over LSP the e= 2e Packet Loss
>  >> measurement, in my view, is addressing the issue.
>  >>
>  >> Regards,
>  >> Greg
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 
------------------------------------------=
--------------
ZTE Information Security =
;Notice: The information contained in this ma=
il is solely property of the sender's or=
ganization. This mail communication is confidentia=
l. Recipients named above are obligated to&nb=
sp;maintain secrecy and are not permitted to&=
nbsp;disclose the contents of this communication&n=
bsp;to others.
This email and any&=
nbsp;files transmitted with it are confidential&nb=
sp;and intended solely for the use of th=
e individual or entity to whom they are&=
nbsp;addressed. If you have received this ema=
il in error please notify the originator =
;of the message. Any views expressed in =
this message are those of the individual =
;sender.
This message has been sca=
nned for viruses and Spam by ZTE Anti-Sp=
am system.
--_000_6D3D47CB84BDE349BC23BF1C94E316E4405D43134BEMV62UKRDdoma_-- From c-sai@bx.jp.nec.com Fri Jul 29 04:08:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1B21F8B7D for ; Fri, 29 Jul 2011 04:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8z2wlIObc1a for ; Fri, 29 Jul 2011 04:08:35 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10C21F8B7A for ; Fri, 29 Jul 2011 04:08:34 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6TB8TCF028536; Fri, 29 Jul 2011 20:08:29 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6TB8T507646; Fri, 29 Jul 2011 20:08:29 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6TB8TSP024475; Fri, 29 Jul 2011 20:08:29 +0900 (JST) Received: from togyo.jp.nec.com ([10.26.220.4] [10.26.220.4]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-120060; Fri, 29 Jul 2011 20:07:42 +0900 Received: from vpcja157 ([10.38.16.157] [10.38.16.157]) by mail.jp.nec.com with ESMTP; Fri, 29 Jul 2011 20:07:42 +0900 From: "Zhenlong Cui" To: "'Eric Gray'" References: <4DFA60E3.90807@pi.nu><791AD3077F94194BB2BDD13565B6295D13B65A62@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B69562@Polydeuces.office.hd><791AD3077F94194BB2BDD13565B6295D13B695EF@Polydeuces.office.hd><60F069FADFF94B1C8594EEB26514F486@nsl.ad.nec.co.jp><5DA50667-3D9E-4E5F-951A-8125326A3B15@gmail.com><9522723C01DA447B94833A2F6F92B95C@nsl.ad.nec.co.jp> <662500A437844CE68AC30DB3B9E41C40@nsl.ad.nec.co.jp> <5FF7D74540DE4099930540A97AA013CE@nsl.ad.nec.co.jp> Date: Fri, 29 Jul 2011 20:07:41 +0900 Message-ID: <5FC4A1E146A940E5AA6F786C4A0A06A0@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcxL2snyIGgv9L4NQty7H08vt4OU1gAkKRTQAAIYSLAADzDIUAAmgkLgAABh89AAJGtisA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 11:08:37 -0000 Hi Eric, I have some questions for DSMAP TLV again. I'm just like to clarify the behavior for the responder, it's not for protocol redundancy :) 1) In sec 2.1 ------ ... IF_Num information for both Requester and Responder interfaces, as well as multipath information is included in the format and MAY be present ... ------ Is the above explanation correct? I think the IF_Num is just for the Responder, as sec 2.1.1. 2) In sec 2.1.1 ----- Ingress IF_Num identifies the ingress port on the target node. A value of 0 indicates that the port is not part of the identifier. Egress IF_Num identifies the ingress port on the target node. A value of 0 indicates that the port is not part of the identifier. ----- I think we have four cases for this TLV as follows. a) Both of the Ingress IF_Num and Egress IF_Num are 0. b) Only Ingress IF_Num is 0. c) Only Engress IF_Num is 0. d) Both of the Ingress IF_Num and Egress IF_Num are not equal to 0. So, I think we need to clarify the behavior for the responder in each case. Following examples just is my considered opinion, could you confirm it? In the case a): Should be processed by Per-node model. In the case b): Should be replied by Egress interface, because the request frame is targeted for Egress interfase. In the case c): Should be replied by Ingress interface, because the request frame is targeted for Ingress interfase. In the case d): Should be discarded, because this frame is wrong. Best, Zhenlong > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Friday, July 29, 2011 2:39 AM > To: Zhenlong Cui; 'Sam Aldrin' > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > Zhenlong, > > I'm not sure what you mean by a different behavior between > node ID and interface ID. There is certainly a minimum > difference associated with what box-local entity it is > that is logically responsible for replying to a message. > > But it seems as if we have converged in this discussion. > > Thanks for taking the time to review and discuss the draft! > > -- > E > > -----Original Message----- > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > Sent: Thursday, July 28, 2011 1:22 PM > To: Eric Gray; 'Sam Aldrin' > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > Importance: High > > Hi, Eric > > Small correction to the mail I just sent: > > ... "protocol redundancy is _not_ what I had in mind when I wrote my original mail." ... > > Best > Zhenlong > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Zhenlong Cui > > Sent: Friday, July 29, 2011 2:04 AM > > To: 'Eric Gray'; 'Sam Aldrin' > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > Hi Eric, > > > > Sorry, protocol redundancy is what I had in mind when I wrote my original mail. > > > > I didn't understand why to define a different behavior for "destination node identifier" and "destination interface > > identifier". > > > > In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface > > MIP case). > > > > I do understand the draft contains no such requirements for the for P2MP case. > > Essentially, the requestor receiving multiple responses which include different return code may not be a problem. > > > > Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here. > > > > > > Thanks for your response. > > > > > -----Original Message----- > > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > > Sent: Thursday, July 28, 2011 12:45 AM > > > To: Zhenlong Cui; 'Sam Aldrin' > > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > > > Not sure why you think the protocol redundancy is necessary, > > > or even a good idea. > > > > > > The DSMAP TLV as defined allows specification of an interface. > > > > > > Asking for a potentially new TLV that will also provide this > > > information in the event that one is unable to handle, read or > > > interpret the DSMAP TLV is pointless. If one cannot use one > > > TLV, the chances are very good that one cannot use a newer one > > > either. > > > > > > -----Original Message----- > > > From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > > Sent: Wednesday, July 27, 2011 10:46 AM > > > To: 'Sam Aldrin'; Eric Gray > > > Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > Importance: High > > > > > > Hi Sam and Eric, > > > > > > Ok, I understand that the issue of unknown TLVs is outside the scope of this document. > > > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > > > 1) Which return code to send when source/destination identifiersare wrong or drop the request. > > > > As said above, it should be dropped, if the source is unknown. > > > > > > OK, I think this is clear now: > > > - A responder will drop requests from an unknown source. > > > - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.) > > > > > > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below. > > > The information collected MUST include identifiers related to the nodes and interfaces composing that route. > > > > > > I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity, > > > therefore they > > > should have the same behavior in the responder. > > > > > > So, my suggestions regarding these issues are as follows. > > > 1) It should be dropped, if the identifier of the DSMAP TLV is wrong. > > > 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new > TLV. > > > > > > > > > Best, > > > Zhenlong > > > > > > > -----Original Message----- > > > > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > > > > Sent: Wednesday, July 27, 2011 6:29 AM > > > > To: Zhenlong Cui > > > > Cc: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > > > > > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft. > > > > Having said that, please find responses inline. > > > > > > > > Sam > > > > > > > > Sent from my iPad > > > > > > > > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" wrote: > > > > > > > > > Hi Eric, > > > > > > > > > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security > > problem > > > > with > > > > > responding. > > > > > On the other hand, you say that you should send a reply when the request includes an unknown TLV. > > > > > > > > > Unknown source is not same as receiving malformed Tlv or unsupported tlv. > > > > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers. > > > > > > > > > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, > does > > > > the responder > > > > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't > it? > > > > If received from unknown source, most vendors drop the packet. > > > > > > > > > > > > > > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV. > > > > > 1) Which return code to send when source/destination identifiers are wrong or drop the request. > > > > As said above, it should be dropped, if the source is unknown. > > > > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request. > > > > Return code 5, dsmap mismatch. This is already defined in rfc4379. > > > > > > > > > > > > > > > Best, > > > > > Zhenlong > > > > > > > > > >> -----Original Message----- > > > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > > >> Sent: Wednesday, July 27, 2011 12:56 AM > > > > >> To: Zhenlong Cui > > > > >> Cc: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > >> > > > > >> Zhenlong, > > > > >> > > > > >> Q-1: See RFC 4379, where these regitry entries are derived from. > > > > >> RFC 4379 sets up a number of registries - including the TLV > > > > >> registry - and defines explicitly how to handle unknown TLV > > > > >> types in section 3, in two very obscure paragraphs on page > > > > >> 10, just before section 3.1. > > > > >> > > > > >> Q-2: "ingress port" is not correct - thanks for spotting this > > > > >> cut-and-paste duplication error. > > > > >> > > > > >> -- > > > > >> Eric > > > > >> > > > > >> -----Original Message----- > > > > >> From: Zhenlong Cui [mailto:c-sai@bx.jp.nec.com] > > > > >> Sent: Tuesday, July 12, 2011 5:20 AM > > > > >> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05 > > > > >> > > > > >> Dear Authors, > > > > >> > > > > >> Two questions regarding the idenfifiers TLV and DSMAP TLV. > > > > >> > > > > >> Question 1: > > > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > > > >>>>> request received?) or drop the packet. > > > > >>>>> > > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > > >>>>> EG > screaming into the night. What does one do when one gets > > > > >>>>> EG > something either not recognizably intended for one, or not > > > > >>>>> EG > from a source that one recognizes? From a security point > > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > > >>>>> EG > the requester in this case (this is an attack vector for > > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > > >>>>> > > > > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the > > requestor(One > > > > >> or > > > > >> more of the TLVs was not understood)? Can this way two answers be generated? > > > > >> > > > > >> > > > > >> Question 2: > > > > >> In section 2.1.1, Is below("ingress port") correct? > > > > >> > > > > >> Egress IF_Num identifies the ingress port on the target node. A > > > > >> value of 0 indicates that the port is not part of the identifier. > > > > >> > > > > >> > > > > >> Best, > > > > >> zhenlong > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > > > > >>> Sent: Monday, June 27, 2011 8:04 PM > > > > >>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > > > > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv > > > > >>> > > > > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379: > > > > >>> > > > > >>> Types are defined below; Length is the length of the Value field in > > > > >>> octets. The Value field depends on the Type; it is zero padded to > > > > >>> align to a 4-octet boundary. > > > > >>> > > > > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV > > is > > > > determined > > > > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow > > your > > > > argument > > > > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information > > > > >> is > > > > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure > > > > >> of > > > > >>> each TLV to extract the value instead of applying the simple rule above. > > > > >>> > > > > >>> > > > > >>> Best, > > > > >>> > > > > >>> Rolf > > > > >>> > > > > >>> > > > > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > >>> > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Eric Gray [mailto:eric.gray@ericsson.com] > > > > >>>> Sent: Montag, 27. Juni 2011 12:42 > > > > >>>> To: Rolf Winter; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > > >>>> cv@tools.ietf.org > > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > > >>>> cv > > > > >>>> > > > > >>>> IMO, that would be a problem with RFC 4379. Perhaps there is > > > > >>>> an errata? > > > > >>>> > > > > >>>> TLVs are meant to follow each other, where the beginning of the > > > > >>>> next TLV is determined by the length of the current TLV - hence > > > > >>>> it is not correct to specify any content as having any value at > > > > >>>> all if it is beyond the end of the TLV. > > > > >>>> > > > > >>>> -----Original Message----- > > > > >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > > > >>>> Sent: Monday, June 27, 2011 5:06 AM > > > > >>>> To: Eric Gray; mpls@ietf.org; draft-ietf-mpls-tp-on-demand- > > > > >>>> cv@tools.ietf.org > > > > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > > >>>> cv > > > > >>>> Importance: High > > > > >>>> > > > > >>>> Hi Eric, > > > > >>>> > > > > >>>> just one more to follow up. You say: > > > > >>>> > > > > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long, > > > > >>>>> EG > even if the last two octets "Must be Zero"). The length of > > > > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made > > > > >>>>> EG > longer by the addition of the 2-word AGI. Nice catch! > > > > >>>> > > > > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be > > > > >>>> included in the length of the sub-TLVs. Why are they included here? > > > > >>>> > > > > >>>> Best, > > > > >>>> > > > > >>>> Rolf > > > > >>>> > > > > >>>> > > > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > > >>>> London W3 6BL | Registered in England 2832014 > > > > >>>> > > > > >>>> > > > > >>>>> > > > > >>>>> EG > Apparently. > > > > >>>>> > > > > >>>>> Which return code to send when identifiers are wrong (Malformed echo > > > > >>>>> request received?) or drop the packet. > > > > >>>>> > > > > >>>>> EG > Drop the packet, probably log the error, possibly run off > > > > >>>>> EG > screaming into the night. What does one do when one gets > > > > >>>>> EG > something either not recognizably intended for one, or not > > > > >>>>> EG > from a source that one recognizes? From a security point > > > > >>>>> EG > of view, we cannot require an implementation to reply to > > > > >>>>> EG > the requester in this case (this is an attack vector for > > > > >>>>> EG > all kinds of hate and discontent). Nor can we forbid it. > > > > >>>>> > > > > >>>>> Using the per-interface model and say the DSMAP TLV did not match the > > > > >>>>> ingress IF identifier, then should this request frame be dropped? > > > > >>>>> Should we reply to the requestor? Can this way two answers be > > > > >>>>> generated? > > > > >>>>> > > > > >>>>> Nit (section 2.1): s/mpls/MPLS/ > > > > >>>>> > > > > >>>>> EG > Thanks. > > > > >>>>> > > > > >>>>> > > > > >>>>> Best, > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> Rolf > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > > >>>>> London W3 6BL | Registered in England 2832014 > > > > >>>>> > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > > > >>>> Behalf > > > > >>>>> Of > > > > >>>>>> Loa Andersson > > > > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01 > > > > >>>>>> To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org; > > > > >>>>> Ross > > > > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team > > > > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand- > > > > >>>> cv > > > > >>>>>> > > > > >>>>>> Working Group. > > > > >>>>>> > > > > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID > > > > >>>>>> after wg last call and published version -04 of the document. > > > > >>>>>> > > > > >>>>>> A document detailing how the comments have been addressed will be > > > > >>>>>> found at: > > > > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls > > > > >>>>>> > > > > >>>>>> This is to start a working group call to verify that all comments > > > > >>>>>> been adequately addressed. Please send your comments to the > > > > >>>>>> mpls working group mailing list before June 24th. > > > > >>>>>> > > > > >>>>>> Loa > > > > >>>>>> on behalf of the MPLS wg co-chairs > > > > >>>>>> > > > > >>>>>> -- > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Loa Andersson email: > > > > >>>>> loa.andersson@ericsson.com > > > > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > > > > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > > > > >>>>>> +46 767 72 92 13 > > > > >>>>>> _______________________________________________ > > > > >>>>>> mpls mailing list > > > > >>>>>> mpls@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > > > > >>>>> _______________________________________________ > > > > >>>>> mpls mailing list > > > > >>>>> mpls@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/mpls > > > > >>> _______________________________________________ > > > > >>> mpls mailing list > > > > >>> mpls@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From hideki.endo.es@hitachi.com Sun Jul 31 23:38:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F56F21F86BB for ; Sun, 31 Jul 2011 23:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIQNWOaXYL71 for ; Sun, 31 Jul 2011 23:38:56 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id F0CBC21F8698 for ; Sun, 31 Jul 2011 23:38:55 -0700 (PDT) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 5066137AC6; Mon, 1 Aug 2011 15:39:00 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id p716cxZi016800; Mon, 1 Aug 2011 15:38:59 +0900 Received: from vshuts2.hitachi.co.jp (vshuts2.hitachi.co.jp [10.201.6.71]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p716cwx0007604; Mon, 1 Aug 2011 15:38:59 +0900 X-AuditID: b753bd60-a467eba0000050a4-32-4e364a02b36d Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 57FBA8B0326; Mon, 1 Aug 2011 15:38:58 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p716cw01220800; Mon, 1 Aug 2011 15:38:58 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Mon, 1 Aug 2011 15:38:43 +0900 References: <4E1C5B89.8070904@ripe.net> Priority: normal Importance: normal X400-Content-Identifier: X4E3649D000000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml281108011538081KP] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 06:38:56 -0000 Hi Yaacov, I put two comments in this list on draft-ietf-mpls-tp-linear-protection as we discussed in Quebec. 1. PSC protocol version field You should infom the reason why you have changed the protocol version from 0 to 1 in the draft-08. This is very important to implement PSC protocol. 2. Priorities of SF-P and FS You said; It is possible to give higher priority of FS than SF-P in the next version of this draft. It's because, in the current draft, it is impossible to keep selecting a protection path securely, even in the case of SF on the protection path. I think it's reasonalble. However, due to this change, a race condition will bother us. It's because an operator has to input the FS command to both ends of connection. You should explore the solution to avoid the race condition. BR, Hideki