From michelg@upperside.fr Tue Jan 3 04:48:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEC421F851C for ; Tue, 3 Jan 2012 04:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAeaa5AU50iz for ; Tue, 3 Jan 2012 04:48:40 -0800 (PST) Received: from smtp28.msg.oleane.net (smtp28.msg.oleane.net [62.161.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1868721F853F for ; Tue, 3 Jan 2012 04:48:38 -0800 (PST) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp28.msg.oleane.net (MSA) with ESMTP id q03CmZPL024315 for ; Tue, 3 Jan 2012 13:48:35 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 3 Jan 2012 13:48:29 +0100 Message-ID: <000001ccca16$01bc2320$05346960$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CCCA1E.6382FC20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczKFdFWs/6+Y/auSRCWHkDBFNmySQ== Content-Language: fr X-PMX-Spam: Probability=11% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.3.123017 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World 2012: The Cloud Impact X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 03 Jan 2012 12:48:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CCCA1E.6382FC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 14th edition of MPLS & Ethernet World Congress will take place from 7 to 10 February 2012 in Paris. The agenda will pay particular attention to Cloud services impact, End-to-end MPLS and Mobile LTE backhaul. The early bird registration deadline has been extended to the 6th of January, 2012. All details at: http://www.uppersideconferences.com/ ------=_NextPart_000_0001_01CCCA1E.6382FC20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 14th edition of = MPLS & Ethernet World Congress will take place from 7 to 10 February = 2012 in Paris.

 

The agenda will pay = particular attention to Cloud services impact, End-to-end MPLS and = Mobile LTE backhaul.

 

The early bird = registration deadline has been extended to the 6th of = January, 2012.

 

All details at: =  http://www.uppersideconferences.com/

 

= ------=_NextPart_000_0001_01CCCA1E.6382FC20-- From jaiharik@ipinfusion.com Tue Jan 3 09:26:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB6621F84BE; Tue, 3 Jan 2012 09:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZdiscBJcO1T; Tue, 3 Jan 2012 09:26:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0855F21F84BC; Tue, 3 Jan 2012 09:26:50 -0800 (PST) Received: by iabz21 with SMTP id z21so10003567iab.31 for ; Tue, 03 Jan 2012 09:26:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.2 with SMTP id zs2mr64477360igb.21.1325611610669; Tue, 03 Jan 2012 09:26:50 -0800 (PST) Received: by 10.231.223.131 with HTTP; Tue, 3 Jan 2012 09:26:50 -0800 (PST) Date: Tue, 3 Jan 2012 22:56:50 +0530 Message-ID: From: Jaihari Kalijanakiraman To: mpls@ietf.org, ccamp@ietf.org Content-Type: multipart/alternative; boundary=e89a8f83a53f2a039f04b5a30157 Cc: Jaihari Kalijanakiraman Subject: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 03 Jan 2012 17:26:51 -0000 --e89a8f83a53f2a039f04b5a30157 Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, Happy new year to all.. I have few queries on the draft.. 1. The draft "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03" talks about configuration of various OAM functions for an LSP or MEG. Shouldnt the MIB have objects to configure these OAM functions as part of MEG configuration? 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for MPLS-TP*"? 3. The ME table has objects for configuring PhbTCValues for OAM packets. As per MPLS-TP OAM framework, the OAM packets has to fate share with the data traffic. If thats the case, what is the use for these objects? 4. The RFC 6427 "*MPLS Fault Management OAM*" talks about server layer MEP sending FM message to the client layer MEPs.. How these server-client relationships be configured or derived? Shouldnt there be objects for identifying the server-client relationships?? *Thanks & Regards,* *Jai Hari M.K. IP Infusion.* --e89a8f83a53f2a039f04b5a30157 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Authors,

Happy new year to all..

=
I have few queries on the draft..

1. The draf= t "draft-ietf-mpls-lsp-ping-mpls-tp-o= am-conf-03" talks about configuration of various OAM functions for= an LSP or MEG. Shouldnt the MIB have objects to configure these OAM functi= ons as part of MEG configuration?

2. Will this MIB be enhanced also to configure "Y.1731 based OAM for MPLS-TP"?

3. The ME= table has objects for configuring PhbTCValues for OAM packets. As per MPLS= -TP OAM framework, the OAM packets has to fate share with the data traffic.= If thats the case, what is the use for these objects?

4. The RFC 6427 "MPLS Fault Management OAM" talks abo= ut server layer MEP sending FM message to the client layer MEPs.. How these= server-client relationships be configured or derived? Shouldnt there be ob= jects for identifying the server-client relationships??

=A0
Thanks & R= egards,
Jai Hari M.K.
IP= Infusion.
--e89a8f83a53f2a039f04b5a30157-- From stbryant@cisco.com Tue Jan 3 10:02:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE621F8498; Tue, 3 Jan 2012 10:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.629 X-Spam-Level: X-Spam-Status: No, score=-110.629 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zqbvBk+3Ttp; Tue, 3 Jan 2012 10:02:21 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DE65321F8485; Tue, 3 Jan 2012 10:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=221; q=dns/txt; s=iport; t=1325613741; x=1326823341; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J64Xg2/VaTZ9zKGRbLUBEnUxj7H/kMgfNkMI3uNlEIE=; b=gEG00f13AL0bMK+ZcbSs+S5fQC6zHxc5oHdI3rDxFeyyptNt0qNJHmkg +MuEokUC37xuPi1iSR2N0iUDIOmIOmPDgYG+BHFW2VohNBETlj88rpLOw B8Y/1gDxQwKzOiYSmdpUKXivDQT/qoLpcOr9PcDeZxekfqAxl2jpDltSa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQIANlBA0+Q/khM/2dsb2JhbABDggWqWYEFgXIBAQEDARIBAgEiQAEFCwshFg8JAwIBAgFFBg0BBwEBHodYl14Bgy4PAZo5jA8ElQKSNA X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="62659280" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 Jan 2012 18:02:19 +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 q03I2Ihv016808; Tue, 3 Jan 2012 18:02:19 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q03I2Hn7006678; Tue, 3 Jan 2012 18:02:18 GMT Message-ID: <4F0342A9.1000301@cisco.com> Date: Tue, 03 Jan 2012 18:02:17 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jaihari Kalijanakiraman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 03 Jan 2012 18:02:22 -0000 > 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for > MPLS-TP*"? > Without prejudice to any decisions on Y.1731 and MPLS-TP. Wouldn't such a MIB be a derivative of the Y.1731 MIB? Stewart From aldrin.ietf@gmail.com Tue Jan 3 10:12:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292D25E8003; Tue, 3 Jan 2012 10:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtG4jSKtguOn; Tue, 3 Jan 2012 10:12:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 983FF5E8002; Tue, 3 Jan 2012 10:12:29 -0800 (PST) Received: by iabz21 with SMTP id z21so10059624iab.31 for ; Tue, 03 Jan 2012 10:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=x2VV0Fm7COQUBFfFFKQyq7JbH7z+FEYyXRLuGT99FgQ=; b=XQpe1m7uV1SgEknmuan0k5ihuTgdUtdthveXZoLIgbgL92rWfS8AT3/nLV5ufX/nJn lrxiUHgmuB2xLADRGNx7tsoVkNWvEdom4NkvAWVhMxKRlAg5uGNFXTTr6Z7jr0qFHJql Or4m39jW9bW+eqAfIZahdJ4XFphNgVOTib8Ng= Received: by 10.50.217.168 with SMTP id oz8mr63448842igc.24.1325614349176; Tue, 03 Jan 2012 10:12:29 -0800 (PST) Received: from [192.168.253.142] ([12.207.18.42]) by mx.google.com with ESMTPS id py9sm90631421igc.2.2012.01.03.10.12.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 10:12:28 -0800 (PST) References: <4F0342A9.1000301@cisco.com> In-Reply-To: <4F0342A9.1000301@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Tue, 3 Jan 2012 10:12:28 -0800 To: "stbryant@cisco.com" Cc: "mpls@ietf.org" , "ccamp@ietf.org" , Jaihari Kalijanakiraman Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 03 Jan 2012 18:12:30 -0000 [speaking as a co-author of the MIB] I echo what Stewart has said. In addition, unless IETF standardizes a specific technology, in this case, Y= .1731 based MPLS TP OAM, it is not prudent to add MIB objects supporting tha= t specific technology. If at all the need arises and the requirement needs t= o be fulfilled, will surely address that. At this point we do not see the ne= ed. Cheers Sam Sent from my iPad On Jan 3, 2012, at 10:02 AM, Stewart Bryant wrote: >=20 >> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for MPL= S-TP*"? >>=20 > Without prejudice to any decisions on Y.1731 and MPLS-TP. >=20 > Wouldn't such a MIB be a derivative of the Y.1731 MIB? >=20 > Stewart > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Tue Jan 3 11:03:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001735E802C; Tue, 3 Jan 2012 11:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taj3KNsSqGrd; Tue, 3 Jan 2012 11:03:49 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2465E802A; Tue, 3 Jan 2012 11:03:49 -0800 (PST) Received: from [10.100.68.169] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 8990E203A14F; Tue, 3 Jan 2012 14:03:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4F0342A9.1000301@cisco.com> Date: Tue, 3 Jan 2012 14:03:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D57BB9E-5415-44CF-A553-A61E9E86E49E@lucidvision.com> References: <4F0342A9.1000301@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1251.1) Cc: mpls@ietf.org, ccamp@ietf.org, Jaihari Kalijanakiraman Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 03 Jan 2012 19:03:50 -0000 Stewart, The question of whether or not to allow "configuration" via the = OAM protocols (or protocol extensions) was something I raised several = months ago in PWE3, although it was also discussed in MPLS as I recall = in Taipei as well. It seems to have arisen again. The conclusions in = PWE3 were to allow configuration of only OAM-related things (i.e.: not = allowing expansion of the protocols for general configuration). = Presumably configuration via MIBs there is still okay. In MPLS I recall = the chairs stating that configuration was a thing reserved for NetConf = when the question of MIB-based configuration was raised for WG MIB = drafts in general (and in particular WRT to the MPLS-TP MIBs). Those = positions seem slightly at odds with each other. And now your answer = now seems inconsistent with those as well. Can we get a single answer from the ADs/IESG on this that = pertains to all MPLS-TP related work? --Tom On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote: >=20 >> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for = MPLS-TP*"? >>=20 > Without prejudice to any decisions on Y.1731 and MPLS-TP. >=20 > Wouldn't such a MIB be a derivative of the Y.1731 MIB? >=20 > Stewart > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From david.i.allan@ericsson.com Tue Jan 3 14:48:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91D11E80FC for ; Tue, 3 Jan 2012 14:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH6Kbq6TmSa8 for ; Tue, 3 Jan 2012 14:48:41 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA7B11E80B3 for ; Tue, 3 Jan 2012 14:48:40 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q03Mmaai004226; Tue, 3 Jan 2012 16:48:38 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.43]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 3 Jan 2012 17:48:36 -0500 From: David Allan I To: Chao Fu , "mpls@ietf.org" Date: Tue, 3 Jan 2012 17:48:35 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlg Message-ID: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@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: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5228FC4BCFEUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 03 Jan 2012 22:48:42 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5228FC4BCFEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave --_000_60C093A41B5E45409A19D42CF7786DFD5228FC4BCFEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI Chao:
 
Some answers in line...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent:= =20 Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,
 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Based=20 Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help m= e to=20 clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
   My doubt: It is said to compare wit= h the=20 locally configured reception period in the definition, but in the Entry=20 criteria, it is compared with it own CC-V-configured transmission period. A= re=20 they same? Just because these two values should be same? For LOC in 5.1.1.1= , it=20 also uses the receiving MEP's configured CC-V reception=20 period.   
   And such Period=20 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it=20 is not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not = one=20 that many felt tearing the service down or forcing a protection switch was = a=20 suitable consequent action. It does not indicate an impairment in informati= on=20 transfer capability, just in the ability to measure it. Hence flag it north= bound=20 and presumably offline action would bring the OAM back into spec. Now as fo= r an=20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

Part of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC=20 6371:
   If a MEP detects a LOC defect that is not caused by a= =20 period
   misconfiguration, it should block all the traffic=20 (including also the
   user data packets) that it receives fro= m the=20 transport path, if this
   consequent action has been enabled = by=20 the operator.
   
   My doubt: Does it mean the period=20 misconfiguration should or might cause the LOC? Will the packets be discard= ed?=20 If not, there should not be LOC. My opinion is that the period misconfigura= tion=20 should not cause LOC.
  

There=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC=20 6371:
   Note that the reception period is the same as the=20 configured transmission rate.
   
   My doubt: Does it mean no need to=20 configure reception period? But many places mention "configured reception=20 period", do they mean the configured transmission rate?  
   
=  A configured reception rate would be = an expected=20 rate which IMO would be optional. Again an artifact of the original expecta= tion=20 of no handshaking between the MEPs in establishing a session periodicity an= d=20 configuration would be the only way such agreement would=20 happen.

 4. In 3.7.3 of RFC=20 6428:
  It will also communicate session DOWN to its session peer u= sing=20 CC messages.
  
  My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

It i= s telling=20 it's peer that it has taken the session into the down state at it's=20 end. 

So=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a tra= nsition=20 from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 = of RFC=20 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt: Does it mean the BFD session will not b= e=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
   Why need P/F here? There is no timer negotiation. I= =20 think here the configured transmission rates should be same on both Engpoin= ts,=20 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC=20 6371.

 P/F is needed as examination of= any other=20 slow start mechanism revealed that we would have to reinvent what we=20 already had. So there is a handshake to get from the default to the desired= =20 rate.

I hope=20 this helps

Dave 


--_000_60C093A41B5E45409A19D42CF7786DFD5228FC4BCFEUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Tue Jan 3 22:56:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696A921F85E0 for ; Tue, 3 Jan 2012 22:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk0+t99TA-XV for ; Tue, 3 Jan 2012 22:56:21 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 5CE4621F85DD for ; Tue, 3 Jan 2012 22:56:20 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1325660137!54575594!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 27481 invoked from network); 4 Jan 2012 06:55:40 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-27.messagelabs.com with SMTP; 4 Jan 2012 06:55:40 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-46-4f03f90c637d Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id EA.D5.08306.C09F30F4; Wed, 4 Jan 2012 09:00:28 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 4 Jan 2012 08:56:16 +0200 From: Alexander Vainshtein To: David Allan I , Chao Fu Date: Wed, 4 Jan 2012 08:55:59 +0200 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgABILIuU= Message-ID: References: , <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@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_A3C5DF08D38B6049839A6F553B331C760115ED9B688CILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTeUgUURzu7dtjNCefm8dzidhGCzrWdjtgKzeiA0yoNQqKwmqcfe0Ozc4u O2NkRAldsFtQ2LlFGmholySFaWK1FZgUVhCZZQcd2JYUZYkd2kxDJkTz1/e+7/t97/eY34+C 5ojJQvGiTEIiKzDGRH1Z/FOPLakPuu0nwlnOF2310Hn9+E2Ds6OqxjAH5n378sCY1xDtNOVV VvbpCuDKUpDLimJAZmVi9RCJczEFIX4Dy5UwVt7jYhyMNSiwHPETUXYxbDBIRA8zO9H6z5er 2HjRSkQu4OFFr4tZuNRtczqnz7A5mNnjshxTZyUu8/GSldj8LC9Y/USSWC+xKszaC9DXtr/J GPxeBjZ+fr1dXwrObw4DisJoGv7RgsIgQYHp+O7TWmMYJFJm1ABwV/wQ1A5lAN/v7jGpLiNy 4brTnUYVp6LF+GrjG5MaBFEWbu0cpdJ6lI0rd1w0qHgkcuKvtx7pNfsMXBc/aNDwTPzgUO/v GBotwS8bSoGKzegYwN1PJ6g4Aa3AdfeqoYqB0lxv6xmdiiHKwB2vynVa0whXNrVBDafhty/7 DZo/DT/ZVQs0fwDv7n6o0+5KwbeOvNJr/kx8rbpdvxekR4fERoeURIeUaHwObj+w36jhifjk iXdQwzZ8uD+mH8pXANMpkMkLQbnI77VPsQWK5RzC8TIRSA4X8NcBbZK6LoHHt8fHAKIAk0Rb dkK32cBukEr8MZBJ6Zg0OrlXoUYUBTwlPlbyrQkVC0SKAUxBJpWuGqtotIct2URCgT/SAuUP 7IOW4VxAmVlRXjPVbv//gcmgI9z7RWbkVaZzPSFBEvqTM4qiGEy71etTQsRLNq7jBfmvrKMS 1DaSlDbmqB5aCrJ+ifdqeisYY8mgZ6oCUgVfsThYq+7Q1oGBgTjIUB49ks5XXUnKhg1Wx5Vg nRJ8qf53sLI5g5KlFCR3pNQWlpvvfai5k7Kl/nlEvP6+v7DlRrBlYnGoOT3+c1851/0s27nq 8rHcpbinq21F1bv2eVflaOF8oQKuetgYbk52rH0W7os9OeprcKZGGqs+1mzLnpz/+IawSIfs zZN2HKx9O2Xu2PhFd1HTm8jyEY7Fw0Y3VZxZ7di2ec+Vc2cZveRjHRNgSGJ/ASwR+hIeBAAA Cc: "mpls@ietf.org" Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Jan 2012 06:56:22 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B688CILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dave, Chao and all, It looks like Chao has discovered multiple technical inconsistencies between= 6371 (Informational) and 6428 (Standards Track) - and that in spite of ju= st two months between their publication dates (09/11 vs. 11/11) This is not completely unexpected for those who have closely followed the MP= LS-TP story, but does not sound well for the beginner readers/new implemente= rs. IMHO and FWIW the least we could do is to file appropriate technical Errata= on 6371 for each of these inconsistencies (starting from ones identified by= Chao and adding new ones as we discover them). It is also worth considering 6371bis (provided we find volunteers for this j= ob:-) in order to align the framework with the MPLS-TP reality. My 2c, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of David Allan= I [david.i.allan@ericsson.com] Sent: Wednesday, January 04, 2012 12:48 AM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao= Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? T= hanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception per= iod in the definition, but in the Entry criteria, it is compared with it own= CC-V-configured transmission period. Are they same? Just because these two= values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable cons= equent action. It does not indicate an impairment in information transfer ca= pability, just in the ability to measure it. Hence flag it northbound and pr= esumably offline action would bring the OAM back into spec. Now as for an im= plementation explicitly modifying the periodicity to an unacceptable value,= how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed aft= er the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. My= opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the per= iodicity of CC/CV to less than 1/3 of the expected rate so that one got an L= OC. Once a lower rate BFD PDU was received that advertised the changed rate,= the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmission= rate. My doubt: Does it mean no need to configure reception period? But many pl= aces mention "configured reception period", do they mean the configured tran= smission rate? A configured reception rate would be an expected rate which IMO would be op= tional. Again an artifact of the original expectation of no handshaking betw= een the MEPs in establishing a session periodicity and configuration would b= e the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC message= s. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session DO= WN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state at= it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are loc= al inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from U= P to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the confi= gured values but use the default values? What the values will be filled in t= he packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the config= ured transmission rates should be same on both Engpoints, otherwise there ar= e Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed tha= t we would have to reinvent what we already had. So there is a handshake to= get from the default to the desired rate. I hope this helps Dave 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_A3C5DF08D38B6049839A6F553B331C760115ED9B688CILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dave, Chao and all,
 
It looks like Chao has discovered multip= le technical inconsistencies between 6371 (Informational)  and 6428 (St= andards Track)  - and that i= n spite of just two months between their publication dates (09/11 vs. 11/11)
 
This is not completely unexpected for th= ose who have closely followed the MPLS-TP story, but does not sound well for the beginner readers/new impleme= nters.
 
IMHO and FWIW the least we could do is t= o file appropriate technical Errata on 6371 for each of these inconsistencie= s (starting from ones identified by Chao= and adding new ones as we discover them).
 
It is also worth considering 6371bis (pr= ovided we find volunteers for this job:-) in order to align the= framework with the MPLS-TP reality.
 
My 2c,
     Sasha
 

From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of David Allan I [david.i.allan@= ericsson.com]
Sent: Wednesday, January 04, 2012 12:48 AM
To: Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:
 
Some answers in line...


From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi all,
 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Based= Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP". = Who can help me to clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect:    If proactive CC-V OAM packets are received with the expected gl= obally
   unique Source MEP identifier but with a transmission period dif= ferent
   than the locally configured reception period, then a CC-V perio= d
   misconfiguration defect is detected.
   o  Entry criteria: A MEP receives a CC-V proactive packet= with the
      expected globally unique Source MEP identifie= r but with a
      transmission period different than its own CC= -V-configured
      transmission period.
   
   My doubt: It is said to compare with the loc= ally configured reception period in the definition, but in the Entry criteri= a, it is compared with it own CC-V-configured transmission period. Are they same? Just because these two values should be= same? For LOC in 5.1.1.1, it also uses the receiving MEP's configured CC-V= reception period.   
   And such Period M= isconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? Why= it is not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not one t= hat many felt tearing the service down or forcing a protection switch was a= suitable consequent action. It does not indicate an impairment in information transfer capability, just in the ability to me= asure it. Hence flag it northbound and presumably offline action would bring= the OAM back into spec. Now as for an implementation explicitly modifying t= he periodicity to an unacceptable value, how the other end reacts is implementation or policy dependant.

Part of this is a consequence of beleiving that some of the BFD= handshaking could be dispensed with at the time 6371 was written. That view= changed after the BFD WG did a thorough review of what became 6428.

 2. In 5.1.2 of RFC 6371:<= br>    If a MEP detects a LOC defect that is not caused by a period    misconfiguration, it should block all the traffic (including al= so the
   user data packets) that it receives from the transport path, if= this
   consequent action has been enabled by the operator.
   
   My doubt: Does it= mean the period misconfiguration should or might cause the LOC? Will the pa= ckets be discarded? If not, there should not be LOC. My opinion is that the= period misconfiguration should not cause LOC.
  

There could be a corner cases if without any warning one en= d reduced the periodicity of CC/CV to less than 1/3 of the expected rate so= that one got an LOC. Once a lower rate BFD PDU was received that advertised the changed rate, the receiver could adapt= vs. staying in a defect state.

  
3. In 5.1.3 of RFC 6371:
   Note that the reception period is the same as the configured tr= ansmission rate.
   
   My doubt: Does it= mean no need to configure reception period? But many places mention "c= onfigured reception period", do they mean the configured transmission r= ate?  
   
 = A configured reception rat= e would be an expected rate which IMO would be optional. Again an artifact of the original expectation of no handshaking between the= MEPs in establishing a session periodicity and configuration would be the o= nly way such agreement would happen.

 4. In 3.7.3 of RFC 6428:<= br>   It will also communicate session DOWN to its session peer using CC me= ssages.
  
  My doubt: <= font style=3D"BACKGROUND-COLOR: #ffff99">Does it mean only notify the pe= er to bring the session DOWN but the local session will not be DOWN? Or we s= hould bring the local session DOWN also? But it is not in the BFD State machine of Figure 7.
 

It is telling it's peer that it has taken the session into t= he down state at it's end. 

So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN= DOWN are local inputs to the state machine that will transition it from UP= to DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a trans= ition from UP to DOWN in coordinated session operation.

 5.  In 3.7.= 1 of RFC 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modif= y the
   periodicity of control message exchange from their default rate= s to
   the desired rates and to set the detect multiplier to 3.
   
   My doubt: = Does it mean the BFD session will= not be started with the configured values but use the default values? What= the values will be filled in the packet? The default ones or the configured values?
   Why need P/F here? There is no timer negotiation. I think here= the configured transmission rates should be same on both Engpoints, otherwi= se there are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.=

 P/F is needed as examination of any other slow&nb= sp;start mechanism revealed that we would have to reinvent what we already h= ad. So there is a handshake to get from the default to the desired rate.

I hope this helps

Dave 


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_A3C5DF08D38B6049839A6F553B331C760115ED9B688CILPTMAIL02e_-- From housley@vigilsec.com Tue Dec 20 10:30: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 B45F121F889A; Tue, 20 Dec 2011 10:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5-o2h4hKs74; Tue, 20 Dec 2011 10:30:06 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6D48F21F8880; Tue, 20 Dec 2011 10:30:06 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EB8F09A47BA; Tue, 20 Dec 2011 13:30:14 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id EoSp4kSzJ-EC; Tue, 20 Dec 2011 13:30:02 -0500 (EST) Received: from [10.0.0.189] (unknown [65.201.148.146]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C257A9A47A2; Tue, 20 Dec 2011 13:30:13 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-329-353726373; protocol="application/pkcs7-signature"; micalg=sha1 From: Russ Housley In-Reply-To: Date: Tue, 20 Dec 2011 13:29:53 -0500 Message-Id: References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> To: Malcolm.BETTS@zte.com.cn X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 04 Jan 2012 05:31:32 -0800 Cc: draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org, mpls@ietf.org, ietf-bounces@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 20 Dec 2011 18:30:07 -0000 --Apple-Mail-329-353726373 Content-Type: multipart/alternative; boundary=Apple-Mail-328-353726342 --Apple-Mail-328-353726342 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My understanding is that there is not a stable agreed G.8113.1 document = to reference. Is my understanding incorrect? Russ On Dec 20, 2011, at 11:09 AM, Malcolm.BETTS@zte.com.cn wrote: > Hi Adrian,=20 >=20 > Thank you for finding time to respond to this request. As you know I = was attending the same 2 week SG 15 meeting and was probably at least as = busy as you given my official role in the meeting.=20 >=20 > I will update draft-betts-itu-oam-ach-code-point early in the new year = based on the results of SG 15 the ended last Friday and your comments. = I will also discussan update of the shepherd write up with Huub.=20 >=20 > Regards,=20 >=20 > Malcolm=20 >=20 >=20 >=20 > "Adrian Farrel" =20 > Sent by: ietf-bounces@ietf.org > 09/12/2011 05:49 AM > Please respond to > adrian@olddog.co.uk >=20 > To > , "'Huub helvoort'" = > cc > mpls@ietf.org, ietf@ietf.org > Subject > Questions about draft-betts-itu-oam-ach-code-point >=20 >=20 >=20 >=20 >=20 > Hi Malcolm and Huub, >=20 > I have squeezed a little time from the current ITU-T meeting to look = at your > draft and write-up. I have also read the email threads on the IETF = discussion > list and the MPLS list. Sorry that this has taken me a week to = process, but your > publication request came at pretty much the worst possible time for = getting me > to do this task. >=20 > I don't like proliferating threads across multiple mailing lists. On = the other > hand it is difficult to ensure that all the constituencies are = present, so I am > perpetuating the cross-posting. >=20 > My review of the document... >=20 > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. = I think > only one of these is real (the spurious space in a citation). The = other nits are > spurious caused by citations wrapping across lines. Could you please = keep a note > of the nit so that you can fix it the next time the draft is respun or = so it can > be captured in an RFC Editor Note at a later stage (you don't have to = post a new > revision to address this now unless you really want to). >=20 > 2. This document requests a code point from a registry that contains = code points > that are used equally for MPLS LSPs and pseudowires. I can't tell from = the I-D > whether it is your intention that your code point would also be = applicable in > both cases. What is your intention? Is this "obvious" from G.8113.1 or = does it > need to be clarified? >=20 >=20 > My review of the write-up and discussions... >=20 > 3. There seems to be quite a feeling on the mailing lists that this = document > should be run through the MPLS working group. The write-up makes a = case for > progressing it as AD sponsored. As far as I can see, the main = assertions to > answer are as follows. Do you have a view on these points before I = make a > decision on what to do? >=20 > a. This is a proposal to use an MPLS code point and so is part of MPLS = by > definition. >=20 > b. The type of network being managed by the OAM described in G.8113.1 = is an MPLS > network. Therefore, this is clearly relevant to the MPLS working . >=20 > Do you object to this going through the MPLS on principle, or were you = just > hoping to save the WG the work? If the latter, and if the WG wants to = look at > the draft, the easiest approach seems to be to redirect the work to = the working > group. >=20 > 4. G.8113.1 is clearly important to understanding to which the code = point is > being put. Thus, an available and stable copy of group. G.8113.1 will = be key to > the last call review of you I-D. Can you make a stable copy available = (for > example, through liaison)? How does the editing work currently in = progress in > the SG15 meeting affect that availability? >=20 > 5. Can you clarify for me why the suggested value has been suggested. = This will > help guide IANA who would normally do their allocation in a "tidy" = way. >=20 > Looking forward to your reply. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-328-353726342 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii My understanding is that there is not a stable agreed G.8113.1 document to reference.  Is my understanding incorrect?

Russ


On Dec 20, 2011, at 11:09 AM, Malcolm.BETTS@zte.com.cn wrote:

Hi Adrian,

Thank you for finding time to respond to this request.  As you know I was attending the same 2 week SG 15 meeting and was probably at least as busy as you given my official role in the meeting.

I will update draft-betts-itu-oam-ach-code-point early in the new year based on  the results of SG 15 the ended last Friday and your comments.  I will also discussan update of the shepherd write up  with Huub.

Regards,

Malcolm



"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: ietf-bounces@ietf.org

09/12/2011 05:49 AM
Please respond to
adrian@olddog.co.uk

To
<draft-betts-itu-oam-ach-code-point@tools.ietf.org>, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
cc
mpls@ietf.org, ietf@ietf.org
Subject
Questions about draft-betts-itu-oam-ach-code-point





Hi Malcolm and Huub,

I have squeezed a little time from the current ITU-T meeting to look at your
draft and write-up. I have also read the email threads on the IETF discussion
list and the MPLS list. Sorry that this has taken me a week to process, but your
publication request came at pretty much the worst possible time for getting me
to do this task.

I don't like proliferating threads across multiple mailing lists. On the other
hand it is difficult to ensure that all the constituencies are present, so I am
perpetuating the cross-posting.

My review of the document...

1. idnits (
http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
only one of these is real (the spurious space in a citation). The other nits are
spurious caused by citations wrapping across lines. Could you please keep a note
of the nit so that you can fix it the next time the draft is respun or so it can
be captured in an RFC Editor Note at a later stage (you don't have to post a new
revision to address this now unless you really want to).

2. This document requests a code point from a registry that contains code points
that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
whether it is your intention that your code point would also be applicable in
both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
need to be clarified?


My review of the write-up and discussions...

3. There seems to be quite a feeling on the mailing lists that this document
should be run through the MPLS working group. The write-up makes a case for
progressing it as AD sponsored. As far as I can see, the main assertions to
answer are as follows. Do you have a view on these points before I make a
decision on what to do?

a. This is a proposal to use an MPLS code point and so is part of MPLS by
definition.

b. The type of network being managed by the OAM described in G.8113.1 is an MPLS
network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you just
hoping to save the WG the work? If the latter, and if the WG wants to look at
the draft, the easiest approach seems to be to redirect the work to the working
group.

4. G.8113.1 is clearly important to understanding to which the code point is
being put. Thus, an available and stable copy of group. G.8113.1 will be key to
the last call review of you I-D. Can you make a stable copy available (for
example, through liaison)? How does the editing work currently in progress in
the SG15 meeting affect that availability?

5. Can you clarify for me why the suggested value has been suggested. This will
help guide IANA who would normally do their allocation in a "tidy" way.

Looking forward to your reply.

Thanks,
Adrian

_______________________________________________
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

--Apple-Mail-328-353726342-- --Apple-Mail-329-353726373 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFezCCBXcw ggRfoAMCAQICEQC/HkHRL9TErrj9ADkdlht/MA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDIy MzAwMDAwMFoXDTEyMDIyMzIzNTk1OVowJTEjMCEGCSqGSIb3DQEJARYUaG91c2xleUB2aWdpbHNl Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw0MgZJ40HVA6CN9jGwA0pudBn 0OQT8816EBgpVzV5X3DTnf8roF3vTPNTfZyuyuaDcZADMhmuZ7blVxN2lVlaHmY+WTJZkcvkFwGU FX2X8lAyBc4I1+J7oSpupF2X8nHW6W7/QvYHD6lxMNssB0/ma/z+5QuE+ypnCEJdbeDbGcipdjXl wXCBYbIRTQmEzec5VuPZAxVtpMehL+dNyG2xc5q9viXm0eYKdlLmegcFpPTa0CwWUpnMhXjAUUl4 1k4GJnyX4INEL7JJnCkhHPJYKbOsoMwtV4/8D8nIJSz7R4VcRQo0Sq+0ENMrwLZai7LIBflq691Q fONyCvWvjg3fAgMBAAGjggIWMIICEjAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUaZfWeIVDGMaHXO9NcMRXavC7TLIwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQC MAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBG BgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5j b21vZG8ubmV0L0NQUzCBpQYDVR0fBIGdMIGaMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNv bS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMEqgSKBGhkRo dHRwOi8vY3JsLmNvbW9kby5uZXQvVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBsBggrBgEFBQcBAQRgMF4wNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL1VUTkFBQUNsaWVudENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMB8GA1UdEQQYMBaBFGhvdXNsZXlAdmlnaWxzZWMuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQAakko5qXz1U0VWMkiuo+bNCY3QEsM55vIqJujM+c3romvLuBVnDk+ZQ/MjyCrrJ8acR3bFCQGn r+9+rV/cxLcZCxFUDuUhucaSxlu82N3/75fi1JFe/ZByJJW80U/oY6xnmNUX8S5tQ/+tmr/JpysO h68BU/qKagXUvDlMVHwSrumBzbG84+/SBMYx4ZB4KgtiL0EaqzKiqLMtjQrGLeSe02A0OoIwRoeY CzGojMjPHjv9GfvBGNUDXDhB+GiiDK+zT9O65KulkuDHB9A14nYQtXihcaAE9bXRPBjDy1zEZ7kf XolnnBjx/eokmW7aXnfL/h+a3pLwvu2Hf7xqbTmBMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC/HkHR L9TErrj9ADkdlht/MAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMTIyMDE4Mjk1NFowIwYJKoZIhvcNAQkEMRYEFO7bCXWtLTFS6BV2b83U xu7KQGCkMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEh MB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0 LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC/HkHRL9TErrj9ADkdlht/MIHXBgsq hkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRAL8eQdEv1MSuuP0AOR2WG38wDQYJKoZIhvcNAQEBBQAE ggEAoBLnvOLfcNQCRINrOywGpmiFG9rGW4CkxKo6qx0IYb2ZAnVYjnBkcyAnh9jpO8ZAWyKExhSs PO9+dSNwNFwvqhHjq4lJqz79kzsQV9eFxz8tCHogLwKe0VrPtmfQ+CB6457hodE7y+dP51CE2N2q xidaQ5dUrzQTlxw2VV6rFqdFofrmIrWRSTBiqUAj9PgRgh9dncKwzftcZ7HcSnt1epguPfk6iDaJ e/kTgDNI/LG1Qm35digt9r3iteWp5YxZrS+UyRTIhRQ55fw0dY6tteOJ77fO9f46Sixli6y9ATQb NrcyqXPyOb4gdpaf+je47oOhehgTAPhOBLb8J5SQnwAAAAAAAA== --Apple-Mail-329-353726373-- From housley@vigilsec.com Wed Dec 21 10:15: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 36B9721F8B0D; Wed, 21 Dec 2011 10:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-KwLATt3W6s; Wed, 21 Dec 2011 10:15:47 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id AADD821F8B10; Wed, 21 Dec 2011 10:15:45 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B032FF24059; Wed, 21 Dec 2011 13:15:47 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 9kDE7HkkArGL; Wed, 21 Dec 2011 13:15:44 -0500 (EST) Received: from [192.168.43.27] (unknown [198.232.60.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8A27FF24054; Wed, 21 Dec 2011 13:15:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-353-439266330 From: Russ Housley In-Reply-To: <73E555AA235F3846B8051DB38C877627131E4EBF@lhreml508-mbs> Date: Wed, 21 Dec 2011 13:15:33 -0500 Message-Id: <46D73BA2-C2BF-4D06-88AD-A17D0E51F764@vigilsec.com> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> , <73E555AA235F3846B8051DB38C877627131E4EBF@lhreml508-mbs> To: Huub helvoort X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 04 Jan 2012 05:31:32 -0800 Cc: draft-betts-itu-oam-ach-code-point@tools.ietf.org, IETF , mpls@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 21 Dec 2011 18:15:48 -0000 --Apple-Mail-353-439266330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Huub: I was not in the meeting, but this does not fit the report of the = meeting that I have received. In particular, the ITU received many = technical comments, and then editing sessions were held to address them. = However the stable version that you reference is not the output of that = editing session. How will those technical comments be addressed? These = outstanding technical comments is the reason that I am asking about = stability. Russ On Dec 21, 2011, at 5:51 AM, Huub helvoort wrote: > Hello Russ, >=20 > You wrote: >=20 > > My understanding is that there is not a stable agreed G.8113.1 = document to reference. > > Is my understanding incorrect? >=20 > Your understanding is partially incorrect: >=20 > The draft recommendation G.8113.1 is stable, there have been no major = technical > changes since it was sent to the IETF (when it still had the draft = name G.tpoam)=20 > attache to liaison: https://datatracker.ietf.org/liaison/983/ > This is also the status I reported when we did discuss this during = IETF82 in Taipei. >=20 > G.8113.1 could not be approved because of the technical reason that = there is > no ACh codepoint assigned.=20 >=20 > Best regards, Huub. >=20 > =3D=3D=3D=3D=3D=3D > On Dec 20, 2011, at 11:09 AM, Malcolm.BETTS@zte.com.cn wrote: >=20 >> Hi Adrian,=20 >>=20 >> Thank you for finding time to respond to this request. As you know I = was attending the same 2 week SG 15 meeting and was probably at least as = busy as you given my official role in the meeting.=20 >>=20 >> I will update draft-betts-itu-oam-ach-code-point early in the new = year based on the results of SG 15 the ended last Friday and your = comments. I will also discussan update of the shepherd write up with = Huub.=20 >>=20 >> Regards,=20 >>=20 >> Malcolm=20 >>=20 >>=20 >>=20 >> "Adrian Farrel" =20 >> Sent by: ietf-bounces@ietf.org >> 09/12/2011 05:49 AM >> Please respond to >> adrian@olddog.co.uk >>=20 >> To >> , "'Huub = helvoort'" >> cc >> mpls@ietf.org, ietf@ietf.org >> Subject >> Questions about draft-betts-itu-oam-ach-code-point >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi Malcolm and Huub, >>=20 >> I have squeezed a little time from the current ITU-T meeting to look = at your >> draft and write-up. I have also read the email threads on the IETF = discussion >> list and the MPLS list. Sorry that this has taken me a week to = process, but your >> publication request came at pretty much the worst possible time for = getting me >> to do this task. >>=20 >> I don't like proliferating threads across multiple mailing lists. On = the other >> hand it is difficult to ensure that all the constituencies are = present, so I am >> perpetuating the cross-posting. >>=20 >> My review of the document... >>=20 >> 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. = I think >> only one of these is real (the spurious space in a citation). The = other nits are >> spurious caused by citations wrapping across lines. Could you please = keep a note >> of the nit so that you can fix it the next time the draft is respun = or so it can >> be captured in an RFC Editor Note at a later stage (you don't have to = post a new >> revision to address this now unless you really want to). >>=20 >> 2. This document requests a code point from a registry that contains = code points >> that are used equally for MPLS LSPs and pseudowires. I can't tell = from the I-D >> whether it is your intention that your code point would also be = applicable in >> both cases. What is your intention? Is this "obvious" from G.8113.1 = or does it >> need to be clarified? >>=20 >>=20 >> My review of the write-up and discussions... >>=20 >> 3. There seems to be quite a feeling on the mailing lists that this = document >> should be run through the MPLS working group. The write-up makes a = case for >> progressing it as AD sponsored. As far as I can see, the main = assertions to >> answer are as follows. Do you have a view on these points before I = make a >> decision on what to do? >>=20 >> a. This is a proposal to use an MPLS code point and so is part of = MPLS by >> definition. >>=20 >> b. The type of network being managed by the OAM described in G.8113.1 = is an MPLS >> network. Therefore, this is clearly relevant to the MPLS working . >>=20 >> Do you object to this going through the MPLS on principle, or were = you just >> hoping to save the WG the work? If the latter, and if the WG wants to = look at >> the draft, the easiest approach seems to be to redirect the work to = the working >> group. >>=20 >> 4. G.8113.1 is clearly important to understanding to which the code = point is >> being put. Thus, an available and stable copy of group. G.8113.1 will = be key to >> the last call review of you I-D. Can you make a stable copy available = (for >> example, through liaison)? How does the editing work currently in = progress in >> the SG15 meeting affect that availability? >>=20 >> 5. Can you clarify for me why the suggested value has been suggested. = This will >> help guide IANA who would normally do their allocation in a "tidy" = way. >>=20 >> Looking forward to your reply. >>=20 >> Thanks, >> Adrian >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 >=20 --Apple-Mail-353-439266330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello = Russ,

You wrote:

> My understanding is = that there is not a stable agreed G.8113.1 document to = reference.
> Is my understanding incorrect?

Your = understanding is partially incorrect:

The draft recommendation = G.8113.1 is stable, there have been no major technical
changes since = it was sent to the IETF (when it still had the draft name G.tpoam) 
attache to = liaison: https://datatracker.ietf.org/liaison/983/
This = is also the status I reported when we did discuss this during IETF82 in = Taipei.

G.8113.1 could not be approved because of the technical = reason that there is
no ACh codepoint assigned. 

Best regards, = Huub.

=3D=3D=3D=3D=3D=3D
On Dec 20, 2011, = at 11:09 AM, Malcolm.BETTS@zte.com.cn wrote:

Hi Adrian, 

Thank you for finding time to respond to = this request.  As you know I was attending the same 2 week SG 15 = meeting and was probably at least as busy as you given my official role = in the meeting. 

I will update = draft-betts-itu-oam-ach-code-point early in the new year based on =  the results of SG 15 the ended last Friday and your comments. =  I will also discussan update of the shepherd write up  with = Huub. 

Regards, 

Malcolm 



"Adrian Farrel" <adrian@olddog.co.uk> 
Sent by: ietf-bounces@ietf.org
09/12/2011 05:49 AM
Please respond to
adrian@olddog.co.uk
To
<draft-betts-itu-oam-ach-code-point@tools.ietf.org>= ;, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
cc
mpls@ietf.org, ietf@ietf.org
Subject
Questions about = draft-betts-itu-oam-ach-code-point





Hi Malcolm and Huub,

I = have squeezed a little time from the current ITU-T meeting to look at = your
draft and write-up. I have also read the email threads on the = IETF discussion
list and the MPLS list. Sorry that this has taken me = a week to process, but your
publication request came at pretty much = the worst possible time for getting me
to do this task.

I = don't like proliferating threads across multiple mailing lists. On the = other
hand it is difficult to ensure that all the constituencies are = present, so I am
perpetuating the cross-posting.

My review of = the document...

1. idnits (
http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
only one of these is = real (the spurious space in a citation). The other nits are
spurious = caused by citations wrapping across lines. Could you please keep a = note
of the nit so that you can fix it the next time the draft is = respun or so it can
be captured in an RFC Editor Note at a later = stage (you don't have to post a new
revision to address this now = unless you really want to).

2. This document requests a code = point from a registry that contains code points
that are used equally = for MPLS LSPs and pseudowires. I can't tell from the I-D
whether it = is your intention that your code point would also be applicable = in
both cases. What is your intention? Is this "obvious" from = G.8113.1 or does it
need to be clarified?


My review of the = write-up and discussions...

3. There seems to be quite a feeling = on the mailing lists that this document
should be run through the = MPLS working group. The write-up makes a case for
progressing it as = AD sponsored. As far as I can see, the main assertions to
answer are = as follows. Do you have a view on these points before I make = a
decision on what to do?

a. This is a proposal to use an MPLS = code point and so is part of MPLS by
definition.

b. The type = of network being managed by the OAM described in G.8113.1 is an = MPLS
network. Therefore, this is clearly relevant to the MPLS working = .

Do you object to this going through the MPLS on principle, or = were you just
hoping to save the WG the work? If the latter, and if = the WG wants to look at
the draft, the easiest approach seems to be = to redirect the work to the working
group.

4. G.8113.1 is = clearly important to understanding to which the code point is
being = put. Thus, an available and stable copy of group. G.8113.1 will be key = to
the last call review of you I-D. Can you make a stable copy = available (for
example, through liaison)? How does the editing work = currently in progress in
the SG15 meeting affect that = availability?

5. Can you clarify for me why the suggested value = has been suggested. This will
help guide IANA who would normally do = their allocation in a "tidy" way.

Looking forward to your = reply.

Thanks,
Adrian

___________________________________= ____________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf<= font = size=3D"2">


_______________________________________= ________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/m= ailman/listinfo/ietf



= --Apple-Mail-353-439266330-- From loa@pi.nu Wed Jan 4 05:44:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982AC21F8746 for ; Wed, 4 Jan 2012 05:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3geMhzapWjL for ; Wed, 4 Jan 2012 05:44:14 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0672D21F8742 for ; Wed, 4 Jan 2012 05:44:13 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 9F6CA2A8003; Wed, 4 Jan 2012 14:44:11 +0100 (CET) Message-ID: <4F0457A4.9060403@pi.nu> Date: Wed, 04 Jan 2012 14:44:04 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <4EE1EE2A.5090803@pi.nu> In-Reply-To: <4EE1EE2A.5090803@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , draft-beckhaus-ldp-dod@tools.ietf.org Subject: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-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, 04 Jan 2012 13:44:14 -0000 Working Group, this poll has ended, and we have a new working group document. Could the authors please re-publish the document as draft-ietf-mpls-ldp-dod-00. Without any other changes than the administrative information and the file name. Loa for the mpls wg chairs On 2011-12-09 12:16, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-beckhaus-ldp-dod-01 an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Dec 23, 2011! > > Loa > for the mpls wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From yaakov_s@rad.com Wed Jan 4 08:01:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804CC21F8784 for ; Wed, 4 Jan 2012 08:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.558 X-Spam-Level: X-Spam-Status: No, score=-101.558 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj3HaHre2gnG for ; Wed, 4 Jan 2012 08:01:19 -0800 (PST) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 53EB821F876D for ; Wed, 4 Jan 2012 08:01:15 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 4 Jan 2012 17:51:58 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Wed, 4 Jan 2012 18:01:05 +0200 From: Yaakov Stein To: "draft-beckhaus-ldp-dod@tools.ietf.org" Thread-Topic: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-01 Thread-Index: AQHMyub8TtmstZJpF065wRL86RG+OpX8Wktg Date: Wed, 4 Jan 2012 16:01:04 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9042C53B5@EXRAD5.ad.rad.co.il> References: <4EE1EE2A.5090803@pi.nu> <4F0457A4.9060403@pi.nu> In-Reply-To: <4F0457A4.9060403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-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, 04 Jan 2012 16:01:19 -0000 Draft authors,=20 Now that this draft has become a WG item, I really would like to hear how you intend addressing the security issues. Let's start with a simple one. As I have said in earlier emails,=20 devices in the access network are unguarded, and it is relatively easy to subvert one or to concatenate new devices. In particular, it is not hard to reprogram a L2 device or insert a small device somewhere that transparently passes everything exc= ept LDP KeepAlives. Presumably I would only intermittently trigger this discarding of KeepAlive= s=20 and leave it on for only a minute or so in order to make the problem hard to diagnose and localize. When the LDP peers detect the loss they terminate the session=20 and discard all label mappings, thus producing a total denial of service. I am interested in hearing how you would deal with this scenario. Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, January 04, 2012 15:44 To: mpls@ietf.org Cc: Ross Callon; draft-beckhaus-ldp-dod@tools.ietf.org Subject: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-01 Working Group, this poll has ended, and we have a new working group document. Could the authors please re-publish the document as draft-ietf-mpls-ldp-dod-00. Without any other changes than the administrative information and the file name. Loa for the mpls wg chairs On 2011-12-09 12:16, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > draft-beckhaus-ldp-dod-01 an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Dec 23, 2011! > > Loa > for the mpls wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Wed Jan 4 11:32:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2826411E8097 for ; Wed, 4 Jan 2012 11:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.787 X-Spam-Level: X-Spam-Status: No, score=-106.787 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lol46BMlVStD for ; Wed, 4 Jan 2012 11:32:23 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1EACC11E808F for ; Wed, 4 Jan 2012 11:32:23 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTwSpNqsOBZ+qgWXA3RcFsgpdSiQAEaEr@postini.com; Wed, 04 Jan 2012 11:32:23 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Jan 2012 11:31:06 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 11:31:05 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 4 Jan 2012 14:31:04 -0500 From: Ross Callon To: "adrian@olddog.co.uk" Date: Wed, 4 Jan 2012 14:31:00 -0500 Thread-Topic: Request for publication of draft-ietf-mpls-tp-oam-analysis-07.txt Thread-Index: AczLF0lIeUJ0DYHaSI6j87/KK4yueA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Request for publication of draft-ietf-mpls-tp-oam-analysis-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: Wed, 04 Jan 2012 19:32:24 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MPLS WG requests publication of draft-ietf-mpls-tp-oam-analysis-07.txt.= A PROTO writeup is attached. Thanks, Ross (as MPLS WG co-chair) --_000_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The MPLS WG requests publication of draft-ietf-mpls-tp-oam-analysis-07= .txt. A PROTO writeup is attached.
 
Thanks, Ross
(as MPLS WG co-chair)
 
 
--_000_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Proto Writeup for draft-ietf-mpls-tp-oam-analysis-07.docx" Content-Description: Proto Writeup for draft-ietf-mpls-tp-oam-analysis-07.docx Content-Disposition: attachment; filename="Proto Writeup for draft-ietf-mpls-tp-oam-analysis-07.docx"; size=16198; creation-date="Tue, 03 Jan 2012 04:31:51 GMT"; modification-date="Tue, 03 Jan 2012 04:36:27 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDd/JU3ZgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtuwjAQvFfqP0S+Vomhh6qqCBz6OLZIpR9g7A1Y9Uv28vr7bgJEVQtBKuUSKVnvzOzsxIPR2pps CTFp70rWL3osAye90m5Wso/JS37PsoTCKWG8g5JtILHR8PpqMNkESBl1u1SyOWJ44DzJOViRCh/A UaXy0Qqk1zjjQchPMQN+2+vdcekdgsMcaww2HDxBJRYGs+c1fd4qiWASyx63B2uukokQjJYCSSlf OvWDJd8xFNTZnElzHdINyWD8IENdOU6w63sja6JWkI1FxFdhSQZf+ai48nJhaYaiG+aATl9VWkLb X6OF6CWkRJ5bU7QVK7Tb6z+qI+HGQPp/FVvcLnrSOY4+JE57OZsf6s0rUDlZESCihnZ1x0cHRLLs EsPvkLvGb1KAlHfgzbN/tgcNzEnKin6JiZgaOJvvV/Ja6JMiVjB9v5j738C7hLT5kz7+wYz9dVF3 H0gdb+634RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYz sKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdh b9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687 HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKySzWrDMBCE74W+g9h7LTv9oYTIuZRArq37AIq9/qGyJLSbtn77CkNShwb34otgRmjmk7Sb7Xdv xCcG6pxVkCUpCLSlqzrbKHgvdnfPIIi1rbRxFhUMSLDNb282r2g0x0PUdp5ETLGkoGX2aympbLHX lDiPNu7ULvSaowyN9Lr80A3KVZo+yTDNgPwiU+wrBWFf3YMoBh+b/892dd2V+OLKY4+Wr1TILzy8 IXO8HMVYHRpkBRMzibQgr4OslgShPxQnZw4hWxSBBxM/8/wMNOq5+scl6zmOCP62j1KOazbH8LAk Q+0sF/pgJhxn6wQhLwY9/wEAAP//AwBQSwMEFAAGAAgAAAAhALjX5QF7FgAA95gBABEAAAB3b3Jk L2RvY3VtZW50LnhtbOxdaW/bSBL9vsD+h4Y+TQAfkizLB9YOvDlmAkyygZ1F9muLalnckGxuNylF +fX7qknKbN0+J5FqgIFiiiKbze46Xr2q+sfr73EkRsrYUCcXjdZBsyFUEuh+mNxeNP795f3+aUPY TCZ9GelEXTQmyjZeX/79b/8Yn/d1kMcqyQQukdjzEb4dZll6fnhog6GKpT3QqUrw5UCbWGb409we xtJ8y9P9QMepzMJeGIXZ5LDdbHYb5WX0RSM3yXl5if04DIy2epDRT871YBAGqvyofmE2uW/xy7fl kN0dD42KMAad2GGY2upq8UOvhkccVhcZrXqIURxV543TTe7WN3KM9xFHxbDH2vRTowNlLY6+Lb6c XrHVXHXvcgLpEtNfbDIE/57VSGIZJtPL0OqYef/Tl3eAl3dY3PuQLnX3IJiLS6ylnu5P6DMV43Os xf71RaPZfHPS6b5/16gOfcaLnjv4Vg1kHmXz33yuHXJX/mzcx002iRQuOZLRReMPJWmltxqH9F0m e7b8rE6I1CCjAaTaXjTOWt3piQtPaJ0etVef0T7pnK4+46jb7aw+o3N82lx9xnHnbM1Iu53WmpGe HLXXjPS03VkzUkzYmpG2ms2TNUNtNc/O1oy11Tprrhlsq43hrp611tFJZ91wO91jN9zDu9ViioVl f1RLol1exP54Y2ePRTK5xVrDz93P8JkWP3eLs7xUoCNtql823X/FyDe5R3VpDJAk6rlNZYCdmRpl lRmpxuVnozMtaAhZMRC3LYzWg3eG7ppNUpxvUxVFN5k0WXHr5xjf5VcTZipPNxrLu6T/fCNZPFMC imt2omiGnIDypBFN4WPWAb2LvpmZh/qUb/Lmx+czq4uuKqE5Q5UN9uM0svtZuq9lvC8TGU1saPeb J949aTm61VA9ZE2GVoe8564O3lcKs6StqRWWtIUy9nRta4GkJVEGbY1FF4VkbbQhrss/rvMIB2Se 6VJIlFL1vU4yEsLSBmF40XijcxMqIz6pMf1SSZtd2VBeNL6EsbJ0WFzrWMKoGZ8PrxI7/5MAdkD9 Ks5weBKBXdMFuPtKGWN+oceCEFoiXcVvrQP5SnwdahFakQ2VqMxzcTNU6VCZvpPA2RBfV87Ga/GH dCez4CosVqwVZ8p6u4dNRBj33oz8pSYiC67SONoSwSXcf/PSKgWOomFbRRNh1ChUY9WHXIP0KgEW oQdOzrHsYtkFue1AhZ/dvWXZtY2yy5NAWImz7v+tkXHd+98yi/SyMic3mYc75GHLZmGJXQ6wf0+E iUgB/oRBHkmzB/Mb7hEsdAAiFh89FYVqpArl5s3hJhACowUENS803BmXnXdmHojLsuJixXVutkxk X5aehCdzl+jvXdNb8LMM4nkTBxoBuh9LQ8E9gWgHgUsf3t387r5K814UBi7y+9qH91l5rfDLOKhI EWMfVHq2oOJuKC/eb7zfKNRSACF/ZRB/N/Ybwkq1SPUvBsZeXmtrxRugqzqpAkaVG09O6ZKA0YH4 Q4khYkZkGzhDINY2w18BUdcQAa/A2T0Bx1cMlIpmjKupDUnR8LPu0VX7uPELT6Odfbxf91mWABjZ UGbuTU+XxwNMw4P7m4ZMjaiz5dheZHtxfP6k1IhN7EXehLwJKzbvQoj1+ZigO2NEbhmotsSMIH5S 71XFN5oykGBM9oXsq//lMlNlnF/0dDYUA6Nj8U1NxNfffeNhCUC3zQG2WMU9sCFmbM2FccZdwym9 OWGV5kNqzFybAxkZF2HK7fkmCQCQJWXIbynltmCueRJoB5UTgJ5NpmDXFNPUfkl0sg8bptThr8HL BvtjMUF7k3ncZjtnKEdqkznYtbXkzQkbOWzkFHk5y3hPTM/nvKIxGzkIBz8JYOoyP5OJJ4SX2Hm7 ppgCnQTKJFbIns7LMJFKgd6A2tqjGCH9s0jTKHI4yPJBPMmby00UGrNcmeU65TYwUQhlDAoT4D6e LO2zMpN3RzBndtBJd7FXtbB0B/IuFPIylKGKSqr/WrBWgoCg0jwMGzNsXC/LAG3x/JUa2Apk+irT V6tiKs+/335t+uonLSrf80B8GXr+JJ6ssm+3g2QKwmWYFHUfUWBRzlFqt45zOqWaEtXYmWnqe6ZQ QWikatUgCo7x9JQ87YND0qdkW5RnS1GJEim1tExiqqtJlOVA4QJ0QhDlLpkJYZkIVYtEAB709ETm qq5kfLFxyMbhT2kcMleVuaorJRdzVan6KeOG64k94KoGr1YRNQhSmxqgRUiDGB1Tu8WzRzfxbFl4 sfBi4TUtJ+qm4kmCtxz0cFmqC7ni20wlS5TqM2F+vmC5iLWZJlo4jqKs1aYq4vYaCRmGIiOoWx5k 8Jn37h8aYYXGCo0VGiu0op7y8i4O0M+b0ezVwe3BnrAqQNHxbLIn0A7HuLJD0kF3aaS+u+NWxwrN dcRAxuiHIwEFhyAh3dsgZ8IRE46YcFTsXtc0hYGDjUWVJ2yWMEW32fa+urqimqcZmKGlhA5/uH+Q efmfj3++3mSCdo1K683JJpARayjWUKyhnkZD8X5j8hGTj5h89Ag/1WMk3VuZM1zGcBnDZc8Il22i 4XkT8ibkTfiMm7DGzPX22tYRWKnaWX89g0QmE0ExthCN2O/oJLN9cll0ccEHLvjAjWTHxSJ4ElrM ikaynDRLSbOhtbliAskCAomLp3pthO8IkNdF4kXYi5S4Qv0H8TZE2kWm/W7smyg0RrcZ3WZ0+2nQ 7d0xu1l3FcWK+oczIndJFHrXgqzT1mV2qPOoj9xCIdHZDK04B9y9rBK3nOHHGX4/ZYYf24RsE1ZC ipP5Hp3Mt22oK0dgi/JNR91uZzVeyBqeNfxPqeG9qBBEvbFh/5rVPqt9VvsMBY2oBWDB0AKCvC5r CBFYhX5TeiysjkJU/SmaLqDkDwpHWRQTyqm00DBEm1IPzC4bNIQPKFLM0ov5I8wfYf5IIaofwSUt YOyZgrRLINxtTiQyKkUpN1Rv8/i0SyZiF7Fsmxmd3DrqUG6MQjF+Krcv0Xh7jASsfjgK+7mM7N4D k2BZobFCY4XGCo0VWgRS5vhxLhhFZtHYlvu4xtECVlFPhVBkNoyg7VHcwaCWWtkmDx4bqsBKMR5q sIryBLVpbIamg4L+9wwD5hVxFh9n8b1oFl+F0XqW4rYFltgdozeaXcpbo7g/5wLl5SixYYYWMqyQ 4J1zD5nSVIzq7iN35Xz2rpxsALIByAbgixqA22brfamX8Xa9RQzKoQqbp6k2GTUXIQ7xWJtv5K/e Gp2n3DBkJUbIZCMmGzHZaCmFp3V61F7N1mufdE5Xn8GMvws/RbzVPDtbM6tsjj+7Ob47eWcgGw1A NiKcOplQ9eFsiOxXtCxDuzGZCJmmCmWKgWq7AMA4RGsyCs8GrmEZepsZFSuGDhg6kL0qysTQwTTs iil5kXaYjGUbCnJmk1RdNG6NjLeZWtQPLXigkNDMLZoHtDkXFvuAYWxMguNcsy56WV3EMDbD2Axj M4z9CAY5cmELF9Q+AJ3mhLulaF2301qDK50ctdegdaftzpr83LNWt2y3ki3zCJvNk+5qUJAxMJDg r/VfXDdwE13ukacqL5Q3IW/CygvhYhePLnZRbStvr21b8FpQ3eHbAoimMPVbHeQxIA5xM1QpmOd9 19RTJzKKJmKkDOoOA6DOhjJzUe2nJlO/PekeNxs0yeln14UW2sw6KuESrQa9t0ancbDMc8bZUIiA Vco808W6KZPCzXtAexZbXtogDC8aM+FnJW12ZUN50fgSxsgy+PQzGAq7EyzjIo1Epu6XstkTupCU RuvBuxkgftdSWy26BVroJoRTo0h8eCuSMLMMSlfmIDOqmFE1o9KeP0C6iSPLPiv7rJWQYp/10T7r trmnHrc6ldZCwZNmL6pTJFrA+EHngPghmLXn11fOPssjlkcsjx5XtoD0PqE3m+h/3oT1hL/jztka OIujSQv4JUcnnXXBr0732M0s1mQFKdpUBpSRMz6PwgSYUBsXKf+4zhkkMlU0/afCvvD6xPeF5UAI yB7eAdkVWIJueREqM5LNYNRAuYpXFlTqTItEmxiwwQgdHTarC1Kg02wqsJSaQxPaCNGvCUSwlJqv xlqZCgxlz0O428ylDpNBJXwZzSZDBPaHK1xpRqpxuQlufdY9umofk8EyW/Hc/+bzRaPZfHPS6b5/ x3HVJUFkJmAtYm3vrMm82G9dbvx53/B+YxeVXdRp2f3xuf3xhngVC0rx14y/bcOtr+9cTeoVWPig yOk1OjUhUnijyYG4QqD6zgWtOaf0CxkhG7g/EWnei0I7pKRgK67fvwHQfRNS0WavAwG1KpiaVETW 2vNTgxeQBNBEPorqJuav+wpAjBgnmL+1vZfdM98xI37dJ14CgdDCSXRGyeMRMsURGNmIyu/pL693 jvcNazbWbKzZ7qXZFluShTNWeW4cAeEIyMpqWEyLeDQtYuFe2zr1TxGQ8C4CMk/ln+fvT6MkH64+ Xfk2I8suv0AUUyjngh6ts+aaxEWWXSy7oNwgS9Y132OKP1H8qdFgiHYVCEvrhCMjc5ERYVVAUyPU 99AipE+Be2AfbtosleYpiIGUydbTgE+8KVys0Twf1/N+PTudvV/2ftn7vZf3y0H93Qrq64EnbheA zlQi7g5/3Q2vjHRR5WZtEth/s1whed+wQmKFxArpXgrpvgYg7zevdADvN95v99pvMAC3DWT1EtKo HKwME2o1meSUdk4gaumhooHyMAyG5J3W4v4cj4XRx2VSMQkLRAnDqX7dFRcVC/QTNNIlxc8ZafNL jmMaHNN48bIQuwMLIR77383jsaXhYIUePKy2GjNJmEnCTJJp4fWnNx92R3JxNJYLrpUFOJdwjV0J UCIcj02YIfJKfS6lcFl9kYhkcpvLW7WHLpjwgUFd/8/HPzcJxnoh12tWaKzQWKGxQqsnD61KKFpR HIIVWkEv6iuO0c6xivbEPz+9FwZFX+ye+Pjhn6KvBiHKjIFohAMqCw72BMCTsI/MLXCNjAEJCeWw ofG8yVwcXvJVGtcX4/piFQTO5Fgmx8K8gdhgcmxRO2d5rjBpL8mM2PnGi4JK2aOMFTKEg6EKvinD JKNKwHJ4g8MbLx7eWGwFelQij2XufcOkPiYZzYdpW1w6bmXpuG0jGX1CDYeraQ0H8RsoxFQSxFV3 KBDVKlb46gGEorWoKkskpj1yMcvKI6m4WutbqzLLqFdNlreB2AxnM/zFzfDdidWDZfTtlSBi8od3 N78XbGPYkMiNTXSOUmGunSNqhkV5n9pj3bV43AC89kwBz23xYG12W9htYbflvrkRUJaudq9nkG+b L1MEXoUfKVuSGlovR7hlk3N5VZfGX8GZUfv/Tg88EbxkVnYtYZY0mUuZmVNiVb6NN2uL8TZPPXmK y1NprLhYcbHiuq/i2lId5YmVmv9Qq6C/ZVppCbdzZiIWNhhepKu3d6IuAcFuMivzunp752TJ4hno KNJjaqxVgdTnvvG3WGF7ank989c7nbU4a3HW4vfS4os3oW81e35ppfmYwMgERqwFl8PPBEYmMG5M YPyigmGCrgSRuMnjWJpHFmdkA8CLsbEBwAbAExgA3q6qrHD/YN0A8L4prPDiECEEruIGeLuyZ+lP fEJvzL+ls9aalset06P26taa7ZPOmjrUR93uGkYDB6mxfDyR0uJ6NAvq0dgf1SpeTghBR2kkwNY0 Y8UMqYFKpXF9t13KHADzHkWlqGGWtEEY+gPA0adqxvygxyAS/pchKlpV9SwFoKER6lVTIWah0V5g FKpxVb/iX1cfRaZ1ZFVGecHi4+c/b0RPWjDVvxiZ2FSbDD2ms7E239DWykWwq/PLgs6uFoZEylWM 5phDhdrYaNZM10OJjIHMo0zEMkGesQtxUy3oVBmXgkwdsmKNFC5tCIkIZCp7IfpAhxjqbxpnocA2 jiODC8COQF6X3E/xztSrsmqXa8F1167LjT+bDjopB02JzUb9Lw8NnimczU4weF0uvkcQUNmU8+WR 04e+6CXoDlqQiePTbtOHdLZgXdPqsXnqFiWtifIduwrjlhZ2QKs8E/1w4LqIZzgDFcf7IlIjFRXr FztjuglqhIseMngHWChYhbRwaR/sf/ksaH+Uq4fWL+2hvhiAsVHmHdKfOP1WJcqEgYhhP8sktDHK naM3HN26XL5uY9EaFm4NY9OhfRwwOLe26S7oL/tNUQP0nNL093t0Zfe8Q1rneNrQYDsht3EcZkO3 G6qflNsS2zzTqMRVT4x0e0JJpPdjkDRj9edy+9gxVl0qZTFWq1KJjXdXDhd7kVraCQiHrxACtCN/ NzpPRd/IQWbrm3HaHq8vehPcriaE/CDqYmDDM1Qqu8ZHO9bYNcXJbNcsNuK4g+4Cy7bFHXTrKrBs Ql0dqu83bycyms/O/LybyDkwbk4KpwNKzrkLy/2KO3X1sn7Fk5TrhJ+xxPwkNplvKjCY6HvtjGMw jvHiZPtNjO66vvfMcdb3rO9Z398LvIf6f3kk6XlVu8MVvR72dyjjEDhbKi0hhwQWEk5w63CCSNoM 4B5K7zvkIoiUNK4ZHKDC3BI+MpAjoAtAKNK8Rz3RCVvZKGfWc0nWIwbe6RwJYYnGEu1eEm2xBeHt Ko/F733DFgTvN95v99pv8xGbYkdtm1nh0s/e6iBHiOX/AgAAAP//7Fhtb5swEP4rFp+nFggvISqR qr5M+7Apa/sHHHCCJ8CWbZq1v353BtqQVEHbt2ag8GJzvpzNPed7zpCfDS25eSFXl7uFWeJV2atc Xu0WkkBT8/whdVz35jaOQtfpu27ZhjalOX6zsl1xEN3fOVbJCjSCcrrW3R1UPNMydUq2MahPCp06 iRc5l6cEvPnMPy3hx8H8tMQsioLTEkE4d09LhEEyYmkUeCOWxjN/xNK5H4xYCgs2YqnnuvGIqZ6b JCO2el7ijhjr+WDu6VXzZnEwZm4QhdZcdMXOW7SkGa+34CQlr1nq+KCkazw0JXTQxoj2n1XrZ+pe 1EaDDNUZ56lzIxrFmSI/2A5HMqrNteY0dZ54xTR2kwdR0RpfFte1Ph6SgXfua7FemolSKBhiHdm1 R2uGfu17/W6++vUG7bGSbR+iDK2Fu+zvFiogNuHtIDBMeDuKlRPeEHD/jje7yXUYhNsnihi4ST8V XBP40ZrweiNURQ0XNS1JLrKmYrUhu4JnBYrUwhDdrH+xzBAjyJoRXsmSoRDLL8g3Q6QSzzyHQAhn prhEVYNcANZnPyol0ezaD+3G/gkDLiwf+V2VC9xWYPOQimmmnpmzJGJzOGsMyGc1RVrnRAoOn15p 9IbDCZ/VZ14KUzB1OMWz+6Y95PUXApGgAz7OnBEKZwUZOgfAk6xRCiPDG/xtzMAYkl/CuMNuXmNg 2AI89MXQTzBlGUtVVmqPAvReNfEFTGphNY6pz8QXjtdk4gt/zRdayt3jbRSEA/GWtLcM38J7Iu1H WfdE2j+IXd5/S9r3EuMB1s4uxyDtMcilPkwD/NgP7xOnj0B7O37HGmzlRAMZWQ04xXDcI7zH/OEu 8O7ClmnI7SNWVXap4/ldBaiA53Del5Tk9jtFlUZI6A/aIpHi2wI09c21MEZU722sPr63CkZzBnlL DBUaULQRAtLkt+a2MbbZcU4o/mBFp2MROMTODJKxr4rn8AaLVStuMrBy1lbpYMHaiduqz1rkL/ah z9+WfwAAAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1l MS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXY bYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5 QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxF jBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2Q U9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xut K1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlslii BmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K +BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0L SV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX 1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNx vhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpc VFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq 2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8Tqe KBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5 LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQ qp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz +Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFi SiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAO r+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJW XoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO 4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI2 7E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjX pAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd +fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gC I52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShL JvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLs vTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u 5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ 02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/ deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAEaJgqkV AwAANAcAABEAAAB3b3JkL3NldHRpbmdzLnhtbJxV23KbMBB970z/geG5NhgbnDBxMq2Ne5mk7ZTk AwQIWxPdRpJN3K/vClCIW5rp9MninD1H2tVqfXXzxKh3xEoTwVf+bBr6HualqAjfrfyH++3kwve0 QbxCVHC88k9Y+zfXb99cNanGxkCY9sCC61Ss/IPiqS73mCE9YaRUQovaTErBUlHXpMT9j98r1Mrf GyPTIOhFUyExB7daKIaMngq1CzrlRpQHhrkJojBMAoUpMnBgvSdSOzf2v26w1d6ZHF9L4sioi2tm 4WuRfbqNUNWz4l+OZwVSiRJrDZVltEuXIcKdjab/4tPV85YUCqnTC5NruLafQjCvSSVWJRQU7jwM /cASsLGoc4MMBlpLTGnbBCXFCLZv0p1CjCG4tA5pNRWu0YGae1TkRkgIOiI44DLqLcs9Uqg0WOUS leC2FtwoQV1cJb4KsxZMKki4OwQ0i0Sm9YaerLQ9mF38EMI4WRiul4tkm3UKyw5MmMXRYpSJ42Sd JWOaOEu28SiThPFmvhzTJHGUzC/GmOU8nG9HNZfJ/H0Uj2kul0mWbcaYv2e63iyTuK/zeQ2yxSyL R/fJknC7vbT7BF1Zob4stQ/gu3KrLdyRx7qLXCNWKIK8O/tEQMXSQj1+INzxBYanil8y+aFw5GTS EZohSrfQB46A19ExFdFyg+vWmN4htRuc28RYqkZR6Lovz262i7H6qMRBdq6NQvIzrwB2G84Wi96P cHNLmMP1ocidisNLeUEdePXtqKxhMBSoSQ0MN2wrdIv4znUd5pOH3IY2aUlVbgcgvkNSQsNDSLGb rXxKdnszs6/IwFeF1GP7UeyinotaDr4s136g0mYG0f3CBnRLiOoXAzZ32HzAFg5bDFjssHjAEocl FtufYDTA03+EQeOWFq8FpaLB1ScHrvw/oK4Ieo8khnu1kwEaTKQt0I8K7R1T/ARzB1fEwH+LJBVD Tys/Crtm7qMpOomDOYu1TjZYnqFehQyCKdZe1Zm4bfLfztKkFS4JNGR+YsUwiKbdwSnRJscSZpYR ClJuh9m71nn4u7v+BQAA//8DAFBLAwQUAAYACAAAACEABSNqIqQBAAATBQAAEgAAAHdvcmQvZm9u dFRhYmxlLnhtbMST3U6DQBCF7018B7L3ypZWWxtpU3966YXRB5jCUDZhd8nOtujbO7CoaWoTuTAu CQlndg/Dx5nb5Zuuoj06UtakYnQpRYQms7ky21S8vqwvZiIiDyaHyhpMxTuSWC7Oz26beWGNp4jP G5q7VJTe1/M4pqxEDXRpazRcK6zT4PnRbWNbFCrDB5vtNBofJ1Jexw4r8PxuKlVNondrfuPWWJfX zmZIxM3qKvhpUEYs+u6iZm5Ac9f3UKmNU12hBmMJR1zbQ5UKmci1vOJ7e03kuL2LuHXISnCE/muj DHIBWlXvnyo1iigUauWz8lPfg1OwqTCUSG25sKONTMVK8koe1yIoo1RMWkFO73ol4ab61SvjQyXr fMKWm86HFfb5OsXtx+H/HJF4URopesImerYaAqpjIom8ZhJXzKMlMx5ExHW+HcFfEuEgyGQ1m34T mR1+/zcRTmPH8TSR0XogkXu7cwpdy+REPqZM4IY5JB2NySAa2ubozA8BKdQb5sfp+GcWoHlM4ASH Ng0hFW06hs3J8FT8PCdSTv5mTvqBocUHAAAA//8DAFBLAwQUAAYACAAAACEALZUC/5gBAABoBwAA FAAAAHdvcmQvd2ViU2V0dGluZ3MueG1s7FXLbsIwELxX6j9Evpc8eIREBCSKOPXU0g8wiUMsxd7I NqTw9V2SiJAWJJB6K6c4sw+PdzT2ZPYlcmvHlOYgI+L2HGIxGUPC5SYin6vly5hY2lCZ0Bwki8ie aTKbPj9NyrBk6w9mDGZqC7tIHaqIZMYUoW3rOGOC6h4UTGIsBSWowV+1sSFNecwWEG8Fk8b2HGdk K5ZTgwx0xgtNmm7lLd1KUEmhIGZaIxGR1/0E5ZJMkWPCd7r5WmXIk4j0g3HfCxzfqeJrSPYLvsPY juZ4fmIfswVVbyw1J3TonPB3vskuBlZQXMqfgzEgfkWQ1zxRx71MWydxwgRT9SEiqAMuChrjzKt1 DDngfOnWQE0mP2N4X+W6w+m+WnV+/ntK7UqM6tD1siuLOxr4vj8OvOB2Xa6o0sJnmrRgV5EG/9d6 1DZ5zXiedEUZDjw/6Lte7ZUfrmgn2vFECz+mf92+F9xQQ7qR4ZJHPGfgDAd9VOV2j7iPu+t0Y/7l 3dWodfQLFIYLfmBLUHMFpWYKHxGMn72P028AAAD//wMAUEsDBBQABgAIAAAAIQB7nbBS9AEAAPED AAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJxTwW7bMAy9D9g/GD6vkZN0W1soKoYUQzdsbYC47VmT6USoLAkSkzX7+lF2kyjbTvOJfKSfnsgn fv3SmWILIWpnZ+V4VJUFWOUabVez8qH+fHZRFhGlbaRxFmblDmJ5Ld6+4YvgPATUEAuisHFWrhH9 FWNRraGTcURlS5XWhU4ipWHFXNtqBTdObTqwyCZV9YHBC4JtoDnzB8JyYLza4v+SNk4lffGx3nkS LHgNnTcSQdwlOYazA8Brh9LUugMxnRB+yPhCriAKwoaAP7nQRPH+8iNnQ8jnaxmkQpqemJ5XhGcA /+S90UoiDVZ81yq46Fos7vsRFImAs7yF01iWoDZB405UnOUp/6ZtknLB2RCRtiBXQfp1FHRslvGl kgbmdHnRShOBsyPAb0GmxS6kJsV8i1dbUOhCEfUvWu2kLH7ICGlks3Irg5YWaXSpbUj62PiIQdQa DXFTbcj7MG/LY30uxn0DBaeNiWDQQIVTdf0J8b6lu+E/xI5zsb2GQWomJwsPZ/zBOnedl3Ynvm6s JjcXd4A/XXiO74ovVo1on6/1tIDn+OBrd5NM9DrZUzBzw5PG9dJLRTubXia/HH2RlfiS7AMNLXpP eAT4LW0hmHQq/WtX0Ox7/i4kpz0OL1iMJ6OKvt5ae4z8cXha4jcAAAD//wMAUEsDBBQABgAIAAAA IQCnOfDfeAEAAO0CAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACMUstOwzAQvCPxD5HvifNAFYqaVKKoJyohKAJxM/a2NY0fst2m+XucpE0b wQHJB+/O7Ozu2NPZUVTBAYzlShYoiWIUgKSKcbkp0NtqEd6jwDoiGamUhAI1YNGsvL2ZUp1TZeDZ KA3GcbCBV5I2p7pAW+d0jrGlWxDERp4hPbhWRhDnQ7PBmtAd2QBO43iCBTjCiCO4FQz1oIhOkowO knpvqk6AUQwVCJDO4iRK8IXrwAj7Z0GHXDEFd432O53GvdZmtAcH9tHygVjXdVRn3Rh+/gR/LJ9e u1VDLluvKKByymjuuKugnOLL1d/s/usbqOvTQ+ABaoA4ZcoXZW0wJ5X3uys951vHd9DUyjDrq0eR L2dgqeHa+XfstUcJz66IdUv/sGsO7KEZt/kNt90MHHj7L8q0azeEfrfOyn5kYIE3J++tPCPv2fxx tUBlGidpGCdhnK3iu7w98We71ai+NatPiNN8/1bMJmPFs0Bv0PiDlj8AAAD//wMAUEsDBBQABgAI AAAAIQABJsxhFQkAAIJEAAAPAAAAd29yZC9zdHlsZXMueG1szFtbU9s4FH7fmf0PHr93yY0EmKYd SmFhhlJKYPbZsRXiwbGytsOlv36PjmTHsSPrCLud7UODZel856bvKKDz8fPrKnKeWZKGPJ66/b96 rsNinwdh/Dh1H+4vPhy5Tpp5ceBFPGZT942l7udPf/7x8eUkzd4iljogIE5Pkqm7zLL1ycFB6i/Z ykv/4msWw7sFT1ZeBo/J4wFfLEKffeX+ZsXi7GDQ640PEhZ5GYCny3CdukraC0XaC0+CdcJ9lqag 7SqS8lZeGLufQL2A+1/ZwttEWSoek9tEPaon/LjgcZY6Lyde6ofhPSgOJq7CmCeXp3EauvCGeWl2 mobe3pdLMWvvGz/NStK+hEHoHgjE9CfIfPaiqTsY5CNnQoOdsciLH/MxFn94mJU1mbrF0BzkTl0v +TA7FcIO0Mz8s2Tuesd4eEJV1p4PjgOcKBShHUzGAkY83G0iGPA2GVdicQmILwuCx4qPIZIQ15nM C3jLFtfcf2LBLIMXUxdyCwcfrm6TkCdh9jZ1j4/V4IytwsswCJhIw3xivAwD9s+SxQ8pC7bjPy4w qZREn2/iDNQfTzDuURqcv/psLZIK8GJPxPRGLIiE2LSEgwptwq02cqCCioP/5pB9GbW9KEvmiY3j oP6NQGj1pjXQQFhUNgDlWuk6bC9i1F7EYXsRmLztfDFprwXQZduIyNwoZSU9qBn3ZfKV/TA8bkhZ saKWRcYVtaQxrqjliHFFLSWMK2oZYFxRC7hxRS2+xhW1cDau8D0krmoWDdEbpI19H2YRE+sbCajf kupUcXFuvcR7TLz10hGltKp2E1nONvOMpirS6fvJcpYlPH40egTqsdi67+bk89V66aUhnGEMrh+0 dP29N4+Y83cSBkaoQ5l8NZvwKLK3hN1Gns+WPApY4tyzVxlRi/U33JnJc4VRuZZhvQ4fl5kzW2LJ NYKNNU7Xe0LKvw5T9EHjZhprTDEJJ8VwrMlLvfBvLAg3q9w1hNPIWPK5RZgrEKhis4tGIkT13WW0 QgSAYoIsF/YmoHyC/rK42MsXMaboL0vRO+UT9JeF653yMT+a42vNNF+95Mkhba+J9d494xFPFpso 3wNGephY7+ACgmaC9SYu5JNIYmK9g3fo0zn1ffjmRslT61hsedQCxTocEgU3G90W66BUaK9vYZF1 gCpYAwusdlxrAWRNunfsORS/arItBsjSxVnTuJ2HGg9ACSKdoX9seGY+Qw80nEdFuYrh1yUpc2ho Q83Oo6KpfJL1ziLG7QqfBVC7CmgB1K4UWgBp8kN/5ilqIh2kfXG0wLKm5aKKYdqRmXlizcwFkF0J 6KhuEs5fmt2rz4V63SSgWAeoXjcJKNbRqdSyom4SsDqrmwQsTdXQx6jMqTZGWdfNMlBxEiBY1A15 E4C6IW8CUDfkTQBqT95mkO7Im4BlzQ0Fp5bJmwCEU2y+6hdAZfImAFlzg2Q79TujvO6hlOYvtx2Q NwHFOkB18iagWEdHR94ELJxikwkVrILqCFjdkDcBqBvyJgB1Q94EoG7ImwDUDXkTgNqTtxmkO/Im YFlzQ8GpZfImAFnTQwFUJm8CEE6x4Ya95I27/peTNwHFOkB18iagWEenQqjFIZWAZR2gClZB3gQs nGKTDAoLk9vGqG7Im2BRN+RNAOqGvAlA3ZA3Aag9eZtBuiNvApY1NxScWiZvApA1PRRAZfImAFlz w17yxs34y8mbgGIdoDp5E1Cso1Mh1ILnCFjWAapgFeRNwMJ8aU3eBCCc8l4gG4u6IW+CRd2QNwGo G/ImALUnbzNId+RNwLLmhoJTy+RNALKmhwKoTN4EIGtu2EveuEd+OXkTUKwDVCdvAop1dCqEWpA3 Acs6QBWsguoIWN2QNwEIE7M1eROAcMo7gHAX2YSpG/ImWNQNeROA2pO3GaQ78iZgWXNDwall8iYA WdNDAVQmbwKQNTeIe7ZwX5R8PbWvSQLqPYP8VgMZcKAJEhVQGXjHFiyB3iVmvh3SEjC30AJRkx5U E79w/uTQLnYPNQlChgrnUcjxSvcb3tIpNSIMJw2dBPffz5xL2QBTW4cptXvzBrqHyu1C2JAkGodA z+xtDS076/xmuZAGrUSik0u1AGHn2RU0BKm2HrFY9PnARGyjUsP4d1uFij9Dl1uQz+n1zkf988ND 1eCEIg1KFLDKzD72G5WBtw1AiDf3oG3pu+hCqqkFXVZP+Xgu7mzpJdLB2/aNfI7q4dBbczYZjS/O 5fJag9ecQRse+LTfw79kycdTaO9K5V1t5VdvkTFo5FOz8Kk+STaLoZxSq1h2LRrlJDzfZOLN9XOU a99TXlaKQS+ecHWy0303dc/4Jgnh3vkNexExzzvvpu59uIJGQxh27vjKw8tj2HlXW+Knu0MyCvL/ sxQ/n1hSBGQ4lgqXmvJG+UipKQ/HSr11mlzxIXyeDx5sSFjVNlHcZMOmiWr6anorUP16Zqgei+1J XM7buekLQ6C/Ru9M9BM06Iz9Bo07zcEp0nN1BaHFD1UyaVjczcPZ2TySWQI/XMVi20JTKGadpIfg 1ZNi4f0Zi6JvHuZUxtf6qRFbZPJtv4dnqoqoOc8yvtKvT7DlADXZJwBcXFZGPgoj9L6PN6s5S6Bn sMH/N1ycRWpcA50WOC7DXbA0aI9kQ/W6XredfN5yH5BzItirptBl8QZVqpDf3sxvqTtQyA6jlzlQ cYwvboLnPunBv4sLlaf5oGgehvwHVcAVuErvkp2atHXJ/bfr20RQLHQ6ZyyoewYmODsz9nmoXLWE g3MFLyviG8sEea/pPadIGmgBG6fhM9dE7B+RqGsOPHvcV+ypm9A/GqoWZ92MwWR0pDaxBmQ4HitG 1skYHR5hdYG9p5FxODo2aDoe9Q2aToYDg6ZHg5FBU3CYQVMovNCDjbmhM6bfOz426NrvHwO7NUsZ gLqGKcPJyKTuaHyI6sKGAX0xW9SBApJEHAGgKxuEqIf9TeVqz/2200Cp1ivz0p+lWo9jZiLY4UZ/ k0LZmInTa/WAunfvVuu9mLRDD852i5NZtIkxZKTJlVlPDb/34PabQyW/u/TR97UQ5Z39rUOjULQh kS/+LyGYy0LV+dk5L7Hpp/8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAN38lTdmAQAAIAUAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABO AgAACwAAAAAAAAAAAAAAAACfAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA1mSzUfoAAAAx AwAAHAAAAAAAAAAAAAAAAADDBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA BgAIAAAAIQC41+UBexYAAPeYAQARAAAAAAAAAAAAAAAAAP8IAAB3b3JkL2RvY3VtZW50LnhtbFBL AQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAKkfAAB3b3JkL3RoZW1lL3Ro ZW1lMS54bWxQSwECLQAUAAYACAAAACEARomCqRUDAAA0BwAAEQAAAAAAAAAAAAAAAAByJgAAd29y ZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABSNqIqQBAAATBQAAEgAAAAAAAAAAAAAAAAC2 KQAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAC2VAv+YAQAAaAcAABQAAAAAAAAA AAAAAAAAiisAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHudsFL0AQAA8QMA ABAAAAAAAAAAAAAAAAAAVC0AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEApznw33gB AADtAgAAEQAAAAAAAAAAAAAAAAB+MAAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA ASbMYRUJAACCRAAADwAAAAAAAAAAAAAAAAAtMwAAd29yZC9zdHlsZXMueG1sUEsFBgAAAAALAAsA wQIAAG88AAAAAA== --_004_DF7F294AF4153D498141CBEFADB17704C6F7B91B98EMBX01WFjnprn_-- From gregory.mirsky@ericsson.com Wed Jan 4 12:09:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F421F8718 for ; Wed, 4 Jan 2012 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm6jCI64-sEO for ; Wed, 4 Jan 2012 12:09:02 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B32C921F870E for ; Wed, 4 Jan 2012 12:09:02 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q04K8wqS001595; Wed, 4 Jan 2012 14:09:00 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 4 Jan 2012 15:08:56 -0500 From: Gregory Mirsky To: David Allan I , Chao Fu , "mpls@ietf.org" Date: Wed, 4 Jan 2012 15:08:54 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdA= Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@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_FE60A4E52763E84B935532D7D9294FF132298DE806EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Jan 2012 20:09:04 -0000 --_000_FE60A4E52763E84B935532D7D9294FF132298DE806EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mes= sages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to = change timers via AdminDown state. Secondly, even if operator prefers this = operation to be more BFD-ish, it will work through P/F sequence and old fre= quency should be used until remote peer acknowledges the change with F bit = in its CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is= , as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave --_000_FE60A4E52763E84B935532D7D9294FF132298DE806EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" c= hange=20 frequency of CC messages when running MPLS-TP CC-CV (case #2). Firstly, the= re's=20 suggestion to change timers via AdminDown state. Secondly, even if operator= =20 prefers this operation to be more BFD-ish, it will work through P/F sequenc= e=20 and old frequency should be used until remote peer acknowledges the ch= ange=20 with F bit in its CC packet.
 
I'd note that RFC 6428 addresses CC-CV while pure = CC mode=20 of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.
 
  &n= bsp; Regards,
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent= :=20 Tuesday, January 03, 2012 2:49 PM
To: Chao Fu;=20 mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

HI Chao:
 
Some answers in line...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent:= =20 Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,
 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Based=20 Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help m= e to=20 clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
   My doubt: It is said to compare wit= h the=20 locally configured reception period in the definition, but in the Entry=20 criteria, it is compared with it own CC-V-configured transmission period. A= re=20 they same? Just because these two values should be same? For LOC in 5.1.1.1= , it=20 also uses the receiving MEP's configured CC-V reception=20 period.   
   And such Period=20 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it=20 is not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not one = that=20 many felt tearing the service down or forcing a protection switch was a sui= table=20 consequent action. It does not indicate an impairment in information transf= er=20 capability, just in the ability to measure it. Hence flag it northbound and= =20 presumably offline action would bring the OAM back into spec. Now as for an= =20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

Part of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC=20 6371:
   If a MEP detects a LOC defect that is not caused by a= =20 period
   misconfiguration, it should block all the traffic=20 (including also the
   user data packets) that it receives fro= m the=20 transport path, if this
   consequent action has been enabled = by=20 the operator.
   
   My doubt: Does it mean the period=20 misconfiguration should or might cause the LOC? Will the packets be discard= ed?=20 If not, there should not be LOC. My opinion is that the period misconfigura= tion=20 should not cause LOC.
  

There=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC=20 6371:
   Note that the reception period is the same as the=20 configured transmission rate.
   
   My doubt: Does it mean no need to=20 configure reception period? But many places mention "configured reception=20 period", do they mean the configured transmission rate?  
   
=
 A configured reception rate would be an expected r= ate which=20 IMO would be optional. Again an artifact of the original expectation of no= =20 handshaking between the MEPs in establishing a session periodicity and=20 configuration would be the only way such agreement would=20 happen.

 4. In 3.7.3 of RFC=20 6428:
  It will also communicate session DOWN to its session peer u= sing=20 CC messages.
  
  My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

It i= s telling=20 it's peer that it has taken the session into the down state at it's=20 end. 

So=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a transit= ion=20 from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: = Session=20 Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt:
Does it mean the BFD session will not b= e=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
   Why need P/F here? There is no timer negotiation. I= =20 think here the configured transmission rates should be same on both Engpoin= ts,=20 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC=20 6371.

 P/F is needed as examination of= any other=20 slow start mechanism revealed that we would have to reinvent what we=20 already had. So there is a handshake to get from the default to the desired= =20 rate.

I hope=20 this helps

Dave 


--_000_FE60A4E52763E84B935532D7D9294FF132298DE806EUSAACMS0715e_-- From david.i.allan@ericsson.com Wed Jan 4 14:13:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D2A11E80D2 for ; Wed, 4 Jan 2012 14:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkZ9yF3gWcYI for ; Wed, 4 Jan 2012 14:13:25 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C02B111E80B6 for ; Wed, 4 Jan 2012 14:13:24 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q04MDLct014375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jan 2012 16:13:22 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.43]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 4 Jan 2012 17:13:20 -0500 From: David Allan I To: Gregory Mirsky , Chao Fu , "mpls@ietf.org" Date: Wed, 4 Jan 2012 17:13:19 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5228FC5248EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Jan 2012 22:13:26 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5228FC5248EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg: I agree that a sudden change in frequency would not happen, and there is an= actual discipline for doing so which 6428 does go into in some detail. A s= udden actual change would be an interesting implementation bug. However I think Sasha is correct in that an Errata to 6371 would clean up m= isconceptions, as much as my first reaction was that it was an informationa= l step in a journey was a not fully defined end. I think the tweaks to addr= ess the first three points could be quite minor. best D ________________________________ From: Gregory Mirsky Sent: Wednesday, January 04, 2012 12:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mes= sages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to = change timers via AdminDown state. Secondly, even if operator prefers this = operation to be more BFD-ish, it will work through P/F sequence and old fre= quency should be used until remote peer acknowledges the change with F bit = in its CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is= , as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave --_000_60C093A41B5E45409A19D42CF7786DFD5228FC5248EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Greg:
 
I agree that a sudden change in frequency would not h= appen,=20 and there is an actual discipline for doing so which 6428 does go into in s= ome=20 detail. A sudden actual change would be an interesting implementation=20 bug.
 
However I think Sasha is correct in that an Errata to= 6371=20 would clean up misconceptions, as much as my first reaction was that it was= an=20 informational step in a journey was a not fully defined end. I think the tw= eaks=20 to address the first three points could be quite minor.
 
best
D


From: Gregory Mirsky
Sent: W= ednesday,=20 January 04, 2012 12:09 PM
To: David Allan I; Chao Fu;=20 mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" chan= ge=20 frequency of CC messages when running MPLS-TP CC-CV (case #2). Firstly, the= re's=20 suggestion to change timers via AdminDown state. Secondly, even if operator= =20 prefers this operation to be more BFD-ish, it will work through P/F sequenc= e=20 and old frequency should be used until remote peer acknowledges the ch= ange=20 with F bit in its CC packet.
 
I'd note that RFC 6428 addresses CC-CV while pure CC = mode of=20 MPLS-TP OAM is, as I understand, is per RFC 5884/5885.
 
  &n= bsp; Regards,
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent= :=20 Tuesday, January 03, 2012 2:49 PM
To: Chao Fu;=20 mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

HI Chao:
 
Some answers in line...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent:= =20 Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,
 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Based=20 Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help m= e to=20 clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
   My doubt: It is said to compare wit= h the=20 locally configured reception period in the definition, but in the Entry=20 criteria, it is compared with it own CC-V-configured transmission period. A= re=20 they same? Just because these two values should be same? For LOC in 5.1.1.1= , it=20 also uses the receiving MEP's configured CC-V reception=20 period.   
   And such Period=20 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it=20 is not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not = one=20 that many felt tearing the service down or forcing a protection switch was = a=20 suitable consequent action. It does not indicate an impairment in informati= on=20 transfer capability, just in the ability to measure it. Hence flag it north= bound=20 and presumably offline action would bring the OAM back into spec. Now as fo= r an=20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

Part of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC=20 6371:
   If a MEP detects a LOC defect that is not caused by a= =20 period
   misconfiguration, it should block all the traffic=20 (including also the
   user data packets) that it receives fro= m the=20 transport path, if this
   consequent action has been enabled = by=20 the operator.
   
   My doubt: Does it mean the period=20 misconfiguration should or might cause the LOC? Will the packets be discard= ed?=20 If not, there should not be LOC. My opinion is that the period misconfigura= tion=20 should not cause LOC.
  

There=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC=20 6371:
   Note that the reception period is the same as the=20 configured transmission rate.
   
   My doubt: Does it mean no need to=20 configure reception period? But many places mention "configured reception=20 period", do they mean the configured transmission rate?  
   
=  A configured reception rate would be = an expected=20 rate which IMO would be optional. Again an artifact of the original expecta= tion=20 of no handshaking between the MEPs in establishing a session periodicity an= d=20 configuration would be the only way such agreement would=20 happen.

 4. In 3.7.3 of RFC=20 6428:
  It will also communicate session DOWN to its session peer u= sing=20 CC messages.
  
  My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

It i= s telling=20 it's peer that it has taken the session into the down state at it's=20 end. 

So=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a tra= nsition=20 from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 = of RFC=20 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt: Does it mean the BFD session will not b= e=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
   Why need P/F here? There is no timer negotiation. I= =20 think here the configured transmission rates should be same on both Engpoin= ts,=20 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC=20 6371.

 P/F is needed as examination of= any other=20 slow start mechanism revealed that we would have to reinvent what we=20 already had. So there is a handshake to get from the default to the desired= =20 rate.

I hope=20 this helps

Dave 


--_000_60C093A41B5E45409A19D42CF7786DFD5228FC5248EUSAACMS0703e_-- From gregory.mirsky@ericsson.com Wed Jan 4 14:36:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D929421F8715 for ; Wed, 4 Jan 2012 14:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmxhM6tBepjv for ; Wed, 4 Jan 2012 14:36:02 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1715F21F86F9 for ; Wed, 4 Jan 2012 14:35:55 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q04MZoHB030639; Wed, 4 Jan 2012 16:35:52 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 4 Jan 2012 17:35:49 -0500 From: Gregory Mirsky To: David Allan I , Chao Fu , "mpls@ietf.org" Date: Wed, 4 Jan 2012 17:35:48 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQ Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5228FC5248@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_FE60A4E52763E84B935532D7D9294FF13229934E0FEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 04 Jan 2012 22:36:04 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13229934E0FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, et al., I do agree that RFC 6371 might be in need of revision at some time. But I'm= not sure that we're at that point already. I've re-checked Section 5.1.1.3 Period Misconfiguration and it refers to pe= riod of CV message. My understanding that this period is fixed at 1 sec and= since Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range= . So, we're talking not about Period Misconfiguration per se, but about wro= ng frequency of CV messages, message with unique MEP ID, as they are refere= nced in the RFC. Hope I've interpreted the 5.1.1.3 correctly. Regards, Greg ________________________________ From: David Allan I Sent: Wednesday, January 04, 2012 2:13 PM To: Gregory Mirsky; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Greg: I agree that a sudden change in frequency would not happen, and there is an= actual discipline for doing so which 6428 does go into in some detail. A s= udden actual change would be an interesting implementation bug. However I think Sasha is correct in that an Errata to 6371 would clean up m= isconceptions, as much as my first reaction was that it was an informationa= l step in a journey was a not fully defined end. I think the tweaks to addr= ess the first three points could be quite minor. best D ________________________________ From: Gregory Mirsky Sent: Wednesday, January 04, 2012 12:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mes= sages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to = change timers via AdminDown state. Secondly, even if operator prefers this = operation to be more BFD-ish, it will work through P/F sequence and old fre= quency should be used until remote peer acknowledges the change with F bit = in its CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is= , as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave --_000_FE60A4E52763E84B935532D7D9294FF13229934E0FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dave, et al.,
I do agree that RFC 6371 might be in need of revis= ion at=20 some time. But I'm not sure that we're at that point=20 already.
I've re-checked Section 5.1.1.3 Period Misconfigur= ation and=20 it refers to period of CV message. My understanding that this period is fix= ed at=20 1 sec and since Detect Multiplier is 1 generation randomized within 0.75 - = 0.9=20 range. So, we're talking not about Period Misconfiguration per se, but abou= t=20 wrong frequency of CV messages, message with unique MEP ID, as they are=20 referenced in the RFC.
 
Hope I've interpreted the 5.1.1.3=20 correctly.
 
  &n= bsp; Regards,
        Greg


From: David Allan I
Sent: We= dnesday,=20 January 04, 2012 2:13 PM
To: Gregory Mirsky; Chao Fu;=20 mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

Hi Greg:
 
I agree that a sudden change in frequency would no= t happen,=20 and there is an actual discipline for doing so which 6428 does go into in s= ome=20 detail. A sudden actual change would be an interesting implementation=20 bug.
 
However I think Sasha is correct in that an Errata= to 6371=20 would clean up misconceptions, as much as my first reaction was that it was= an=20 informational step in a journey was a not fully defined end. I think the tw= eaks=20 to address the first three points could be quite minor.
 
best
D


From: Gregory Mirsky
Sent: W= ednesday,=20 January 04, 2012 12:09 PM
To: David Allan I; Chao Fu;=20 mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" c= hange=20 frequency of CC messages when running MPLS-TP CC-CV (case #2). Firstly, the= re's=20 suggestion to change timers via AdminDown state. Secondly, even if operator= =20 prefers this operation to be more BFD-ish, it will work through P/F sequenc= e=20 and old frequency should be used until remote peer acknowledges the ch= ange=20 with F bit in its CC packet.
 
I'd note that RFC 6428 addresses CC-CV while pure = CC mode=20 of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.
 
  &n= bsp; Regards,
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent= :=20 Tuesday, January 03, 2012 2:49 PM
To: Chao Fu;=20 mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

HI Chao:
 
Some answers in line...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent:= =20 Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,
 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Based=20 Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help m= e to=20 clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
   My doubt: It is said to compare wit= h the=20 locally configured reception period in the definition, but in the Entry=20 criteria, it is compared with it own CC-V-configured transmission period. A= re=20 they same? Just because these two values should be same? For LOC in 5.1.1.1= , it=20 also uses the receiving MEP's configured CC-V reception=20 period.   
   And such Period=20 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it=20 is not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not one = that=20 many felt tearing the service down or forcing a protection switch was a sui= table=20 consequent action. It does not indicate an impairment in information transf= er=20 capability, just in the ability to measure it. Hence flag it northbound and= =20 presumably offline action would bring the OAM back into spec. Now as for an= =20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

Part of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC=20 6371:
   If a MEP detects a LOC defect that is not caused by a= =20 period
   misconfiguration, it should block all the traffic=20 (including also the
   user data packets) that it receives fro= m the=20 transport path, if this
   consequent action has been enabled = by=20 the operator.
   
   My doubt: Does it mean the period=20 misconfiguration should or might cause the LOC? Will the packets be discard= ed?=20 If not, there should not be LOC. My opinion is that the period misconfigura= tion=20 should not cause LOC.
  

There=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC=20 6371:
   Note that the reception period is the same as the=20 configured transmission rate.
   
   My doubt: Does it mean no need to=20 configure reception period? But many places mention "configured reception=20 period", do they mean the configured transmission rate?  
   
=
 A configured reception rate would be an expected r= ate which=20 IMO would be optional. Again an artifact of the original expectation of no= =20 handshaking between the MEPs in establishing a session periodicity and=20 configuration would be the only way such agreement would=20 happen.

 4. In 3.7.3 of RFC=20 6428:
  It will also communicate session DOWN to its session peer u= sing=20 CC messages.
  
  My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

It i= s telling=20 it's peer that it has taken the session into the down state at it's=20 end. 

So=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a transit= ion=20 from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: = Session=20 Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt:
Does it mean the BFD session will not b= e=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
   Why need P/F here? There is no timer negotiation. I= =20 think here the configured transmission rates should be same on both Engpoin= ts,=20 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC=20 6371.

 P/F is needed as examination of= any other=20 slow start mechanism revealed that we would have to reinvent what we=20 already had. So there is a handshake to get from the default to the desired= =20 rate.

I hope=20 this helps

Dave 


--_000_FE60A4E52763E84B935532D7D9294FF13229934E0FEUSAACMS0715e_-- From internet-drafts@ietf.org Wed Jan 4 17:06:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819821F86CD; Wed, 4 Jan 2012 17:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5RYkPKxymkS; Wed, 4 Jan 2012 17:06:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D321F86A8; Wed, 4 Jan 2012 17:06:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120105010642.3528.9602.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 17:06:42 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-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: Thu, 05 Jan 2012 01:06:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-00.txt Pages : 30 Date : 2012-01-04 Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-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-ldp-dod-00.txt From Alexander.Vainshtein@ecitele.com Thu Jan 5 01:15:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF521F8613 for ; Thu, 5 Jan 2012 01:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.076 X-Spam-Level: X-Spam-Status: No, score=-4.076 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etsmN2rjscKQ for ; Thu, 5 Jan 2012 01:15:41 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id CE22621F8608 for ; Thu, 5 Jan 2012 01:15:40 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1325754938!7839113!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 26914 invoked from network); 5 Jan 2012 09:15:38 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-3.tower-174.messagelabs.com with SMTP; 5 Jan 2012 09:15:38 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-78-4f0566be6876 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id F7.0E.08306.EB6650F4; Thu, 5 Jan 2012 11:00:46 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 5 Jan 2012 10:56:36 +0200 From: Alexander Vainshtein To: Gregory Mirsky Date: Thu, 5 Jan 2012 10:56:34 +0200 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAAGn42QA== Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF6F8ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTmzmMdzYlx1fYq/dgmsTRX1rRYsbUIIqOHhWERlI27t92h3dlt Z4y2hPZPWBZURIstVBpmZU8s6GE/yrDUNioi0K3t5as2kzA1sofNOGlCdH9993zf+c653HMo XHskKpniBQl5BM7BamKII5GBQUP2VrLQ2NGiNb19fB033TvRTJp6uyqBKXT6HLmIKBgZeq4p uBkIRxXU1n7DVuMbfGABJwguiZOQ3opEi5ld7eG3cxYvq+etZjaL1bsdnAU5kSCZWc7tRoKV zY/R/3MWyDJe0CPB4rLygs3MLisqNJhM83INWWx+6sys7LyYtXZe1CODk+MdeicSRc6G9HJk 8zXcfv/soMb9cS+2I9jt1/jA3h5QCaIpyOTAm6FmTMXT4JNXlzWVIIbSMo0A7mu+hamXowD2 932PUlQaxgwbzoc1Ck5gjPBF3RlcwTizDX7qfUYomGBS4I9gYKxCPGOCw60dhKrPhQ0RP6ni xTD87LMcpyiaWQMjvQvVWn0Ahn/VjflHM+thV/f7MX8gd/e17QKm1tLBUNfJP10zsPb2Y1zF ifBD5y9S1SfClxWXgap3wYv+0JgnzcTB1mNdhKpPgnfPthOHwLTAJNvApJTApBQ1ngGrGwc0 Kp4D62o+4uM4eKcTmxyvBlH1IIl3uKVSp8041+AqkzKRhZeQA2VaXM4GoE7U+xvgRTCtCTAU YGPpdz6iUEty20WvswkkURibSBfZyULt1FKX1WvnRHuJp8yBxCYAKZxNoIvyZY62ct6dyOMa p5bIP3AYT55iccmzK0gl2Ubj/y+sjt5v6VupZWzygG5FyI084z7TKYqF9E9eLhHnQTa0Ywvv kP7SGBWttBErtzGiaGjRzTlF3qbybWBGso4OKQSjEPYyYSJX2aXdo6OjEaCTHx1PVyiqWHnT JrIjsjEmG29IIBRjeXkmqGQfKH3a+mhF6HyV1yqW76tNpx/Of+CuWBHszHjDkk/iNq0Lz07Y lIs2+lrr24u7Qw1Xy5cPlvQvLc6rPu6v2vPmDF9TdyEvxb8koybRn5n65UZ244GWqup6R0t6 fMnQcM6lXd3egTby1KxgWur+lNO6kVU9e6QrM7ccIsoPLnvdf3G3nyVEO5eVjntE7jfcdf1q JgQAAA== Cc: "mpls@ietf.org" , Chao Fu Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Jan 2012 09:15:47 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF6F8ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. You've said that "pure CC mode of MPLS-TP OAM is, as I understand, is per RF= C 5884/5885". I tend to disagree with statement on both counts. RFC 5884 in its Section 7 "Encapsulation= " explicitly states: The BFD Control packet sent by the ingress LSR MUST be a UDP packet with a well-known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. The source IP address is a routable address of the sender. The destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following exception. If the FEC is an LDP IP FEC, the ingress LSR may discover multiple alternate paths to the egress LSR for this FEC using LSP Ping traceroute. In this case, the destination IP address, used in a BFD session established for one such alternate path, is the address in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 discovered by LSP Ping traceroute [RFC4379] to exercise that particular alternate path. I suspect that the highlighted text does not sit well with MPLS-TP with its= emphasis on independence from IP. RFC 5885 in the part that describes PW-ACH encapsulation for the BFD control= packets (without IP/UDP headers) could be easily reused in RFC 6428. However, these documents have defined different ACH types for BFD packets: * RFC 5885 uses type 0x0007 for CC * RFC 6428 uses type 0x0022 for CC. Taking into account that PWs are supposed to be part of MPLS-TP, this looks= a bit fishy to me, but I am not sure what could be done about that. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg= ory Mirsky Sent: Wednesday, January 04, 2012 10:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mess= ages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to ch= ange timers via AdminDown state. Secondly, even if operator prefers this ope= ration to be more BFD-ish, it will work through P/F sequence and old frequen= cy should be used until remote peer acknowledges the change with F bit in it= s CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is,= as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao= Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? T= hanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception per= iod in the definition, but in the Entry criteria, it is compared with it own= CC-V-configured transmission period. Are they same? Just because these two= values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable cons= equent action. It does not indicate an impairment in information transfer ca= pability, just in the ability to measure it. Hence flag it northbound and pr= esumably offline action would bring the OAM back into spec. Now as for an im= plementation explicitly modifying the periodicity to an unacceptable value,= how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed aft= er the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. My= opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the per= iodicity of CC/CV to less than 1/3 of the expected rate so that one got an L= OC. Once a lower rate BFD PDU was received that advertised the changed rate,= the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmission= rate. My doubt: Does it mean no need to configure reception period? But many pl= aces mention "configured reception period", do they mean the configured tran= smission rate? A configured reception rate would be an expected rate which IMO would be op= tional. Again an artifact of the original expectation of no handshaking betw= een the MEPs in establishing a session periodicity and configuration would b= e the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC message= s. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session DO= WN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state at= it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are loc= al inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from U= P to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the confi= gured values but use the default values? What the values will be filled in t= he packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the config= ured transmission rates should be same on both Engpoints, otherwise there ar= e Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed tha= t we would have to reinvent what we already had. So there is a handshake to= get from the default to the desired rate. I hope this helps Dave 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_A3C5DF08D38B6049839A6F553B331C760115EDBFF6F8ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear Greg,

Lots of thanks for a prompt r= esponse.

 

You’ve said that “= pure CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885”.

&nb= sp;

I tend to disagree with state= ment on both counts.

=  

 

RFC 5884 in its Section 7 “Encapsulation” explicitly= states:

 

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet<=
/span>
   with a well-known destina=
tion port 3784 [BFD-IP] and a source port
=
   assigned by the sender as per the procedures in [BFD-IP].&n=
bsp; The source<=
/o:p>
&nbs=
p;  IP address is a routable address of the sender.  The destinati=
on IP
&=
nbsp;  address MUST be randomly chosen from the 127/8 range for IPv4 an=
d
&nbs=
p;  from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following
   exception.  If the FEC is an LDP IP FEC, the ingress L= SR may discover
   multiple alternat=
e paths to the egress LSR for this FEC using LSP
   Ping traceroute.  In this case, the destination IP addr= ess, used in a
   BFD session establ=
ished for one such alternate path, is the address
   in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 rang= e for IPv6
   discovered by LSP Ping=
 traceroute [RFC=
4379] to exercise that
   partic=
ular alternate path.
 <=
/pre>

I suspect that the highlighted text does not= sit well with MPLS-TP with its emphasis on independence from IP.=

 

RFC 5885 in the part that describes PW-ACH encapsulation= for the BFD control packets (without IP/UDP headers) could be easily reused= in RFC 6428.

However, these= documents have defined different ACH types for BFD packets:

·       =   RFC 5885= uses type 0x0007 for CC

·&n= bsp;        RFC 6428 uses type 0x0022 for CC.<= /span>

 

Taking into account that PWs are supposed to be part of MPLS= -TP, this looks a bit fishy to me, but I am not sure what could be done abou= t that.

 

Regards,

     Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ] On Behalf Of Gregory Mirsky
Sent: Wednesday, January 04,= 2012 10:09 PM
To: David Allan I; Chao Fu; mpls@ietf.org
Sub= ject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
<= /p>

 

Dear Dave, Chao, et al.

I thin= k that an BFD peer would not be "suddenly" change frequency of CC= messages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion= to change timers via AdminDown state. Secondly, even if operator prefers th= is operation to be more BFD-ish, it will work through P/F sequence and = old frequency should be used until remote peer acknowledges the change with= F bit in its CC packet.

 

I'd note that RFC 6428 addresses CC-CV whi= le pure CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.

 

    Regards,

        Greg

 


=

From: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent= : Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org=
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:

 

Some answers in line...=

 


From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To:= mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC= 6428

Hi all,

<= /div>

 

I have some doubts on RFC 6371 "OAM Framework for MPLS-Bas= ed Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".&nbs= p; Who can help me to clarify them? Thanks a lot!

1.= Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect:
&nbs= p;  If proactive CC-V OAM packets are received with the expected global= ly
   unique Source MEP identifier but with a transmission peri= od different
   than the locally configured reception period, t= hen a CC-V period
   misconfiguration defect is detected.
&n= bsp;  o  Entry criteria: A MEP receives a CC-V proactive packet wi= th the
      expected globally unique Source MEP= identifier but with a
      transmission period= different than its own CC-V-configured
      tr= ansmission period.
   
   My doubt: It is said to compare with the locally configu= red reception period in the definition, but in the Entry criteria, it is com= pared with it own CC-V-configured transmission period. Are they same? Just b= ecause these two values should be same? For LOC in 5.1.1.1, it also uses the= receiving MEP's configured CC-V reception period.  &n= bsp;
   And such Period= Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it is not in RFC 6428? <= /o:p>

  
The short story is that a mismatch is a problem=  but not one that many felt tearing the service down or forcing a prot= ection switch was a suitable consequent action. It does not indicate an impa= irment in information transfer capability, just in the ability to measure it= . Hence flag it northbound and presumably offline action would bring the OAM= back into spec. Now as for an implementation explicitly modifying the perio= dicity to an unacceptable value, how the other end reacts is implementation= or policy dependant.

Part of this is a consequence= of beleiving that some of the BFD handshaking could be dispensed with at th= e time 6371 was written. That view changed after the BFD WG did a thorough r= eview of what became 6428.

 2. In 5.1.2 of RFC= 6371:
   If a MEP detects a LOC defect that is not caused by a= period
   misconfiguration, it should block all the traffic (i= ncluding also the
   user data packets) that it receives from t= he transport path, if this
   consequent action has been enable= d by the operator.
   
   My doubt: Does it mean the period misconfiguration shoul= d or might cause the LOC? Will the packets be discarded? If not, there shoul= d not be LOC. My opinion is that the period misconfiguration should not caus= e LOC.
 = ; 

There could be a corner cases if with= out any warning one end reduced the periodicity of CC/CV to less than 1/3 of= the expected rate so that one got an LOC. Once a lower rate BFD PDU was rec= eived that advertised the changed rate, the receiver could adapt vs. staying= in a defect state.

  
3. In 5.1.3 of= RFC 6371:
   Note that the reception period is the same as the= configured transmission rate.
   
   My doubt: Does it mean no need to configure= reception period? But many places mention "configured reception period= ", do they mean the configured transmission rate?  
&nbs= p;  
 A configured reception rate woul= d be an expected rate which IMO would be optional. Again an artifact of the= original expectation of no handshaking between the MEPs in establishing a s= ession periodicity and configuration would be the only way such agreement wo= uld happen.

 4. In 3.7.3 of RFC 6428:
 = It will also communicate session DOWN to its session peer using CC messages= .
  
  My doubt:= Does it mean only notify the peer to bring the session DOWN but the local s= ession will not be DOWN? Or we should bring the local session DOWN also? But= it is not in the BFD State machine of Figure 7.
 

It is telling it's peer that it has taken the sessi= on into the down state at it's end. 

So LDI/LK= R, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local inputs= to the state machine that will transition it from UP to DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a trans= ition from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: Session Initiation and= Modification

   Session initiation occurs starti= ng from MinRx =3D 1 second, MinTx >=3D 1
   second, and the= detect multiplier =3D 3.

   Once in the UP state= , Poll/Final discipline is used to modify the
   periodicity of= control message exchange from their default rates to
   the de= sired rates and to set the detect multiplier to 3.
   
=    My doubt: Does it mean t= he BFD session will not be started with the configured values but use the de= fault values? What the values will be filled in the packet? The default ones= or the configured values?=
   Why need P/F here? There is no timer negotiation. I thi= nk here the configured transmission rates should be same on both Engpoints,= otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC 6371.

 P/F is needed as examinat= ion of any other slow start mechanism revealed that we would have to re= invent what we already had. So there is a handshake to get from the default= to the desired rate.

I hope this helps=

Dave 

&nbs= p;

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_A3C5DF08D38B6049839A6F553B331C760115EDBFF6F8ILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Thu Jan 5 01:35:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2221F85A6 for ; Thu, 5 Jan 2012 01:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbaZo-tY9mXE for ; Thu, 5 Jan 2012 01:35:47 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A1B6221F860B for ; Thu, 5 Jan 2012 01:35:46 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1325756093!49014687!5 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 18762 invoked from network); 5 Jan 2012 09:35:00 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-5.tower-27.messagelabs.com with SMTP; 5 Jan 2012 09:35:00 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-c4-4f056fe94155 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 45.5F.08306.9EF650F4; Thu, 5 Jan 2012 11:39:53 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 5 Jan 2012 11:35:43 +0200 From: Alexander Vainshtein To: Gregory Mirsky Date: Thu, 5 Jan 2012 11:35:42 +0200 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFA= Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTaWjTYBjHeZO0TeciWXe9m37ooojHOlovKq4qiDg/aOcBigcza981wSap TaZWHQ4UJvOLOh1aPKbOOTdlUu9zWlFUdqEIOue5QbVeMDyHcyYLmwMxn355/s/xT3geErfs NGWSvKigoMj6GWMCURHv/mJ7Jxnc9ot1o5yvWy/iztuH7hicsa5y4Gw/ftIwi8jr+frYmHc5 /NyUV139E8vHl5eCXFYUJYVVkNWLZI+LyQ/y61hPiLHyXhfjYKwBP+tBAhIVF8MGAkj0MjMS rP88uWoaL1qR6JG8vOhzMfMWu21O55RpNgczY8wox6TpCUs4XrYim8DyfquAZJn1IasaWX0O 537VVhKBin3Yht0HKk2l4G43KAdmEtKTYXXPBYPOabDtRYNRYwt9GcA9HUvLQYLKFQCeevUR 0wQj7YKR+uf9SSm0HT6rOYFrjNNr4cfYI0Jjgh4Nf5Z19XMy7YTf7j8l9PxpMBKvVIeRKi+A X49maEjRC+GOshH62O04fNWyWWMzvQy2vW43aQxUa98fnML0SemwveswplumYfW1VlznVPiu 87dBz0+FHWUNQM+XYHPvoX7HFJ0E7+/XnUE6A96qfULsBGnhIW3DQ0rCQ0r0eDasutpt1HkC rDnyHh/gppud2NB4FTDVgQzeH1AKBZ99ok0qVnKQh1eQH+V4JCEC9HV6ewk8axoXBTQJmETq TSnhthjYdXJIiIIMEmNSqRLB4LYML5S8IY6VuYJgsR/JUQBJnEmhPmsa5WVDG1FQGpDmqP9/ F545zCOpiysqBZPs9v+/MOnUDs+H+Rbap27nGoQCKDjQZyRJMpBq1EYkBZEPbSji/cpfGSPN mo1E1UZNvw05wAoy79P1ByArM52KaQKtCVyxOFirHdKWvr6+OEhXPzqZEkQ1K1E9s8HquNoY UxsvTyG0xurlDEqZpSDPFWkuydrKGd0/Lom+ktHxh9EnsbNbciMra6UryYWzc4umdiTlvOh9 yp1vmxhpWpHdVLbaNHeVmYuEhm+6t7f+U6So6nTqlJlj07Z1tLRuqun0H4w3Nuw7ft1cbitw RHsaerHFljMjFi25e2XeTBCcGl5/51ssy/iyJ2nNjWOTJ0gMIXOsYzwelNk/hWqVQCMEAAA= Cc: "mpls@ietf.org" , Chao Fu Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Jan 2012 09:35:53 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear Greg, I've followed your example and checked Section 5.1.1.3 "Period Misconfigurat= ion Defect" in RFC 6371, and I disagree with your reading.. First of all, this document does not distinguish between Connectivity Check= (CC) and Connectivity Verification (CV). It almost explicitly assumes that= the same packet is used for both purposes - at least when we speak about pr= oactive CC and CV (because" CC packets" are not mentioned in the text, and= "CV packets" are always mentioned as "on-demand CV -packets"). And, in part= icular, Section 5.1.1.3 refers to "CC-V packets" with CC-V standing for "Con= nectivity Check and Connectivity Verification" in the Terminology section. When it comes to the Period Misconfiguration defect, IMHO the text in RFC 63= 71 admits at least two readings: 1. Transmission period is encoded in the CC-V packets, and the receive= r compares the received value with its configured one. This reading matches= the definition of the Unexpected Period defect in Annex I.5 of ITU-T Y.173= 1 (02/08) and is trivial to implement 2. The receiver of CC-V messages evaluates the actual transmission per= iod of CC-V messages and compares it with the configured value. I cannot sa= y that such a reading strictly contradicts 6371, but it leaves multiple open= questions, e.g.: a. How do you evaluate the transmission period? The receiver has to so= mehow eliminate the PDV effects, and the estimate may depend on the specific= elimination method and its parameters b. How do you compare the estimated actual transmission period with the= configured one? This requires definition of some limits of tolerance etc. Taking into account the history of MPLS-TP, I'd say that the first reading a= bove looks like matching the intention of the authors/Editors. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg= ory Mirsky Sent: Thursday, January 05, 2012 12:36 AM To: David Allan I; Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Dave, et al., I do agree that RFC 6371 might be in need of revision at some time. But I'm= not sure that we're at that point already. I've re-checked Section 5.1.1.3 Period Misconfiguration and it refers to per= iod of CV message. My understanding that this period is fixed at 1 sec and s= ince Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. S= o, we're talking not about Period Misconfiguration per se, but about wrong f= requency of CV messages, message with unique MEP ID, as they are referenced= in the RFC. Hope I've interpreted the 5.1.1.3 correctly. Regards, Greg ________________________________ From: David Allan I Sent: Wednesday, January 04, 2012 2:13 PM To: Gregory Mirsky; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Greg: I agree that a sudden change in frequency would not happen, and there is an= actual discipline for doing so which 6428 does go into in some detail. A su= dden actual change would be an interesting implementation bug. However I think Sasha is correct in that an Errata to 6371 would clean up mi= sconceptions, as much as my first reaction was that it was an informational= step in a journey was a not fully defined end. I think the tweaks to addres= s the first three points could be quite minor. best D ________________________________ From: Gregory Mirsky Sent: Wednesday, January 04, 2012 12:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mess= ages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to ch= ange timers via AdminDown state. Secondly, even if operator prefers this ope= ration to be more BFD-ish, it will work through P/F sequence and old frequen= cy should be used until remote peer acknowledges the change with F bit in it= s CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is,= as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao= Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? T= hanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception per= iod in the definition, but in the Entry criteria, it is compared with it own= CC-V-configured transmission period. Are they same? Just because these two= values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable cons= equent action. It does not indicate an impairment in information transfer ca= pability, just in the ability to measure it. Hence flag it northbound and pr= esumably offline action would bring the OAM back into spec. Now as for an im= plementation explicitly modifying the periodicity to an unacceptable value,= how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed aft= er the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. My= opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the per= iodicity of CC/CV to less than 1/3 of the expected rate so that one got an L= OC. Once a lower rate BFD PDU was received that advertised the changed rate,= the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmission= rate. My doubt: Does it mean no need to configure reception period? But many pl= aces mention "configured reception period", do they mean the configured tran= smission rate? A configured reception rate would be an expected rate which IMO would be op= tional. Again an artifact of the original expectation of no handshaking betw= een the MEPs in establishing a session periodicity and configuration would b= e the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC message= s. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session DO= WN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state at= it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are loc= al inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from U= P to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the confi= gured values but use the default values? What the values will be filled in t= he packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the config= ured transmission rates should be same on both Engpoints, otherwise there ar= e Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed tha= t we would have to reinvent what we already had. So there is a handshake to= get from the default to the desired rate. I hope this helps Dave 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_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear Greg,

 

<= p class=3DMsoNormal>I’ve followed your example and checked Secti= on 5.1.1.3 “Period Misconfiguration Defect” in RFC 6371, an= d I disagree with your reading..

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

First of all, th= is document does not distinguish between Connectivity Check (CC) and Connect= ivity Verification (CV). It almost explicitly assumes that the same packet i= s used for both purposes – at least when we speak about proactive CC a= nd CV (because” CC packets” are not mentioned  in the text,= and “CV packets” are always mentioned as “on-demand CV &#= 8211;packets”). And, in particular, Section 5.1.1.3 refers to “C= C-V packets” with CC-V standing for “Connectivity Check and Conn= ectivity Verification” in the Terminology section.

 

When it comes to the Period Misconfiguration defect, IMHO the= text in RFC 6371 admits at least two readings:

<= ![if !supportLists]>1.       Transmission period is enc= oded in the CC-V packets, and the receiver compares the received value with= its configured one. This reading matches the definition of the Unexpected P= eriod defect in  Annex I.5 of ITU-T Y.1731 (02/08) and is trivial to im= plement

2.  = ;     The receiver of CC-V messages evaluates the actual transmission pe= riod of CC-V messages and compares it with the configured value.  I can= not say that such a reading strictly contradicts 6371, but it leaves multipl= e open questions, e.g.:

a.       = How do you evaluate the transm= ission period? The receiver has to somehow eliminate the PDV effects, and th= e estimate may depend on the specific elimination method and its parameters<= o:p>

b.=       How do you compare the estimated actual transmission period w= ith the configured one? This requires definition of some limits of tolerance= etc.

Taking into account th= e history of MPLS-TP, I’d say that the first reading above looks like= matching the intention of the authors/Editors.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>My 2c,

  &nbs= p;  Sasha

=  

From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsk= y
Sent: Thursday, January 05, 2012 12:36 AM
To: David Al= lan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in R= FC 6371 and RFC 6428

<= o:p> 

Hi Dave, et al.,=

I do agree that RFC 6371 might be in need of revis= ion at some time. But I'm not sure that we're at that point already.<= o:p>

I've re-checked Section 5.1.1.3 Period M= isconfiguration and it refers to period of CV message. My understanding that= this period is fixed at 1 sec and since Detect Multiplier is 1 generation r= andomized within 0.75 - 0.9 range. So, we're talking not about Period Miscon= figuration per se, but about wrong frequency of CV messages, message with un= ique MEP ID, as they are referenced in the RFC.

 

Hope I've interpret= ed the 5.1.1.3 correctly.

 

    Regards,

        Gre= g

 


From: David Allan I
Sent: Wednesday, January 04, 2012 2:13 PM<= br>To: Gregory Mirsky; Chao Fu; mpls@ietf.org
Subject: RE:= [mpls] Some doubts in RFC 6371 and RFC 6428

Hi Greg:

 =

I agree that a sudden change in frequency wo= uld not happen, and there is an actual discipline for doing so which 6428 do= es go into in some detail. A sudden actual change would be an interesting im= plementation bug.

 

However I think Sasha is correct in that an Errat= a to 6371 would clean up misconceptions, as much as my first reaction was th= at it was an informational step in a journey was a not fully defined end. I= think the tweaks to address the first three points could be quite minor.

 

best

D

 


From: Gregory Mirsky=
Sent: Wednesday, January 04, 2012 12:09 PM
To: David A= llan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in= RFC 6371 and RFC 6428

Dear Dave,= Chao, et al.

I think that an BFD= peer would not be "suddenly" change frequency of CC messages when= running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to change time= rs via AdminDown state. Secondly, even if operator prefers this operation to= be more BFD-ish, it will work through P/F sequence and old frequency s= hould be used until remote peer acknowledges the change with F bit in its CC= packet.

 

I'd note that RFC 6428 addresses CC-CV while pure CC mode= of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.=

 

 &nb= sp;  Regards,

  &n= bsp;     Greg

 


From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of David Allan I
Sent: Tuesday, J= anuary 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject:<= /b> Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:

 = ;

Some answers in line...

 


From: mpls-bounc= es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent:
Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org<= br>Subject: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi all,

 

I have som= e doubts on RFC 6371 "OAM Framework for MPLS-Based Transport"= and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help me= to clarify them? Thanks a lot!

1. Section 5.1.1.3 of= RFC 6371 defines Period Misconfiguration Defect:
   If proacti= ve CC-V OAM packets are received with the expected globally
  = unique Source MEP identifier but with a transmission period different
&n= bsp;  than the locally configured reception period, then a CC-V period<= br>   misconfiguration defect is detected.
   o = Entry criteria: A MEP receives a CC-V proactive packet with the
 &n= bsp;    expected globally unique Source MEP identifier but wi= th a
      transmission period different than it= s own CC-V-configured
      transmission period.=
   
   My= doubt: It is said to compare with the locally configured reception peri= od in the definition, but in the Entry criteria, it is compared with it own= CC-V-configured transmission period. Are they same? Just because these two= values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= configured CC-V reception period.   
   And such Period Misconfiguration= Defect is not defined in RFC 6428. Does MPLS TP need it? Why it is not in R= FC 6428? 

 = ; 
The short story is that a mismatch is a problem  but not on= e that many felt tearing the service down or forcing a protection switch was= a suitable consequent action. It does not indicate an impairment in informa= tion transfer capability, just in the ability to measure it. Hence flag it n= orthbound and presumably offline action would bring the OAM back into spec.= Now as for an implementation explicitly modifying the periodicity to an una= cceptable value, how the other end reacts is implementation or policy depend= ant.

Part of this is a consequence of beleiving tha= t some of the BFD handshaking could be dispensed with at the time 6371 was w= ritten. That view changed after the BFD WG did a thorough review of what bec= ame 6428.

 2. In 5.1.2 of RFC 6371:
 &n= bsp; If a MEP detects a LOC defect that is not caused by a period
 &= nbsp; misconfiguration, it should block all the traffic (including also the<= br>   user data packets) that it receives from the transport path,= if this
   consequent action has been enabled by the operator.=
   
   My doubt: Does it mean the period misconfiguration should or might cause t= he LOC? Will the packets be discarded? If not, there should not be LOC. My o= pinion is that the period misconfiguration should not cause LOC.=
  

There could be a corner cases if without any warning on= e end reduced the periodicity of CC/CV to less than 1/3 of the expected rate= so that one got an LOC. Once a lower rate BFD PDU was received that adverti= sed the changed rate, the receiver could adapt vs. staying in a defect state= .

  
3. In 5.1.3 of RFC 6371:
 = ;  Note that the reception period is the same as the configured transmi= ssion rate.
   
   My doubt: Does it mean no need to configure reception period? B= ut many places mention "configured reception period", do they mean= the configured transmission rate?  
   <= i>
 A configured reception rate would be an expected rat= e which IMO would be optional. Again an artifact of the original expectation= of no handshaking between the MEPs in establishing a session periodicity an= d configuration would be the only way such agreement would happen.

 4. In 3.7.3 of RFC 6428:
  It will also communi= cate session DOWN to its session peer using CC messages.
  
=   My doubt: Does it mean only no= tify the peer to bring the session DOWN but the local session will not be DO= WN? Or we should bring the local session DOWN also? But it is not in the BFD= State machine of Figure 7.
 

It is telling it's peer that it has taken the session into the down state= at it's end. 

So LDI/LKR, TIME OUT, MISCONNEC= TIVIY or a local focing of ADMIN DOWN are local inputs to the state machine= that will transition it from UP to DOWN.

Receiving= ADMIN DOWN or DOWN from a peer will also cause a transition from UP to DOWN= in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 s= econd, MinTx >=3D 1
   second, and the detect multiplier =3D= 3.

   Once in the UP state, Poll/Final disciplin= e is used to modify the
   periodicity of control message excha= nge from their default rates to
   the desired rates and to set= the detect multiplier to 3.
   
   My doubt: Does it mean the BFD session will no= t be started with the configured values but use the default values? What the= values will be filled in the packet? The default ones or the configured val= ues?
   W= hy need P/F here? There is no timer negotiation. I think here the configured= transmission rates should be same on both Engpoints, otherwise there are Pe= riod Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.

 P/F is needed as examination of any other slow&= nbsp;start mechanism revealed that we would have to reinvent what we already= had. So there is a handshake to get from the default to the desired rate.

I hope this helps

Dave 

 

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_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_-- From loa@pi.nu Thu Jan 5 03:24:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1321F86B4 for ; Thu, 5 Jan 2012 03:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-OhSdB3xJV for ; Thu, 5 Jan 2012 03:24:27 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 479C921F86B2 for ; Thu, 5 Jan 2012 03:24:27 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 97C2F2A8003 for ; Thu, 5 Jan 2012 12:24:24 +0100 (CET) Message-ID: <4F05886A.6070603@pi.nu> Date: Thu, 05 Jan 2012 12:24:26 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Poll on two drafts (draft-fbb-mpls-gach-adv and draft-fbb-mpls-tp-ethernet-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, 05 Jan 2012 11:24:28 -0000 Working Group, this is to start a two week poll to see if there is support to make draft-fbb-mpls-gach-adv-01 draft-fbb-mpls-tp-ethernet-addressing-01 mpls working group drafts. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends January 18, 2012! Loa for the mpls wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From yaacov.weingarten@nsn.com Thu Jan 5 04:06:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5A21F87F1 for ; Thu, 5 Jan 2012 04:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D38FfA9tMBfq for ; Thu, 5 Jan 2012 04:06:48 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 89B9721F87E3 for ; Thu, 5 Jan 2012 04:06:48 -0800 (PST) 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 q05C6eaN004516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 13:06:40 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q05C6dfW017795; Thu, 5 Jan 2012 13:06:40 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 13:06:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 13:06:36 +0100 Message-ID: In-Reply-To: <76CD132C3ADEF848BD84D028D243C927229F4ED7@szxeml509-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06 Thread-Index: Acya1oQkEkmaA6JvQ7S2g+rIofFNNwwyiw0A References: <76CD132C3ADEF848BD84D028D243C927229F4ED7@szxeml509-mbx.china.huawei.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Jie Dong" , X-OriginalArrivalTime: 05 Jan 2012 12:06:38.0072 (UTC) FILETIME=[7A1C5780:01CCCBA2] Subject: Re: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 12:06:49 -0000 Jie, Hi Sorry for the long delay in replying to this set of comments - but it has been a rather busy time, and I have finally been freed up a little to address the Ring Protection document. Please see my replies in-line below. I will, hopefully submit an updated version of the draft based on the resolution of your comments (as soon as everyone is satisfied with the resolutions). Thank you, yaacov -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Jie Dong Sent: Friday, November 04, 2011 11:46 AM To: mpls@ietf.org Subject: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06 Hi,=20 Here are some comments on this tp ring protection draft.=20 1. This draft describes the label stack operation of each protection mechanism. For better clarity, I would recommend using the same protected LSP as example when possible, i.e. using LSR-B as the ingress and LSR-E as the egress in all description of p2p protection, and describes the label stack operation from the ingress to the egress. [yw>] I will try to align the examples on p2p protection to use the working path B-A-F in section 2.3 2. Label operation in the last paragraph before 2.3.1, "packets arrive at LSR-B with label [LI], and then send out to LSR-A with [[PA(F)|L1]]". Should B swap the inner label LI with LE, which is expected by the egress LSR-F? [yw>] On the assumption that you mean the paragraph just prior to Section 2.3.1, you are correct and I will correct the text, thank you! 3. Label stack operation of wrapping in sec 2.3.2 needs some clarification: "1. The data packet arrives at LSR-A with label stack [LI+S] (i.e. top label from the LSP and bottom-of-stack indicator)" If the section takes the protected LSP in figure 1 as example, LSR-A is the ingress of SPME A-F, NOT the ingress of the ring. If the ingress LSR is B, packets arrive at A may contain the label for SPME B-A, and the inner LSP label LI should be swapped on LSR-B. [yw>] To be honest, this is tied to your first question, i.e. we have confused you by referring to a different working path, the working path in this description is the path A-F and not B-A-F, but I will try and align (as I mentioned above) "2. In the normal case (no switching), LSR-A forwards the packet with label stack [PA1(F)|LE+S] (i.e. swap the label for the LSP, to be acceptable to the SPME egress, and push the label for the primary SPME from LSR-A to LSR-F)." "LE" is defined as "the label of the LSP that is expected at the egress point from the ring", but here it is used as the label expected by SPME egress. Since the inner LSP label needs be swapped each time the SPME label is popped, using "LE" for this operation may be confusing. It would be clearer to define a new term for this. [yw>] see my previous comment! 4. In some specifications "+S" is added to the LSP label. Does it also allow carrying PW label or other labels in the label stack? [yw>] This document is based on use of the Linear Protection defined in RFC6378 which is only applicable to LSPs, so I am not sure that I understand the full context and implications of your question. Best regards, Jie _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Jan 5 10:33:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF921F8853 for ; Thu, 5 Jan 2012 10:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEiBdkj3LdL7 for ; Thu, 5 Jan 2012 10:33:21 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1370A21F8854 for ; Thu, 5 Jan 2012 10:33:21 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q05IXA4h012053; Thu, 5 Jan 2012 12:33:13 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 5 Jan 2012 13:33:05 -0500 From: Gregory Mirsky To: Alexander Vainshtein Date: Thu, 5 Jan 2012 13:33:04 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFAAE895QA== Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , Chao Fu Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Jan 2012 18:33:27 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, your analysis is thorough as always. I hope Editors will provide their opin= ions. In the meantime I'll note that in explaining entry and exit condition= s for the Period Misconfiguration Defect text is explititly calls for "expe= cted globally unique Source MEP identifier" which to me is implicit referen= ce to MPLS-TP CV message as it is defined in the Section 3.5 of the RFC 642= 8. AFAIK, CC message does not include MEP ID and I've concluded that the Pe= riod Misconfiguration Defect is not applicable to CCs. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, January 05, 2012 1:36 AM To: Gregory Mirsky Cc: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Greg, I've followed your example and checked Section 5.1.1.3 "Period Misconfigura= tion Defect" in RFC 6371, and I disagree with your reading.. First of all, this document does not distinguish between Connectivity Check= (CC) and Connectivity Verification (CV). It almost explicitly assumes that= the same packet is used for both purposes - at least when we speak about p= roactive CC and CV (because" CC packets" are not mentioned in the text, an= d "CV packets" are always mentioned as "on-demand CV -packets"). And, in pa= rticular, Section 5.1.1.3 refers to "CC-V packets" with CC-V standing for "= Connectivity Check and Connectivity Verification" in the Terminology sectio= n. When it comes to the Period Misconfiguration defect, IMHO the text in RFC 6= 371 admits at least two readings: 1. Transmission period is encoded in the CC-V packets, and the receiv= er compares the received value with its configured one. This reading matche= s the definition of the Unexpected Period defect in Annex I.5 of ITU-T Y.1= 731 (02/08) and is trivial to implement 2. The receiver of CC-V messages evaluates the actual transmission pe= riod of CC-V messages and compares it with the configured value. I cannot = say that such a reading strictly contradicts 6371, but it leaves multiple o= pen questions, e.g.: a. How do you evaluate the transmission period? The receiver has to s= omehow eliminate the PDV effects, and the estimate may depend on the specif= ic elimination method and its parameters b. How do you compare the estimated actual transmission period with th= e configured one? This requires definition of some limits of tolerance etc. Taking into account the history of MPLS-TP, I'd say that the first reading = above looks like matching the intention of the authors/Editors. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= gory Mirsky Sent: Thursday, January 05, 2012 12:36 AM To: David Allan I; Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Dave, et al., I do agree that RFC 6371 might be in need of revision at some time. But I'm= not sure that we're at that point already. I've re-checked Section 5.1.1.3 Period Misconfiguration and it refers to pe= riod of CV message. My understanding that this period is fixed at 1 sec and= since Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range= . So, we're talking not about Period Misconfiguration per se, but about wro= ng frequency of CV messages, message with unique MEP ID, as they are refere= nced in the RFC. Hope I've interpreted the 5.1.1.3 correctly. Regards, Greg ________________________________ From: David Allan I Sent: Wednesday, January 04, 2012 2:13 PM To: Gregory Mirsky; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Greg: I agree that a sudden change in frequency would not happen, and there is an= actual discipline for doing so which 6428 does go into in some detail. A s= udden actual change would be an interesting implementation bug. However I think Sasha is correct in that an Errata to 6371 would clean up m= isconceptions, as much as my first reaction was that it was an informationa= l step in a journey was a not fully defined end. I think the tweaks to addr= ess the first three points could be quite minor. best D ________________________________ From: Gregory Mirsky Sent: Wednesday, January 04, 2012 12:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mes= sages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to = change timers via AdminDown state. Secondly, even if operator prefers this = operation to be more BFD-ish, it will work through P/F sequence and old fre= quency should be used until remote peer acknowledges the change with F bit = in its CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is= , as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave 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_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sasha,
your analysis is thorough as always. I hope Editor= s will=20 provide their opinions. In the meantime I'll note that in explaining entry = and=20 exit conditions for the Period Misconfiguration Defect text is explititly c= alls=20 for "expected globally unique Source MEP identifier" which to me is implici= t=20 reference to MPLS-TP CV message as it is defined in the Section 3.5 of the = RFC=20 6428. AFAIK, CC message does not include MEP ID and I've concluded that the= =20 Period Misconfiguration Defect is not applicable to CCs.
 
  &n= bsp; Regards,
        Greg


From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, Januar= y 05,=20 2012 1:36 AM
To: Gregory Mirsky
Cc: David Allan I; Chao= Fu;=20 mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

Dear=20 Greg,

 

I’ve=20 followed your example and checked Section 5.1.1.3 “Period Misconfi= guration=20 Defect” in RFC 6371= , and=20 I disagree with your reading..

 

First=20 of all, this document does not distinguish between Connectivity Check (CC) = and=20 Connectivity Verification (CV). It almost explicitly assumes that the same= =20 packet is used for both purposes – at least when we speak about proac= tive CC and=20 CV (because” CC packets” are not mentioned  in the text, a= nd “CV packets”=20 are always mentioned as “on-demand CV –packets”). And, in= particular, Section=20 5.1.1.3 refers to “CC-V packets” with CC-V standing for “= Connectivity Check and=20 Connectivity Verification” in the Terminology=20 section.

 

When=20 it comes to the Period Misconfiguration defect, IMHO the text in RFC 6371 a= dmits=20 at least two readings:

1.      = =20 Transmission=20 period is encoded in the CC-V packets, and the receiver compares the receiv= ed=20 value with its configured one. This reading matches the definition of the=20 Unexpected Period defect in  Annex I.5 of ITU-T Y.1731 (02/08) and is= =20 trivial to implement

2.      = =20 The=20 receiver of CC-V messages evaluates the actual transmission period of CC-V= =20 messages and compares it with the configured value.  I cannot say that= such=20 a reading strictly contradicts 6371, but it leaves multiple open questions,= =20 e.g.:

<= ![if !supportLists]>a.      = =20 How=20 do you evaluate the transmission period? The receiver has to somehow elimin= ate=20 the PDV effects, and the estimate may depend on the specific elimination me= thod=20 and its parameters

<= ![if !supportLists]>b.     =20 How=20 do you compare the estimated actual transmission period with the configured= one?=20 This requires definition of some limits of tolerance etc.=

Taking=20 into account the history of MPLS-TP, I’d say that the first reading a= bove looks=20 like matching the intention of the authors/Editors.

 

My=20 2c,

    =20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gr= egory=20 Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: Da= vid=20 Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts i= n RFC=20 6371 and RFC 6428

 

H= i Dave,=20 et al.,

I= do=20 agree that RFC 6371 might be in need of revision at some time. But I'm not = sure=20 that we're at that point already.

I= 've=20 re-checked Section 5.1.1.3 Period Misconfiguration and it refers to period = of CV=20 message. My understanding that this period is fixed at 1 sec and since Dete= ct=20 Multiplier is 1 generation randomized within 0.75 - 0.9 range. So, we're ta= lking=20 not about Period Misconfiguration per se, but about wrong frequency of CV=20 messages, message with unique MEP ID, as they are referenced in the=20 RFC.

 

H= ope=20 I've interpreted the 5.1.1.3 correctly.

 

    R= egards,

        G= reg

 


From:<= /B> David Allan = I=20
Sent: Wednesday, January 04, 2012 2:13 PM
To: Gregory= =20 Mirsky; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in= RFC=20 6371 and RFC 6428

H= i=20 Greg:

 

I= agree=20 that a sudden change in frequency would not happen, and there is an actual= =20 discipline for doing so which 6428 does go into in some detail. A sudden ac= tual=20 change would be an interesting implementation bug.

 

H= owever=20 I think Sasha is correct in that an Errata to 6371 would clean up=20 misconceptions, as much as my first reaction was that it was an information= al=20 step in a journey was a not fully defined end. I think the tweaks to addres= s the=20 first three points could be quite minor.

 

b= est

D=

 


From:<= /B> Gregory Mirs= ky=20
Sent: Wednesday, January 04, 2012 12:09 PM
To: David A= llan=20 I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC = 6371=20 and RFC 6428

D= ear=20 Dave, Chao, et al.

I= think=20 that an BFD peer would not be "suddenly" change frequency of CC messages wh= en=20 running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to change time= rs=20 via AdminDown state. Secondly, even if operator prefers this operation to b= e=20 more BFD-ish, it will work through P/F sequence and old frequency shou= ld be=20 used until remote peer acknowledges the change with F bit in its CC=20 packet.

 

I= 'd note=20 that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is, as I=20 understand, is per RFC 5884/5885.

 

    R= egards,

        G= reg

 


From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Cha= o Fu;=20 mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

H= I=20 Chao:

 

S= ome=20 answers in line...

 


From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ch= ao=20 Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,

 

I have some doubts on RFC 6371 "OAM Framework for= =20 MPLS-Based Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who= can=20 help me to clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
  =20 My doubt: It is said to compare with the locally configured reception p= eriod=20 in the definition, but in the Entry criteria, it is compared with it own=20 CC-V-configured transmission period. Are they same? Just because these two= =20 values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= =20 configured CC-V reception period.   
   And such Period Misconfiguration= Defect=20 is not defined in RFC 6428. Does MPLS TP need it? Why it is not in RFC=20 6428? 

  
T= he=20 short story is that a mismatch is a problem  but not one that many fel= t=20 tearing the service down or forcing a protection switch was a suitable=20 consequent action. It does not indicate an impairment in information transf= er=20 capability, just in the ability to measure it. Hence flag it northbound and= =20 presumably offline action would bring the OAM back into spec. Now as for an= =20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

P= art of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC 6371:
   If a MEP detects a LOC de= fect=20 that is not caused by a period
   misconfiguration, it should = block=20 all the traffic (including also the
   user data packets) that= it=20 receives from the transport path, if this
   consequent action= has=20 been enabled by the operator.
   
   My doubt: Does it mean the period misconfigur= ation=20 should or might cause the LOC? Will the packets be discarded? If not, there= =20 should not be LOC. My opinion is that the period misconfiguration should no= t=20 cause LOC.
 &= nbsp;

T= here=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC 6371:
   Note that the= =20 reception period is the same as the configured transmission=20 rate.
   
   My doubt: Does it mean no need to configure=20 reception period? But many places mention "configured reception period", do= they=20 mean the configured transmission rate?  
   
<= /I>&= nbsp;A=20 configured reception rate would be an expected rate which IMO would be opti= onal.=20 Again an artifact of the original expectation of no handshaking between the= MEPs=20 in establishing a session periodicity and configuration would be the only w= ay=20 such agreement would happen.

 4. In 3.7.3 of RFC 6428:
  It will also communicate sessio= n=20 DOWN to its session peer using CC messages.
  
  <= SPAN=20 style=3D"BACKGROUND: #ffff99">My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

I= t is=20 telling it's peer that it has taken the session into the down state at it's= =20 end. 

S= o=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

R= eceiving=20 ADMIN DOWN or DOWN from a peer will also cause a transition from UP to DOWN= in=20 coordinated session operation.

&= nbsp;5.  In=20 3.7.1 of RFC 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt: Does it mean the BFD session will n= ot be=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
 &nb= sp; Why=20 need P/F here? There is no timer negotiation. I think here the configured=20 transmission rates should be same on both Engpoints, otherwise there are Pe= riod=20 Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.
&= nbsp;P/F=20 is needed as examination of any other slow start mechanism revealed th= at we=20 would have to reinvent what we already had. So there is a handshake to get = from=20 the default to the desired rate.

I= hope=20 this helps

D= ave 

 

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

--_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_-- From Alexander.Vainshtein@ecitele.com Thu Jan 5 10:51:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032A021F8874 for ; Thu, 5 Jan 2012 10:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edyFzvEZZTrP for ; Thu, 5 Jan 2012 10:51:57 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id BD89421F87ED for ; Thu, 5 Jan 2012 10:51:55 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1325789487!51689042!5 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 32354 invoked from network); 5 Jan 2012 18:51:32 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-27.messagelabs.com with SMTP; 5 Jan 2012 18:51:32 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-fa-4f05f241d7c2 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id A5.7B.08306.142F50F4; Thu, 5 Jan 2012 20:56:01 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 5 Jan 2012 20:51:51 +0200 From: Alexander Vainshtein To: Gregory Mirsky , David Allan I , "Italo.Busi@alcatel-lucent.com" Date: Thu, 5 Jan 2012 20:51:32 +0200 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFAAE895QAAAsP+b Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLsWRmVeSWpSXmKPExsUy+dWnL7pOn1j9DQ40slg8PL+d2eLwvKOs Fs+fdDFaHN1qYXFr6UpWB1aP1md7WT1+fb3K5rFz1l12jyVLfjIFsEQ1MNok5uXllySWpCqk pBYn2yoFFGWWJSZXKilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8 lMy8dFslz2B/XQsLU0tdQyU7NWVDY2uukIzMYoVU3dzEzByF3NTi4sT0VAWgSMIW5oy37/ez FfzeyFQx4+oq1gbGrU1MXYycHBICJhJ3Hj1jhbDFJC7cW8/WxcjFISSwk1HixsqZjBDOZEaJ 1ke9LCBVbAK2EptW3wWrEhFYyCgx53QfM0iCWcBZon36HvYuRg4OFgEViTNtUiBhYQELiW8n b4L1ighYSmx6NY0Vwo6SOPW/D+wKXoFAiVkrnrNDLJvDIrHy2TZGkASnQITE8z0dYDYj0Hnf T61hgtglLnHryXyoFwQkluw5zwxhi0q8fPyPFaJeVOJO+3pGiPp8ie6F/1gglglKnJz5hAWi XlLi4IobLBMYxWYhGTsLScssJC0QcQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjZGZO QUlSbrqBkW5+aYleanJmSWpOql5yfu4mRkjaerGD8fYZzUOMAhyMSjy8jxpY/IVYE8uKK3MP MUpyMCmJ8u58y+ovxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3bhVQjjclsbIqtSgfJuUKjIGJ zFLcyfnAVJxXEm9sYICboyTO2538xldIIB2YQrNTUwtSi2DmyHBwKEnwHvsAtEKwKDU9tSIt M6cEIc3EwQlyBg/QGQdBaniLCxJzizPTIfKnGHU5bixYcI5RiCUvPy9VSpx3CkiRAEhRRmke 3BxQDqv/////K0ZxYAAI89aCVPEA8x/cpFdAS5iAlkSJsIAsAeYkuJRUA2Nzk5tM7Cep+1rH 5N14/JYUv5xY7flwGvfXd5yz1Rad3ll9oj9DhW3hCyGbiaEft9YXFb19fOp0svQFRc6NQUpV s+2aF+k/1nzQ8fzC0z8K7aZ//E/f6FB0L65oLnUXvHvikeXBc1cUZp1VXTTvmhvrnbXxYnmX nHym9h4rkC3iqJ6idmypWYISS3FGoqEWc1FxIgC44SLsPAQAAA== Cc: "mpls@ietf.org" , Chao Fu Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Jan 2012 18:51:59 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. I would also be happy to hear the Editors' position on the ambiguous issue -= Dave and Italo, could you please comment? Regarding presence of the globally unique Source MEP identifier in the CC or= CV messages - I suspect that this is just one more case of inconsistency be= tween 6371 (which, IMHO, has been strongly associated with Y.1731) and 6428.= .. should we file one more Errata on that? My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Thursday, January 05, 2012 8:33 PM To: Alexander Vainshtein Cc: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Sasha, your analysis is thorough as always. I hope Editors will provide their opini= ons. In the meantime I'll note that in explaining entry and exit conditions= for the Period Misconfiguration Defect text is explititly calls for "expect= ed globally unique Source MEP identifier" which to me is implicit reference= to MPLS-TP CV message as it is defined in the Section 3.5 of the RFC 6428.= AFAIK, CC message does not include MEP ID and I've concluded that the Perio= d Misconfiguration Defect is not applicable to CCs. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, January 05, 2012 1:36 AM To: Gregory Mirsky Cc: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Greg, I=92ve followed your example and checked Section 5.1.1.3 =93Period Misconfig= uration Defect=94 in RFC 6371, and I disagree with your reading.. First of all, this document does not distinguish between Connectivity Check= (CC) and Connectivity Verification (CV). It almost explicitly assumes that= the same packet is used for both purposes =96 at least when we speak about= proactive CC and CV (because=94 CC packets=94 are not mentioned in the tex= t, and =93CV packets=94 are always mentioned as =93on-demand CV =96packets= =94). And, in particular, Section 5.1.1.3 refers to =93CC-V packets=94 with= CC-V standing for =93Connectivity Check and Connectivity Verification=94 in= the Terminology section. When it comes to the Period Misconfiguration defect, IMHO the text in RFC 63= 71 admits at least two readings: 1. Transmission period is encoded in the CC-V packets, and the receive= r compares the received value with its configured one. This reading matches= the definition of the Unexpected Period defect in Annex I.5 of ITU-T Y.173= 1 (02/08) and is trivial to implement 2. The receiver of CC-V messages evaluates the actual transmission per= iod of CC-V messages and compares it with the configured value. I cannot sa= y that such a reading strictly contradicts 6371, but it leaves multiple open= questions, e.g.: a. How do you evaluate the transmission period? The receiver has to so= mehow eliminate the PDV effects, and the estimate may depend on the specific= elimination method and its parameters b. How do you compare the estimated actual transmission period with the= configured one? This requires definition of some limits of tolerance etc. Taking into account the history of MPLS-TP, I=92d say that the first reading= above looks like matching the intention of the authors/Editors. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg= ory Mirsky Sent: Thursday, January 05, 2012 12:36 AM To: David Allan I; Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Dave, et al., I do agree that RFC 6371 might be in need of revision at some time. But I'm= not sure that we're at that point already. I've re-checked Section 5.1.1.3 Period Misconfiguration and it refers to per= iod of CV message. My understanding that this period is fixed at 1 sec and s= ince Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. S= o, we're talking not about Period Misconfiguration per se, but about wrong f= requency of CV messages, message with unique MEP ID, as they are referenced= in the RFC. Hope I've interpreted the 5.1.1.3 correctly. Regards, Greg ________________________________ From: David Allan I Sent: Wednesday, January 04, 2012 2:13 PM To: Gregory Mirsky; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi Greg: I agree that a sudden change in frequency would not happen, and there is an= actual discipline for doing so which 6428 does go into in some detail. A su= dden actual change would be an interesting implementation bug. However I think Sasha is correct in that an Errata to 6371 would clean up mi= sconceptions, as much as my first reaction was that it was an informational= step in a journey was a not fully defined end. I think the tweaks to addres= s the first three points could be quite minor. best D ________________________________ From: Gregory Mirsky Sent: Wednesday, January 04, 2012 12:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mess= ages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to ch= ange timers via AdminDown state. Secondly, even if operator prefers this ope= ration to be more BFD-ish, it will work through P/F sequence and old frequen= cy should be used until remote peer acknowledges the change with F bit in it= s CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is,= as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao= Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? T= hanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception per= iod in the definition, but in the Entry criteria, it is compared with it own= CC-V-configured transmission period. Are they same? Just because these two= values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable cons= equent action. It does not indicate an impairment in information transfer ca= pability, just in the ability to measure it. Hence flag it northbound and pr= esumably offline action would bring the OAM back into spec. Now as for an im= plementation explicitly modifying the periodicity to an unacceptable value,= how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed aft= er the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. My= opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the per= iodicity of CC/CV to less than 1/3 of the expected rate so that one got an L= OC. Once a lower rate BFD PDU was received that advertised the changed rate,= the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmission= rate. My doubt: Does it mean no need to configure reception period? But many pl= aces mention "configured reception period", do they mean the configured tran= smission rate? A configured reception rate would be an expected rate which IMO would be op= tional. Again an artifact of the original expectation of no handshaking betw= een the MEPs in establishing a session periodicity and configuration would b= e the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC message= s. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session DO= WN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state at= it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are loc= al inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from U= P to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the confi= gured values but use the default values? What the values will be filled in t= he packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the config= ured transmission rates should be same on both Engpoints, otherwise there ar= e Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed tha= t we would have to reinvent what we already had. So there is a handshake to= get from the default to the desired rate. I hope this helps Dave This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Dear Greg,
Lots of thanks for a prompt response.
 
I would also be happy to hear the Editor= s' position on the ambiguous issue - Dave and  Italo= , could you please comment?
 
Regarding presence of the gl= obally unique Source MEP identifier in the CC or CV messages - I suspect tha= t this is just one more case of inconsistency between 6371 (which, IMHO, has= been strongly associated with Y.1731) and 6428... should we file one more Errata on that?
 
My 2c,
     Sasha
 

From: Gregory Mirs= ky [gregory.mirsky@ericsson.com]
Sent: Thursday, January 05, 2012 8:33 PM
To: Alexander Vainshtein
Cc: David Allan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Sasha,
your analysis is thorough as always= . I hope Editors will provide their opinions. In the meantime I'll note that= in explaining entry and exit conditions for the Period Misconfiguration Defect text is explititly calls for "e= xpected globally unique Source MEP identifier" which to me is implicit= reference to MPLS-TP CV message as it is defined in the Section 3.5 of the= RFC 6428. AFAIK, CC message does not include MEP ID and I've concluded that the Period Misconfiguration Defect is not ap= plicable to CCs.
 
 &nb= sp;  Regards,
 &nb= sp;      Greg


From: Alexander Vainshtein [mailto:A= lexander.Vainshtein@ecitele.com]
Sent: Thursday, January 05, 2012 1:36 AM
To: Gregory Mirsky
Cc: David Allan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Greg,

 

I=92ve followed your example and checked Sec= tion 5.1.1.3 =93Period Misconfiguration Defect=94 in RFC 6371, and I disagree with your reading..

 

First of all, this document does not disting= uish between Connectivity Check (CC) and Connectivity Verification (CV). It= almost explicitly assumes that the same packet is used for both purposes =96 at least when we speak about proa= ctive CC and CV (because=94 CC packets=94 are not mentioned  in the tex= t, and =93CV packets=94 are always mentioned as =93on-demand CV =96packets= =94). And, in particular, Section 5.1.1.3 refers to =93CC-V packets=94 with CC-V standing for =93Connectivity Check and Connect= ivity Verification=94 in the Terminology section.

 

When it comes to the Period Misconfiguration= defect, IMHO the text in RFC 6371 admits at least two readings:

1.=      &n= bsp; Transmission period i= s encoded in the CC-V packets, and the receiver compares the received value= with its configured one. This reading matches the definition of the Unexpected Period defect in  Annex I.5 o= f ITU-T Y.1731 (02/08) and is trivial to implement

2.=      &n= bsp; The receiver of CC-V= messages evaluates the actual transmission period of CC-V messages and comp= ares it with the configured value.  I cannot say that such a reading strictly contradicts 6371, but it le= aves multiple open questions, e.g.:

a.  &= nbsp;    How do you evaluate t= he transmission period? The receiver has to somehow eliminate the PDV effect= s, and the estimate may depend on the specific elimination method and its parameters

b.  &= nbsp;   How do you compare th= e estimated actual transmission period with the configured one? This require= s definition of some limits of tolerance etc.

Taking into account the history of MPLS-TP,= I=92d say that the first reading above looks like matching the intention of= the authors/Editors.

 

My 2c,

     Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On Behalf Of Gregory Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: David Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

 

Hi Dave, et al.,

I do agree that RFC 6371 might be in need of revi= sion at some time. But I'm not sure that we're at that point already.=

I've re-checked Section 5.1.1.3 Period Misconfigu= ration and it refers to period of CV message. My understanding that this per= iod is fixed at 1 sec and since Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. So, we're ta= lking not about Period Misconfiguration per se, but about wrong frequency of= CV messages, message with unique MEP ID, as they are referenced in the RFC.=

 

Hope I've interpreted the 5.1.1.3 correctly.

 

    Regards,

        Greg

 


From: David Allan I
Sent: Wednesday, January 04, 2012 2:13 PM
To: Gregory Mirsky; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi Greg:

 

I agree that a sudden change in frequency would n= ot happen, and there is an actual discipline for doing so which 6428 does go= into in some detail. A sudden actual change would be an interesting implementation bug.

 

However I think Sasha is correct in that an Errat= a to 6371 would clean up misconceptions, as much as my first reaction was th= at it was an informational step in a journey was a not fully defined end. I think the tweaks to address the fi= rst three points could be quite minor.

 

best

D

 


From: Gregory Mirsky
Sent: Wednesday, January 04, 2012 12:09 PM
To: David Allan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Dave, Chao, et al.

I think that an BFD peer would not be "sudde= nly" change frequency of CC messages when running MPLS-TP CC-CV (case #= 2). Firstly, there's suggestion to change timers via AdminDown state. Secondly, even if operator prefers this operation to b= e more BFD-ish, it will work through P/F sequence and old frequency sho= uld be used until remote peer acknowledges the change with F bit in its CC p= acket.

 

I'd note that RFC 6428 addresses CC-CV while pure= CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.

 

    Regards,

        Greg

 


From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:

 

Some answers in line...

 


From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi all,

 

I have some doubts on RFC 6371 "OAM Framewo= rk for MPLS-Based Transport" and RFC 6428 "CC, CV, and RDI for MPL= S-TP".  Who can help me to clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect:    If proactive CC-V OAM packets are received with the expected gl= obally
   unique Source MEP identifier but with a transmission period dif= ferent
   than the locally configured reception period, then a CC-V perio= d
   misconfiguration defect is detected.
   o  Entry criteria: A MEP receives a CC-V proactive packet= with the
      expected globally unique Source MEP identifie= r but with a
      transmission period different than its own CC= -V-configured
      transmission period.
   
   My doubt: It is said to= compare with the locally configured reception period in the definition, but= in the Entry criteria, it is compared with it own CC-V-configured transmiss= ion period. Are they same? Just because these two values should be same? For LOC in 5.1.1.1, it also uses the receiving M= EP's configured CC-V reception period.   
   And such Period Misconf= iguration Defect is not defined in RFC 6428. Does MPLS TP need it? Why it is= not in RFC 6428? 

  
The short story is that a mismatch is a problem  but not one that m= any felt tearing the service down or forcing a protection switch was a suita= ble consequent action. It does not indicate an impairment in information transfer capability, just in the ability to me= asure it. Hence flag it northbound and presumably offline action would bring= the OAM back into spec. Now as for an implementation explicitly modifying t= he periodicity to an unacceptable value, how the other end reacts is implementation or policy dependant.

Part of this is a consequence of beleiving that some of the BFD hands= haking could be dispensed with at the time 6371 was written. That view chang= ed after the BFD WG did a thorough review of what became 6428.

 2. In 5.1.2 of RFC 6371:
   If a MEP detects a LOC defect that is not caused by a period    misconfiguration, it should block all the traffic (including al= so the
   user data packets) that it receives from the transport path, if= this
   consequent action has been enabled by the operator.
   
   My doubt: Does it mean= the period misconfiguration should or might cause the LOC? Will the packets= be discarded? If not, there should not be LOC. My opinion is that the perio= d misconfiguration should not cause LOC.
  

There could be a corner cases if without any warning one end red= uced the periodicity of CC/CV to less than 1/3 of the expected rate so that= one got an LOC. Once a lower rate BFD PDU was received that advertised the changed rate, the receiver could adapt= vs. staying in a defect state.

  
3. In 5.1.3 of RFC 6371:
   Note that the reception period is the same as the configured tr= ansmission rate.
   
   My doubt: Does it mean= no need to configure reception period? But many places mention "config= ured reception period", do they mean the configured transmission rate?<= /span>  
   
 A configured reception rate would be an expected rate w= hich IMO would be optional. Again an artifact of the original expectation of= no handshaking between the MEPs in establishing a session periodicity and configuration would be the only way= such agreement would happen.

 4. In 3.7.3 of RFC 6428:
  It will also communicate session DOWN to its session peer using CC me= ssages.
  
  My doubt: Does it mean only n= otify the peer to bring the session DOWN but the local session will not be D= OWN? Or we should bring the local session DOWN also? But it is not in the BF= D State machine of Figure 7.
 

It is telling it's peer that it has taken the session into the do= wn state at it's end. 

So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN= are local inputs to the state machine that will transition it from UP to DO= WN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a transition= from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: Session Initiation a= nd Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modif= y the
   periodicity of control message exchange from their default rate= s to
   the desired rates and to set the detect multiplier to 3.
   
   My doubt: Does it mean= the BFD session will not be started with the configured values but use the= default values? What the values will be filled in the packet? The default o= nes or the configured values?
   Why need P/F here? There is no timer negotiation. I think h= ere the configured transmission rates should be same on both Engpoints, othe= rwise there are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 63= 71.

 P/F is needed as examination of any other slow sta= rt mechanism revealed that we would have to reinvent what we already had. So= there is a handshake to get from the default to the desired rate.

I hope this helps

Dave 

 

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

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

--_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_-- From gregory.mirsky@ericsson.com Thu Jan 5 11:34:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9F21F8897 for ; Thu, 5 Jan 2012 11:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixa3c9IjG4T1 for ; Thu, 5 Jan 2012 11:34:34 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A756221F8894 for ; Thu, 5 Jan 2012 11:34:34 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q05JYJKi026487; Thu, 5 Jan 2012 13:34:28 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 5 Jan 2012 14:34:19 -0500 From: Gregory Mirsky To: Alexander Vainshtein Date: Thu, 5 Jan 2012 14:34:17 -0500 Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428 Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAAGn42QAAWrvVw Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF132299351F6EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , Chao Fu Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 05 Jan 2012 19:34:40 -0000 --_000_FE60A4E52763E84B935532D7D9294FF132299351F6EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, immenesly appreciate your input. My statement in question was based on my interpretation of Section 3.1 of t= he RFC 6428. The very first paragraph suggests that CC-only mode of MPLS-TP OAM may be s= upported "via protocols and procedures described in RFC 5885 [7] with AC= H channel 7". And the second paragraph outlines interoperation with the RFC 5884, i.e. IP= /UDP encapsulation of BFD over LSP/PW. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, January 05, 2012 12:57 AM To: Gregory Mirsky Cc: David Allan I; Chao Fu; mpls@ietf.org Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Greg, Lots of thanks for a prompt response. You've said that "pure CC mode of MPLS-TP OAM is, as I understand, is per R= FC 5884/5885". I tend to disagree with statement on both counts. RFC 5884 in its Section 7 "Encapsulatio= n" explicitly states: The BFD Control packet sent by the ingress LSR MUST be a UDP packet with a well-known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. The source IP address is a routable address of the sender. The destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following exception. If the FEC is an LDP IP FEC, the ingress LSR may discover multiple alternate paths to the egress LSR for this FEC using LSP Ping traceroute. In this case, the destination IP address, used in a BFD session established for one such alternate path, is the address in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 discovered by LSP Ping traceroute [RFC4379] to exercise that particular alternate path. I suspect that the highlighted text does not sit well with MPLS-TP with its= emphasis on independence from IP. RFC 5885 in the part that describes PW-ACH encapsulation for the BFD contro= l packets (without IP/UDP headers) could be easily reused in RFC 6428. However, these documents have defined different ACH types for BFD packets: * RFC 5885 uses type 0x0007 for CC * RFC 6428 uses type 0x0022 for CC. Taking into account that PWs are supposed to be part of MPLS-TP, this looks= a bit fishy to me, but I am not sure what could be done about that. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= gory Mirsky Sent: Wednesday, January 04, 2012 10:09 PM To: David Allan I; Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 Dear Dave, Chao, et al. I think that an BFD peer would not be "suddenly" change frequency of CC mes= sages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to = change timers via AdminDown state. Secondly, even if operator prefers this = operation to be more BFD-ish, it will work through P/F sequence and old fre= quency should be used until remote peer acknowledges the change with F bit = in its CC packet. I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is= , as I understand, is per RFC 5884/5885. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Tuesday, January 03, 2012 2:49 PM To: Chao Fu; mpls@ietf.org Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 HI Chao: Some answers in line... ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha= o Fu Sent: Wednesday, December 28, 2011 6:51 PM To: mpls@ietf.org Subject: [mpls] Some doubts in RFC 6371 and RFC 6428 Hi all, I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and= RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify them? = Thanks a lot! 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected. o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period. My doubt: It is said to compare with the locally configured reception pe= riod in the definition, but in the Entry criteria, it is compared with it o= wn CC-V-configured transmission period. Are they same? Just because these t= wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME= P's configured CC-V reception period. And such Period Misconfiguration Defect is not defined in RFC 6428. Does= MPLS TP need it? Why it is not in RFC 6428? The short story is that a mismatch is a problem but not one that many felt= tearing the service down or forcing a protection switch was a suitable con= sequent action. It does not indicate an impairment in information transfer = capability, just in the ability to measure it. Hence flag it northbound and= presumably offline action would bring the OAM back into spec. Now as for a= n implementation explicitly modifying the periodicity to an unacceptable va= lue, how the other end reacts is implementation or policy dependant. Part of this is a consequence of beleiving that some of the BFD handshaking= could be dispensed with at the time 6371 was written. That view changed af= ter the BFD WG did a thorough review of what became 6428. 2. In 5.1.2 of RFC 6371: If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator. My doubt: Does it mean the period misconfiguration should or might cause= the LOC? Will the packets be discarded? If not, there should not be LOC. M= y opinion is that the period misconfiguration should not cause LOC. There could be a corner cases if without any warning one end reduced the pe= riodicity of CC/CV to less than 1/3 of the expected rate so that one got an= LOC. Once a lower rate BFD PDU was received that advertised the changed ra= te, the receiver could adapt vs. staying in a defect state. 3. In 5.1.3 of RFC 6371: Note that the reception period is the same as the configured transmissio= n rate. My doubt: Does it mean no need to configure reception period? But many p= laces mention "configured reception period", do they mean the configured tr= ansmission rate? A configured reception rate would be an expected rate which IMO would be o= ptional. Again an artifact of the original expectation of no handshaking be= tween the MEPs in establishing a session periodicity and configuration woul= d be the only way such agreement would happen. 4. In 3.7.3 of RFC 6428: It will also communicate session DOWN to its session peer using CC messag= es. My doubt: Does it mean only notify the peer to bring the session DOWN but= the local session will not be DOWN? Or we should bring the local session D= OWN also? But it is not in the BFD State machine of Figure 7. It is telling it's peer that it has taken the session into the down state a= t it's end. So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo= cal inputs to the state machine that will transition it from UP to DOWN. Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from = UP to DOWN in coordinated session operation. 5. In 3.7.1 of RFC 6428: Session Initiation and Modification Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1 second, and the detect multiplier =3D 3. Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3. My doubt: Does it mean the BFD session will not be started with the conf= igured values but use the default values? What the values will be filled in= the packet? The default ones or the configured values? Why need P/F here? There is no timer negotiation. I think here the confi= gured transmission rates should be same on both Engpoints, otherwise there = are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. P/F is needed as examination of any other slow start mechanism revealed th= at we would have to reinvent what we already had. So there is a handshake t= o get from the default to the desired rate. I hope this helps Dave 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_FE60A4E52763E84B935532D7D9294FF132299351F6EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sasha,
immenesly appreciate your input.
My statement in question was based on my interpret= ation of=20 Section 3.1 of the RFC 6428.
The very first paragraph suggests that CC-only mod= e of=20 MPLS-TP OAM may be supported "via protocols and procedures described i= n RFC=20 5885 [7] with ACH channel 7".
And the second paragraph outlines interoperation w= ith the=20 RFC 5884, i.e. IP/UDP encapsulation of BFD over LSP/PW.
 
  &n= bsp; Regards,
        Greg


From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, Januar= y 05,=20 2012 12:57 AM
To: Gregory Mirsky
Cc: David Allan I; Cha= o Fu;=20 mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

Dear=20 Greg,

Lots=20 of thanks for a prompt response.

 

You’ve=20 said that “p= ure CC=20 mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885”.

 

I=20 tend to disagree with statement on both counts.

 

 

RFC 5884 in its Section 7=20 “Encapsulation” explicitly states:

 

   The BFD Control packet=
 sent by the ingress LSR MUST be a UDP packet
 &n=
bsp; with a well-known destination port 3784 [BFD-IP] and a source port
   assigned by the sender as per the proc=
edures in [BFD-IP].  The source
   IP address is a routable address of the =
sender.  The destination IP
   address MUST be randomly chose=
n from the 127/8 range for IPv4 and
   from the 0:0:0:0:0:FFFF:7F0=
0/104 range for IPv6 with =
the following
   exception.  =
If the FEC is an LDP IP FEC, the ingress LSR may discover=
   multiple alternate paths to the egress LSR for t=
his FEC using LSP
   Ping tracerou=
te.  In this case, the destination IP address, used in a
   BFD session established for one such alterna=
te path, is the address
   in the =
127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6
   discovered by LSP Ping traceroute [RFC4379] to exercise that<=
o:p>
   particular alternate path.
 

I=20 suspect that the highlighted text does not sit well with MPLS-TP with its=20 emphasis on independence from IP.

 

RFC=20 5885 in the part that describes PW-ACH encapsulation for the BFD control pa= ckets=20 (without IP/UDP headers) could be easily reused in RFC=20 6428.

However,=20 these documents have defined different ACH types for BFD=20 packets:

·      &= nbsp; =20 RFC=20 5885 uses type 0x0007 for CC

·      &= nbsp; =20 RFC=20 6428 uses type 0x0022 for CC.

 

Taking=20 into account that PWs are supposed to be part of MPLS-TP, this looks a bit = fishy=20 to me, but I am not sure what could be done about that.

 

Regards,

    =20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gr= egory=20 Mirsky
Sent: Wednesday, January 04, 2012 10:09 PM
To: D= avid=20 Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts i= n RFC=20 6371 and RFC 6428

 

D= ear=20 Dave, Chao, et al.

I= think=20 that an BFD peer would not be "suddenly" change frequency of CC messages wh= en=20 running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to change time= rs=20 via AdminDown state. Secondly, even if operator prefers this operation to b= e=20 more BFD-ish, it will work through P/F sequence and old frequency shou= ld be=20 used until remote peer acknowledges the change with F bit in its CC=20 packet.

 

I= 'd note=20 that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is, as I=20 understand, is per RFC 5884/5885.

 

    R= egards,

        G= reg

 


From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Cha= o Fu;=20 mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC= =20 6428

H= I=20 Chao:

 

S= ome=20 answers in line...

 


From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ch= ao=20 Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,

 

I have some doubts on RFC 6371 "OAM Framework for= =20 MPLS-Based Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who= can=20 help me to clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
   If proactive CC-V OAM packets are received with the= =20 expected globally
   unique Source MEP identifier but with a=20 transmission period different
   than the locally configured=20 reception period, then a CC-V period
   misconfiguration defec= t is=20 detected.
   o  Entry criteria: A MEP receives a CC-V=20 proactive packet with the
      expected global= ly=20 unique Source MEP identifier but with a
     =20 transmission period different than its own=20 CC-V-configured
      transmission=20 period.
   
  =20 My doubt: It is said to compare with the locally configured reception p= eriod=20 in the definition, but in the Entry criteria, it is compared with it own=20 CC-V-configured transmission period. Are they same? Just because these two= =20 values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's= =20 configured CC-V reception period.   
   And such Period Misconfiguration= Defect=20 is not defined in RFC 6428. Does MPLS TP need it? Why it is not in RFC=20 6428? 

  
T= he=20 short story is that a mismatch is a problem  but not one that many fel= t=20 tearing the service down or forcing a protection switch was a suitable=20 consequent action. It does not indicate an impairment in information transf= er=20 capability, just in the ability to measure it. Hence flag it northbound and= =20 presumably offline action would bring the OAM back into spec. Now as for an= =20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

P= art of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

 2. In 5.1.2 of RFC 6371:
   If a MEP detects a LOC de= fect=20 that is not caused by a period
   misconfiguration, it should = block=20 all the traffic (including also the
   user data packets) that= it=20 receives from the transport path, if this
   consequent action= has=20 been enabled by the operator.
   
   My doubt: Does it mean the period misconfigur= ation=20 should or might cause the LOC? Will the packets be discarded? If not, there= =20 should not be LOC. My opinion is that the period misconfiguration should no= t=20 cause LOC.
 &= nbsp;

T= here=20 could be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

  
3. In 5.1.3 of RFC 6371:
   Note that the= =20 reception period is the same as the configured transmission=20 rate.
   
   My doubt: Does it mean no need to configure=20 reception period? But many places mention "configured reception period", do= they=20 mean the configured transmission rate?  
   
<= /I>&= nbsp;A=20 configured reception rate would be an expected rate which IMO would be opti= onal.=20 Again an artifact of the original expectation of no handshaking between the= MEPs=20 in establishing a session periodicity and configuration would be the only w= ay=20 such agreement would happen.

 4. In 3.7.3 of RFC 6428:
  It will also communicate sessio= n=20 DOWN to its session peer using CC messages.
  
  <= SPAN=20 style=3D"BACKGROUND: #ffff99">My doubt: Does it mean only notify the peer t= o bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure=20 7.
 

I= t is=20 telling it's peer that it has taken the session into the down state at it's= =20 end. 

S= o=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

R= eceiving=20 ADMIN DOWN or DOWN from a peer will also cause a transition from UP to DOWN= in=20 coordinated session operation.

&= nbsp;5.  In=20 3.7.1 of RFC 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx =3D 1 second,= MinTx=20 >=3D 1
   second, and the detect multiplier =3D 3.

   Once in the UP state, Poll/Final discipline is used to modi= fy=20 the
   periodicity of control message exchange from their defa= ult=20 rates to
   the desired rates and to set the detect multiplier= to=20 3.
   
   My doubt: Does it mean the BFD session will n= ot be=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
 &nb= sp; Why=20 need P/F here? There is no timer negotiation. I think here the configured=20 transmission rates should be same on both Engpoints, otherwise there are Pe= riod=20 Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.
&= nbsp;P/F=20 is needed as examination of any other slow start mechanism revealed th= at we=20 would have to reinvent what we already had. So there is a handshake to get = from=20 the default to the desired rate.

I= hope=20 this helps

D= ave 

 

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

--_000_FE60A4E52763E84B935532D7D9294FF132299351F6EUSAACMS0715e_-- From gregimirsky@gmail.com Thu Jan 5 15:37:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFB521F87E4; Thu, 5 Jan 2012 15:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKFaWc+DYxK; Thu, 5 Jan 2012 15:37:23 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E41921F87CF; Thu, 5 Jan 2012 15:37:23 -0800 (PST) Received: by obcuz6 with SMTP id uz6so1432479obc.31 for ; Thu, 05 Jan 2012 15:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mKlAEpSfcMZ7MomThAlsMYiSUehCbb9vGtuAoBi0p8c=; b=KeNoJZvTeIYAaYyiVTqjp7tgoGB1LqbnqntJTSvpumkEyV0kd72nRc82sYmiKAJ6iw hpXsc1UmbdfzKXktQiyjcSZ7/eJicxF7Q09c9HPgum9yftj5S5tOMCjuGezPXpkojZPZ W99zMB83XR3AFlgTdX2vPOyvzKAVEnSiqtZxo= MIME-Version: 1.0 Received: by 10.182.193.42 with SMTP id hl10mr3066219obc.61.1325806640232; Thu, 05 Jan 2012 15:37:20 -0800 (PST) Received: by 10.182.38.72 with HTTP; Thu, 5 Jan 2012 15:37:20 -0800 (PST) In-Reply-To: <0D57BB9E-5415-44CF-A553-A61E9E86E49E@lucidvision.com> References: <4F0342A9.1000301@cisco.com> <0D57BB9E-5415-44CF-A553-A61E9E86E49E@lucidvision.com> Date: Thu, 5 Jan 2012 15:37:20 -0800 Message-ID: From: Greg Mirsky To: Thomas Nadeau Content-Type: multipart/alternative; boundary=f46d044786abd4f87004b5d069c1 Cc: mpls@ietf.org, ccamp@ietf.org, Jaihari Kalijanakiraman , stbryant@cisco.com Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 05 Jan 2012 23:37:24 -0000 --f46d044786abd4f87004b5d069c1 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom, et al., I had to refresh my recollection of the discussion in Taipei. According to minutes we don't have the decision regarding the use of MIBs to configure MPLS-TP objects. Somewhere in my memory stuck that the proposal was to limit new MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or one of options chairs and the WG is looking into. Regards, Greg On Tue, Jan 3, 2012 at 11:03 AM, Thomas Nadeau wrote: > > Stewart, > > The question of whether or not to allow "configuration" via the OAM > protocols (or protocol extensions) was something I raised several months > ago in PWE3, although it was also discussed in MPLS as I recall in Taipei > as well. It seems to have arisen again. The conclusions in PWE3 were to > allow configuration of only OAM-related things (i.e.: not allowing > expansion of the protocols for general configuration). Presumably > configuration via MIBs there is still okay. In MPLS I recall the chairs > stating that configuration was a thing reserved for NetConf when the > question of MIB-based configuration was raised for WG MIB drafts in general > (and in particular WRT to the MPLS-TP MIBs). Those positions seem > slightly at odds with each other. And now your answer now seems > inconsistent with those as well. > > Can we get a single answer from the ADs/IESG on this that pertains > to all MPLS-TP related work? > > --Tom > > > On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote: > > > > >> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for > MPLS-TP*"? > >> > > Without prejudice to any decisions on Y.1731 and MPLS-TP. > > > > Wouldn't such a MIB be a derivative of the Y.1731 MIB? > > > > 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 > --f46d044786abd4f87004b5d069c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Tom, et al.,
I had to refresh my recollection of the discussion in = Taipei. According to minutes we don't have the decision regarding the u= se of MIBs to configure MPLS-TP objects. Somewhere in my memory stuck that = the proposal was to limit new MPLS-TP MIBs to R/O and I wonder if it is sel= f-inflicted memory or one of options chairs and the WG is looking into.

Regards,
Greg

On Tue, Jan 3, 2012 = at 11:03 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

=A0 =A0 =A0 =A0Stewart,

=A0 =A0 =A0 =A0The question of whether or not to allow "configuration= " via the OAM protocols (or protocol extensions) was something I raise= d several months ago in PWE3, although it was also discussed in MPLS as I r= ecall in Taipei as well. It seems to have arisen again. =A0 The conclusions= in PWE3 were to allow configuration of only OAM-related things (i.e.: not = allowing expansion of the protocols for general configuration). Presumably = configuration via MIBs there is still okay. In MPLS I recall the chairs sta= ting that configuration was a thing reserved for NetConf when the question = of MIB-based configuration was raised for WG MIB drafts in general (and in = particular WRT to the MPLS-TP MIBs). =A0 =A0Those positions seem slightly a= t odds with each other. =A0And now your answer now seems inconsistent with = those as well.

=A0 =A0 =A0 =A0Can we get a single answer from the ADs/IESG on this that p= ertains to all MPLS-TP related work?

=A0 =A0 =A0 =A0--Tom


On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote:

>
>> 2. Will this MIB be enhanced also to configure "*Y.1731 based= OAM for MPLS-TP*"?
>>
> Without prejudice to any decisions on Y.1731 and MPLS-TP.
>
> Wouldn't such a MIB be a derivative of the Y.1731 MIB?
>
> Stewart
> _______________________________________________
> 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

--f46d044786abd4f87004b5d069c1-- From aldrin.ietf@gmail.com Thu Jan 5 15:51:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824E21F88E9; Thu, 5 Jan 2012 15:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIjikDguC5LS; Thu, 5 Jan 2012 15:51:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 007B021F88E6; Thu, 5 Jan 2012 15:51:51 -0800 (PST) Received: by iabz21 with SMTP id z21so1827144iab.31 for ; Thu, 05 Jan 2012 15:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=LS6vWWI9RzQz5wbeKJiiQToEbi8EBa41IE3IC4fxEnc=; b=cfjsf24bqxAORj5fxQ1uLfjKa97jQgmygZzfKRdg5Sz8QSy8w2FqaTCJCkVW36DCtE UIAse7HQi6pjqeE+b1Adv2K8YrIt5bj5y+P7xEgusO7mszKznHPyLTPm40g4NteY9zze 0gJn50fS4fi4hHI5Eqv1zUXzIaw6hbrqoAxpg= Received: by 10.42.76.66 with SMTP id d2mr4127258ick.7.1325807511620; Thu, 05 Jan 2012 15:51:51 -0800 (PST) Received: from [192.168.253.142] ([12.207.18.42]) by mx.google.com with ESMTPS id cv10sm121249187igc.0.2012.01.05.15.51.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 15:51:50 -0800 (PST) References: <4F0342A9.1000301@cisco.com> <0D57BB9E-5415-44CF-A553-A61E9E86E49E@lucidvision.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-754B4705-EC6D-45C3-9258-619D77DDE0CC Message-Id: <0EED0879-0913-4B65-B6C1-B3DDA4DA9F83@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Date: Thu, 5 Jan 2012 15:51:50 -0800 To: Greg Mirsky Cc: "stbryant@cisco.com" , "ccamp@ietf.org" , Jaihari Kalijanakiraman , "mpls@ietf.org" Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 05 Jan 2012 23:51:53 -0000 --Apple-Mail-754B4705-EC6D-45C3-9258-619D77DDE0CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Greg, The question was in fact got asked over email by WG chairs, and also by me, w= hen I presented at Quebec and Taipei. The decision was still inconclusive, t= hough the strongest indication given thus far is "TP MIB's should be readonl= y, albeit OAM configuration like Bfd, ping etc". The other comment George ga= ve at Taipei was "Netconf will be used for configuration". I have sent a request to WG chairs, after Taipei, to provide a conclusive an= swer, so that, we could update the drafts accordingly. Yet to receive a answ= er though. HTH, Sam Sent from my iPad On Jan 5, 2012, at 3:37 PM, Greg Mirsky wrote: > Dear Tom, et al., > I had to refresh my recollection of the discussion in Taipei. According to= minutes we don't have the decision regarding the use of MIBs to configure M= PLS-TP objects. Somewhere in my memory stuck that the proposal was to limit n= ew MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or one of= options chairs and the WG is looking into. >=20 > Regards, > Greg >=20 > On Tue, Jan 3, 2012 at 11:03 AM, Thomas Nadeau w= rote: >=20 > Stewart, >=20 > The question of whether or not to allow "configuration" via the OAM= protocols (or protocol extensions) was something I raised several months ag= o in PWE3, although it was also discussed in MPLS as I recall in Taipei as w= ell. It seems to have arisen again. The conclusions in PWE3 were to allow c= onfiguration of only OAM-related things (i.e.: not allowing expansion of the= protocols for general configuration). Presumably configuration via MIBs the= re is still okay. In MPLS I recall the chairs stating that configuration was= a thing reserved for NetConf when the question of MIB-based configuration w= as raised for WG MIB drafts in general (and in particular WRT to the MPLS-TP= MIBs). Those positions seem slightly at odds with each other. And now y= our answer now seems inconsistent with those as well. >=20 > Can we get a single answer from the ADs/IESG on this that pertains t= o all MPLS-TP related work? >=20 > --Tom >=20 >=20 > On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote: >=20 > > > >> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for M= PLS-TP*"? > >> > > Without prejudice to any decisions on Y.1731 and MPLS-TP. > > > > Wouldn't such a MIB be a derivative of the Y.1731 MIB? > > > > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-754B4705-EC6D-45C3-9258-619D77DDE0CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Greg,

The question was in fact got asked over email by WG chairs, and also= by me, when I presented at Quebec and Taipei. The decision was still inconc= lusive, though the strongest indication given thus far is "TP MIB's should b= e readonly, albeit OAM configuration like Bfd, ping etc". The other comment G= eorge gave at Taipei was "Netconf will be used for configuration".

I have sent a request to WG chairs, after Taipei, to provide= a conclusive answer, so that, we could update the drafts accordingly. Yet t= o receive a answer though.

HTH,
Sam
Sent from my iPad

On Jan 5, 2012, at 3:37 PM, Greg Mirsky &l= t;gregimirsky@gmail.com> wro= te:

Dear Tom, et al.,=
I had to refresh my recollection of the discussion in Taipei. According t= o minutes we don't have the decision regarding the use of MIBs to configure M= PLS-TP objects. Somewhere in my memory stuck that the proposal was to limit n= ew MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or one of= options chairs and the WG is looking into.

Regards,
Greg

On Tue, Jan 3, 2012 a= t 11:03 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

       Stewart,

       The question of whether or not to allow "configu= ration" via the OAM protocols (or protocol extensions) was something I raise= d several months ago in PWE3, although it was also discussed in MPLS as I re= call in Taipei as well. It seems to have arisen again.   The conclusion= s in PWE3 were to allow configuration of only OAM-related things (i.e.: not a= llowing expansion of the protocols for general configuration). Presumably co= nfiguration via MIBs there is still okay. In MPLS I recall the chairs statin= g that configuration was a thing reserved for NetConf when the question of M= IB-based configuration was raised for WG MIB drafts in general (and in parti= cular WRT to the MPLS-TP MIBs).    Those positions seem slightly a= t odds with each other.  And now your answer now seems inconsistent wit= h those as well.

       Can we get a single answer from the ADs/IESG on t= his that pertains to all MPLS-TP related work?

       --Tom


On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote:

>
>> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM f= or MPLS-TP*"?
>>
> Without prejudice to any decisions on Y.1731 and MPLS-TP.
>
> Wouldn't such a MIB be a derivative of the Y.1731 MIB?
>
> Stewart
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

_______________________________________________
mpls mailing list
mpls@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mpls

____________________= ___________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman= /listinfo/mpls
= --Apple-Mail-754B4705-EC6D-45C3-9258-619D77DDE0CC-- From sriganeshkini@gmail.com Thu Jan 5 16:16:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187E611E8080 for ; Thu, 5 Jan 2012 16:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUhnuPlKvyp4 for ; Thu, 5 Jan 2012 16:16:05 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F89611E807A for ; Thu, 5 Jan 2012 16:16:05 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so874759wgb.13 for ; Thu, 05 Jan 2012 16:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=M4OShKbUqClu9M1gF301ICSnh34UyseX1De0NtTEJCA=; b=xKAaWYi4lFRL0QlcAyu4vpJE1gSCnLQQ3JOu212HH6lz/rMs4Y6k5aYGcbZqbilo9E Y5rQL4AiXvfTLp20PAGu6JRx9hKz7ryYKA1omArCxVo2mC9heo7qRgVaWR4LtRYni3jZ dKJ8axGrOLkrk/CRM921tvNPknhPNUNUhTop8= Received: by 10.180.109.77 with SMTP id hq13mr3839350wib.7.1325808964364; Thu, 05 Jan 2012 16:16:04 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.216.36.77 with HTTP; Thu, 5 Jan 2012 16:15:33 -0800 (PST) From: Sriganesh Kini Date: Thu, 5 Jan 2012 16:15:33 -0800 X-Google-Sender-Auth: VfkRMhzmfvfPfT6H1b97SQrhU6E Message-ID: To: Loa Andersson , mpls@ietf.org, Ross Callon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [mpls] Comment on draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:16:06 -0000 Hi Dan and other authors, Some comments 1. Is there an equivalent of 'Promiscous ARP' in GAP ? 2. The semantics of the 'Message Identifier' should be explained. 3. In sec 5.1, instead of "... Protocol message transmission SHALL operate on a per-.." can we use "... Protocol instance SHOULD operate on a per-...". 4. In sec 5.1, instead of per-data-channel it would be better to use "per Interface (or section)". 5. If IP is used in G-ACh but IP is not used in the data plane, is GAP still required ? Thanks On Thu, Jan 5, 2012 at 3:24 AM, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > =C2=A0 draft-fbb-mpls-gach-adv-01 > =C2=A0 draft-fbb-mpls-tp-ethernet-addressing-01 > mpls working group drafts. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends January 18, 2012! > > Loa > for the mpls wg chairs > > -- > > > Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0loa@pi.nu > Ericsson Inc =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phone: +46 10 717 52 13 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --=20 - Sri From fuchao1998@gmail.com Thu Jan 5 21:05:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A64121F87DE for ; Thu, 5 Jan 2012 21:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEt+58VRkVac for ; Thu, 5 Jan 2012 21:05:10 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7F421F87DD for ; Thu, 5 Jan 2012 21:05:06 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1060057vcb.31 for ; Thu, 05 Jan 2012 21:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xy4s3YK7QrLGz1wQFdFwYhVpOkS+U4gFhinxE/ovyWw=; b=eMAVGOsVlkc3i2qZM4c9zQxx6/F4Ay6tlIqwCczyszv9MJlYw4KhNCZhdm3eoxwTfg F/p6qGI17uoukUEAUNT/8GUSl215LznDMLiwkJXhmIRlSVgcoiHZTvPggls2Do9FajEN fmimKmgH7dhQhGGy3uqHs5c5FBxFFCjL4dIvc= MIME-Version: 1.0 Received: by 10.220.149.200 with SMTP id u8mr2690577vcv.35.1325826305668; Thu, 05 Jan 2012 21:05:05 -0800 (PST) Received: by 10.52.70.113 with HTTP; Thu, 5 Jan 2012 21:05:05 -0800 (PST) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 6 Jan 2012 13:05:05 +0800 Message-ID: From: Chao Fu To: David Allan I Content-Type: multipart/alternative; boundary=f46d043c821cfbb45904b5d4fd29 Cc: "mpls@ietf.org" Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 06 Jan 2012 05:05:11 -0000 --f46d043c821cfbb45904b5d4fd29 Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, Thank you very for your response. For the first point, I just wonder that we use "*configured reception period" *or * "configured transmission period" *to get the Period Misconfiguration Defect. And I think it is not clear in RFC 6371 on the usage of *configured reception period.* For the fourth point "4. In 3.7.3 of RFC 6428", just because there is Period Misconfiguration Defect in RFC 6371, and if the defect is introduced into RFC 6428 also, then it will bring the local BFD session state down. But I don't think it is necessary. For the fifth point " 5. In 3.7.1 of RFC 6428: Session Initiation and Modification": Does it mean the P/F is used here just because the slow start mechanism? Is the P/F used to avoid LOC defect when the transmission interval misconfiguration? I think the P/F is useful only when the transmission intervals can be different on both endpoints, and there can be different LOC detection timers. Otherwise it is useless if the mis-configuration defect of RFC6371 has come when we initialize the BFD session. Is my understanding correct? Thanks! Regards Chao Fu 2012/1/4 David Allan I > ** > HI Chao: > > Some answers in line... > > ------------------------------ > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Chao Fu > *Sent:* Wednesday, December 28, 2011 6:51 PM > *To:* mpls@ietf.org > *Subject:* [mpls] Some doubts in RFC 6371 and RFC 6428 > > Hi all, > > I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" > and RFC 6428 "CC, CV, and RDI for MPLS-TP". Who can help me to clarify > them? Thanks a lot! > > 1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect: > If proactive CC-V OAM packets are received with the expected globally > unique Source MEP identifier but with a transmission period different > than the locally configured reception period, then a CC-V period > misconfiguration defect is detected. > o Entry criteria: A MEP receives a CC-V proactive packet with the > expected globally unique Source MEP identifier but with a > transmission period different than its own CC-V-configured > transmission period. > > My doubt:* It is said to compare with the locally configured reception > period in the definition, but in the Entry criteria, it is compared with it > own CC-V-configured transmission period. Are they same? Just because these > two values should be same? For LOC in 5.1.1.1, it also uses the receiving > MEP's configured CC-V reception period.* > * And such Period Misconfiguration Defect is not defined in RFC 6428. > Does MPLS TP need it? Why it is not in RFC 6428?* > > > The short story is that a mismatch is a problem but not one that many > felt tearing the service down or forcing a protection switch was a suitable > consequent action. It does not indicate an impairment in information > transfer capability, just in the ability to measure it. Hence flag it > northbound and presumably offline action would bring the OAM back into > spec. Now as for an implementation explicitly modifying the periodicity to > an unacceptable value, how the other end reacts is implementation or policy > dependant. > > Part of this is a consequence of beleiving that some of the BFD > handshaking could be dispensed with at the time 6371 was written. That view > changed after the BFD WG did a thorough review of what became 6428. > > 2. In 5.1.2 of RFC 6371: > If a MEP detects a LOC defect that is not caused by a period > misconfiguration, it should block all the traffic (including also the > user data packets) that it receives from the transport path, if this > consequent action has been enabled by the operator. > > *My doubt: Does it mean the period misconfiguration should or might > cause the LOC? Will the packets be discarded? If not, there should not be > LOC. My opinion is that the period misconfiguration should not cause LOC. > * > > There could be a corner cases if without any warning one end reduced the > periodicity of CC/CV to less than 1/3 of the expected rate so that one got > an LOC. Once a lower rate BFD PDU was received that advertised the changed > rate, the receiver could adapt vs. staying in a defect state. > > > 3. In 5.1.3 of RFC 6371: > Note that the reception period is the same as the configured > transmission rate. > > *My doubt: Does it mean no need to configure reception period? But > many places mention "configured reception period", do they mean the > configured transmission rate?* > * > * A configured reception rate would be an expected rate which IMO would > be optional. Again an artifact of the original expectation of no > handshaking between the MEPs in establishing a session periodicity and > configuration would be the only way such agreement would happen. > > 4. In 3.7.3 of RFC 6428: > It will also communicate session DOWN to its session peer using CC > messages. > > *My doubt: **Does it mean only notify the peer to bring the session > DOWN but the local session will not be DOWN? Or we should bring the local > session DOWN also? But it is not in the BFD State machine of Figure 7. > * > It is telling it's peer that it has taken the session into the down state > at it's end. > > So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are > local inputs to the state machine that will transition it from UP to DOWN. > > Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from > UP to DOWN in coordinated session operation. > > 5. In 3.7.1 of RFC 6428: Session Initiation and Modification > > Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 > second, and the detect multiplier = 3. > > Once in the UP state, Poll/Final discipline is used to modify the > periodicity of control message exchange from their default rates to > the desired rates and to set the detect multiplier to 3. > > *My doubt: Does it mean the BFD session will not be started with the > configured values but use the default values? What the values will be > filled in the packet? The default ones or the configured values? > Why need P/F here? There is no timer negotiation. I think here the > configured transmission rates should be same on both Engpoints, otherwise > there are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371. > > * P/F is needed as examination of any other slow start mechanism revealed > that we would have to reinvent what we already had. So there is a handshake > to get from the default to the desired rate. > > I hope this helps > > Dave > > -- Regards Chao Fu --f46d043c821cfbb45904b5d4fd29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thank you very for your response.

For the first point, I just wonder that we use "configured reception period"=A0 or =A0"configured transmi= ssion=20 period" to = get the Period Misconfiguration=20 Defect. And I think=A0it=A0is not clear in RFC 6371 on the usage of configured reception=20 period.<= /p>

For the fourth point "4. In 3.7.3 of RFC 6428", just because t= here is Period=20 Misconfiguration Defect in RFC 6371, and if the defect is introduced into R= FC=20 6428 also, then it will bring the local BFD session state down. But I don&#= 39;t think=20 it is necessary.=A0

For the fifth point "=A05.=A0=A0In 3.7.1= of RFC 6428: Session=20 Initiation and Modification": Does it mean the P/F is used here just b= ecause the=20 slow start mechanism? Is the P/F used to avoid LOC defect when the transmis= sion interval misconfiguration? =A0I think the P/F is useful only when the = transmission intervals can be different on both endpoints, and there can be= different LOC detection timers. Otherwise it is useless if the mis-configu= ration defect of RFC6371 has come when we initialize the BFD session. Is my= understanding correct? Thanks!


Regards

Chao Fu


2= 012/1/4 David Allan I <david.i.allan@ericsson.com>
HI Chao:
=A0
Some answers in line...


From: mpls-bounces@ietf.org=20 [mailto:mpls-bou= nces@ietf.org] On Behalf Of Chao Fu
Sent:=20 Wednesday, December 28, 2011 6:51 PM
To:=20 mpls@ietf.org
= Subject: [mpls] Some doubts in RFC 6371 and RFC=20 6428

Hi all,
=A0
I have some doubts=A0on RFC 6371 "OAM Framework for MPLS-Based=20 Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".=A0 Wh= o can help me to=20 clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20 Defect:
=A0=A0 If proactive CC-V OAM packets are received with the=20 expected globally
=A0=A0 unique Source MEP identifier but with a=20 transmission period different
=A0=A0 than the locally configured=20 reception period, then a CC-V period
=A0=A0 misconfiguration defect is= =20 detected.
=A0=A0 o=A0 Entry criteria: A MEP receives a CC-V=20 proactive packet with the
=A0=A0=A0=A0=A0 expected globally=20 unique Source MEP identifier but with a
=A0=A0=A0=A0=A0=20 transmission period different than its own=20 CC-V-configured
=A0=A0=A0=A0=A0 transmission=20 period.
=A0=A0=A0
=A0=A0 My doubt: It is said to co= mpare with the=20 locally configured reception period in the definition, but in the Entry=20 criteria, it is compared with it own CC-V-configured transmission period. A= re=20 they same? Just because these two values should be same? For LOC in 5.1.1.1= , it=20 also uses the receiving MEP's configured CC-V reception=20 period.=A0=A0=A0
=A0=A0 And such Period=20 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W= hy it=20 is not in RFC 6428?=A0

=A0=A0
The short story i= s that a mismatch is a problem =A0but not one=20 that many felt tearing the service down or forcing a protection switch was = a=20 suitable consequent action. It does not indicate an impairment in informati= on=20 transfer capability, just in the ability to measure it. Hence flag it north= bound=20 and presumably offline action would bring the OAM back into spec. Now as fo= r an=20 implementation explicitly modifying the periodicity to an unacceptable valu= e,=20 how the other end reacts is implementation or policy=20 dependant.

Part of=20 this is a consequence of beleiving that some of the BFD handshaking could b= e=20 dispensed with at the time 6371 was written. That view changed after the BF= D WG=20 did a thorough review of what became 6428.

=A02. In 5.1.2 of RFC=20 6371:
=A0=A0 If a MEP detects a LOC defect that is not caused by a=20 period
=A0=A0 misconfiguration, it should block all the traffic=20 (including also the
=A0=A0 user data packets) that it receives from the= =20 transport path, if this
=A0=A0 consequent action has been enabled by=20 the operator.
=A0=A0=A0
=A0=A0 My doubt: Does it mean the period=20 misconfiguration should or might cause the LOC? Will the packets be discard= ed?=20 If not, there should not be LOC. My opinion is that the period misconfigura= tion=20 should not cause LOC.
=A0=A0

There=20 could=A0be a corner cases if without any warning one end reduced the=20 periodicity of CC/CV to less than 1/3 of the expected rate so that one got = an=20 LOC. Once a lower rate BFD PDU was received that advertised the changed rat= e,=20 the receiver could adapt vs. staying in a defect state.

=A0=A0
3. In 5.1.3 of RFC=20 6371:
=A0=A0 Note that the reception period is the same as the=20 configured transmission rate.
=A0=A0=A0
=A0=A0 My doubt: Does it mean no need to=20 configure reception period? But many places mention "configured recept= ion=20 period", do they mean the configured transmission rate?=A0
=A0
=A0=A0=A0
<= span>=A0A configured reception rate would be an expe= cted=20 rate which IMO would be optional. Again an artifact of the original expecta= tion=20 of no handshaking between the MEPs in establishing a session periodicity an= d=20 configuration would be the only way such agreement would=20 happen.

=A04. In 3.7.3 of RFC=20 6428:
=A0 It will also communicate session DOWN to its session peer usin= g=20 CC messages.
=A0=A0
=A0 = My doubt: Does it = mean only notify the peer to bring=20 the session DOWN but the local session will not be DOWN? Or we should bring= the=20 local session DOWN also? But it is not in the BFD State machine of Figure= =20 7.
=A0

It is telling=20 it's peer that it has taken the session into the down state at it's= =20 end.=A0

So=20 LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local= =20 inputs to the state machine that will transition it from UP to=20 DOWN.

Receiving ADMIN DOWN or DOW= N from a peer will also cause a transition=20 from UP to DOWN in coordinated session operation.

=A05.=A0=A0In 3.7.1 of RFC=20 6428: Session Initiation and Modification

=A0=A0 Session initiation occurs starting from MinRx =3D 1 second, MinTx= =20 >=3D 1
=A0=A0 second, and the detect multiplier =3D 3.

=A0=A0 Once in the UP state, Poll/Final discipline is used to modify=20 the
=A0=A0 periodicity of control message exchange from their default=20 rates to
=A0=A0 the desired rates and to set the detect multiplier to=20 3.
=A0=A0=A0
=A0=A0 My d= oubt: Does it mean the BFD = session will not be=20 started with the configured values but use the default values? What the val= ues=20 will be filled in the packet? The default ones or the configured=20 values?
=A0=A0 Why need P/F here? There is no timer negotiation. I=20 think here the configured transmission rates should be same on both Engpoin= ts,=20 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R= FC=20 6371.

=A0P/F is needed as examination of any other=20 slow=A0start mechanism revealed that we would have to reinvent what we=20 already had. So there is a handshake to get from the default to the desired= =20 rate.

I hope=20 this helps

Dave=A0




--
Regards=
Chao Fu

--f46d043c821cfbb45904b5d4fd29-- From tnadeau@lucidvision.com Fri Jan 6 04:45:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615021F8872; Fri, 6 Jan 2012 04:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irXiZ-Hmp3Ez; Fri, 6 Jan 2012 04:45:49 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F0A8121F8591; Fri, 6 Jan 2012 04:45:48 -0800 (PST) Received: from [192.168.1.76] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id F2EFC203F58A; Fri, 6 Jan 2012 07:45:47 -0500 (EST) References: <4F0342A9.1000301@cisco.com> <0D57BB9E-5415-44CF-A553-A61E9E86E49E@lucidvision.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-FA5B4631-8B44-43F4-9590-2D58EF9A7A4E Message-Id: <709A4494-16A8-4010-8EBE-93BCBDB15E3D@lucidvision.com> X-Mailer: iPad Mail (9A405) From: Thomas D Nadeau Date: Fri, 6 Jan 2012 07:45:47 -0500 To: Greg Mirsky Cc: "mpls@ietf.org" , "ccamp@ietf.org" , Jaihari Kalijanakiraman , "stbryant@cisco.com" Subject: Re: [mpls] Questions on draft-vkst-mpls-tp-oam-id-mib-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, 06 Jan 2012 12:45:49 -0000 --Apple-Mail-FA5B4631-8B44-43F4-9590-2D58EF9A7A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I need to dig up the email, but I am pretty sure that Matthew had sent out a= note clarifying things for PWE3. For MPLS I believe that George made the st= atement at the meeting (the second one in Taipei). In any event, the point s= till remains that that there is no clear and consistent directive on this fr= om the IESG right now across various WGs where it needs to be. --Tom On Jan 5, 2012, at 6:37 PM, Greg Mirsky wrote: > Dear Tom, et al., > I had to refresh my recollection of the discussion in Taipei. According to= minutes we don't have the decision regarding the use of MIBs to configure M= PLS-TP objects. Somewhere in my memory stuck that the proposal was to limit n= ew MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or one of= options chairs and the WG is looking into. >=20 > Regards, > Greg >=20 > On Tue, Jan 3, 2012 at 11:03 AM, Thomas Nadeau w= rote: >=20 > Stewart, >=20 > The question of whether or not to allow "configuration" via the OAM= protocols (or protocol extensions) was something I raised several months ag= o in PWE3, although it was also discussed in MPLS as I recall in Taipei as w= ell. It seems to have arisen again. The conclusions in PWE3 were to allow c= onfiguration of only OAM-related things (i.e.: not allowing expansion of the= protocols for general configuration). Presumably configuration via MIBs the= re is still okay. In MPLS I recall the chairs stating that configuration was= a thing reserved for NetConf when the question of MIB-based configuration w= as raised for WG MIB drafts in general (and in particular WRT to the MPLS-TP= MIBs). Those positions seem slightly at odds with each other. And now y= our answer now seems inconsistent with those as well. >=20 > Can we get a single answer from the ADs/IESG on this that pertains t= o all MPLS-TP related work? >=20 > --Tom >=20 >=20 > On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote: >=20 > > > >> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for M= PLS-TP*"? > >> > > Without prejudice to any decisions on Y.1731 and MPLS-TP. > > > > Wouldn't such a MIB be a derivative of the Y.1731 MIB? > > > > 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 --Apple-Mail-FA5B4631-8B44-43F4-9590-2D58EF9A7A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I need to dig up the email= , but I am pretty sure that Matthew had sent out a note clarifying things fo= r PWE3. For MPLS I believe that George made the statement at the meeting (th= e second one in Taipei).  In any event, the point still remains that th= at there is no clear and consistent directive on this from the IESG right no= w across various WGs where it needs to be.

--Tom




On Jan 5, 2012, at 6:37 PM, Greg Mirsky &= lt;gregimirsky@gmail.com> wr= ote:

Dear Tom, et al.= ,
I had to refresh my recollection of the discussion in Taipei. According= to minutes we don't have the decision regarding the use of MIBs to configur= e MPLS-TP objects. Somewhere in my memory stuck that the proposal was to lim= it new MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or on= e of options chairs and the WG is looking into.

Regards,
Greg

On Tue, Jan 3, 2012 a= t 11:03 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

       Stewart,

       The question of whether or not to allow "configu= ration" via the OAM protocols (or protocol extensions) was something I raise= d several months ago in PWE3, although it was also discussed in MPLS as I re= call in Taipei as well. It seems to have arisen again.   The conclusion= s in PWE3 were to allow configuration of only OAM-related things (i.e.: not a= llowing expansion of the protocols for general configuration). Presumably co= nfiguration via MIBs there is still okay. In MPLS I recall the chairs statin= g that configuration was a thing reserved for NetConf when the question of M= IB-based configuration was raised for WG MIB drafts in general (and in parti= cular WRT to the MPLS-TP MIBs).    Those positions seem slightly a= t odds with each other.  And now your answer now seems inconsistent wit= h those as well.

       Can we get a single answer from the ADs/IESG on t= his that pertains to all MPLS-TP related work?

       --Tom


On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote:

>
>> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM f= or MPLS-TP*"?
>>
> Without prejudice to any decisions on Y.1731 and MPLS-TP.
>
> Wouldn't such a MIB be a derivative of the Y.1731 MIB?
>
> Stewart
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

_______________________________________________
mpls mailing list
mpls@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mpls

= --Apple-Mail-FA5B4631-8B44-43F4-9590-2D58EF9A7A4E-- From scott.mansfield@ericsson.com Sun Jan 8 05:54:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE921F857D; Sun, 8 Jan 2012 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw2VTqNPz50Q; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A62EB21F857A; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q08Dslvg030164; Sun, 8 Jan 2012 07:54:50 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 8 Jan 2012 08:54:41 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 08:53:05 -0500 Thread-Topic: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stbryant@cisco.com" , "rcallon@juniper.net" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" Subject: [mpls] FW: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Jan 2012 13:54:59 -0000 This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determine= d recommendation G.8113.1 (May 2011). The liaison also provides a pointer = to the internet draft draft-betts-itu-oam-ach-code-point that requests an A= Ch code point that is needed by G.8113.1. This is a liaison that will requ= ire a response and the ITU-T has requested a response no later than 1 Augus= t 2012. I would suggest that we use the liaison response to provide the ou= tcome of running the IETF process required to assign the requested code poi= nt. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 > = From scott.mansfield@ericsson.com Sun Jan 8 06:03:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618A21F857F; Sun, 8 Jan 2012 06:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6toldkBkO4w; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1521F857A; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q08E2xVd015650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jan 2012 08:02:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 8 Jan 2012 09:02:58 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 09:01:22 -0500 Thread-Topic: New Liaison Statement, "LS368 - MPLS-TP Recommendations" Thread-Index: AczN4pkSBaUC0mYaQoOGlA/HaKlurQAKkiSA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stbryant@cisco.com" , "rcallon@juniper.net" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" Subject: [mpls] FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 08 Jan 2012 14:03:02 -0000 This is a liaison from SG15 Q9, Q12, and Q14 providing the text of G.8110.1= , G.8121, and G.8151. This liaison is for information only. G.8110.1 was = approved at the SG15 plenary meeting in December 2011. G.8121 and G.8151 e= ntered the alternative approval process (AAP) and will enter a 4 week last = call (the last call hasn't been initiated yet). Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:51 AM > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; mpls@ietf.org;=20 > lear@cisco.com; Scott Mansfield; stbryant@cisco.com;=20 > adrian@olddog.co.uk; malcolm.betts@zte.com.cn; Ghani Abbas;=20 > Kam.Lam@alcatel-lucent.com; tsbsg15@itu.int;=20 > greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations" >=20 > Title: LS368 - MPLS-TP Recommendations > Submission Date: 2012-01-08 > URL of the IETF Web page: /liaison/1126/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > swallow@cisco.com, loa@pi.nu) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,mpl > s@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com,stbryan > t@cisco.com,adrian@olddog.co.uk > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact:=20 > malcolm.betts@zte.com.cn,Ghani.Abbas@ericsson.com,Kam.Lam@alca > tel-lucent.com > Purpose: For information >=20 > Body: At the December 2011 meeting of ITU-T Study Group 15,=20 > Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS=20 > Transport Profile (MPLS-TP) layer network" was approved. A=20 > copy is attached for your information. =20 > We would like to draw your attention to clause 10 that=20 > describes the MPLS-TP Diff-Serv Architecture. > In addition, the approval process was initiated for=20 > Recommendations ITU-T G.8121/Y.1381 "Characteristics of=20 > MPLS-TP Network Equipment Functional Blocks" and ITU-T=20 > G.8151/Y.1374 "Management aspects of the MPLS-TP network element". >=20 > Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1. >=20 > Attachment(s): >=20 > LS368 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1308.pdf >=20 > LS368 - Att1_PLEN-517Rev3=20 > https://datatracker.ietf.org/documents/LIAISON/file1309.pdf >=20 > LS368 - Att2_PLEN-540Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1310.pdf >=20 > LS368 - Att3_PLEN-543Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1311.pdf >=20 >=20 > = From nurit.sprecher@nsn.com Mon Jan 9 09:20:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8911E809B; Mon, 9 Jan 2012 09:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLnwcX7-t59J; Mon, 9 Jan 2012 09:20:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61311E809A; Mon, 9 Jan 2012 09:20:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q09HK3XF004485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:20:03 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q09HJrxG026756; Mon, 9 Jan 2012 18:20:03 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:20:02 +0100 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: Mon, 9 Jan 2012 18:19:57 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:20:02.0328 (UTC) FILETIME=[EBF91980:01CCCEF2] Cc: andrew.g.malis@verizon.com, dbrungard@att.com, stbryant@cisco.com Subject: Re: [mpls] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Jan 2012 17:20:11 -0000 Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From adrian@olddog.co.uk Mon Jan 9 09:33:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B9811E80C7; Mon, 9 Jan 2012 09:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYEK9gKkXSNS; Mon, 9 Jan 2012 09:33:26 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 710AA11E80A3; Mon, 9 Jan 2012 09:33:26 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09HXJIt020028; Mon, 9 Jan 2012 17:33:19 GMT Received: from 950129200 (adsl-84-227-210-28.adslplus.ch [84.227.210.28]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09HXHb2019949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jan 2012 17:33:18 GMT From: "Adrian Farrel" To: , "'Huub helvoort'" References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> In-Reply-To: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> Date: Mon, 9 Jan 2012 17:33:16 -0000 Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@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: AQMS9l89V+yYISRa9OjQYS/w8kDy1ZN3+0VQ Content-Language: en-gb Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point 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, 09 Jan 2012 17:33:27 -0000 Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: 09 December 2011 10:49 > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort' > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Questions about draft-betts-itu-oam-ach-code-point > > Hi Malcolm and Huub, > > I have squeezed a little time from the current ITU-T meeting to look at your > draft and write-up. I have also read the email threads on the IETF discussion > list and the MPLS list. Sorry that this has taken me a week to process, but your > publication request came at pretty much the worst possible time for getting me > to do this task. > > I don't like proliferating threads across multiple mailing lists. On the other > hand it is difficult to ensure that all the constituencies are present, so I am > perpetuating the cross-posting. > > My review of the document... > > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think > only one of these is real (the spurious space in a citation). The other nits are > spurious caused by citations wrapping across lines. Could you please keep a note > of the nit so that you can fix it the next time the draft is respun or so it can > be captured in an RFC Editor Note at a later stage (you don't have to post a new > revision to address this now unless you really want to). > > 2. This document requests a code point from a registry that contains code points > that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D > whether it is your intention that your code point would also be applicable in > both cases. What is your intention? Is this "obvious" from G.8113.1 or does it > need to be clarified? > > > My review of the write-up and discussions... > > 3. There seems to be quite a feeling on the mailing lists that this document > should be run through the MPLS working group. The write-up makes a case for > progressing it as AD sponsored. As far as I can see, the main assertions to > answer are as follows. Do you have a view on these points before I make a > decision on what to do? > > a. This is a proposal to use an MPLS code point and so is part of MPLS by > definition. > > b. The type of network being managed by the OAM described in G.8113.1 is an > MPLS network. Therefore, this is clearly relevant to the MPLS working . > > Do you object to this going through the MPLS on principle, or were you just > hoping to save the WG the work? If the latter, and if the WG wants to look at > the draft, the easiest approach seems to be to redirect the work to the working > group. > > 4. G.8113.1 is clearly important to understanding to which the code point is > being put. Thus, an available and stable copy of group. G.8113.1 will be key to > the last call review of you I-D. Can you make a stable copy available (for > example, through liaison)? How does the editing work currently in progress in > the SG15 meeting affect that availability? > > 5. Can you clarify for me why the suggested value has been suggested. This will > help guide IANA who would normally do their allocation in a "tidy" way. > > Looking forward to your reply. > > Thanks, > Adrian From nurit.sprecher@nsn.com Mon Jan 9 09:41:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055311E80E6; Mon, 9 Jan 2012 09:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgfjPvmaeHaC; Mon, 9 Jan 2012 09:41:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0811E80BD; Mon, 9 Jan 2012 09:41:52 -0800 (PST) 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 q09HfkoF014113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:41:46 +0100 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 q09HfkhZ009479; Mon, 9 Jan 2012 18:41:46 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:41:46 +0100 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: Mon, 9 Jan 2012 18:41:43 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E7C@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OAAAL2zAA== References: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:41:46.0156 (UTC) FILETIME=[F51D76C0:01CCCEF5] Cc: andrew.g.malis@verizon.com, dbrungard@att.com Subject: Re: [mpls] [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 09 Jan 2012 17:41:54 -0000 When saying support, I mean of course that I fully support the proposal = of Scott! -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: =E1 09 =E9=F0=E5=E0=F8 2012 19:20 To: ext Scott Mansfield; ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; = ccamp@ietf.org Cc: andrew.g.malis@verizon.com; dbrungard@att.com Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration = andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Thomas.Beckhaus@telekom.de Wed Jan 11 04:43:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3534D21F8812 for ; Wed, 11 Jan 2012 04:43:31 -0800 (PST) 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_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLzxWoN6IC-c for ; Wed, 11 Jan 2012 04:43:30 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77D21F87EF for ; Wed, 11 Jan 2012 04:43:30 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jan 2012 13:43:28 +0100 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.181]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 11 Jan 2012 13:43:22 +0100 From: To: Date: Wed, 11 Jan 2012 13:43:21 +0100 Thread-Topic: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-01 Thread-Index: AQHMyub8TtmstZJpF065wRL86RG+OpX8WktggAluNVA= Message-ID: References: <4EE1EE2A.5090803@pi.nu> <4F0457A4.9060403@pi.nu> <07F7D7DED63154409F13298786A2ADC9042C53B5@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9042C53B5@EXRAD5.ad.rad.co.il> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, draft-beckhaus-ldp-dod@tools.ietf.org Subject: Re: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-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, 11 Jan 2012 12:43:31 -0000 Yaakov, as you have mentioned in the earlier mail, I understand your security conce= rns not as a protocol (LDP-DoD) related topic but an issue based on the (se= amless mpls architecture) scenario. I agree: if somebody wants to extends M= PLS behind the "trusted" part of the network, we have to consider additiona= l security requirements (But there is no difference, wether I put such a me= ntioned L2-device between an LER and an LSR in the traditional MPLS deploym= ent ot between an Access Node and an AGN1 in seamless-mpls). I spoke to the authors of the Seamless MPLS draft and the next version of t= he draft will include an update to the security section to address the issu= es you raised regarding the Seamless MPLS architecture. Therefore, my understanding is that there are no additional security requir= ements of LDP DoD based on the proposed protocol behaviour. Thomas > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, January 04, 2012 5:01 PM > To: draft-beckhaus-ldp-dod@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Poll closed - Re: poll on > draft-beckhaus-ldp-dod-01 > > Draft authors, > > Now that this draft has become a WG item, > I really would like to hear how you intend addressing the > security issues. > > Let's start with a simple one. > > As I have said in earlier emails, > devices in the access network are unguarded, > and it is relatively easy to subvert one or to concatenate > new devices. > > In particular, it is not hard to reprogram a L2 device > or insert a small device somewhere that transparently passes > everything except LDP KeepAlives. > Presumably I would only intermittently trigger this > discarding of KeepAlives > and leave it on for only a minute or so > in order to make the problem hard to diagnose and localize. > > When the LDP peers detect the loss they terminate the session > and discard all label mappings, thus producing a total denial > of service. > > I am interested in hearing how you would deal with this scenario. > > Y(J)S > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Wednesday, January 04, 2012 15:44 > To: mpls@ietf.org > Cc: Ross Callon; draft-beckhaus-ldp-dod@tools.ietf.org > Subject: [mpls] Poll closed - Re: poll on draft-beckhaus-ldp-dod-01 > > Working Group, > > this poll has ended, and we have a new working group document. > > Could the authors please re-publish the document as > draft-ietf-mpls-ldp-dod-00. > > Without any other changes than the administrative information and > the file name. > > > Loa > for the mpls wg chairs > > On 2011-12-09 12:16, Loa Andersson wrote: > > Working Group, > > > > this is to start a two week poll to see if there is support to make > > draft-beckhaus-ldp-dod-01 an mpls working group draft. > > > > Pleased send your comments to the mpls working group mailing list > > (mpls@ietf.org). > > > > This poll ends Dec 23, 2011! > > > > Loa > > for the mpls wg chairs > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From Alexander.Vainshtein@ecitele.com Wed Jan 11 04:55:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1678221F866E for ; Wed, 11 Jan 2012 04:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQp8JZ6+MelH for ; Wed, 11 Jan 2012 04:55:09 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id ED21E21F852F for ; Wed, 11 Jan 2012 04:55:08 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1326286504!10447370!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 5497 invoked from network); 11 Jan 2012 12:55:05 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-9.tower-182.messagelabs.com with SMTP; 11 Jan 2012 12:55:05 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-05-4f0d879c5e98 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 16.76.08306.C978D0F4; Wed, 11 Jan 2012 14:59:08 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 11 Jan 2012 14:55:04 +0200 From: Alexander Vainshtein To: "david.i.allan@ericsson.com" , "Italo.Busi@alcatel-lucent.com" Date: Wed, 11 Jan 2012 14:55:03 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFA== 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_A3C5DF08D38B6049839A6F553B331C760115EDD18C02ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRjv3e3jmru4lrZXMRgXRWYTzYJVTiooFhkaRoQQdm5v29F2N+7O aBG0LDM1yjCqSeUqM61QUqMPjcrSvkSDPjGLQotakWVFaaTdeWlC9P71e57n9/yeHy/Pg2PG Ul0MzrAi4lnaQ2n16tJw31fL4QIiPbG3cKr1x+6nmPVVxwXM2nLeau08Wa2xtr8+DBZq7Plv rmjs+3+e09gHvj3S2isq+lX2qvpqkKHJCoAUmmU5kRaR2YkEh43K4JmNtMNPmRmnjUqizD4P 7UBexIo2ivb5EOukUvXmf16KRGNYM2IdnJNhXTZqWWa6xWqdO8+SRKVOn5qUvEC/ys0IZmTx 0ozH7EWCQLuQWcqsa8DcTfmfge9hI9h0qzotAPIqQREYj0NyDhx8cl+l4Mnw/otabRHQ40by EoB55Y9VSrAfwEMFvzCZpSVtsO7M82FWJBkA8EprmVoOMLIEwKq9R4Z11eQ0ePndHrWMJ0m4 9WBQVwRwqWMm3F2XKacjyQRYU7N9mEKQK2FXx2OdjIFk4/vds8OWMNIEO3vK/9gjYUVTB6bg KPiue1Cj8KNgV0EtkOUxkoMtxRGK5ER4J9ijVujR8HrVU3UJiCwbo1r2t6NsTIdCmQVDjX1a BcfDymPvsRHcdq1bNTYfArrTIJrx+MQcrytxtoXLFROQgxGRByU4OG8dULbo7UXwrC2uGZA4 oAxEMjKkGzX0RsHvbQbRuIqKItBOIt04IYdz+t204M7mcz1IaAYQx6hIYvEWqUY4af9mxHMj pSXSN+/DYiIcnLSvrJidnJj4/4AyEcWODyuMpEtaww0I+RA/ohOL4xQk4uXxE3nkQpvWMx7x b1mFj5dtGCQb7/NlG4KP9gqMS6nfBRa8sjjUDoxqlmNRjInQyEKkTHLnsqM68i1tHRoaCgOT 9AGTiLAsZZAubVQpLA1RSUMaagzyEOlcRksxAbCusdcirmV72lbkBB+8/J72sf36pxtTxt2+ XBJXuat89ROXMTp0c1sGPgW71TfQ/FFs6A819YYzzxUkzF3z8kht0RI+b4fL1JM2Y/2BQPD5 UZLPYm+cuBr/qDCYkQV1XfndpeP0ptjJ9Utjo2pylh83LC/sdC8qf9Hk/3LoVO38+fcoteCm k2ZivED/Bvj+uJomBAAA Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 12:55:12 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDD18C02ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs in= RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node (= neither Up nor Down), per-interface Up and per-interface Down. Is this under= standing correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' e= xclusively to refer to the n=3D0 case of the term 'Section' defined in RFC 5= 960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for= an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-T= P section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) co= nsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sha= ring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encoun= tered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW)= and explain how fate-sharing with the data packets is provided in such a ca= se? My guess (FWIW) is that this is impossible without some changes in the M= PLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain= how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or I= LM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both D= own. a. Is this understanding correct? If not, could you please present some exa= mples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would i= mply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115EDD18C02ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dave, Italo and al= l,

 

I have a couple of questions regarding the definition of Up and Down MRP= s in R= FC 6371.

The problematic text states:=

 

   A node hosting a MEP can either support per-node= MEP or per-interface

=    MEP(s).  A per-node MEP resides in an unspecified location= within the

 &nbs= p; node, while a per-interface MEP resides on a specific side of the

   forwarding engi= ne.  In particular, a per-interface MEP is called an<= /p>

   "Up MEP" or a &qu= ot;Down MEP" depending on its location relative to the

   forwarding engine. = An "Up MEP" transmits OAM packets towards, and<= /p>

   receives them from, the dir= ection of the forwarding engine, while a

   "Down MEP" receives OAM packets fr= om, and transmits them towards, the

   direction of a server layer.

 

Here are my questions:

 

1.  The text= seems to suggest that there are three types of MEPs: per-node (neither Up n= or Down), per-interface Up and per-interface Down. Is this understanding cor= rect?

<= span style=3D'mso-list:Ignore'>2.Which types of MEPs can be e= ncountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?

a. = ; The text in section 2.2 states: ̶= 0;This document uses the term 'Section' exclusively to refer to the n=3D0 ca= se of the term 'Section' defined in RFC 5960”

b.  The text in Section 3.3 states: “Any MPLS-TP LSR ca= n implement a MEP for an MPLS-TP Section”

c.<= span style=3D'font:7.0pt "Times New Roman"'>  My guess (FWIW) is that only Down MEPs can be associated with th= e MPLS-TP section. Is this guess correct?

3.  Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW= ) considered as an ME?

a.  The text in= Section 3.3 states: “In the context of an MPLS-TP LSP, only LERs can= implement MEPs”

b.  The text men= tions (e.g., in Section 6.4) that OAM flows must be fate-sharing with the da= ta packets for the corresponding ME

c.  4.  <= /span>Can you describe a case when a per-inter= face Up Source MEP can be encountered for one of the MEs that MPLS-TP deals= with (i.e., Section, LSP or PW) and explain how fate-sharing with the data= packets is provided in such a case? My guess (FWIW) is that this is impossi= ble without some changes in the MPLS-TP data plane as defined in RFC 3031 and= RFC 5= 960. Is this guess correct? If not could you please explain how it is su= pposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  The diagrams in Figure 3of the RFC seem to s= uggest that, in the case of per-interface MEPs, Source and Sink MEP are alwa= ys either both Up or both Down.

a.  Is= this understanding correct? If not, could you please present some examples= to the contrary?

b.  <= span style=3D'font-size:10.0pt;font-family:"Courier New"'>If my understandin= g in (a) above is correct and if, as mentioned in (4) above, per-interface U= p MEPs cannot be implemented in MPLS-TP, this would imply that per-interface= Up Sink MEPs are useless. Did I miss something?

 

Regards, and lots o= f thanks in advance,

   &n= bsp; Sasha

 

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

--_000_A3C5DF08D38B6049839A6F553B331C760115EDD18C02ILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Wed Jan 11 05:03:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DFE21F8820 for ; Wed, 11 Jan 2012 05:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.528 X-Spam-Level: X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UJwbngs2SbK for ; Wed, 11 Jan 2012 05:03:34 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 17C2321F87F1 for ; Wed, 11 Jan 2012 05:03:31 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1326286960!55502208!13 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 4166 invoked from network); 11 Jan 2012 13:02:51 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-27.messagelabs.com with SMTP; 11 Jan 2012 13:02:51 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-6d-4f0d899463fd Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id C6.D6.08306.4998D0F4; Wed, 11 Jan 2012 15:07:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 11 Jan 2012 15:03:28 +0200 From: Alexander Vainshtein To: "david.i.allan@ericsson.com" , "Italo.Busi@alcatel-lucent.com" Date: Wed, 11 Jan 2012 15:03:26 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4g 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_A3C5DF08D38B6049839A6F553B331C760115EDD18C10ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLsWRmVeSWpSXmKPExsUy+dWnL7pTO3n9DX59YrF4eH47s8XRrRYW t5auZLU493QOowOLR+uzvaweU35vZPX49fUqm8eSJT+ZAliiGhhtEvPy8ksSS1IVUlKLk22V AooyyxKTK5UUMlNslQyVFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5yfkpmXrqt kmewv66FhamlrqGSnZqyobE1V0hGZrFCqm5uYmaOQm5qcXFieqoCUCRhC3PGz3VzGAs+rGCs eL5xBksDY8NUxi5GTg4JAROJaT9+sEHYYhIX7q0Hsrk4hAR2Mkq87vjCCOFMYZSY9f04E0gV m4CtxKbVd8GqRAQaGCX2HpvFApJgFkiUuPz/GpjNIqAqsWXFGnYQW1hAU+L3gl6gZg6gBi2J nk3BIGERASOJK49+g13BKxAo8eXwfrD5QkD23103wcZwCgRJLG9pZAWxGYGu+35qDRPEKnGJ W0/mM0FcLSCxZM95ZghbVOLl439Q9aISd9rXM4KsZRbIl3i20xxilaDEyZlPWCDKJSUOrrjB MoFRbBaSqbMQOmYh6YAo0ZFYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMUpm5hSUJOWmGxjp 5peW6KUmZ5ak5qTqJefnbmKEpKkXOxhvn9E8xCjAwajEw2ucyuMvxJpYVlyZe4hRkoNJSZQ3 tY3XX4gvKT+lMiOxOCO+qDQntfgQowQHs5IIr1MNUI43JbGyKrUoHyblCgz+icxS3Mn5wNSb VxJvbGCAm6Mkztud/MZXSCAdmDyzU1MLUotg5shwcChJ8J5vB1ohWJSanlqRlplTgpBm4uAE OYMH6IzjIDW8xQWJucWZ6RD5U4zGHMu6F5xj5LixAEgKseTl56VKifPeBikVACnNKM2DmwbK X/X///9/xSgODAZh3tMgVTzA3Ac37xXQKiagVVvW8YCsAmYmuJRUA+PiT3d8tRIeNgnfaf9l 0qVU4m3qEnOqavYT1ZvqO475pV1bcW6y358ZDO+U30y2zLJgu30iV+2TwJKpYV/r6qVUjz2o n5HzRydWVWUVQ16NQhjHR35va+sHuTPfTXFMa3yh5bBZOfdFJnOp7aPNGd43Hx2avMBCaEMC /4p3Z80fampJBTLcyVdiKc5INNRiLipOBADqggzLOgQAAA== Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 13:03:37 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDD18C10ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-pl= atform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs in= RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node (= neither Up nor Down), per-interface Up and per-interface Down. Is this under= standing correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' e= xclusively to refer to the n=3D0 case of the term 'Section' defined in RFC 5= 960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for= an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-T= P section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) co= nsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sha= ring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encoun= tered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW)= and explain how fate-sharing with the data packets is provided in such a ca= se? My guess (FWIW) is that this is impossible without some changes in the M= PLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain= how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or I= LM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both D= own. a. Is this understanding correct? If not, could you please present some exa= mples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would i= mply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. 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_A3C5DF08D38B6049839A6F553B331C760115EDD18C10ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dave, Italo and all,

<= span style=3D'color:#1F497D'>An additional question:

 

Is there any relationship between per-node vs. per-interface MEPs and p= er-platform vs. per-interface label spaces?

If yes= , does it mean that only per-node MEPs can be encountered in the case of PWs= ?

 

Regards, and, again, lots of thanks in advance,

<= p class=3DMsoNormal>     S= asha

 

<= b>From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Al= exander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To:
david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com
Cc:= mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: [= mpls] Up and Down MEPs in RFC 6371

 

Dave, Italo and all,<= o:p>

 

I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC= 6371.

The problematic text states:

 

   A node hosting a MEP can either support per-node M= EP or per-interface

&n= bsp;  MEP(s).  A per-node MEP resides in an unspecified location w= ithin the

  = node, while a per-interface MEP resides on a specific side of the

   forwarding engine.=   In particular, a per-interface MEP is called an

=

   "Up MEP" or a "= Down MEP" depending on its location relative to the

   forwarding engine.  An= "Up MEP" transmits OAM packets towards, and

=

   receives them from, the direct= ion of the forwarding engine, while a

   "Down MEP" receives OAM packets from,= and transmits them towards, the

   direction of a server layer.

 

Here are my questions:

 

1.  <= /span>The text se= ems to suggest that there are three types of MEPs: per-node (neither Up nor= Down), per-interface Up and per-interface Down. Is this understanding corre= ct?

2.=   Which types of MEPs can be encou= ntered in an MPLS-TP Section considered as a Maintenance Entity (ME)? <= /o:p>

a.  <= /span>The text in section 2.2 states: “T= his document uses the term 'Section' exclusively to refer to the n=3D0 case= of the term 'Section' defined in RFC 5960”

b= .  The text in Section 3.3 states: “Any MPLS-TP LSR can imp= lement a MEP for an MPLS-TP Section”

c.  My guess (FWIW) is that only Down MEPs can be associated with the MP= LS-TP section. Is this guess correct?

3.  a.  <= span style=3D'font-size:10.0pt;font-family:"Courier New"'>The text in Sectio= n 3.3 states: “In the context of an MPLS-TP LSP, only LERs can impleme= nt MEPs”

b.  The text mentions (e.= g., in Section 6.4) that OAM flows must be fate-sharing with the data packet= s for the corresponding ME

c.  My guess= (FWIW) is that LERs (and T-PEs) can only implement per-node or per-interfac= e Down MEPs. Is this guess correct? If not, what did I miss?

4.  Can you describe a case when a per-interface Up So= urce MEP can be encountered for one of the MEs that MPLS-TP deals with (i.e.= , Section, LSP or PW) and explain how fate-sharing with the data packets is= provided in such a case? My guess (FWIW) is that this is impossible without= some changes in the MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is= this guess correct? If not could you please explain how it is supposed to o= perate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  The diagrams in Figure 3of the RFC seem to suggest that= , in the case of per-interface MEPs, Source and Sink MEP are always either b= oth Up or both Down.

a.  Is this unders= tanding correct? If not, could you please present some examples to the contr= ary?

<= span style=3D'mso-list:Ignore'>b.If my understanding in (a) a= bove is correct and if, as mentioned in (4) above, per-interface Up MEPs can= not be implemented in MPLS-TP, this would imply that per-interface Up Sink M= EPs are useless. Did I miss something?

 

Regards, and lots of thanks i= n advance,

     Sasha=

 

This e-mail mess= age is intended for the recipient only and contains information which is CON= FIDENTIAL 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 t= hen delete the original and all copies thereof.

<= p> 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_A3C5DF08D38B6049839A6F553B331C760115EDD18C10ILPTMAIL02e_-- From malcolm.betts@zte.com.cn Wed Jan 11 07:39:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4421F874C; Wed, 11 Jan 2012 07:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjEYlKjH+YNq; Wed, 11 Jan 2012 07:39:01 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6753E21F873B; Wed, 11 Jan 2012 07:39:00 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690817668700; Wed, 11 Jan 2012 23:17:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 95170.4345976004; Wed, 11 Jan 2012 23:38:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0BFcfQc018910; Wed, 11 Jan 2012 23:38:41 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> To: MIME-Version: 1.0 X-KeepSent: 5883B78D:5D3252AF-85257982:00557BCD; 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, 11 Jan 2012 10:38:38 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-11 23:38:45, Serialize complete at 2012-01-11 23:38:45 Content-Type: multipart/alternative; boundary="=_alternative 0055F1DA85257982_=" X-MAIL: mse02.zte.com.cn q0BFcfQc018910 Cc: 'Huub helvoort' , mpls@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 15:39:03 -0000 This is a multipart message in MIME format. --=_alternative 0055F1DA85257982_= Content-Type: text/plain; charset="US-ASCII" Hi Adrian, I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week. Regards, Malcolm "Adrian Farrel" 09/01/2012 12:33 PM Please respond to To , "'Huub helvoort'" cc , Subject RE: Questions about draft-betts-itu-oam-ach-code-point Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: 09 December 2011 10:49 > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort' > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Questions about draft-betts-itu-oam-ach-code-point > > Hi Malcolm and Huub, > > I have squeezed a little time from the current ITU-T meeting to look at your > draft and write-up. I have also read the email threads on the IETF discussion > list and the MPLS list. Sorry that this has taken me a week to process, but your > publication request came at pretty much the worst possible time for getting me > to do this task. > > I don't like proliferating threads across multiple mailing lists. On the other > hand it is difficult to ensure that all the constituencies are present, so I am > perpetuating the cross-posting. > > My review of the document... > > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think > only one of these is real (the spurious space in a citation). The other nits are > spurious caused by citations wrapping across lines. Could you please keep a note > of the nit so that you can fix it the next time the draft is respun or so it can > be captured in an RFC Editor Note at a later stage (you don't have to post a new > revision to address this now unless you really want to). > > 2. This document requests a code point from a registry that contains code points > that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D > whether it is your intention that your code point would also be applicable in > both cases. What is your intention? Is this "obvious" from G.8113.1 or does it > need to be clarified? > > > My review of the write-up and discussions... > > 3. There seems to be quite a feeling on the mailing lists that this document > should be run through the MPLS working group. The write-up makes a case for > progressing it as AD sponsored. As far as I can see, the main assertions to > answer are as follows. Do you have a view on these points before I make a > decision on what to do? > > a. This is a proposal to use an MPLS code point and so is part of MPLS by > definition. > > b. The type of network being managed by the OAM described in G.8113.1 is an > MPLS network. Therefore, this is clearly relevant to the MPLS working . > > Do you object to this going through the MPLS on principle, or were you just > hoping to save the WG the work? If the latter, and if the WG wants to look at > the draft, the easiest approach seems to be to redirect the work to the working > group. > > 4. G.8113.1 is clearly important to understanding to which the code point is > being put. Thus, an available and stable copy of group. G.8113.1 will be key to > the last call review of you I-D. Can you make a stable copy available (for > example, through liaison)? How does the editing work currently in progress in > the SG15 meeting affect that availability? > > 5. Can you clarify for me why the suggested value has been suggested. This will > help guide IANA who would normally do their allocation in a "tidy" way. > > Looking forward to your reply. > > Thanks, > Adrian --=_alternative 0055F1DA85257982_= Content-Type: text/html; charset="US-ASCII" Hi Adrian,

I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA.  None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented,  I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week.


Regards,

Malcolm



"Adrian Farrel" <adrian@olddog.co.uk>

09/01/2012 12:33 PM
Please respond to
<adrian@olddog.co.uk>

To
<draft-betts-itu-oam-ach-code-point@tools.ietf.org>, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
cc
<mpls@ietf.org>, <ietf@ietf.org>
Subject
RE: Questions about draft-betts-itu-oam-ach-code-point





Hi Huub and Malcolm,

I recognise that the intervening month between my original email and this one
included an SG15 meeting, Christmas, and New Year, but I had hoped for a
response by now so that we could work out what to do with the document.

In the meantime, at least my question 4 has progressed. Can you confirm that the
version of G.8113.1 for which a code point is requested is that which has been
sent to WTSA by SG15 (i.e., that which was determined), and that there are no
plans to make any updates or revisions to that document until after it has been
approved.

Thanks,
Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [
mailto:ietf-bounces@ietf.org] On Behalf Of Adrian
> Farrel
> Sent: 09 December 2011 10:49
> To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort'
> Cc: mpls@ietf.org; ietf@ietf.org
> Subject: Questions about draft-betts-itu-oam-ach-code-point
>
> Hi Malcolm and Huub,
>
> I have squeezed a little time from the current ITU-T meeting to look at your
> draft and write-up. I have also read the email threads on the IETF discussion
> list and the MPLS list. Sorry that this has taken me a week to process, but
your
> publication request came at pretty much the worst possible time for getting me
> to do this task.
>
> I don't like proliferating threads across multiple mailing lists. On the other
> hand it is difficult to ensure that all the constituencies are present, so I
am
> perpetuating the cross-posting.
>
> My review of the document...
>
> 1. idnits (
http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
> only one of these is real (the spurious space in a citation). The other nits
are
> spurious caused by citations wrapping across lines. Could you please keep a
note
> of the nit so that you can fix it the next time the draft is respun or so it
can
> be captured in an RFC Editor Note at a later stage (you don't have to post a
new
> revision to address this now unless you really want to).
>
> 2. This document requests a code point from a registry that contains code
points
> that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
> whether it is your intention that your code point would also be applicable in
> both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
> need to be clarified?
>
>
> My review of the write-up and discussions...
>
> 3. There seems to be quite a feeling on the mailing lists that this document
> should be run through the MPLS working group. The write-up makes a case for
> progressing it as AD sponsored. As far as I can see, the main assertions to
> answer are as follows. Do you have a view on these points before I make a
> decision on what to do?
>
> a. This is a proposal to use an MPLS code point and so is part of MPLS by
> definition.
>
> b. The type of network being managed by the OAM described in G.8113.1 is an
> MPLS network. Therefore, this is clearly relevant to the MPLS working .
>
> Do you object to this going through the MPLS on principle, or were you just
> hoping to save the WG the work? If the latter, and if the WG wants to look at
> the draft, the easiest approach seems to be to redirect the work to the
working
> group.
>
> 4. G.8113.1 is clearly important to understanding to which the code point is
> being put. Thus, an available and stable copy of group. G.8113.1 will be key
to
> the last call review of you I-D. Can you make a stable copy available (for
> example, through liaison)? How does the editing work currently in progress in
> the SG15 meeting affect that availability?
>
> 5. Can you clarify for me why the suggested value has been suggested. This
will
> help guide IANA who would normally do their allocation in a "tidy" way.
>
> Looking forward to your reply.
>
> Thanks,
> Adrian



--=_alternative 0055F1DA85257982_=-- From david.i.allan@ericsson.com Wed Jan 11 08:29:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8B21F8674 for ; Wed, 11 Jan 2012 08:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h14PISWNW6eg for ; Wed, 11 Jan 2012 08:29:16 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BBCBB21F865F for ; Wed, 11 Jan 2012 08:29:15 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q0BGSOLK019780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jan 2012 10:29:07 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.43]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 11 Jan 2012 11:29:02 -0500 From: David Allan I To: Alexander Vainshtein , "Italo.Busi@alcatel-lucent.com" Date: Wed, 11 Jan 2012 11:29:00 -0500 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@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: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52290B80F6EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 16:29:19 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52290B80F6EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of = arrival for an LSP, it scopes even a per-platform label to being of only pe= r-interface significance, but there should be no issue there, it is purely = an implementation choice. If I take a more general view, and apply the concept of per-interface MEPs = across the MPLS architecture (e.g. MP2P), then with per platform labels, I = simply have multiple MEPs that have a common label of arrival on different = interfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_60C093A41B5E45409A19D42CF7786DFD52290B80F6EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI Sasha:
 
Good question!
 
I'm not aware of any explicit relationship, nor can I= envision=20 the need for specifying one.
 
Given MPLS-TP is restricted to connections, implying = a single=20 interface of arrival for an LSP, it scopes even a per-platform label to bei= ng of=20 only per-interface significance, but there should be no issue there, it is= =20 purely an implementation choice.
 
If I take a more general view, and apply the concept = of=20 per-interface MEPs across the MPLS architecture (e.g. MP2P), then with per= =20 platform labels, I simply have multiple MEPs that have a common label of ar= rival=20 on different interfaces for a given LSP.
 
So that is my first blush,
 
cheers
Dave


From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, Janua= ry=20 11, 2012 5:03 AM
To: David Allan I;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

Dave, Italo and=20 all,

An additional=20 question:

 

Is=20 there any relationship between per-node vs. per-interface MEPs and per-plat= form=20 vs. per-interface label spaces?

If=20 yes, does it mean that only per-node MEPs can be encountered in the case of= =20 PWs?

 

Regards, and, again, lo= ts of=20 thanks in advance,

    = ;=20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55=20 PM
To: david.i.allan@ericsson.com;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC=20 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition = of Up=20 and Down MRPs in RFC=20 6371.

The problematic text states:

 

   A node h= osting=20 a MEP can either support per-node MEP or per-interface

   MEP(s).&= nbsp; A=20 per-node MEP resides in an unspecified location within the

   node, wh= ile a=20 per-interface MEP resides on a specific side of the

   forwardi= ng=20 engine.  In particular, a per-interface MEP is called=20 an

   "Up MEP"= or a=20 "Down MEP" depending on its location relative to the

   forwardi= ng=20 engine.  An "Up MEP" transmits OAM packets towards,=20 and

   receives= them=20 from, the direction of the forwarding engine, while a

   "Down ME= P"=20 receives OAM packets from, and transmits them towards, the

   directio= n of a=20 server layer.

 

Here are my=20 questions:

 

1.&n= bsp;=20 The text seems to sug= gest=20 that there are three types of MEPs: per-node (neither Up nor Down),=20 per-interface Up and per-interface Down. Is this understanding=20 correct?

2.&n= bsp;=20 Which types of MEPs c= an be=20 encountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?= =20

a.&n= bsp;=20 The text in section 2= .2=20 states: “This document uses the term 'Section' exclusively to refer t= o the n=3D0=20 case of the term 'Section' defined in RFC 5960”

b.&n= bsp;=20 The text in Section 3= .3=20 states: “Any MPLS-TP LSR can implement a MEP for an MPLS-TP=20 Section”

c.&n= bsp;=20 My guess (FWIW) is th= at only=20 Down MEPs can be associated with the MPLS-TP section. Is this guess correct= ?=20

3.&n= bsp;=20 Which type of MEPs ca= n be=20 encountered in a P2P MPLS-TP LSP (or MS-PW) considered as an=20 ME?

a.&n= bsp;=20 The text in Section 3= .3=20 states: “In the context of an MPLS-TP LSP, only LERs can implement=20 MEPs”

b.&n= bsp;=20 The text mentions (e.= g., in=20 Section 6.4) that OAM flows must be fate-sharing with the data packets for = the=20 corresponding ME

c.&n= bsp;=20 My guess (FWIW) is th= at LERs=20 (and T-PEs) can only implement per-node or per-interface Down MEPs. Is this= =20 guess correct? If not, what did I miss?

4.&n= bsp;=20 Can you describe a ca= se when=20 a per-interface Up Source MEP can be encountered for one of the MEs that MP= LS-TP=20 deals with (i.e., Section, LSP or PW) and explain how fate-sharing with the= data=20 packets is provided in such a case? My guess (FWIW) is that this is impossi= ble=20 without some changes in the MPLS-TP data plane as defined in RFC 3031= and=20 RFC 5= 960.=20 Is this guess correct? If not could you please explain how it is supposed t= o=20 operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?=

5.&n= bsp;=20 The diagrams in Figur= e 3of=20 the RFC seem to suggest that, in the case of per-interface MEPs, Source and= Sink=20 MEP are always either both Up or both Down.

a.&n= bsp;=20 Is this understanding= =20 correct? If not, could you please present some examples to the=20 contrary?

b.&n= bsp;=20 If my understanding i= n (a)=20 above is correct and if, as mentioned in (4) above, per-interface Up MEPs c= annot=20 be implemented in MPLS-TP, this would imply that per-interface Up Sink MEPs= are=20 useless. Did I miss something?

 

Regards, and lots of thanks in advance,

     Sasha

 

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

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

--_000_60C093A41B5E45409A19D42CF7786DFD52290B80F6EUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Wed Jan 11 08:37:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474021F87DA for ; Wed, 11 Jan 2012 08:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1wUm0Ivtqja for ; Wed, 11 Jan 2012 08:37:42 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id C60AA21F8839 for ; Wed, 11 Jan 2012 08:37:41 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1326299858!10440033!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 28582 invoked from network); 11 Jan 2012 16:37:38 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-7.tower-182.messagelabs.com with SMTP; 11 Jan 2012 16:37:38 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-da-4f0dbbc57723 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8C.8B.08306.5CBBD0F4; Wed, 11 Jan 2012 18:41:41 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 11 Jan 2012 18:37:37 +0200 From: Alexander Vainshtein To: David Allan I Date: Wed, 11 Jan 2012 18:37:36 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIA== Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@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_A3C5DF08D38B6049839A6F553B331C760115EDD18D3CILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0wUVxTu3ZlZBtyp1xXcC6nJOEYU6xK2i3ENLlGjCZrg+vrh4wcdd6+7 k+7MrDuDER+R/ugDlQSimLhp6hpXECWCiA9Yai1qo4aAJZAgItbgo1D7h/pcmtIZJlAS4/y4 +e4533e+kzvn0IS1JimDFiQVhyU+yJlTyKPDI6/st+OMJ6eyJdX1pPMq4bp92eXqO1NLuTqe /QCWkwXfPP+JKjg2epEqSLzuMRfEYu9N68ltpWAZL0myyquY9WHF6+bWh4XdvLeEYwWfm3Nw bCjIe7GIJdXN8aEQlnxcfgr7wbdMowkSiyWv7BMkv5tbs8ljd7kWL7U7uPzMuQ5nXsrmgKCw 2C7yQpAVsaLwfsxqkS+biMDdn5vI0NgA2FM7sLYUDN0Ch0AyjWAuetlQaTbwLHR/oF7DKbQV xgG6Ge8YJ1nhcYCqGtbp2AzdqPH8o3FBKsxGdb+NUrqAgDGAqhuOjgtIOA9daG2mdDwTZqHR aLnpEKA1wUJ0pHGToV2Jrt94bNIxAzegvgc9SYbXC4AGW+brOBluQf2DdYSOgdbc23t143wC 2lDf05Mmo2mIYq2dhIHT0NDgv5TBT0P939UDgy+jqt4ayvCage6eeEoa/HT0y9lesgLMikwp G5kiiUyRGPFFKBofMRv4c1R96k9iArffGDRNjUdB0jmQLgRD6g7Rn/OFXS5Ws7FXUHEQZ3tl sREYM/XHNfCwPasNQBpwFsaJLR4rxe9WSsQ2kE6buDTmdTPjsX66Q/aVBHglUBQuDmKlDSCa 4FKZlfu1HOPjS/bisDyRWq39gEoiY5pX1qZXUoucOTkfv3A25rD3ZaEV+rXx/ArjEA5P1PmM pjnE/KPbzwhjP96zUwiq/6dNdLLehkVrw9Git6GEeFER/Eb+HnDS1YejHYDujWqnlZRkCWfY mCSdCnVqoFiarKbv18GxsbFhYNOeYSbzSje1aNs3WW9YszJpVk0XLLqVtkyTqYxSkP9IYu98 6+96seGT+swKTxdsze08cHzN/ryOsiWR7m1vu2f7V1jPHPzbKZy29Jfn/pqIsEur+rc/7In8 lS+W5WUeuL7qx5rQ7OCVXcTGi0PivpbvF8wrA3B576hI1c6ZvusSl3AU8YnykXfUkze/T+fh 6e6KocKv58T7Yle3JoCNI5UA71hIhBX+P2UTh+M6BAAA Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 16:37:46 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDD18D3CILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dave, Lots of thanks for a prompt response! I am not sure I can agree with your statement "MPLS-TP is restricted to conn= ections, implying a single interface of arrival for an LSP". Please consider the case when an LSP of interest (or a PW) is nested in a pr= otected "tunnel" that is comprised of, say, active and standby LSPs. I would expect these LSPs to be as disjoint as possible including the "last= mile" interfaces on the tail-end LER. If this is the case, I would say that binding a MEP on the nested LSP/PW to= a specific interface would be impossible. Or do I miss something? What do you think? Regards, Sasha From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:29 PM To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of a= rrival for an LSP, it scopes even a per-platform label to being of only per-= interface significance, but there should be no issue there, it is purely an= implementation choice. If I take a more general view, and apply the concept of per-interface MEPs a= cross the MPLS architecture (e.g. MP2P), then with per platform labels, I si= mply have multiple MEPs that have a common label of arrival on different int= erfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-pl= atform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs in= RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node (= neither Up nor Down), per-interface Up and per-interface Down. Is this under= standing correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' e= xclusively to refer to the n=3D0 case of the term 'Section' defined in RFC 5= 960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for= an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-T= P section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) co= nsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sha= ring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encoun= tered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW)= and explain how fate-sharing with the data packets is provided in such a ca= se? My guess (FWIW) is that this is impossible without some changes in the M= PLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain= how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or I= LM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both D= own. a. Is this understanding correct? If not, could you please present some exa= mples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would i= mply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115EDD18D3CILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dave,

Lots of thanks for a prompt response!

 

I am not sure I can agre= e with your statement “MPLS-TP is restricted to connections, i= mplying a single interface of arrival for an LSP”.

Please consider the case when an LSP of interest (or a PW) is= nested in a protected “tunnel” that is comprised of, say, activ= e and standby LSPs.

I would expect these LSPs to be as disjoint as possible i= ncluding the “last mile” interfaces on the tail-end LER.

If this is= the case, I would say that binding a MEP on the nested LSP/PW to a specific= interface would be impossible. Or do I miss something?

 =

What do you think?

&= nbsp;

Regards,

     Sasha

 

From: David Allan I [mailto:david.i.allan@ericss= on.com]
Sent: Wednesday, January 11, 2012 6:29 PM
To: A= lexander Vainshtein; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.o= rg; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down M= EPs in RFC 6371

&= nbsp;

HI Sasha:

 

Good question!=

 

I'm not aware of any explicit relationship, nor can I envision= the need for specifying one.

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'> =

Given MPLS-TP is restricted to c= onnections, implying a single interface of arrival for an LSP, it scopes eve= n a per-platform label to being of only per-interface significance, but ther= e should be no issue there, it is purely an implementation choice.

 

If I take a more general view, and apply the concept of per-interface ME= Ps across the MPLS architecture (e.g. MP2P), then with per platform labels,= I simply have multiple MEPs that have a common label of arrival on differen= t interfaces for a given LSP.

<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'> =

So that is my first blush,

 

cheers

Dave

 


<= b>From:= Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent:= Wednesday, January 11, 2012 5:03 AM
To: David Allan I; Italo.= Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryan= t@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

Dave, Italo a= nd all,

An additional question:

 

Is there any relati= onship between per-node vs. per-interface MEPs and per-platform vs. per-inte= rface label spaces?

If yes, does it mean that only= per-node MEPs can be encountered in the case of PWs?

<= p class=3DMsoNormal> 

Regards, and, agai= n, lots of thanks in advance,

     Sasha

 =

From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: david.i.allan@e= ricsson.com; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stew= art Bryant (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs i= n RFC 6371

 =

Dave, Italo and all,

 

I have a couple of qu= estions regarding the definition of Up and Down MRPs in RFC 6371.

The problematic text states:

 

 &nb= sp; A node hosting a MEP can either support per-node MEP or per-interface

   MEP(s).&nbs= p; A per-node MEP resides in an unspecified location within the

   node, while a per-int= erface MEP resides on a specific side of the

   forwarding engine.  In particular= , a per-interface MEP is called an

   "Up MEP" or a "Down MEP" depen= ding on its location relative to the

   forwarding engine.  An "Up MEP" t= ransmits OAM packets towards, and

   receives them from, the direction of the forwardin= g engine, while a

&nbs= p;  "Down MEP" receives OAM packets from, and transmits them= towards, the

 &n= bsp; direction of a server layer.

 

He= re are my questions:

<= o:p> 

1.  The text seems to suggest that there are three= types of MEPs: per-node (neither Up nor Down), per-interface Up and per-int= erface Down. Is this understanding correct?

2. = ; Which ty= pes of MEPs can be encountered in an MPLS-TP Section considered as a Mainten= ance Entity (ME)?

a.  The text in section 2.2 states: &= #8220;This document uses the term 'Section' exclusively to refer to the n=3D= 0 case of the term 'Section' defined in RFC 5960”

b.  The text in Section 3.3 states: “Any MPLS-TP LSR can implement a M= EP for an MPLS-TP Section”

c.  My guess (FWIW) is= that only Down MEPs can be associated with the MPLS-TP section. Is this gue= ss correct?

3.  Which type of MEPs can be encountered i= n a P2P MPLS-TP LSP (or MS-PW) considered as an ME?

a.  The text in Section 3.3 states: “In the context of an MPLS-TP LSP, on= ly LERs can implement MEPs”

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>b.  <= span style=3D'font-size:10.0pt;font-family:"Courier New"'>The text mentions= (e.g., in Section 6.4) that OAM flows must be fate-sharing with the data pa= ckets for the corresponding ME

c.  My guess (FWIW) is t= hat LERs (and T-PEs) can only implement per-node or per-interface Down MEPs.= Is this guess correct? If not, what did I miss?

4.=   Ca= n you describe a case when a per-interface Up Source MEP can be encountered= for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and e= xplain how fate-sharing with the data packets is provided in such a case? My= guess (FWIW) is that this is impossible without some changes in the MPLS-TP= data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not c= ould you please explain how it is supposed to operate in the terms of RFC 30= 31 (NHLFE, FTN and/or ILM)?

5.  The diagrams in Figure 3= of the RFC seem to suggest that, in the case of per-interface MEPs, Source a= nd Sink MEP are always either both Up or both Down.

a.  Is this understanding correct? If not, could you please present some exampl= es to the contrary?

b.  If my understanding in (a) a= bove is correct and if, as mentioned in (4) above, per-interface Up MEPs can= not be implemented in MPLS-TP, this would imply that per-interface Up Sink M= EPs are useless. Did I miss something?

 

Regards, and lots of thanks i= n advance,

     Sasha=

 

This e-mail mess= age is intended for the recipient only and contains information which is CON= FIDENTIAL 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 t= hen 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 h= ave received this transmission in error, please inform us by e-mail, phone o= r fax, and then delete the original and all copies thereof.

<= /div>

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_A3C5DF08D38B6049839A6F553B331C760115EDD18D3CILPTMAIL02e_-- From neil.2.harrison@bt.com Wed Jan 11 08:50:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135F321F8611 for ; Wed, 11 Jan 2012 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PAiIaycgT3j for ; Wed, 11 Jan 2012 08:50:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E212121F860D for ; Wed, 11 Jan 2012 08:50:26 -0800 (PST) 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.213.0; Wed, 11 Jan 2012 16:50:26 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 11 Jan 2012 16:50:19 +0000 From: To: , Date: Wed, 11 Jan 2012 16:50:14 +0000 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAAUiLg Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440B14080B9@EMV62-UKRD.domain1.systemhost.net> References: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@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_6D3D47CB84BDE349BC23BF1C94E316E440B14080B9EMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, Italo.Busi@alcatel-lucent.com, stbryant@cisco.com Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 16:50:39 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E440B14080B9EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Please excuse for jumping in..... A connection has a very specific construct meaning, ie it can only have a s= ingle source. Indeed, this is whole basis of the 3 labelling short-cuts (= =3D=3Dinformation removal) that can be applied to the co-ps mode traffic un= its: - remove SA label - no need for PID label (if single client over server connection lif= e) - forwarding label (=3D=3DDA proxy) only need be link-unique (amongs= t all potential clients sharing that link) None of these labelling short-cuts can be applied to the cl-ps mode traffic= units.....simply because it is not based on a parent connection that 'stee= rs/constrains' the child traffic units. Not sure how well this is appreciated by all, eg I have seen some fairly se= nior IETF folks swear a PW label is a scaling/muxing label when in practice= it must be SA label proxy if there is any server merging...as indeed there= is in the LDP spin of MPLS. Of course, one cannot also truly manage resou= rce when one does not have connections either. This is why must MPLS-TP is restricted to connections. Note also in the case you are suggesting the 'working' and 'protection' ent= ities are 2 different connections. And yes maximal disjointedness between = them is a key goal...noting carefully that the lowest layer network graph (= usually a duct layer) determines the maximum practical disjoint connectivit= y, ie all client layers cannot have a greater disjointed connectivity than = the duct layer. regards, Neil From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 11 January 2012 16:38 To: David Allan I Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant@= cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Lots of thanks for a prompt response! I am not sure I can agree with your statement "MPLS-TP is restricted to con= nections, implying a single interface of arrival for an LSP". Please consider the case when an LSP of interest (or a PW) is nested in a p= rotected "tunnel" that is comprised of, say, active and standby LSPs. I would expect these LSPs to be as disjoint as possible including the "last= mile" interfaces on the tail-end LER. If this is the case, I would say that binding a MEP on the nested LSP/PW to= a specific interface would be impossible. Or do I miss something? What do you think? Regards, Sasha From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:29 PM To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of = arrival for an LSP, it scopes even a per-platform label to being of only pe= r-interface significance, but there should be no issue there, it is purely = an implementation choice. If I take a more general view, and apply the concept of per-interface MEPs = across the MPLS architecture (e.g. MP2P), then with per platform labels, I = simply have multiple MEPs that have a common label of arrival on different = interfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha 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. 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_6D3D47CB84BDE349BC23BF1C94E316E440B14080B9EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,  Please excuse for jumping in.....

 

A connection has a very specific construct meaning, ie it can only have a sin= gle source.  Indeed, this is whole basis of the 3 labelling short-cuts (=3D=3Dinformation removal) that can be applied to the co-ps mode traffic u= nits:

-        remove SA label

-        no need for PID label (if single client over server connection life)

-        forwarding label (=3D=3DDA proxy) only need be link-unique (amongst all potential clie= nts sharing that link)

 

None of these labelling short-cuts can be applied to the cl-ps mode traffic unit= s.....simply because it is not based on a parent connection that ‘steers/constrain= s’ the child traffic units.

 

Not sure how well this is appreciated by all, eg I have seen some fairly senior IETF folks swear a PW label is a scaling/muxing label when in practice it m= ust be SA label proxy if there is any server merging...as indeed there is in the L= DP spin of MPLS.  Of course, one cannot also truly manage resource when o= ne does not have connections either.

 

This is why must MPLS-TP is restricted to connections.

 

Note also in the case you are suggesting the ‘working’ and ‘pr= otection’ entities are 2 different connections.  And yes maximal disjointedness between them is a key goal...noting carefully that the lowest layer network graph (usually a duct layer) determines the maximum practical disjoint conn= ectivity, ie all client layers cannot have a greater disjointed connectivity than the duct layer.

 

regards, Neil

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 11 January 2012 16:38
To: David Allan I
Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

 

Dave,<= /o:p>

Lots of tha= nks for a prompt response!

 =

I am not su= re I can agree with your statement “MPLS-TP is restricted to connections, implying a single interface of arrival for an LSP”.

Please cons= ider the case when an LSP of interest (or a PW) is nested in a protected “tunnel” that is comprised of, say, active and standby LSPs.

I would exp= ect these LSPs to be as disjoint as possible including the “last mile” in= terfaces on the tail-end LER.

If this is = the case, I would say that binding a MEP on the nested LSP/PW to a specific interface would be impossible. Or do I miss something?

 =

What do you= think?

 =

Regards,

  = ;   Sasha

 =

From: David Allan I [mailto:david.i.allan@eri= csson.com]
Sent: Wednesday, January 11, 2012 6:29 PM
To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

 

HI Sasha:

 

Good question!

 

I'm not aware of any explicit relationship, nor can I envision = the need for specifying one.

 

Given MPLS-TP is restricted to connections, implying a single interface of arrival for an LSP, it scopes even a per-platform label to bei= ng of only per-interface significance, but there should be no issue there, it = is purely an implementation choice.

 

If I take a more general view, and apply the concept of per-interface MEPs across the MPLS architecture (e.g. MP2P), then with per platform labels, I simply have multiple MEPs that have a common label of arrival on different interfaces for a given LSP.

 

So that is my first blush,

 

cheers

Dave

 


From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

Dave, Italo= and all,

An addition= al question:

 =

Is there any relationship between per-node vs. per-interface MEPs and per-platform vs. per-interface label spaces?

If yes, does it mean that only per-node MEPs can be= encountered in the case of PWs?

 =

Regards, an= d, again, lots of thanks in advance,

  = ;   Sasha

 =

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC 6371

 

Dave, Italo and all,

 

I have a couple of questions regard= ing the definition of Up and Down MRPs in RFC 6371= .

The problematic text states:

 

   A node ho= sting a MEP can either support per-node MEP or per-interface

   MEP(s).&n= bsp; A per-node MEP resides in an unspecified location within the

   node, whi= le a per-interface MEP resides on a specific side of the

   forwardin= g engine.  In particular, a per-interface MEP is called an

   "Up MEP" or a "Down MEP" depending on its location relative to t= he

   forwardin= g engine.  An "Up MEP" transmits OAM packets towards, and=

   receives = them from, the direction of the forwarding engine, while a

   "Dow= n MEP" receives OAM packets from, and transmits them towards, the

   direction= of a server layer.

 

Here are my questions:=

 

1.The text seems to suggest that there are three types of MEPs: per-node (neither= Up nor Down), per-interface Up and per-interface Down. Is this understanding correct?

2.Which types of MEPs can be encountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?

a.The text in section 2.2 states: “This document uses the term 'Section' exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC 5960”

b.The text in Section 3.3 states: “Any MPLS-TP LSR can implement a MEP for = an MPLS-TP Section”

c.My guess (FWIW) is that only Down MEPs can be associated with the MPLS-TP sect= ion. Is this guess correct?

3.Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) considered = as an ME?

a.The text in Section 3.3 states: “In the context of an MPLS-TP LSP, only L= ERs can implement MEPs”

b.The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sharing wi= th the data packets for the corresponding ME

c.My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or per-interface Down MEPs. Is this guess correct? If not, what did I miss?

4.Can you describe a case when a per-interface Up Source MEP can be encountered f= or one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and expla= in how fate-sharing with the data packets is provided in such a case? My guess (FWIW) is that this is impossible without some changes in the MPLS-TP data plane as defined in RFC 3031= and RFC 5= 960. Is this guess correct? If not could you please explain how it is supposed t= o operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?=

5.The diagrams in Figure 3of the RFC seem to suggest that, in the case of per-interface MEPs, Source and Sink MEP are always either both Up or both D= own.

a.Is this understanding correct? If not, could you please present some examples = to the contrary?

b.If my understanding in (a) above is correct and if, as mentioned in (4) above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would imply th= at per-interface Up Sink MEPs are useless. Did I miss something?

 

Regards, and lots of thanks in adva= nce,

     Sasha=

 

This e-mail message is intended for the recipient onl= y 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 onl= y 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 onl= y 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. =

--_000_6D3D47CB84BDE349BC23BF1C94E316E440B14080B9EMV62UKRDdoma_-- From david.i.allan@ericsson.com Wed Jan 11 08:56:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9A21F8717 for ; Wed, 11 Jan 2012 08:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSneI8YZyHmi for ; Wed, 11 Jan 2012 08:56:01 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8F21F8750 for ; Wed, 11 Jan 2012 08:55:58 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0BGtrCh029412; Wed, 11 Jan 2012 10:55:55 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.43]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 11 Jan 2012 11:55:50 -0500 From: David Allan I To: Alexander Vainshtein Date: Wed, 11 Jan 2012 11:55:49 -0500 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAApaog Message-ID: <60C093A41B5E45409A19D42CF7786DFD52290B814D@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52290B814DEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 16:56:05 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52290B814DEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perfect, good example of UP MEP for a common label appearing on multiple in= terfaces in a TP environment... The implication vis-a-vis using per-interface labels on a protected path is= the protected path is an interface. I am not aware of a mechanism to assig= n a label space to a specific LSP although others may correct me. So it is = per-platform labels, and regardless of per interface or per platform, an UP= MEP distributed across multiple interfaces implying coordination of state. As most implementations would also put a per node MEP on an ingress card, I= 'm not sure there is a practical difference... thanks Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 8:38 AM To: David Allan I Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel-= lucent.com Subject: RE: Up and Down MEPs in RFC 6371 Dave, Lots of thanks for a prompt response! I am not sure I can agree with your statement "MPLS-TP is restricted to con= nections, implying a single interface of arrival for an LSP". Please consider the case when an LSP of interest (or a PW) is nested in a p= rotected "tunnel" that is comprised of, say, active and standby LSPs. I would expect these LSPs to be as disjoint as possible including the "last= mile" interfaces on the tail-end LER. If this is the case, I would say that binding a MEP on the nested LSP/PW to= a specific interface would be impossible. Or do I miss something? What do you think? Regards, Sasha From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:29 PM To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of = arrival for an LSP, it scopes even a per-platform label to being of only pe= r-interface significance, but there should be no issue there, it is purely = an implementation choice. If I take a more general view, and apply the concept of per-interface MEPs = across the MPLS architecture (e.g. MP2P), then with per platform labels, I = simply have multiple MEPs that have a common label of arrival on different = interfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha 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. 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_60C093A41B5E45409A19D42CF7786DFD52290B814DEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Perfect, good example of UP MEP for a common label ap= pearing=20 on multiple interfaces in a TP environment...
 
The implication vis-a-vis using per-interface labels = on a=20 protected path is the protected path is an interface. I am not aware of a=20 mechanism to assign a label space to a specific LSP although others may cor= rect=20 me. So it is per-platform labels, and regardless of per interface or per=20 platform, an UP MEP distributed across multiple interfaces implying coordin= ation=20 of state.
 
As most implementations would also put a per node MEP= on an=20 ingress card, I'm not sure there is a practical=20 difference...
 
thanks
Dave
 
 


From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, Janua= ry=20 11, 2012 8:38 AM
To: David Allan I
Cc: mpls@ietf.org;=20 Stewart Bryant (stbryant@cisco.com);=20 Italo.Busi@alcatel-lucent.com
Subject: RE: Up and Down MEPs in RF= C=20 6371

Dave,=

Lots of thanks for a pr= ompt=20 response!

 

I am not sure I can agr= ee with=20 your statement “M= PLS-TP=20 is restricted to connections, implying a single interface of arrival for an= =20 LSP”.

Please consider the cas= e when an=20 LSP of interest (or a PW) is nested in a protected “tunnel” tha= t is comprised=20 of, say, active and standby LSPs.

I would expect these LS= Ps to be=20 as disjoint as possible including the “last mile” interfaces on= the tail-end=20 LER.

If this is the case, I = would say=20 that binding a MEP on the nested LSP/PW to a specific interface would be=20 impossible. Or do I miss something?

 

What do you=20 think?

 

Regards,

    = ;=20 Sasha

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, January 11,= 2012=20 6:29 PM
To: Alexander Vainshtein;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

 

H= I=20 Sasha:

 

G= ood=20 question!

 

I= 'm not=20 aware of any explicit relationship, nor can I envision the need for specify= ing=20 one.

 

G= iven=20 MPLS-TP is restricted to connections, implying a single interface of arriva= l for=20 an LSP, it scopes even a per-platform label to being of only per-interface= =20 significance, but there should be no issue there, it is purely an implement= ation=20 choice.

 

I= f I=20 take a more general view, and apply the concept of per-interface MEPs acros= s the=20 MPLS architecture (e.g. MP2P), then with per platform labels, I simply have= =20 multiple MEPs that have a common label of arrival on different interfaces f= or a=20 given LSP.

 

S= o that=20 is my first blush,

 

c= heers

D= ave

&nbs= p;


From:<= /B> Alexander=20 Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wedne= sday,=20 January 11, 2012 5:03 AM
To: David Allan I;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

Dave, Italo and=20 all,

An additional=20 question:

 

Is=20 there any relationship between per-node vs. per-interface MEPs and per-plat= form=20 vs. per-interface label spaces?

If=20 yes, does it mean that only per-node MEPs can be encountered in the case of= =20 PWs?

 

Regards, and, again, lo= ts of=20 thanks in advance,

    = ;=20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55=20 PM
To: david.i.allan@ericsson.com;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC=20 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition = of Up=20 and Down MRPs in RFC=20 6371.

The problematic text states:

 

   A node h= osting=20 a MEP can either support per-node MEP or per-interface

   MEP(s).&= nbsp; A=20 per-node MEP resides in an unspecified location within the

   node, wh= ile a=20 per-interface MEP resides on a specific side of the

   forwardi= ng=20 engine.  In particular, a per-interface MEP is called=20 an

   "Up MEP"= or a=20 "Down MEP" depending on its location relative to the

   forwardi= ng=20 engine.  An "Up MEP" transmits OAM packets towards,=20 and

   receives= them=20 from, the direction of the forwarding engine, while a

   "Down ME= P"=20 receives OAM packets from, and transmits them towards, the

   directio= n of a=20 server layer.

 

Here are my=20 questions:

 

1. =20 The text= seems=20 to suggest that there are three types of MEPs: per-node (neither Up nor Dow= n),=20 per-interface Up and per-interface Down. Is this understanding=20 correct?

2. =20 Which ty= pes of=20 MEPs can be encountered in an MPLS-TP Section considered as a Maintenance E= ntity=20 (ME)?

a. =20 The text= in=20 section 2.2 states: “This document uses the term 'Section' exclusivel= y to refer=20 to the n=3D0 case of the term 'Section' defined in RFC 5960”

b. =20 The text= in=20 Section 3.3 states: “Any MPLS-TP LSR can implement a MEP for an MPLS-= TP=20 Section”

c. =20 My guess= (FWIW)=20 is that only Down MEPs can be associated with the MPLS-TP section. Is this = guess=20 correct?

3. =20 Which ty= pe of=20 MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) considered as an=20 ME?

a. =20 The text= in=20 Section 3.3 states: “In the context of an MPLS-TP LSP, only LERs can = implement=20 MEPs”

b. =20 The text= =20 mentions (e.g., in Section 6.4) that OAM flows must be fate-sharing with th= e=20 data packets for the corresponding ME

c. =20 My guess= (FWIW)=20 is that LERs (and T-PEs) can only implement per-node or per-interface Down = MEPs.=20 Is this guess correct? If not, what did I miss?

4. =20 Can you= =20 describe a case when a per-interface Up Source MEP can be encountered for o= ne of=20 the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and explain how= =20 fate-sharing with the data packets is provided in such a case? My guess (FW= IW)=20 is that this is impossible without some changes in the MPLS-TP data plane a= s=20 defined in RFC=20 3031 and RFC 5960= . Is=20 this guess correct? If not could you please explain how it is supposed to=20 operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?=

5. =20 The diag= rams in=20 Figure 3of the RFC seem to suggest that, in the case of per-interface MEPs,= =20 Source and Sink MEP are always either both Up or both Down.=20

a. =20 Is this= =20 understanding correct? If not, could you please present some examples to th= e=20 contrary?

b. =20 If my=20 understanding in (a) above is correct and if, as mentioned in (4) above,=20 per-interface Up MEPs cannot be implemented in MPLS-TP, this would imply th= at=20 per-interface Up Sink MEPs are useless. Did I miss=20 something?

 

Regards, and lots of thanks in advance,

     Sasha

 

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

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

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

--_000_60C093A41B5E45409A19D42CF7786DFD52290B814DEUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Wed Jan 11 10:03:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B871F11E8073 for ; Wed, 11 Jan 2012 10:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqhO7F0QYgIq for ; Wed, 11 Jan 2012 10:03:40 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 69E7521F8637 for ; Wed, 11 Jan 2012 10:03:39 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1326304899!59299158!3 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 10311 invoked from network); 11 Jan 2012 18:01:42 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-8.tower-27.messagelabs.com with SMTP; 11 Jan 2012 18:01:42 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-20-4f0dcfebdce1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 1E.7C.08306.BEFCD0F4; Wed, 11 Jan 2012 20:07:39 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 11 Jan 2012 20:03:36 +0200 From: Alexander Vainshtein To: David Allan I Date: Wed, 11 Jan 2012 20:01:00 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAApaogAAKJwdQ= Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@EUSAACMS0703.eamcs.ericsson.se> , <60C093A41B5E45409A19D42CF7786DFD52290B814D@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52290B814D@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_A3C5DF08D38B6049839A6F553B331C760115ED9B6898ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLsWRmVeSWpSXmKPExsUy+dWnL7pvzvP6G0yYxWbx8Px2ZoujWy0s bi1dyWpx7ukcRgcWj9Zne1k9pvzeyOrx6+tVNo8lS34yBbBENTDaJObl5ZcklqQqpKQWJ9sq BRRlliUmVyopZKbYKhkqKRTkJCan5qbmldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk/JTMvHRb Jc9gf10LC1NLXUMlOzVlQ2NrrpCMzGKFVN3cxMwchdzU4uLE9FQFoEjCFuaMN7caWAvudDFV bH0n2MA48yljFyMnh4SAicSd5TeYIWwxiQv31rOB2EICuxklDv9T6GLkArKnMUqcvrKLFSTB JmArsWn1XbAiEQE9iTUXf7OCFDELLGGUWLZhMthUFgFVievzp4BNFRbQlPi9oJepi5EDqEFL omdTMESvn8TKR1fYQWxegUCJCYu3skMs+80kMavrBFgvp0CERMvOLWDLGIGu+35qDROIzSwg LnHryXwmiKsFJJbsOQ/1gajEy8f/WCHqRSXutK9nhKjPlzi7+TUrxDJBiZMzn7BA1EtKHFxx g2UCo9gsJGNnIWmZhaQFIm4g8f7cfGYIW1ti2cLXULa+xMYvZxmRxRcwsq9ilMzMKShJyk03 MNLNLy3RS03OLEnNSdVLzs/dxAhJVC92MN4+o3mIUYCDUYmHd+deXn8h1sSy4srcQ4ySHExK orwfzgCF+JLyUyozEosz4otKc1KLDzFKcDArifA61QDleFMSK6tSi/JhUq7AGJjILMWdnA9M vnkl8cYGBrg5SuK83clvfIUE0oHpMzs1tSC1CGaODAeHkgSv2jmgFYJFqempFWmZOSUIaSYO TpAzeIDOOH0c5IzigsTc4sx0iPwpRmOOZd0LzjFy3FgAJIVY8vLzUqXEea1BxgmAlGaU5sFN A2Ww+v///79iFAcGgzBvJEgVDzD7wc17BbSKCWjVlnU8IKuAuQkuJdXA2LCmZi67xLGzsw9M m6jgfOlxx2KmPVemOu5yvLdOcO+aJDef+OScS69ZG0/Md361IYTrXcAZ469xxj72Ohcq9t7l COz47jXhZATHbbUfq4JbbF7Fbf141Cuun+04z8u17EnM27Ynx+17dUJoW7KK6VNfycdzrzv0 O74sXcNy+iDbBEftO302nkosxRmJhlrMRcWJAP6KPl47BAAA Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 18:03:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6898ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dave, Lots of thanks for a prompt response. One brief comment and one question: 1. To the best of my understanding per-LSP label space would explicitly co= ntradict RFC 3031. 2. I do not understand why you're speaking about an Up MEP in this case. C= ould you please explain? Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:55 PM To: Alexander Vainshtein Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel-l= ucent.com Subject: RE: Up and Down MEPs in RFC 6371 Perfect, good example of UP MEP for a common label appearing on multiple int= erfaces in a TP environment... The implication vis-a-vis using per-interface labels on a protected path is= the protected path is an interface. I am not aware of a mechanism to assign= a label space to a specific LSP although others may correct me. So it is pe= r-platform labels, and regardless of per interface or per platform, an UP ME= P distributed across multiple interfaces implying coordination of state. As most implementations would also put a per node MEP on an ingress card, I'= m not sure there is a practical difference... thanks Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 8:38 AM To: David Allan I Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel-l= ucent.com Subject: RE: Up and Down MEPs in RFC 6371 Dave, Lots of thanks for a prompt response! I am not sure I can agree with your statement =93MPLS-TP is restricted to co= nnections, implying a single interface of arrival for an LSP=94. Please consider the case when an LSP of interest (or a PW) is nested in a pr= otected =93tunnel=94 that is comprised of, say, active and standby LSPs. I would expect these LSPs to be as disjoint as possible including the =93las= t mile=94 interfaces on the tail-end LER. If this is the case, I would say that binding a MEP on the nested LSP/PW to= a specific interface would be impossible. Or do I miss something? What do you think? Regards, Sasha From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:29 PM To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of a= rrival for an LSP, it scopes even a per-platform label to being of only per-= interface significance, but there should be no issue there, it is purely an= implementation choice. If I take a more general view, and apply the concept of per-interface MEPs a= cross the MPLS architecture (e.g. MP2P), then with per platform labels, I si= mply have multiple MEPs that have a common label of arrival on different int= erfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-pl= atform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs in= RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node (= neither Up nor Down), per-interface Up and per-interface Down. Is this under= standing correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: =93This document uses the term 'Section'= exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960=94 b. The text in Section 3.3 states: =93Any MPLS-TP LSR can implement a MEP f= or an MPLS-TP Section=94 c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-T= P section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) co= nsidered as an ME? a. The text in Section 3.3 states: =93In the context of an MPLS-TP LSP, onl= y LERs can implement MEPs=94 b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sha= ring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encoun= tered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW)= and explain how fate-sharing with the data packets is provided in such a ca= se? My guess (FWIW) is that this is impossible without some changes in the M= PLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain= how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or I= LM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both D= own. a. Is this understanding correct? If not, could you please present some exa= mples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would i= mply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6898ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Dave,
Lots of thanks for a prompt response.
 
One brief comment and one qu= estion:
  1. To the best of my understanding per-LSP l= abel space would explicitly contradict RFC 3031.
  2. I do not understand why you're<= a> speaking about an Up MEP in this case. Could you please explain?
Regards,
     Sasha
 

From: David Allan= I [david.i.allan@ericsson.com]
Sent: Wednesday, January 11, 2012 6:55 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@al= catel-lucent.com
Subject: RE: Up and Down MEPs in RFC 6371

Perfect, good example of UP MEP for= a common label appearing on multiple interfaces in a TP environment...
 
The implication vis-a-vis using per= -interface labels on a protected path is the protected path is an interface.= I am not aware of a mechanism to assign a label space to a specific LSP although others may correct me. So it is pe= r-platform labels, and regardless of per interface or per platform, an UP ME= P distributed across multiple interfaces implying coordination of state.
 
As most implementations would also= put a per node MEP on an ingress card, I'm not sure there is a practical di= fference...
 
thanks
Dave
 
 


From: Alexander Vainshtein [mailto:A= lexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 11, 2012 8:38 AM
To: David Allan I
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@al= catel-lucent.com
Subject: RE: Up and Down MEPs in RFC 6371

Dave,

Lots of thanks for a p= rompt response!

 

I am not sure I can ag= ree with your statement =93MPLS-TP is restricted to connections,= implying a single interface of arrival for an LSP=94.

Please consider the ca= se when an LSP of interest (or a PW) is nested in a protected =93tunnel=94 t= hat is comprised of, say, active and standby LSPs.

I would expect these L= SPs to be as disjoint as possible including the =93last mile=94 interfaces o= n the tail-end LER.

If this is the case, I= would say that binding a MEP on the nested LSP/PW to a specific interface w= ould be impossible. Or do I miss something?

 

What do you think?

 

Regards,

   &nbs= p; Sasha

 

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, January 11, 2012 6:29 PM
To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

 

HI Sasha:

 

Good question!

 

I'm not aware of any explicit relationship, nor c= an I envision the need for specifying one.

 

Given MPLS-TP is restricted to connections, imply= ing a single interface of arrival for an LSP, it scopes even a per-platform= label to being of only per-interface significance, but there should be no issue there, it is purely an implement= ation choice.

 

If I take a more general view, and apply the conc= ept of per-interface MEPs across the MPLS architecture (e.g. MP2P), then wit= h per platform labels, I simply have multiple MEPs that have a common label of arrival on different interfaces f= or a given LSP.

 

So that is my first blush,

 

cheers

Dave

 


From: Alexander Vainshte= in [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

Dave, Italo and all,

An additional question= :

 

Is there any relationship between per-node vs. per-interface MEPs and= per-platform vs. per-interface label spaces?

If yes, does it mean that only per-node MEPs can be encountered in the= case of PWs?

 

Regards, and, again, l= ots of thanks in advance,

   &nbs= p; Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition= of Up and Down MRPs in RFC 6371.

The problematic text states:

 

   A node hosting a MEP can e= ither support per-node MEP or per-interface

   MEP(s).  A per-node M= EP resides in an unspecified location within the

   node, while a per-interfac= e MEP resides on a specific side of the

   forwarding engine.  I= n particular, a per-interface MEP is called an

   "Up MEP" or a &q= uot;Down MEP" depending on its location relative to the

   forwarding engine.  A= n "Up MEP" transmits OAM packets towards, and

   receives them from, the di= rection of the forwarding engine, while a

   "Down MEP" recei= ves OAM packets from, and transmits them towards, the

   direction of a server laye= r.

 

Here are my questions:

 

1.  The text= seems to suggest that there are three types of MEPs: per-node (neither Up n= or Down), per-interface Up and per-interface Down. Is this understanding cor= rect?

2.  Which typ= es of MEPs can be encountered in an MPLS-TP Section considered as a Maintena= nce Entity (ME)?

a.  The text= in section 2.2 states: =93This document uses the term 'Section' exclusively= to refer to the n=3D0 case of the term 'Section' defined in RFC 5960=94

b.  The text= in Section 3.3 states: =93Any MPLS-TP LSR can implement a MEP for an MPLS-T= P Section=94

c.  My guess= (FWIW) is that only Down MEPs can be associated with the MPLS-TP section. I= s this guess correct?

3.  Which typ= e of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) considered as a= n ME?

a.  The text= in Section 3.3 states: =93In the context of an MPLS-TP LSP, only LERs can i= mplement MEPs=94

b.  The text= mentions (e.g., in Section 6.4) that OAM flows must be fate-sharing with th= e data packets for the corresponding ME

c.  My guess= (FWIW) is that LERs (and T-PEs) can only implement per-node or per-interfac= e Down MEPs. Is this guess correct? If not, what did I miss?

4.  Can you d= escribe a case when a per-interface Up Source MEP can be encountered for one= of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and explain h= ow fate-sharing with the data packets is provided in such a case? My guess (FWIW) is that this is impossible with= out some changes in the MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain how it= is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  The diagr= ams in Figure 3of the RFC seem to suggest that, in the case of per-interface= MEPs, Source and Sink MEP are always either both Up or both Down.

a.  Is this u= nderstanding correct? If not, could you please present some examples to the= contrary?

b.  If my und= erstanding in (a) above is correct and if, as mentioned in (4) above, per-in= terface Up MEPs cannot be implemented in MPLS-TP, this would imply that per-= interface Up Sink MEPs are useless. Did I miss something?

 

Regards, and lots of thanks in advance,

     Sasha

 

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

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

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

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

--_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6898ILPTMAIL02e_-- From eosborne@cisco.com Wed Jan 11 10:59:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37F11E8086 for ; Wed, 11 Jan 2012 10:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBUVEYJqfPn8 for ; Wed, 11 Jan 2012 10:59:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C973311E8073 for ; Wed, 11 Jan 2012 10:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=9940; q=dns/txt; s=iport; t=1326308388; x=1327517988; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=8sgnPwlNd5wpQrLkSrtTWuqkU/9m2mmoAfCSYWS9RwI=; b=KbmU8DCaG2SzBGNhyqkh48PZAdx7hnIJpyvBBnTiNWJunwYqGr0ZT2Md jZa0d4yC87gAPBgwaNmGC8wGwxZBaUwGv01Kgdb8DuStQA4OPSJgMbg+f P8gni/e278VRxNvXyfjCzoshdBYdD3VAKwZqcyraSj+amVRjUzeMxNjlo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAXcDU+tJXHA/2dsb2JhbABDrQaBBYFyAQEBAwESAR0KOAcFBwYBCBEBAwEBCwYXAQdFAwYKBAESCBqHWAiZBwGeT4s6YwSIOp8t X-IronPort-AV: E=Sophos;i="4.71,494,1320624000"; d="scan'208";a="50396715" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jan 2012 18:59:34 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q0BIxXmx014386; Wed, 11 Jan 2012 18:59:33 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:59:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 12:58:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAApaogAAKJwdQAAfpV4A== From: "Eric Osborne (eosborne)" To: "Alexander Vainshtein" , "David Allan I" X-OriginalArrivalTime: 11 Jan 2012 18:59:33.0616 (UTC) FILETIME=[27F6D700:01CCD093] Cc: mpls@ietf.org, Italo.Busi@alcatel-lucent.com, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 18:59:50 -0000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, January 11, 2012 1:01 PM > To: David Allan I > Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant) > Subject: Re: [mpls] Up and Down MEPs in RFC 6371 >=20 > Dave, > Lots of thanks for a prompt response. >=20 > One brief comment and one question: >=20 > 1. To the best of my understanding per-LSP label space would explicitly > contradict RFC 3031. Per-LSP label space fits perfectly with rfc5331's idea of context-specific label space, where the context in this case is the LSP (many implementations model a TE LSP as an interface). eric > 2. I do not understand why you're speaking about an Up MEP in this > case. Could you please explain? >=20 > Regards, > Sasha >=20 > ________________________________ >=20 > From: David Allan I [david.i.allan@ericsson.com] > Sent: Wednesday, January 11, 2012 6:55 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel- > lucent.com > Subject: RE: Up and Down MEPs in RFC 6371 >=20 >=20 > Perfect, good example of UP MEP for a common label appearing on multiple > interfaces in a TP environment... >=20 > The implication vis-a-vis using per-interface labels on a protected path is the > protected path is an interface. I am not aware of a mechanism to assign a > label space to a specific LSP although others may correct me. So it is per- > platform labels, and regardless of per interface or per platform, an UP MEP > distributed across multiple interfaces implying coordination of state. >=20 > As most implementations would also put a per node MEP on an ingress card, > I'm not sure there is a practical difference... >=20 > thanks > Dave >=20 >=20 >=20 > ________________________________ >=20 > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, January 11, 2012 8:38 AM > To: David Allan I > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel- > lucent.com > Subject: RE: Up and Down MEPs in RFC 6371 >=20 >=20 >=20 > Dave, >=20 > Lots of thanks for a prompt response! >=20 >=20 >=20 > I am not sure I can agree with your statement "MPLS-TP is restricted to > connections, implying a single interface of arrival for an LSP". >=20 > Please consider the case when an LSP of interest (or a PW) is nested in a > protected "tunnel" that is comprised of, say, active and standby LSPs. >=20 > I would expect these LSPs to be as disjoint as possible including the "last > mile" interfaces on the tail-end LER. >=20 > If this is the case, I would say that binding a MEP on the nested LSP/PW to a > specific interface would be impossible. Or do I miss something? >=20 >=20 >=20 > What do you think? >=20 >=20 >=20 > Regards, >=20 > Sasha >=20 >=20 >=20 > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Wednesday, January 11, 2012 6:29 PM > To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: RE: Up and Down MEPs in RFC 6371 >=20 >=20 >=20 > HI Sasha: >=20 >=20 >=20 > Good question! >=20 >=20 >=20 > I'm not aware of any explicit relationship, nor can I envision the need for > specifying one. >=20 >=20 >=20 > Given MPLS-TP is restricted to connections, implying a single interface of > arrival for an LSP, it scopes even a per-platform label to being of only per- > interface significance, but there should be no issue there, it is purely an > implementation choice. >=20 >=20 >=20 > If I take a more general view, and apply the concept of per-interface MEPs > across the MPLS architecture (e.g. MP2P), then with per platform labels, I > simply have multiple MEPs that have a common label of arrival on different > interfaces for a given LSP. >=20 >=20 >=20 > So that is my first blush, >=20 >=20 >=20 > cheers >=20 > Dave >=20 >=20 >=20 > ________________________________ >=20 > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, January 11, 2012 5:03 AM > To: David Allan I; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: RE: Up and Down MEPs in RFC 6371 >=20 > Dave, Italo and all, >=20 > An additional question: >=20 >=20 >=20 > Is there any relationship between per-node vs. per-interface MEPs and per- > platform vs. per-interface label spaces? >=20 > If yes, does it mean that only per-node MEPs can be encountered in the case > of PWs? >=20 >=20 >=20 > Regards, and, again, lots of thanks in advance, >=20 > Sasha >=20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, January 11, 2012 2:55 PM > To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: [mpls] Up and Down MEPs in RFC 6371 >=20 >=20 >=20 > Dave, Italo and all, >=20 >=20 >=20 > I have a couple of questions regarding the definition of Up and Down MRPs > in RFC 6371 = . >=20 > The problematic text states: >=20 >=20 >=20 > A node hosting a MEP can either support per-node MEP or per-interface >=20 > MEP(s). A per-node MEP resides in an unspecified location within the >=20 > node, while a per-interface MEP resides on a specific side of the >=20 > forwarding engine. In particular, a per-interface MEP is called an >=20 > "Up MEP" or a "Down MEP" depending on its location relative to the >=20 > forwarding engine. An "Up MEP" transmits OAM packets towards, and >=20 > receives them from, the direction of the forwarding engine, while a >=20 > "Down MEP" receives OAM packets from, and transmits them towards, the >=20 > direction of a server layer. >=20 >=20 >=20 > Here are my questions: >=20 >=20 >=20 > 1. The text seems to suggest that there are three types of MEPs: per-node > (neither Up nor Down), per-interface Up and per-interface Down. Is this > understanding correct? >=20 > 2. Which types of MEPs can be encountered in an MPLS-TP Section > considered as a Maintenance Entity (ME)? >=20 > a. The text in section 2.2 states: "This document uses the term 'Section' > exclusively to refer to the n=3D0 case of the term 'Section' defined = in RFC 5960" >=20 > b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for > an MPLS-TP Section" >=20 > c. My guess (FWIW) is that only Down MEPs can be associated with the > MPLS-TP section. Is this guess correct? >=20 > 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS- > PW) considered as an ME? >=20 > a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only LERs > can implement MEPs" >=20 > b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate- > sharing with the data packets for the corresponding ME >=20 > c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or > per-interface Down MEPs. Is this guess correct? If not, what did I miss? >=20 > 4. Can you describe a case when a per-interface Up Source MEP can be > encountered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or > PW) and explain how fate-sharing with the data packets is provided in such a > case? My guess (FWIW) is that this is impossible without some changes in the > MPLS-TP data plane as defined in RFC 3031 > and RFC 5960 > . Is this guess > correct? If not could you please explain how it is supposed to operate in the > terms of RFC 3031 (NHLFE, FTN and/or ILM)? >=20 > 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of > per-interface MEPs, Source and Sink MEP are always either both Up or both > Down. >=20 > a. Is this understanding correct? If not, could you please present some > examples to the contrary? >=20 > b. If my understanding in (a) above is correct and if, as mentioned in (4) > above, per-interface Up MEPs cannot be implemented in MPLS-TP, this > would imply that per-interface Up Sink MEPs are useless. Did I miss > something? >=20 >=20 >=20 > Regards, and lots of thanks in advance, >=20 > Sasha >=20 >=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 > 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 > 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 > 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 gregory.mirsky@ericsson.com Wed Jan 11 11:58:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3E21F85E9 for ; Wed, 11 Jan 2012 11:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4G8w-OKlt4h for ; Wed, 11 Jan 2012 11:58:10 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 082C521F85E4 for ; Wed, 11 Jan 2012 11:58:09 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0BJvtAI009671; Wed, 11 Jan 2012 13:58:01 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 11 Jan 2012 14:57:51 -0500 From: Gregory Mirsky To: Alexander Vainshtein , David Allan I , "Italo.Busi@alcatel-lucent.com" Date: Wed, 11 Jan 2012 14:57:49 -0500 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAA2af1A= 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_FE60A4E52763E84B935532D7D9294FF13229989ECAEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 19:58:13 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13229989ECAEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, et al., would offer my $.02. Couple somewhat generic comments: * in most cases, nodal MEP is identical to Down MEP * ME that is terminated by Up MEPs is different from ME terminated by Down ME= Ps over the same LSP/PW * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down * I don't know how practical are Up MEPs for MPLS-TP More notes are in-line and tagged GIM>>. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO,= PW's Up MEP would be associated with AC and Down MEP would be associated w= ith PW/virtual interface itself. Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? GIM>> IMO, Up and nodal MEPs can be associated with MPLS-TP Section. 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? GIM>> I think that Up MEP can be instantiated with fate sharing. 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_FE60A4E52763E84B935532D7D9294FF13229989ECAEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sasha, et al.,
would offer my $.02.
Couple somewhat generic comments:
  • in most cases, nodal MEP is identical to Down=20 MEP
  • ME that is terminated by Up MEPs is different from ME terminated= by=20 Down MEPs over the same LSP/PW
  • ME can be terminated by MEP of the same class, i.e. nodal, Up or= =20 Down
  • I don't know how practical are Up MEPs for=20 MPLS-TP
 More notes are in-line and tagged=20 GIM>>.
 
  &n= bsp; Regards,
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Wednesday, January 11, 2012 5:03 AM
To:=20 David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org;=20 Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Do= wn=20 MEPs in RFC 6371

Dave, Italo and=20 all,

An additional=20 question:

 

Is=20 there any relationship between per-node vs. per-interface MEPs and per-plat= form=20 vs. per-interface label spaces?

If=20 yes, does it mean that only per-node MEPs can be encountered in the case of= =20 PWs? 

 GIM>= > I=20 think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up = MEP=20 would be associated with AC and Down MEP would be associated with PW/virtua= l=20 interface itself.

 

Regards, and, again, lo= ts of=20 thanks in advance,

    = ;=20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55=20 PM
To: david.i.allan@ericsson.com;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC=20 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition = of Up=20 and Down MRPs in RFC=20 6371.

The problematic text states:

 

   A node h= osting=20 a MEP can either support per-node MEP or per-interface

   MEP(s).&= nbsp; A=20 per-node MEP resides in an unspecified location within the

   node, wh= ile a=20 per-interface MEP resides on a specific side of the

   forwardi= ng=20 engine.  In particular, a per-interface MEP is called=20 an

   "Up MEP"= or a=20 "Down MEP" depending on its location relative to the

   forwardi= ng=20 engine.  An "Up MEP" transmits OAM packets towards,=20 and

   receives= them=20 from, the direction of the forwarding engine, while a

   "Down ME= P"=20 receives OAM packets from, and transmits them towards, the

   directio= n of a=20 server layer.

 

Here are my=20 questions:

 

1.&n= bsp;=20 The text seems to sug= gest=20 that there are three types of MEPs: per-node (neither Up nor Down),=20 per-interface Up and per-interface Down. Is this understanding=20 correct?

2.&n= bsp;=20 Which types of MEPs c= an be=20 encountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?= =20

a.&n= bsp;=20 The text in section 2= .2=20 states: “This document uses the term 'Section' exclusively to refer t= o the n=3D0=20 case of the term 'Section' defined in RFC 5960”

b.&n= bsp;=20 The text in Section 3= .3=20 states: “Any MPLS-TP LSR can implement a MEP for an MPLS-TP=20 Section”

c.&n= bsp;=20 My guess (FWIW) is th= at only=20 Down MEPs can be associated with the MPLS-TP section. Is this guess=20 correct?  

GIM>> I= MO, Up and=20 nodal MEPs can be associated with MPLS-TP=20 Section. 

3.&n= bsp;=20 Which type of MEPs ca= n be=20 encountered in a P2P MPLS-TP LSP (or MS-PW) considered as an=20 ME?

a.&n= bsp;=20 The text in Section 3= .3=20 states: “In the context of an MPLS-TP LSP, only LERs can implement=20 MEPs”

b.&n= bsp;=20 The text mentions (e.= g., in=20 Section 6.4) that OAM flows must be fate-sharing with the data packets for = the=20 corresponding ME

c.&n= bsp;=20 My guess (FWIW) is th= at LERs=20 (and T-PEs) can only implement per-node or per-interface Down MEPs. Is this= =20 guess correct? If not, what did I miss?  

GIM>> I= think that=20 Up MEP can be instantiated w= ith fate=20 sharing.

4.&n= bsp;=20 Can you describe a ca= se when=20 a per-interface Up Source MEP can be encountered for one of the MEs that MP= LS-TP=20 deals with (i.e., Section, LSP or PW) and explain how fate-sharing with the= data=20 packets is provided in such a case? My guess (FWIW) is that this is impossi= ble=20 without some changes in the MPLS-TP data plane as defined in RFC 3031= and=20 RFC 5= 960.=20 Is this guess correct? If not could you please explain how it is supposed t= o=20 operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?=

5.&n= bsp;=20 The diagrams in Figur= e 3of=20 the RFC seem to suggest that, in the case of per-interface MEPs, Source and= Sink=20 MEP are always either both Up or both Down.

a.&n= bsp;=20 Is this understanding= =20 correct? If not, could you please present some examples to the=20 contrary?

b.&n= bsp;=20 If my understanding i= n (a)=20 above is correct and if, as mentioned in (4) above, per-interface Up MEPs c= annot=20 be implemented in MPLS-TP, this would imply that per-interface Up Sink MEPs= are=20 useless. Did I miss something?

 

Regards, and lots of thanks in advance,

     Sasha

 

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

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

--_000_FE60A4E52763E84B935532D7D9294FF13229989ECAEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Wed Jan 11 13:05:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5C711E80A5 for ; Wed, 11 Jan 2012 13:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaSykXxOKEzF for ; Wed, 11 Jan 2012 13:05:23 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15AB911E8079 for ; Wed, 11 Jan 2012 13:05:22 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0BL4jS5024056; Wed, 11 Jan 2012 15:04:46 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 11 Jan 2012 16:04:39 -0500 From: Gregory Mirsky To: "neil.2.harrison@bt.com" , "Alexander.Vainshtein@ecitele.com" , David Allan I Date: Wed, 11 Jan 2012 16:04:38 -0500 Thread-Topic: Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371) Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAAUiLgAAkL/rA= Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD52290B80F6@EUSAACMS0703.eamcs.ericsson.se> <6D3D47CB84BDE349BC23BF1C94E316E440B14080B9@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E440B14080B9@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: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13229989F76EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "stbryant@cisco.com" Subject: [mpls] Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 11 Jan 2012 21:05:29 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13229989F76EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Neal, et al., my apologies for taking discussion off-topic. I find that we're returning t= o question of applicability of local protection as per RFC 4090 to MPLS-TP.= If I missed it being already settled and addressed, my apologies again. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of nei= l.2.harrison@bt.com Sent: Wednesday, January 11, 2012 8:50 AM To: Alexander.Vainshtein@ecitele.com; David Allan I Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; stbryant@cisco.com Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Hi Sasha, Please excuse for jumping in..... A connection has a very specific construct meaning, ie it can only have a s= ingle source. Indeed, this is whole basis of the 3 labelling short-cuts (= =3D=3Dinformation removal) that can be applied to the co-ps mode traffic un= its: - remove SA label - no need for PID label (if single client over server connection lif= e) - forwarding label (=3D=3DDA proxy) only need be link-unique (amongs= t all potential clients sharing that link) None of these labelling short-cuts can be applied to the cl-ps mode traffic= units.....simply because it is not based on a parent connection that 'stee= rs/constrains' the child traffic units. Not sure how well this is appreciated by all, eg I have seen some fairly se= nior IETF folks swear a PW label is a scaling/muxing label when in practice= it must be SA label proxy if there is any server merging...as indeed there= is in the LDP spin of MPLS. Of course, one cannot also truly manage resou= rce when one does not have connections either. This is why must MPLS-TP is restricted to connections. Note also in the case you are suggesting the 'working' and 'protection' ent= ities are 2 different connections. And yes maximal disjointedness between = them is a key goal...noting carefully that the lowest layer network graph (= usually a duct layer) determines the maximum practical disjoint connectivit= y, ie all client layers cannot have a greater disjointed connectivity than = the duct layer. regards, Neil From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 11 January 2012 16:38 To: David Allan I Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant@= cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Lots of thanks for a prompt response! I am not sure I can agree with your statement "MPLS-TP is restricted to con= nections, implying a single interface of arrival for an LSP". Please consider the case when an LSP of interest (or a PW) is nested in a p= rotected "tunnel" that is comprised of, say, active and standby LSPs. I would expect these LSPs to be as disjoint as possible including the "last= mile" interfaces on the tail-end LER. If this is the case, I would say that binding a MEP on the nested LSP/PW to= a specific interface would be impossible. Or do I miss something? What do you think? Regards, Sasha From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, January 11, 2012 6:29 PM To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 HI Sasha: Good question! I'm not aware of any explicit relationship, nor can I envision the need for= specifying one. Given MPLS-TP is restricted to connections, implying a single interface of = arrival for an LSP, it scopes even a per-platform label to being of only pe= r-interface significance, but there should be no issue there, it is purely = an implementation choice. If I take a more general view, and apply the concept of per-interface MEPs = across the MPLS architecture (e.g. MP2P), then with per platform labels, I = simply have multiple MEPs that have a common label of arrival on different = interfaces for a given LSP. So that is my first blush, cheers Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha 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. 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_FE60A4E52763E84B935532D7D9294FF13229989F76EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Neal, et al.,
my apologies for taking discussion off-topic. I fi= nd that=20 we're returning to question of applicability of local protection as per RFC= 4090=20 to MPLS-TP. If I missed it being already settled and addressed, my apologie= s=20 again.
 
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 neil.2.harrison@bt.com
Sent: Wednesday, January 11, 2012 8:50= =20 AM
To: Alexander.Vainshtein@ecitele.com; David Allan I
Cc:<= /B>=20 mpls@ietf.org; Italo.Busi@alcatel-lucent.com;=20 stbryant@cisco.com
Subject: Re: [mpls] Up and Down MEPs in RFC=20 6371

Hi Sasha,&nbs= p;=20 Please excuse for jumping in.....

 

A connection = has a=20 very specific construct meaning, ie it can only have a single source. = =20 Indeed, this is whole basis of the 3 labelling short-cuts (=3D=3Dinformatio= n=20 removal) that can be applied to the co-ps mode traffic=20 units:

-  =      =20 remove SA label

-  =      =20 no need for PID label (if single client over server connection=20 life)

-  =      =20 forwarding label (=3D=3DDA proxy) only need be link-unique (amongst all pot= ential=20 clients sharing that link)

 

None of these= =20 labelling short-cuts can be applied to the cl-ps mode traffic units.....sim= ply=20 because it is not based on a parent connection that ‘steers/constrain= s’ the=20 child traffic units.

 

Not sure how = well=20 this is appreciated by all, eg I have seen some fairly senior IETF folks sw= ear a=20 PW label is a scaling/muxing label when in practice it must be SA label pro= xy if=20 there is any server merging...as indeed there is in the LDP spin of MPLS.=20  Of course, one cannot also truly manage resource when one does not ha= ve=20 connections either.

 

This is why m= ust=20 MPLS-TP is restricted to connections.

 

Note also in = the=20 case you are suggesting the ‘working’ and ‘protectionR= 17; entities are 2 different=20 connections.  And yes maximal disjointedness between them is a key=20 goal...noting carefully that the lowest layer network graph (usually a duct= =20 layer) determines the maximum practical disjoint connectivity, ie all clien= t=20 layers cannot have a greater disjointed connectivity than the duct=20 layer.

 

regards,=20 Neil

 

From:<= /B>= =20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: 11 January 2012 16:38
To:=20 David Allan I
Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com;=20 Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Do= wn=20 MEPs in RFC 6371

 

Dave,

Lots of th= anks for a=20 prompt response!

 

I am not s= ure I can=20 agree with your statement “M= PLS-TP=20 is restricted to connections, implying a single interface of arrival for an= =20 LSP”.

Please con= sider the=20 case when an LSP of interest (or a PW) is nested in a protected “tunn= el” that is=20 comprised of, say, active and standby LSPs.

I would ex= pect these=20 LSPs to be as disjoint as possible including the “last mile” in= terfaces on the=20 tail-end LER.

If this is= the case,=20 I would say that binding a MEP on the nested LSP/PW to a specific interface= =20 would be impossible. Or do I miss something?

 

What do yo= u=20 think?

 

Regards,

    =20 Sasha

 

From:<= /B>= David=20 Allan I [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, Jan= uary=20 11, 2012 6:29 PM
To: Alexander Vainshtein;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

 

H= I=20 Sasha:

 

G= ood=20 question!

 

I= 'm not=20 aware of any explicit relationship, nor can I envision the need for specify= ing=20 one.

 

G= iven=20 MPLS-TP is restricted to connections, implying a single interface of arriva= l for=20 an LSP, it scopes even a per-platform label to being of only per-interface= =20 significance, but there should be no issue there, it is purely an implement= ation=20 choice.

 

I= f I=20 take a more general view, and apply the concept of per-interface MEPs acros= s the=20 MPLS architecture (e.g. MP2P), then with per platform labels, I simply have= =20 multiple MEPs that have a common label of arrival on different interfaces f= or a=20 given LSP.

 

S= o that=20 is my first blush,

 

c= heers

D= ave

&nbs= p;


From:<= /B>= =20 Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent:= =20 Wednesday, January 11, 2012 5:03 AM
To: David Allan I;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

Dave, Ital= o and=20 all,

An additio= nal=20 question:

 

Is there any relationship between per-node vs.=20 per-interface MEPs and per-platform vs. per-interface label=20 spaces?

If yes, does it mean that only per-node MEPs can b= e=20 encountered in the case of PWs?

 

Regards, a= nd, again,=20 lots of thanks in advance,

    =20 Sasha

 

From:<= /B>= =20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55=20 PM
To: david.i.allan@ericsson.com;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC=20 6371

 

Dave, Italo and all,

 

I have a couple of questions regard= ing the=20 definition of Up and Down MRPs in RFC=20 6371.

The problematic text=20 states:

 

   A node h= osting=20 a MEP can either support per-node MEP or per-interface

   MEP(s).&= nbsp; A=20 per-node MEP resides in an unspecified location within the

   node, wh= ile a=20 per-interface MEP resides on a specific side of the

   forwardi= ng=20 engine.  In particular, a per-interface MEP is called=20 an

   "Up MEP"= or a=20 "Down MEP" depending on its location relative to the

   forwardi= ng=20 engine.  An "Up MEP" transmits OAM packets towards,=20 and

   receives= them=20 from, the direction of the forwarding engine, while a

   "Down ME= P"=20 receives OAM packets from, and transmits them towards, the

   directio= n of a=20 server layer.

 

Here are my=20 questions:

 

1.The=20 text seems to suggest that there are three types of MEPs: per-node (neither= Up=20 nor Down), per-interface Up and per-interface Down. Is this understanding=20 correct?

2.Which types of MEPs c= an be=20 encountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?= =20

a.The=20 text in section 2.2 states: “This document uses the term 'Section' ex= clusively=20 to refer to the n=3D0 case of the term 'Section' defined in RFC=20 5960”

b.The=20 text in Section 3.3 states: “Any MPLS-TP LSR can implement a MEP for = an MPLS-TP=20 Section”

c.My=20 guess (FWIW) is that only Down MEPs can be associated with the MPLS-TP sect= ion.=20 Is this guess correct?

3.Which type of MEPs ca= n be=20 encountered in a P2P MPLS-TP LSP (or MS-PW) considered as an=20 ME?

a.The=20 text in Section 3.3 states: “In the context of an MPLS-TP LSP, only L= ERs can=20 implement MEPs”

b.The=20 text mentions (e.g., in Section 6.4) that OAM flows must be fate-sharing wi= th=20 the data packets for the corresponding ME

c.My=20 guess (FWIW) is that LERs (and T-PEs) can only implement per-node or=20 per-interface Down MEPs. Is this guess correct? If not, what did I miss?=20

4.Can=20 you describe a case when a per-interface Up Source MEP can be encountered f= or=20 one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and expla= in=20 how fate-sharing with the data packets is provided in such a case? My guess= =20 (FWIW) is that this is impossible without some changes in the MPLS-TP data = plane=20 as defined in RFC 3031= and=20 RFC 5= 960.=20 Is this guess correct? If not could you please explain how it is supposed t= o=20 operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?=

5.The=20 diagrams in Figure 3of the RFC seem to suggest that, in the case of=20 per-interface MEPs, Source and Sink MEP are always either both Up or both D= own.=20

a.Is=20 this understanding correct? If not, could you please present some examples = to=20 the contrary?

b.If=20 my understanding in (a) above is correct and if, as mentioned in (4) above,= =20 per-interface Up MEPs cannot be implemented in MPLS-TP, this would imply th= at=20 per-interface Up Sink MEPs are useless. Did I miss=20 something?

 

Regards, and lots of thanks in=20 advance,

    =20 Sasha

 

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

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

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

--_000_FE60A4E52763E84B935532D7D9294FF13229989F76EUSAACMS0715e_-- From adrian@olddog.co.uk Wed Jan 11 14:40:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D921F84F7 for ; Wed, 11 Jan 2012 14:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl-RTntMYhzk for ; Wed, 11 Jan 2012 14:40:00 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2D221F84EC for ; Wed, 11 Jan 2012 14:39:59 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0BMdwEB003912; Wed, 11 Jan 2012 22:39:58 GMT Received: from 950129200 (adsl-62-167-106-87.adslplus.ch [62.167.106.87]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0BMdqsb003893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 22:39:57 GMT From: "Adrian Farrel" To: , References: <20120111222040.25290.75566.idtracker@ietfa.amsl.com> In-Reply-To: <20120111222040.25290.75566.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 22:39:53 -0000 Message-ID: <023c01ccd0b1$f2690760$d73b1620$@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: AQEzTa/HlrWMKMpRiu7hHwMGbTmmC5c6x80g Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-bhh-mpls-tp-oam-y1731-08.txt 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: Wed, 11 Jan 2012 22:40:01 -0000 Hi, Now I am confused :-( Does draft-bhh duplicate the intent of draft-betts or compete with it? Huub, you are an editor of draft-bhh and document shepherd for draft-betts: which approach are you advocating? Thanks, Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 11 January 2012 22:21 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-bhh-mpls-tp-oam-y1731-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : MPLS-TP OAM based on Y.1731 > Author(s) : Italo Busi > Huub van Helvoort > Jia He > Filename : draft-bhh-mpls-tp-oam-y1731-08.txt > Pages : 29 > Date : 2012-01-11 > > This document describes methods to leverage Y.1731 [2] Protocol Data > Units (PDU) and procedures (state machines) to provide a set of > Operation, Administration, and Maintenance (OAM) mechanisms that > meets the MPLS Transport Profile (MPLS-TP) OAM requirements as > defined in [8]. > > In particular, this document describes the MPLS-TP technology > specific encapsulation mechanisms to carry these OAM PDUs within > MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP > networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhh-mpls-tp-oam-y1731-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-bhh-mpls-tp-oam-y1731-08.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Alexander.Vainshtein@ecitele.com Wed Jan 11 22:24:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F8321F8491 for ; Wed, 11 Jan 2012 22:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.515 X-Spam-Level: X-Spam-Status: No, score=-4.515 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTi9r-GCHn2J for ; Wed, 11 Jan 2012 22:24:46 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 83EFB21F847D for ; Wed, 11 Jan 2012 22:24:44 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1326349480!8760023!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 25282 invoked from network); 12 Jan 2012 06:24:41 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-13.tower-174.messagelabs.com with SMTP; 12 Jan 2012 06:24:41 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-47-4f0e7d9aeb1e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 57.52.08306.A9D7E0F4; Thu, 12 Jan 2012 08:28:43 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Jan 2012 08:24:43 +0200 From: Alexander Vainshtein To: Gregory Mirsky Date: Thu, 12 Jan 2012 08:24:11 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAA2af1AAFkuLyw== 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_A3C5DF08D38B6049839A6F553B331C760115ED9B689DILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTa2wMURTHc3f2MV2dZmxVbzc+jPGKsrWryAgrIpGUhFaQUIKxe+0OuzNr Z1pKRUuptCQaQiwJqg+UlKpX6hGlCcK2JWjqTT3a1ZAqVUXN7FQ1EfPh5n/v+Z3zP3NzD46Z ThjMOMdLyM+zHlpv1O5qaWu37N8QlWz9esPIvKw9jzHvmvIAU3OWYRqLj+mY4JsDYKouacvb y7qk3V2ndUnfvzzQJxUVdWpStKlZYDLL84LESohyItFhp1P8XDrryKApzmmnbTTl87AO5EW8 ZKdZnw/xTnqKkfrnmyxjHE8h3iE4Od5lp2fMTbYwzPiJFhs9ZfgQW+Ik4zw3J1LI4mU5D+VF osi6ECWfLKvE3OWt23S+p61g7Zk9i7LA9TsgD0TgkBwHC181alU9ENY9K9fnASNuIqsArC6+ ZFA3ewC8+64wTOlJO6woe6pX9ADSCh+XlGIKhJF1AHZePWlQAlpyGCxrDoahaHIk7Dq0Q5MH cDkhHm6vmKvmToP3c7LDOEHOgddzAz1mbwA8deOKTglEkAtg1ZayMATk9jpun9AoGiNjYWPT QY3aNgmLLtViqo6Bza9/6VQ+Bj7JLQeKL0YKsD5EqV794a19TT1/HAevHW3Q7gQDA32qBv5m BPpkqIgVfgwexFQ9CpYcDvXoMfB0+13Q9/wQMBwHcZzHJy33uqxjLUKalIAcnIQ8KMEheCuA +rDeXwCP74ysBiQO6Eji4mUi2aRj08UMbzWIwzV0DGFbH5VsilouODPcrOhe6k/zILEaQByj BxDTMmWccLIZ65Bf+BOaLt9/AWbu5xDkJ8xLSxOt1v9v6Fgi3/Fhlol0yc9zFUI+5P9TZxCO 05AIKfb9/ciF1q7gPNLfsAaPUNqIlNt4oTCE6GO9IudS47dBIn7swqMgwHOC8mrS8gKPzLHE 6kwZJRXUncb3VlOGbGN3d3cLiJWvIVo1jZRHsLdei2ylka3SnWEreZh6Q+YssOkeXrB4lGVx 7a9zzltjvlY0Lnt+yniko3l0R2Foc2XC5x+ByiXf3OBVbvnUbw3ucYOffDIvjF8/e29p6upH Xbvezt9U1PmzvnVldiHjaXiYD+svfi+YkF2yPbVu6M3Mfc8ijDe3hZoS28oWjTbkj6ixzcz5 vHVGVXoo9CGaXtOeXdN2htaKbtYWj/lF9jfPWAI1PwQAAA== Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 06:24:48 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B689DILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. Please see some responses inline below (orange marked [Sasha]). Regards, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, January 11, 2012 9:57 PM To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dear Sasha, et al., would offer my $.02. Couple somewhat generic comments: * in most cases, nodal MEP is identical to Down MEP [[Sasha]] I tend to agree with this statement. * ME that is terminated by Up MEPs is different from ME terminated by Down MEP= s over the same LSP/PW [[Sasha]] It has been my understanding that 6371 consideres each LSP, PW or= Section (in the restricted sense it uses the term) as single individual ME.= Nesting of MEs is only discussed in the context of tandem connections and s= egments. * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down [[Sasha]] Do you mean that all MEPs in teh given ME must belong to the same= class? If so, I agree with you - in particular because I see MEPs as bi-dir= ectional (both transmiting and receiving). * I don't know how practical are Up MEPs for MPLS-TP [[Sasha]] Well, I do not know if they are technically possible, and you doub= t their practical meaning... Looks like we are converging on the same conclu= sion from different directions! More notes are in-line and tagged GIM>>. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-pl= atform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO,= PW's Up MEP would be associated with AC and Down MEP would be associated wi= th PW/virtual interface itself. [[Sasha]] What about PWs between VPLS instances? Or are those out of scope o= f MPLS-TP Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs in= RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node (= neither Up nor Down), per-interface Up and per-interface Down. Is this under= standing correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: =93This document uses the term 'Section'= exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960=94 b. The text in Section 3.3 states: =93Any MPLS-TP LSR can implement a MEP f= or an MPLS-TP Section=94 c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-T= P section. Is this guess correct? GIM>> IMO, Up and nodal MEPs can be associated with MPLS-TP Section. [[Sasha]] Nodal MEPs can be associated with MPLS-TP sessions in the restrict= ed sense of 6371 (0-depth label stack), but seem to be undistinguishable fro= m Down MEPs. But I do not understand what an Up MEP for a Section could mean= - are not Sections by definition terminated on physical interfaces? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) co= nsidered as an ME? a. The text in Section 3.3 states: =93In the context of an MPLS-TP LSP, onl= y LERs can implement MEPs=94 b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sha= ring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? GIM>> I think that Up MEP can be instantiated with fate sharing. [[Sasha]] W= ell, fate-sharing within a box is always an open question... 4. Can you describe a case when a per-interface Up Source MEP can be encoun= tered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW)= and explain how fate-sharing with the data packets is provided in such a ca= se? My guess (FWIW) is that this is impossible without some changes in the M= PLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain= how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or I= LM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both D= own. a. Is this understanding correct? If not, could you please present some exa= mples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would i= mply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B689DILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Dear Greg,
Lots of thanks for a prompt response.
 
Please see some responses inline below (= orange marked [Sasha]).
 
Regards,
     Sasha
 

From: Gregory Mirs= ky [gregory.mirsky@ericsson.com]
Sent: Wednesday, January 11, 2012 9:57 PM
To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.co= m
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC 6371

Dear Sasha, et al.,
would offer my $.02.<= /div>
Couple somewhat generic comments:
  • in most cases, nodal MEP is identical to Down= MEP

[[Sasha]] I tend to agree with this statement.

  • ME that is terminated by Up MEPs is different= from ME terminated by Down MEPs over the same LSP/PW

[[Sasha]] It has= been my understanding that 6371 consideres each LSP, PW or Section (in the= restricted sense it uses the term) as single individual ME. Nesting of MEs is only discussed in the context of tand= em connections and segments. 

  • ME can be terminated by MEP of the same class,= i.e. nodal, Up or Down

[[Sasha]] Do you mean that all MEPs in t= eh given ME must belong to the same class? If so, I agree with you - in part= icular because I see MEPs as bi-directional (both transmiting and receiving).

  • I don't know how practical are Up MEPs for MPL= S-TP

[[Sasha]] Well, I do not know if they ar= e technically possible, and you doubt their practical meaning... Looks like= we are converging on the same conclusion from different directions!

 More notes are in-line and ta= gged GIM>>.
 
 &nb= sp;  Regards,
 &nb= sp;      Greg


From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Dave, Italo and all,

An additional question= :

 

Is there any relationship between per-node vs. per-interface MEPs and= per-platform vs. per-interface label spaces?

If yes, does it mean that only per-node MEPs can be encountered in the= case of PWs? 

 GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up MEP would be associated with A= C and Down MEP would be associated with PW/virtual interface itself.

= [[Sasha]] What a= bout PWs between VPLS instances? Or are those out of scope of MPLS-TP

 

Regards, and, again, l= ots of thanks in advance,

   &nbs= p; Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition= of Up and Down MRPs in RFC 6371.

The problematic text states:

 

   A node hosting a MEP can e= ither support per-node MEP or per-interface

   MEP(s).  A per-node M= EP resides in an unspecified location within the

   node, while a per-interfac= e MEP resides on a specific side of the

   forwarding engine.  I= n particular, a per-interface MEP is called an

   "Up MEP" or a &q= uot;Down MEP" depending on its location relative to the

   forwarding engine.  A= n "Up MEP" transmits OAM packets towards, and

   receives them from, the di= rection of the forwarding engine, while a

   "Down MEP" recei= ves OAM packets from, and transmits them towards, the

   direction of a server laye= r.

 

Here are my questions:

 

1.  The text seems to suggest that there are three= types of MEPs: per-node (neither Up nor Down), per-interface Up and per-int= erface Down. Is this understanding correct?

2.  Which types of MEPs can be encountered in an M= PLS-TP Section considered as a Maintenance Entity (ME)?

a.  The text in section 2.2 states: =93This docume= nt uses the term 'Section' exclusively to refer to the n=3D0 case of the ter= m 'Section' defined in RFC 5960=94

b.  The text in Section 3.3 states: =93Any MPLS-TP= LSR can implement a MEP for an MPLS-TP Section=94

c.  My guess (FWIW) is that only Down MEPs can be= associated with the MPLS-TP section. Is this guess correct?  

GIM>> IMO, U= p and nodal MEPs can be associated with MPLS-TP Section. =

[[Sasha]] Nodal MEPs can be associated with MPLS-TP sessions in the restricted sense of 6371 (0-depth label stack), but seem to be undistinguishable from Down MEPs= . But I do not understand what an Up MEP for a Section could mean - are not= Sections by definition terminated on physical interfaces?

3.  Which type of MEPs can be encountered in a P2P= MPLS-TP LSP (or MS-PW) considered as an ME?

a.  The text in Section 3.3 states: =93In the cont= ext of an MPLS-TP LSP, only LERs can implement MEPs=94

b.  The text mentions (e.g., in Section 6.4) that= OAM flows must be fate-sharing with the data packets for the corresponding= ME

c.  My guess (FWIW) is that LERs (and T-PEs) can o= nly implement per-node or per-interface Down MEPs. Is this guess correct? If= not, what did I miss?  

GIM>> I thin= k that Up MEP can be inst= antiated with fate sharing. [[Sasha]] Well, fate-sharing within a box is always an open question...

4.  Can you describe a case when a per-interface U= p Source MEP can be encountered for one of the MEs that MPLS-TP deals with (= i.e., Section, LSP or PW) and explain how fate-sharing with the data packets is provided in such a case? My guess= (FWIW) is that this is impossible without some changes in the MPLS-TP data= plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please explain how it= is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  The diagrams in Figure 3of the RFC seem to sug= gest that, in the case of per-interface MEPs, Source and Sink MEP are always= either both Up or both Down.

a.  Is this understanding correct? If not, could y= ou please present some examples to the contrary?

b.  If my understanding in (a) above is correct an= d if, as mentioned in (4) above, per-interface Up MEPs cannot be implemented= in MPLS-TP, this would imply that per-interface Up Sink MEPs are useless. Did I miss something?

 

Regards, and lots of thanks in advance,

     Sasha

 

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

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

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

--_000_A3C5DF08D38B6049839A6F553B331C760115ED9B689DILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Wed Jan 11 22:51:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AEA21F8489 for ; Wed, 11 Jan 2012 22:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.544 X-Spam-Level: X-Spam-Status: No, score=-4.544 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAPMwbyscgCi for ; Wed, 11 Jan 2012 22:51:18 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id CA45F21F8476 for ; Wed, 11 Jan 2012 22:51:17 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1326351032!55599510!4 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 21746 invoked from network); 12 Jan 2012 06:50:36 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-27.messagelabs.com with SMTP; 12 Jan 2012 06:50:36 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-c5-4f0e83d51d55 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 9E.D2.08306.5D38E0F4; Thu, 12 Jan 2012 08:55:17 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 12 Jan 2012 08:51:14 +0200 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" Date: Thu, 12 Jan 2012 08:50:46 +0200 Thread-Topic: [mpls] Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAAcaTsAAAESAIAAApaogAAKJwdQAAfpV4AAYEEZR 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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnl+LIzCtJLcpLzFFi42KZ/OrTF91rzXz+BjemsVo8PL+d2aJpzmZG i6NbLSxuLV3JanHu6RxGB1aP1md7WT2m/N7I6vHr61U2jyVLfjIFsEQ1MNok5uXllySWpCqk pBYn2yoFFGWWJSZXKilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8 lMy8dFslz2B/XQsLU0tdQyU7NWVDY2uukIzMYoVU3dzEzByF3NTi4sT0VAWgSMIW5owrv8+x FXxLrDjcfIW9gfGjTxcjJ4eEgInEjfMrGSFsMYkL99azdTFycQgJ7GSUmHy+gxnCmcIo0bp8 J1gVm4CtxKbVd9lAbBEBI4n+7fuZQIqYBY4xSuz6vI4VJMEioCrRvWU3M4gtLGAg8f/4JEaI BkOJ3vVXgZo5gOwoiQ/HZEDCvAKBEvv/7AIrERLwkWg5f58dxOYU8JU4/eYF2C5GoOu+n1rD BGIzC4hL3HoynwniagGJJXvOM0PYohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSH2 CkqcnPmEBaJXUuLgihssExjFZyFZMQtJ+ywk7bOQtC9gZFnFKJmZU1CSlJtuYKSbX1qil5qc WZKak6qXnJ+7iRGSgF7sYLx9RvMQowAHoxIP7869vP5CrIllxZW5hxglOZiURHmtmvj8hfiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwOtUAlfOmJFZWpRblw6QsgAE9kVmKOzkfmFTzSuKNDQxQ OErivN3Jb3yFBNKBKS87NbUgtQimVYaDQ0mC1wFko2BRanpqRVpmTglCmomDE2QzD9DmKpAa 3uKCxNzizHSI/ClGY46VO66fY+RoOQckhVjy8vNSpcR5w0BKBUBKM0rz4KaB8k/9////XzGK A30uzGsNUsUDzF1w814BrWICWlWWArYKmE/gUlINjBp/9NUfzGi948dzc/ubWycKWUyfXyty 0FlvkWhmfjXp/L1oQbHXqxapfefhmBshoWQ3QbZHW/KFdPySj3tv/qk6UvpbXnIC87vchL1b P/I6Pr6Q7VE6JfBT6zJP9+T/jSWyV3wSnUy9phxMOq90+gCz7rKF/k8ElHd/vWW5Vyj2/crz 996cOKjEUpyRaKjFXFScCADnroB2GgQAAA== Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 06:51:19 -0000 Eric, Lots of thanks for a prompt response and an important clarification. 5331 indeed extends RFC 3031 and introduces context-specific label spaces. However, I have been under an impression that: 1. Per-interface label space of 3031 is just a special case of the context-s= pecific label space (with the ingress interface providing the context). 2. Additional contexts are introduced for upstream-allocated labels and not= for downstream-allocated ones 3. 5331 explicitly differentiates between per-tunnel and per-interface label= spaces. This understanding is based on the text in Section 3 of 5331, e.g.: When MPLS labels are upstream-assigned, the context of an MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns the label distributes the binding and context to an LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives an MPLS packet on LSP1, it MUST be able to determine the context of this packet. An example of such a context is a tunnel over which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, after tunnel decapsulation, is looked up in a label space that is specific to the root of the tunnel. This does imply that Lr be able to determine the tunnel over which the packet was received. Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel. Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, transmitted by the neighbor on LSP1, is looked up in a "Neighbor-Specific Label Space". Further, RFC 5960 states that: Per-platform, per-interface, or other context-specific label space [RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP LSPs. The requirements of a particular LSP type may, however, dictate which label spaces or allocation schemes LSPs of that type can use. To me these text suggest that: 1. P2P uni-and bi-directional LSPs in MPLS-TP use the downstream label alloc= ation scheme and appropriate encapsulation. 2. Per-tunnel label space for this kind of tunnels is not permitted. My reading is a bit too literal and implementations can interpret 3031 and 5= 331 differently. A clarification would be very much in place IMO. Regards, Sasha ________________________________________ From: Eric Osborne (eosborne) [eosborne@cisco.com] Sent: Wednesday, January 11, 2012 8:58 PM To: Alexander Vainshtein; David Allan I Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant) Subject: RE: [mpls] Up and Down MEPs in RFC 6371 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, January 11, 2012 1:01 PM > To: David Allan I > Cc: mpls@ietf.org; Italo.Busi@alcatel-lucent.com; Stewart Bryant (stbryant) > Subject: Re: [mpls] Up and Down MEPs in RFC 6371 > > Dave, > Lots of thanks for a prompt response. > > One brief comment and one question: > > 1. To the best of my understanding per-LSP label space would explicitly > contradict RFC 3031. Per-LSP label space fits perfectly with rfc5331's idea of context-specific label space, where the context in this case is the LSP (many implementations model a TE LSP as an interface). eric > 2. I do not understand why you're speaking about an Up MEP in this > case. Could you please explain? > > Regards, > Sasha > > ________________________________ > > From: David Allan I [david.i.allan@ericsson.com] > Sent: Wednesday, January 11, 2012 6:55 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel- > lucent.com > Subject: RE: Up and Down MEPs in RFC 6371 > > > Perfect, good example of UP MEP for a common label appearing on multiple > interfaces in a TP environment... > > The implication vis-a-vis using per-interface labels on a protected path is the > protected path is an interface. I am not aware of a mechanism to assign a > label space to a specific LSP although others may correct me. So it is per- > platform labels, and regardless of per interface or per platform, an UP MEP > distributed across multiple interfaces implying coordination of state. > > As most implementations would also put a per node MEP on an ingress card, > I'm not sure there is a practical difference... > > thanks > Dave > > > > ________________________________ > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, January 11, 2012 8:38 AM > To: David Allan I > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); Italo.Busi@alcatel- > lucent.com > Subject: RE: Up and Down MEPs in RFC 6371 > > > > Dave, > > Lots of thanks for a prompt response! > > > > I am not sure I can agree with your statement "MPLS-TP is restricted to > connections, implying a single interface of arrival for an LSP". > > Please consider the case when an LSP of interest (or a PW) is nested in a > protected "tunnel" that is comprised of, say, active and standby LSPs. > > I would expect these LSPs to be as disjoint as possible including the "last > mile" interfaces on the tail-end LER. > > If this is the case, I would say that binding a MEP on the nested LSP/PW to a > specific interface would be impossible. Or do I miss something? > > > > What do you think? > > > > Regards, > > Sasha > > > > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Wednesday, January 11, 2012 6:29 PM > To: Alexander Vainshtein; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: RE: Up and Down MEPs in RFC 6371 > > > > HI Sasha: > > > > Good question! > > > > I'm not aware of any explicit relationship, nor can I envision the need for > specifying one. > > > > Given MPLS-TP is restricted to connections, implying a single interface of > arrival for an LSP, it scopes even a per-platform label to being of only per- > interface significance, but there should be no issue there, it is purely an > implementation choice. > > > > If I take a more general view, and apply the concept of per-interface MEPs > across the MPLS architecture (e.g. MP2P), then with per platform labels, I > simply have multiple MEPs that have a common label of arrival on different > interfaces for a given LSP. > > > > So that is my first blush, > > > > cheers > > Dave > > > > ________________________________ > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, January 11, 2012 5:03 AM > To: David Allan I; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: RE: Up and Down MEPs in RFC 6371 > > Dave, Italo and all, > > An additional question: > > > > Is there any relationship between per-node vs. per-interface MEPs and per- > platform vs. per-interface label spaces? > > If yes, does it mean that only per-node MEPs can be encountered in the case > of PWs? > > > > Regards, and, again, lots of thanks in advance, > > Sasha > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, January 11, 2012 2:55 PM > To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com > Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) > Subject: [mpls] Up and Down MEPs in RFC 6371 > > > > Dave, Italo and all, > > > > I have a couple of questions regarding the definition of Up and Down MRPs > in RFC 6371 . > > The problematic text states: > > > > A node hosting a MEP can either support per-node MEP or per-interface > > MEP(s). A per-node MEP resides in an unspecified location within the > > node, while a per-interface MEP resides on a specific side of the > > forwarding engine. In particular, a per-interface MEP is called an > > "Up MEP" or a "Down MEP" depending on its location relative to the > > forwarding engine. An "Up MEP" transmits OAM packets towards, and > > receives them from, the direction of the forwarding engine, while a > > "Down MEP" receives OAM packets from, and transmits them towards, the > > direction of a server layer. > > > > Here are my questions: > > > > 1. The text seems to suggest that there are three types of MEPs: per-node > (neither Up nor Down), per-interface Up and per-interface Down. Is this > understanding correct? > > 2. Which types of MEPs can be encountered in an MPLS-TP Section > considered as a Maintenance Entity (ME)? > > a. The text in section 2.2 states: "This document uses the term 'Section' > exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC 5960" > > b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for > an MPLS-TP Section" > > c. My guess (FWIW) is that only Down MEPs can be associated with the > MPLS-TP section. Is this guess correct? > > 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS- > PW) considered as an ME? > > a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only LERs > can implement MEPs" > > b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate- > sharing with the data packets for the corresponding ME > > c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or > per-interface Down MEPs. Is this guess correct? If not, what did I miss? > > 4. Can you describe a case when a per-interface Up Source MEP can be > encountered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or > PW) and explain how fate-sharing with the data packets is provided in such a > case? My guess (FWIW) is that this is impossible without some changes in the > MPLS-TP data plane as defined in RFC 3031 > and RFC 5960 > . Is this guess > correct? If not could you please explain how it is supposed to operate in the > terms of RFC 3031 (NHLFE, FTN and/or ILM)? > > 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of > per-interface MEPs, Source and Sink MEP are always either both Up or both > Down. > > a. Is this understanding correct? If not, could you please present some > examples to the contrary? > > b. If my understanding in (a) above is correct and if, as mentioned in (4) > above, per-interface Up MEPs cannot be implemented in MPLS-TP, this > would imply that per-interface Up Sink MEPs are useless. Did I miss > something? > > > > Regards, and lots of thanks in advance, > > Sasha > > > > 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. > > 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. 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 maarten.vissers@huawei.com Thu Jan 12 08:12:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0BC21F84D7 for ; Thu, 12 Jan 2012 08:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLnRWOVDCdEK for ; Thu, 12 Jan 2012 08:12:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FED021F8471 for ; Thu, 12 Jan 2012 08:12:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath queued) with ESMTP id ADH77248; Thu, 12 Jan 2012 16:11:59 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 16:09:20 +0000 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.01.0323.003; Thu, 12 Jan 2012 16:10:35 +0000 From: Maarten vissers To: "mpls@ietf.org" Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAA2af1AAKvkNoA== Date: Thu, 12 Jan 2012 16:10:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.112.212] Content-Type: multipart/alternative; boundary="_000_D62E6669B3621943B7632961308F8F9E0DD2CF07lhreml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 16:12:46 -0000 --_000_D62E6669B3621943B7632961308F8F9E0DD2CF07lhreml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Up MEPs are used at administrative domain boundaries in the Transport Servi= ce layer (PW, service-LSP), e.g. at UNI-N and E-NNI ports. At UNI-N ports an UP MEPs terminate a PW/service-LSP Service Provider ME an= d a PW/service-LSP Network Operator ME. At ENNI ports an UP MEP terminates a PW/service-LSP Network Operator ME. UP MEPs can also be used to test connectivity and performance of a connecti= on through a switch fabric. In equipment with two switch fabrics (one for transport service layer signa= ls, second for transport path layer signals) you will have a Transport-LSP = MEP which is both a Down MEP from the transport service layer switch fabric= and a UP MEP from the transport path layer switch fabric. In equipment wit= h a single switch fabric, the transport-LSP MEP is a Down MEP. Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= gory Mirsky Sent: woensdag 11 januari 2012 20:58 To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dear Sasha, et al., would offer my $.02. Couple somewhat generic comments: * in most cases, nodal MEP is identical to Down MEP * ME that is terminated by Up MEPs is different from ME terminated by D= own MEPs over the same LSP/PW * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down * I don't know how practical are Up MEPs for MPLS-TP More notes are in-line and tagged GIM>>. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO,= PW's Up MEP would be associated with AC and Down MEP would be associated w= ith PW/virtual interface itself. Regards, and, again, lots of thanks in advance, Sasha --_000_D62E6669B3621943B7632961308F8F9E0DD2CF07lhreml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Up MEPs are used at ad= ministrative domain boundaries in the Transport Service layer (PW, service-= LSP), e.g. at UNI-N and E-NNI ports.

At UNI-N ports an UP M= EPs terminate a PW/service-LSP Service Provider ME and a PW/service-LSP Net= work Operator ME.

At ENNI ports an UP ME= P terminates a PW/service-LSP Network Operator ME.

 

UP MEPs can also be us= ed to test connectivity and performance of a connection through a switch fa= bric.

 

In equipment with two = switch fabrics (one for transport service layer signals, second for transpo= rt path layer signals) you will have a Transport-LSP MEP which is both a Do= wn MEP from the transport service layer switch fabric and a UP MEP from the transport path layer switch fabric. In= equipment with a single switch fabric, the transport-LSP MEP is a Down MEP= .

 

Regards,

Maarten

 

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: woensdag 11 januari 2012 20:58
To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.c= om
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

 

Dear Sasha, et al.,

would offer my $.02.

Couple somewhat generic commen= ts:

  • in most cases, nodal MEP is identical to Down MEP
  • ME that is terminated by Up MEPs is different from ME= terminated by Down MEPs over the same LSP/PW
  • ME can be terminated by MEP of the same class, i.e. n= odal, Up or Down
  • I don't know how practical are Up MEPs for MPLS-TP

 More notes are in-line a= nd tagged GIM>>.

 

    Regards,

      =   Greg<= /p>

 


From:<= /span> mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Dave, Italo and all,

An additional question= :

 

Is there any relationship between per-node vs. per-interface MEPs and = per-platform vs. per-interface label spaces?

If yes, does it mean that only per-node MEPs can be encountered in the= case of PWs? 

 GIM>> I = think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up = MEP would be associated with AC and Down MEP would be associated with PW/virtual interface itself.

 

Regards, and, again, l= ots of thanks in advance,

   &nbs= p; Sasha

 

--_000_D62E6669B3621943B7632961308F8F9E0DD2CF07lhreml509mbx_-- From Alexander.Vainshtein@ecitele.com Thu Jan 12 08:16:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4157921F859A for ; Thu, 12 Jan 2012 08:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZThDrLOXneh for ; Thu, 12 Jan 2012 08:16:44 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 3232721F863F for ; Thu, 12 Jan 2012 08:16:43 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1326384991!10680017!6 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 20633 invoked from network); 12 Jan 2012 16:16:40 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-5.tower-182.messagelabs.com with SMTP; 12 Jan 2012 16:16:40 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-1a-4f0f085a1d62 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id A4.41.08306.A580F0F4; Thu, 12 Jan 2012 18:20:42 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Jan 2012 18:16:40 +0200 From: Alexander Vainshtein To: Maarten vissers , "mpls@ietf.org" Date: Thu, 12 Jan 2012 18:16:38 +0200 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAA2af1AAKvkNoAAAg3uA 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_A3C5DF08D38B6049839A6F553B331C760115EDDBD279ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUgTYRznudvWubw8ly/PTOK6NKmcaBYYOanAsA8xzSCQoq7tabvabmt3 Li0oe4eVkQhZQ9JKe7FMGxKZprUiULTsS2hZSo5erD5UZkgvdrdDG0T36Xf/38vzf3j+fwLX jWsSCI4XkZtn7YxGq6oc/TJmKCKiTOm/+pZnTXQOg6zn9VfVK7G8ww8/qfPq6iawfKyoDGSz PO8UWRHRFiSYjUy+m/Ow5lKG5ixGJoOhXXbWjByIF40M63Ih3sLkaOl/vmxJxvE04s1OC8db jczaQpMhK2vZckMGk7NgfkbmCu0GGyfQyOBgOTvtQILAWhEtVba24Lb69qDKNVEFShobmvEy UH0MeAFBQGop/Di0wwsiJBgH+141aWSso9oAHBwRvUAr4dMA9o5VhAgNZYT+ay9DOIYqhCe/ VuMyVlHJ8FFFPSbj2dRC+KO2HJPzY6hF8IS/UJGvga+rgkDGJFUAL9x5qlLyL2Cwr/NUyBtB 5cLHPw+GREBq6Hv39VAdp+Lh82ANpjRKwbr2J7iCY+H7kd9qRR8LB481AUXvhJ97/BrlsGjY dTaoUvR6eP9Kv+oUiPWFxfrCLL4wi1JPhbVtXzQKXgwvnf+AT+GeeyNYeL0WzGgAes7uErc5 rOlLDM5iMQ2ZORHZUZrZ6fADZWje3QYvehYGAEUAJpJsvUuadGrWI5Q6AkBPYEwsOa6JMulm bXNaSm2sYNviLrYjIQAggTMxZOWTWSYdaWFL9yC3c4rKlV6gAk+YaXZK48mLWzLT0///w8ST x80f1+koqzSSOxFyIfdUTiJBMJAMyMdHu5EVlWzn7OJfGiMi5DYipTbeyhpScLEOgbMqfDeY lxBP9soEJRO2Yn7aK6/L/snJyVEQL116NtkqqyKlZZp2j0rBmBTsscj3E6R1maYSysChpE0P b9y8uSr1dFRvVZMv+nfa1wUVV3MfNB/NVLeS37TnEqtPbLZu3JudNNSS3DBQkzRnTeKZQF55 4+OC4YJ9jXPpmpySW0Pe1ZX6qGh9Q0xKx7OWAc3t8iOPUtXtvqF+R9GB3X2ea2cvX+xC/jjT WM3Pcb6r40XLrvXdb658qEoZZlSCjc1YhLsF9g+8CUT2CQQAAA== Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 16:16:46 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDDBD279ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Maarten, Lots of thanks for an interesting input. However, I strongly suspect that the MPLS data plane does not allow "two swi= tching fabrics": both the server and client layer labels are looked up in th= e same ILM. My reading of 3031 and even 5331 is consistent with this restriction. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Maar= ten vissers Sent: Thursday, January 12, 2012 6:11 PM To: mpls@ietf.org Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Up MEPs are used at administrative domain boundaries in the Transport Servic= e layer (PW, service-LSP), e.g. at UNI-N and E-NNI ports. At UNI-N ports an UP MEPs terminate a PW/service-LSP Service Provider ME and= a PW/service-LSP Network Operator ME. At ENNI ports an UP MEP terminates a PW/service-LSP Network Operator ME. UP MEPs can also be used to test connectivity and performance of a connectio= n through a switch fabric. In equipment with two switch fabrics (one for transport service layer signal= s, second for transport path layer signals) you will have a Transport-LSP ME= P which is both a Down MEP from the transport service layer switch fabric an= d a UP MEP from the transport path layer switch fabric. In equipment with a= single switch fabric, the transport-LSP MEP is a Down MEP. Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg= ory Mirsky Sent: woensdag 11 januari 2012 20:58 To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dear Sasha, et al., would offer my $.02. Couple somewhat generic comments: * in most cases, nodal MEP is identical to Down MEP * ME that is terminated by Up MEPs is different from ME terminated by Dow= n MEPs over the same LSP/PW * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down * I don't know how practical are Up MEPs for MPLS-TP More notes are in-line and tagged GIM>>. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-pl= atform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO,= PW's Up MEP would be associated with AC and Down MEP would be associated wi= th PW/virtual interface itself. Regards, and, again, lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115EDDBD279ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Maarten,

Lots of thanks for an interesting input.

 

However, I strong= ly suspect that the MPLS data plane does not allow “two switching fabr= ics”: both the server and client layer labels are looked up in the sam= e ILM.

 

My reading of 3031 and even 5331 is consistent with this restriction.<= o:p>

 

Regards,

     Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of Maarten vissers
Sent: Thursday,= January 12, 2012 6:11 PM
To: mpls@ietf.org
Subject: Re:= [mpls] Up and Down MEPs in RFC 6371

 

Up MEPs are used at administrative domain boundaries in the Trans= port Service layer (PW, service-LSP), e.g. at UNI-N and E-NNI ports.

At UNI-N po= rts an UP MEPs terminate a PW/service-LSP Service Provider ME and a PW/servi= ce-LSP Network Operator ME.

At ENNI ports an UP MEP terminates a PW/service-LSP= Network Operator ME.

 

UP MEPs can also be used to test connectivity and perf= ormance of a connection through a switch fabric.

 

In equipment with two switc= h fabrics (one for transport service layer signals, second for transport pat= h layer signals) you will have a Transport-LSP MEP which is both a Down MEP= from the transport service layer switch fabric and a UP MEP from the transp= ort path layer switch fabric. In equipment with a single switch fabric, the= transport-LSP MEP is a Down MEP.

=  

Regards,

Maarten

 

=

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ie= tf.org] On Behalf Of Gregory Mirsky
Sent: woensdag 11 janua= ri 2012 20:58
To: Alexander Vainshtein; David Allan I; Italo.Busi@= alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cis= co.com)
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

 

Dear Sasha, et al.,

would offer my $.02.

Couple= somewhat generic comments:

  • in most cases, nodal MEP is identical to Down MEP
  • ME that is terminated b= y Up MEPs is different from ME terminated by Down MEPs over the same LSP/PW<= /span>
  • ME can be terminated= by MEP of the same class, i.e. nodal, Up or Down
  • I don't know how practical are Up MEPs for MPL= S-TP

 More notes are= in-line and tagged GIM>>.

&nbs= p;

    Regards,<= /span>

      &= nbsp; Greg

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ie= tf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday,= January 11, 2012 5:03 AM
To: David Allan I; Italo.Busi@alcatel-lu= cent.com
Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Dave, Italo and all= ,

An= additional question:

 

Is there any relationship= between per-node vs. per-interface MEPs and per-platform vs. per-interface= label spaces?

If yes, does it mean that only per-n= ode MEPs can be encountered in the case of PWs? 

 GIM>> I think that per-= interface MEPs can be placed properly onto PW. IMO, PW's Up MEP would be ass= ociated with AC and Down MEP would be associated with PW/virtual interface&n= bsp;itself.

 

Regards, and, again, lots of thanks in advance,

  &nbs= p;  Sasha

 

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

--_000_A3C5DF08D38B6049839A6F553B331C760115EDDBD279ILPTMAIL02e_-- From malcolm.betts@zte.com.cn Thu Jan 12 09:17:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793AF21F8568; Thu, 12 Jan 2012 09:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95WIMx9gHXRL; Thu, 12 Jan 2012 09:17:52 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD221F8559; Thu, 12 Jan 2012 09:17:51 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901107637492; Fri, 13 Jan 2012 00:55:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4315.4635944796; Fri, 13 Jan 2012 01:17:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0CHHYA1076639; Fri, 13 Jan 2012 01:17:34 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> To: adrian@olddog.co.uk MIME-Version: 1.0 X-KeepSent: 3DDAB338:E71941EB-85257983:005DFB2E; 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, 12 Jan 2012 12:17:27 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-13 01:17:37, Serialize complete at 2012-01-13 01:17:37 Content-Type: multipart/alternative; boundary="=_alternative 005EFE9085257983_=" X-MAIL: mse01.zte.com.cn q0CHHYA1076639 Cc: 'Huub helvoort' , ietf-bounces@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org, mpls@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 17:17:53 -0000 This is a multipart message in MIME format. --=_alternative 005EFE9085257983_= Content-Type: text/plain; charset="US-ASCII" Hi Adrian, Please see in line below for my response to your questions. I will post a revised version of the draft tomorrow. Regards, Malcolm "Adrian Farrel" Sent by: ietf-bounces@ietf.org 09/12/2011 05:49 AM Please respond to adrian@olddog.co.uk To , "'Huub helvoort'" cc mpls@ietf.org, ietf@ietf.org Subject Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). [MB] OK fixed in the update 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this "obvious" from G.8113.1 or does it need to be clarified? [MB] The draft requests a code point to support Ethernet based OAM messages the use of these messages on MPLS-TP LSPs and PWs is described in G.8113.1 other uses are not prohibited by this draft. My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? [MB] The draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15 in December, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were discussed during the drafting sessions and were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, as I stated above I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title of G.8113.1 later this week. 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a "tidy" way. [MB] This value corresponds to the Ethertype used for Ethernet OAM Looking forward to your reply. Thanks, Adrian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --=_alternative 005EFE9085257983_= Content-Type: text/html; charset="US-ASCII" Hi Adrian,

Please see in line below for my response to your questions.  I will post a revised version of the draft tomorrow.

Regards,

Malcolm




"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: ietf-bounces@ietf.org

09/12/2011 05:49 AM
Please respond to
adrian@olddog.co.uk

To
<draft-betts-itu-oam-ach-code-point@tools.ietf.org>, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
cc
mpls@ietf.org, ietf@ietf.org
Subject
Questions about draft-betts-itu-oam-ach-code-point





Hi Malcolm and Huub,

I have squeezed a little time from the current ITU-T meeting to look at your
draft and write-up. I have also read the email threads on the IETF discussion
list and the MPLS list. Sorry that this has taken me a week to process, but your
publication request came at pretty much the worst possible time for getting me
to do this task.

I don't like proliferating threads across multiple mailing lists. On the other
hand it is difficult to ensure that all the constituencies are present, so I am
perpetuating the cross-posting.

My review of the document...

1. idnits (
http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
only one of these is real (the spurious space in a citation). The other nits are
spurious caused by citations wrapping across lines. Could you please keep a note
of the nit so that you can fix it the next time the draft is respun or so it can
be captured in an RFC Editor Note at a later stage (you don't have to post a new
revision to address this now unless you really want to).

[MB] OK fixed in the update

2. This document requests a code point from a registry that contains code points
that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
whether it is your intention that your code point would also be applicable in
both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
need to be clarified?

[MB] The draft requests a code point to support Ethernet based OAM messages the use of these messages on MPLS-TP LSPs and PWs is described in G.8113.1 other uses are not prohibited by this draft.

My review of the write-up and discussions...

3. There seems to be quite a feeling on the mailing lists that this document
should be run through the MPLS working group. The write-up makes a case for
progressing it as AD sponsored. As far as I can see, the main assertions to
answer are as follows. Do you have a view on these points before I make a
decision on what to do?

a. This is a proposal to use an MPLS code point and so is part of MPLS by
definition.

b. The type of network being managed by the OAM described in G.8113.1 is an MPLS
network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you just
hoping to save the WG the work? If the latter, and if the WG wants to look at
the draft, the easiest approach seems to be to redirect the work to the working
group.

[MB]  G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list.  However, the MPLS WG have, by rough consensus, adopted a different approach.  Therefore, further review by the MPLS WG is of little value.

4. G.8113.1 is clearly important to understanding to which the code point is
being put. Thus, an available and stable copy of group. G.8113.1 will be key to
the last call review of you I-D. Can you make a stable copy available (for
example, through liaison)? How does the editing work currently in progress in
the SG15 meeting affect that availability?

[MB] The draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15 in December, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA.  None of the changes in G.8113.1 that were discussed during the drafting sessions and were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented,  as I stated above I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title of G.8113.1 later this week.

5. Can you clarify for me why the suggested value has been suggested. This will
help guide IANA who would normally do their allocation in a "tidy" way.


[MB]  This value corresponds to the Ethertype used for Ethernet OAM


Looking forward to your reply.

Thanks,
Adrian

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


--=_alternative 005EFE9085257983_=-- From gregory.mirsky@ericsson.com Thu Jan 12 10:37:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364021F84D7 for ; Thu, 12 Jan 2012 10:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW4jwMUEtyGa for ; Thu, 12 Jan 2012 10:37:33 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50CCD21F8578 for ; Thu, 12 Jan 2012 10:37:33 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0CIbMN5024935; Thu, 12 Jan 2012 12:37:30 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 12 Jan 2012 13:37:19 -0500 From: Gregory Mirsky To: Alexander Vainshtein Date: Thu, 12 Jan 2012 13:37:18 -0500 Thread-Topic: Up and Down MEPs in RFC 6371 Thread-Index: AczQYDsyb2944ONySw2ev+hjiAJNFAAAJX4gAA2af1AAFkuLywAZbWcg 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_FE60A4E52763E84B935532D7D9294FF1322998A3E0EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [mpls] Up and Down MEPs in RFC 6371 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 18:37:46 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322998A3E0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, we're converging indeed. I've cropped thread related to ME and in-lined my notes coloring them in gr= een: * ME that is terminated by Up MEPs is different from ME terminated by Down ME= Ps over the same LSP/PW [[Sasha]] It has been my understanding that 6371 consideres each LSP, PW or= Section (in the restricted sense it uses the term) as single individual ME= . Nesting of MEs is only discussed in the context of tandem connections and= segments. GIM>> MPLS-TP Rosetta Stone defines ME (Section 3.42) as "... the association of two (or more) Maintenance End Points (MEPs), that s= hould be configured and managed in order to bound the OAM responsibilities = of an OAM flow [editor: definition?] across a network or sub-network, i.e. = a transport path or segment, in the specific layer network that is being mo= nitored and managed." In that context there could be Up MEP-Up MEP, MEP (no= dal)-MEP (nodal), and Down MEP-Down MEP MEs if both nodal and per interface= Maintanence Points (MPs) supported. Might be interesting to look whether U= p-Up ME can coexist with Down-Down ME over the same MPLS-TP connection. At = least from point of overlap it is plausible. * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down [[Sasha]] Do you mean that all MEPs in teh given ME must belong to the same= class? If so, I agree with you - in particular because I see MEPs as bi-di= rectional (both transmiting and receiving). GIM>> Yes, Up-Up, Nodal-Nodal, and Down-Down MEs only. Though I'm not sure = that MEP can be viewed as bi-directional entity on unidirectional MPLS-TP c= onnections, p2p and p2mp LSPs. I think it is not outside of scope of RFC 63= 71 but clearly outside of scope of RFC 6428. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, January 11, 2012 10:24 PM To: Gregory Mirsky Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); David Allan I; Ital= o.Busi@alcatel-lucent.com Subject: RE: Up and Down MEPs in RFC 6371 Dear Greg, Lots of thanks for a prompt response. Please see some responses inline below (orange marked [Sasha]). Regards, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, January 11, 2012 9:57 PM To: Alexander Vainshtein; David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: RE: Up and Down MEPs in RFC 6371 Dear Sasha, et al., would offer my $.02. Couple somewhat generic comments: * in most cases, nodal MEP is identical to Down MEP [[Sasha]] I tend to agree with this statement. * ME that is terminated by Up MEPs is different from ME terminated by Down ME= Ps over the same LSP/PW [[Sasha]] It has been my understanding that 6371 consideres each LSP, PW or= Section (in the restricted sense it uses the term) as single individual ME= . Nesting of MEs is only discussed in the context of tandem connections and= segments. * ME can be terminated by MEP of the same class, i.e. nodal, Up or Down [[Sasha]] Do you mean that all MEPs in teh given ME must belong to the same= class? If so, I agree with you - in particular because I see MEPs as bi-di= rectional (both transmiting and receiving). * I don't know how practical are Up MEPs for MPLS-TP [[Sasha]] Well, I do not know if they are technically possible, and you dou= bt their practical meaning... Looks like we are converging on the same conc= lusion from different directions! More notes are in-line and tagged GIM>>. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 5:03 AM To: David Allan I; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, An additional question: Is there any relationship between per-node vs. per-interface MEPs and per-p= latform vs. per-interface label spaces? If yes, does it mean that only per-node MEPs can be encountered in the case= of PWs? GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO,= PW's Up MEP would be associated with AC and Down MEP would be associated w= ith PW/virtual interface itself. [[Sasha]] What about PWs between VPLS instances? Or are those out of scope = of MPLS-TP Regards, and, again, lots of thanks in advance, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, January 11, 2012 2:55 PM To: david.i.allan@ericsson.com; Italo.Busi@alcatel-lucent.com Cc: mpls@ietf.org; Stewart Bryant (stbryant@cisco.com) Subject: [mpls] Up and Down MEPs in RFC 6371 Dave, Italo and all, I have a couple of questions regarding the definition of Up and Down MRPs i= n RFC 6371. The problematic text states: A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer. Here are my questions: 1. The text seems to suggest that there are three types of MEPs: per-node = (neither Up nor Down), per-interface Up and per-interface Down. Is this und= erstanding correct? 2. Which types of MEPs can be encountered in an MPLS-TP Section considered= as a Maintenance Entity (ME)? a. The text in section 2.2 states: "This document uses the term 'Section' = exclusively to refer to the n=3D0 case of the term 'Section' defined in RFC= 5960" b. The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP fo= r an MPLS-TP Section" c. My guess (FWIW) is that only Down MEPs can be associated with the MPLS-= TP section. Is this guess correct? GIM>> IMO, Up and nodal MEPs can be associated with MPLS-TP Section. [[Sasha]] Nodal MEPs can be associated with MPLS-TP sessions in the restric= ted sense of 6371 (0-depth label stack), but seem to be undistinguishable f= rom Down MEPs. But I do not understand what an Up MEP for a Section could m= ean - are not Sections by definition terminated on physical interfaces? 3. Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) c= onsidered as an ME? a. The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only= LERs can implement MEPs" b. The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sh= aring with the data packets for the corresponding ME c. My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or= per-interface Down MEPs. Is this guess correct? If not, what did I miss? GIM>> I think that Up MEP can be instantiated with fate sharing. [[Sasha]] = Well, fate-sharing within a box is always an open question... 4. Can you describe a case when a per-interface Up Source MEP can be encou= ntered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW= ) and explain how fate-sharing with the data packets is provided in such a = case? My guess (FWIW) is that this is impossible without some changes in th= e MPLS-TP data plane as defined in RFC 3031 and RFC 5960. Is this guess correct? If not could you please ex= plain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN an= d/or ILM)? 5. The diagrams in Figure 3of the RFC seem to suggest that, in the case of= per-interface MEPs, Source and Sink MEP are always either both Up or both = Down. a. Is this understanding correct? If not, could you please present some ex= amples to the contrary? b. If my understanding in (a) above is correct and if, as mentioned in (4)= above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would = imply that per-interface Up Sink MEPs are useless. Did I miss something? Regards, and lots of thanks in advance, Sasha 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. 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_FE60A4E52763E84B935532D7D9294FF1322998A3E0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sasha,
we're converging indeed.
I've cropped thread related to ME and in-lined my = notes=20 coloring them in green:
 
  • ME that is terminated by Up MEPs is different from ME terminated= by=20 Down MEPs over the same LSP/PW

[[Sasha]] It has been my= =20 understanding that 6371 consideres each LSP, PW or Section (in the restri= cted=20 sense it uses the term) as single individual ME. Nesting of MEs is only=20 discussed in the context of tandem connections and=20 segments. 

GIM>> MPLS-TP Rosetta Stone defines ME (Section 3.4= 2)=20 as

"... the association of two (or more) Maintenance End Poi= nts=20 (MEPs), that should be configured and managed in order to bound the OAM=20 responsibilities of an OAM flow [editor: definition?] across a network or= =20 sub-network, i.e. a transport path or segment, in the specific layer netw= ork=20 that is being monitored and managed." In that context there could be Up M= EP-Up=20 MEP, MEP (nodal)-MEP (nodal), and Down MEP-Down MEP MEs if both nodal and= per=20 interface Maintanence Points (MPs) supported. Might be interesting to loo= k=20 whether Up-Up ME can coexist with Down-Down ME over the same MPLS-TP=20 connection. At least from point of overlap it is=20 plausible.

  • ME can be terminated by MEP of the same class, i.e. nodal, Up or= =20 Down

[[Sasha]] Do you mean th= at all=20 MEPs in teh given ME must belong to the same class? If so, I agree with y= ou -=20 in particular because I see MEPs as bi-directional (both transmiting and= =20 receiving).

GIM>> Yes, Up-Up, Nodal-Nodal, and Down-Down MEs on= ly.=20 Though I'm not sure that MEP can be viewed as bi-directional entity on=20 unidirectional MPLS-TP connections, p2p and p2mp LSPs. I think it is not= =20 outside of scope of RFC 6371 but clearly outside of scope of RFC=20 6428.

 

    Regards,

       =20 Greg


From: Alexander Vains= htein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, Jan= uary=20 11, 2012 10:24 PM
To: Gregory Mirsky
Cc: mpls@ietf.or= g;=20 Stewart Bryant (stbryant@cisco.com); David Allan I;=20 Italo.Busi@alcatel-lucent.com
Subject: RE: Up and Down MEPs in = RFC=20 6371

Dear Greg,
Lots of thanks for a prompt=20 response.
 
Please see some responses inline below = (orange marked [Sasha]).
 
Regards,
  &n= bsp; Regards,
     Sasha
 

From: Gregory Mirsky=20 [gregory.mirsky@ericsson.com]
Sent: Wednesday, January 11, 2012 9= :57=20 PM
To: Alexander Vainshtein; David Allan I;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: RE: Up and Down MEPs in RFC=20 6371

Dear Sasha, et al.,
would offer my $.02.
Couple somewhat generic comments:
  • in most cases, nodal MEP is identical to Down=20 MEP

[[= Sasha]] I=20 tend to agree with this statement.

  • ME that is terminated by Up MEPs is different from ME terminated= by=20 Down MEPs over the same LSP/PW

[[Sasha]] It has been my= =20 understanding that 6371 consideres each LSP, PW or Section (in the restri= cted=20 sense it uses the term) as single individual ME. Nesting of MEs is only=20 discussed in the context of tandem connections and=20 segments. 

  • ME can be terminated by MEP of the same class, i.e. nodal, Up or= =20 Down

[[Sasha]] Do you mean th= at all=20 MEPs in teh given ME must belong to the same class? If so, I agree with y= ou -=20 in particular because I see MEPs as bi-directional (both transmiting and= =20 receiving).

  • I don't know how practical are Up MEPs for=20 MPLS-TP

[[Sasha]] Well, I do not= know if=20 they are technically possible, and you doubt their practical meaning... L= ooks=20 like we are converging on the same conclusion from different=20 directions!

 More notes are in-line and tagged=20 GIM>>.
 
  &n= bsp; Regards,
        Greg


From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Wednesday, January 11, 2012 5:03 AM
To:=20 David Allan I; Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org;=20 Stewart Bryant (stbryant@cisco.com)
Subject: Re: [mpls] Up and Do= wn=20 MEPs in RFC 6371

Dave, Italo and all,

An additional=20 question:

 

Is=20 there any relationship between per-node vs. per-interface MEPs and per-plat= form=20 vs. per-interface label spaces?

If=20 yes, does it mean that only per-node MEPs can be encountered in the case of= =20 PWs? 

 GIM>= > I=20 think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up = MEP=20 would be associated with AC and Down MEP would be associated with PW/virtua= l=20 interface itself.

[[Sasha]] What about PWs = between=20 VPLS instances? Or are those out of scope of=20 MPLS-TP

 

Regards, and, again, lo= ts of=20 thanks in advance,

    = ;=20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55=20 PM
To: david.i.allan@ericsson.com;=20 Italo.Busi@alcatel-lucent.com
Cc: mpls@ietf.org; Stewart Bryant=20 (stbryant@cisco.com)
Subject: [mpls] Up and Down MEPs in RFC=20 6371

 

Dave, Italo and all,

 

I have a couple of questions regarding the definition = of Up=20 and Down MRPs in RFC=20 6371.

The problematic text states:

 

   A node h= osting=20 a MEP can either support per-node MEP or per-interface

   MEP(s).&= nbsp; A=20 per-node MEP resides in an unspecified location within the

   node, wh= ile a=20 per-interface MEP resides on a specific side of the

   forwardi= ng=20 engine.  In particular, a per-interface MEP is called an

   "Up MEP"= or a=20 "Down MEP" depending on its location relative to the

   forwardi= ng=20 engine.  An "Up MEP" transmits OAM packets towards, and

   receives= them=20 from, the direction of the forwarding engine, while a

   "Down ME= P"=20 receives OAM packets from, and transmits them towards, the

   directio= n of a=20 server layer.

 

Here are my=20 questions:

 

1.  2.  a.  b.  c.  GIM>> I= MO, Up and=20 nodal MEPs can be associated with MPLS-TP=20 Section. 

[[Sasha]] Nodal MEPs can = be=20 associated with MPLS-TP sessions in the restricted sense of 6371 (0-dep= th=20 label stack), but seem to be undistinguishable from Down MEPs. But I d= o not=20 understand what an Up MEP for a Section could mean - are not Sections by=20 definition terminated on physical=20 interfaces?

3.  a.  b.  c.  GIM>> I= think that=20 Up MEP can be instantiated w= ith fate=20 sharing. [[Sasha]] Well, fate-shar= ing within=20 a box is always an open question...=20

4.  RFC 3031 and RFC=20 5960. Is this guess correct? If not could you please explain how it is= =20 supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  a.  b.  , "adrian@olddog.co.uk" Date: Thu, 12 Jan 2012 12:18:01 -0800 Thread-Topic: Questions about draft-betts-itu-oam-ach-code-point Thread-Index: AczRTigf4fEhMW1tRmCVZffVeuduHQAFXqKg Message-ID: <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> References: <015f01ccb660$3991bdb0$acb53910$@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_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ietf-bounces@ietf.org" , "draft-betts-itu-oam-ach-code-point@tools.ietf.org" , "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 20:19:34 -0000 --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this documen= t should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an= MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look = at the draft, the easiest approach seems to be to redirect the work to the wor= king group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls= -tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was = presented at several meetings in 2009 and early 2010 and had extensive disc= ussion on the MPLS mailing list. However, the MPLS WG have, by rough conse= nsus, adopted a different approach. Therefore, further review by the MPLS = WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since dra= ft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a= code point for G.8113.1, is basically an attempt to subvert the decision b= y the MPLS WG to reject draft-bhh by attempting to bypass the WG with an in= dividual submission. So, I think it is clear that your draft belongs in the MPLS WG. Incidentally, the MPLS/GMPLS change process was put in place in reaction to= the publication of another individual submission, RFC3474, which was compl= etely non-interoperable with standard RSVP, a surprisingly similar situatio= n. --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Snipped, comments inline.


3. There s= eems to be quite a feeling on the mailing lists that this document
= should be run through the MPLS working group. The write-up makes a case= for
progressing it as AD sponsored. As far as I can see, the m= ain assertions to
answer are as follows. Do you have a view on = these points before I make a
decision on what to do?
a. This is a proposal to use an MPLS code point and so is part of MPL= S by
definition.

b. The type of network being m= anaged by the OAM described in G.8113.1 is an MPLS
network. The= refore, this is clearly relevant to the MPLS working .

Do y= ou object to this going through the MPLS on principle, or were you just
hoping to save the WG the work? If the latter, and if the WG wants= to look at
the draft, the easiest approach seems to be to redi= rect the work to the working
group.

[MB]  G.8113.1 supports a subset of the f= unctions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 version w= as posted in March 2009, the draft was presented at several meetings in 200= 9 and early 2010 and had extensive discussion on the MPLS mailing list. &nb= sp;However, the MPLS WG have, by rough consensus, adopted a different appro= ach.  Therefore, further review by the MPLS WG is of little value.


[JD]   Um, I don̵= 7;t think so. 

Since, as yo= u state above, G.8113.1 is  effectively draft-bhh and since draft-bhh = was explicitly rejected by the MPLS WG, your draft, which requests a code p= oint for G.8113.1, is basically an attempt to subvert the decision by the M= PLS WG to reject draft-bhh by attempting to bypass the WG with an individua= l submission. 

So, I think = it  is clear that your draft belongs in the MPLS WG.  =

<= i>Incidentally, the MPLS/GMPLS change process= was put in place in reaction to the publication of another individual subm= ission, RFC3474, which was completely non-interoperable with standard RSVP,= a surprisingly similar situation.

= --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_-- From tnadeau@lucidvision.com Thu Jan 12 12:29:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E1411E8083; Thu, 12 Jan 2012 12:29:54 -0800 (PST) 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.765, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUfMQUxNqqiA; Thu, 12 Jan 2012 12:29:53 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6E411E8072; Thu, 12 Jan 2012 12:29:53 -0800 (PST) Received: from [192.168.1.64] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 00A01204ADF7; Thu, 12 Jan 2012 15:29:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF" From: Thomas Nadeau In-Reply-To: <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> Date: Thu, 12 Jan 2012 15:29:51 -0500 Message-Id: <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1251.1) Cc: "mpls@ietf.org" , "draft-betts-itu-oam-ach-code-point@tools.ietf.org" , "ietf@ietf.org" , "ietf-bounces@ietf.org" Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 20:29:54 -0000 --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 12, 2012, at 3:18 PM, John E Drake wrote: > Snipped, comments inline. >=20 > 3. There seems to be quite a feeling on the mailing lists that this = document > should be run through the MPLS working group. The write-up makes a = case for > progressing it as AD sponsored. As far as I can see, the main = assertions to > answer are as follows. Do you have a view on these points before I = make a > decision on what to do? >=20 > a. This is a proposal to use an MPLS code point and so is part of MPLS = by > definition. >=20 > b. The type of network being managed by the OAM described in G.8113.1 = is an MPLS > network. Therefore, this is clearly relevant to the MPLS working . >=20 > Do you object to this going through the MPLS on principle, or were you = just > hoping to save the WG the work? If the latter, and if the WG wants to = look at > the draft, the easiest approach seems to be to redirect the work to = the working > group. >=20 > [MB] G.8113.1 supports a subset of the functions defined in = draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March = 2009, the draft was presented at several meetings in 2009 and early 2010 = and had extensive discussion on the MPLS mailing list. However, the = MPLS WG have, by rough consensus, adopted a different approach. = Therefore, further review by the MPLS WG is of little value.=20 >=20 > [JD] Um, I don=92t think so.=20 >=20 > Since, as you state above, G.8113.1 is effectively draft-bhh and = since draft-bhh was explicitly rejected by the MPLS WG, your draft, = which requests a code point for G.8113.1, is basically an attempt to = subvert the decision by the MPLS WG to reject draft-bhh by attempting to = bypass the WG with an individual submission.=20 >=20 > So, I think it is clear that your draft belongs in the MPLS WG.=20 >=20 > Incidentally, the MPLS/GMPLS change process was put in place in = reaction to the publication of another individual submission, RFC3474, = which was completely non-interoperable with standard RSVP, a = surprisingly similar situation. >=20 Well said John. I couldn't have put it any better myself, and so = agree with that statement %100. --Tom --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
= Well said John. I couldn't have put it any better myself, and so = agree with that statement %100.

= --Tom


= --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF-- From nurit.sprecher@nsn.com Thu Jan 12 12:39:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0A21F86D8; Thu, 12 Jan 2012 12:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Zv+D5fnZD6; Thu, 12 Jan 2012 12:38:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7D21F86D7; Thu, 12 Jan 2012 12:38:56 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0CKctIq020157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 21:38:55 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0CKct7e014370; Thu, 12 Jan 2012 21:38:55 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 21:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD16A.336E0F94" Date: Thu, 12 Jan 2012 21:38:52 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264051C52A3@DEMUEXC014.nsn-intra.net> In-Reply-To: <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Questions about draft-betts-itu-oam-ach-code-point Thread-Index: AczRaPk52GABdzJgSZm0yu19PmyZjAAACFVg References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk><5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Thomas Nadeau" , "John E Drake" X-OriginalArrivalTime: 12 Jan 2012 20:38:55.0243 (UTC) FILETIME=[33C8ADB0:01CCD16A] Cc: mpls@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org, ietf-bounces@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.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, 12 Jan 2012 20:39:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD16A.336E0F94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I fully agree with John and Tom. G.8113.1 intends to provide an OAM solution for MPLS-TP networks and the discussion on your draft completely belongs in the MPLS WG and also in the PWE3 WG. =20 Two more points: * Malcolm, you say that that the requested code point is not limited to G.8113.1..."other uses are not prohibited by this draft." I think it should be very clear for what exactly use it is requested.=20 * Malcolm, you mention that the value of the code point corresponds to the Ethertype used for Ethernet OAM....are you sure you approached the appropriate organization for the code point you are looking for? It seems that you either need to approach the IEEE and look for an EtherType or simply use PWs to transmit Ethernet OAM.=20 Best regards, Nurit =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: mpls@ietf.org; draft-betts-itu-oam-ach-code-point@tools.ietf.org; ietf@ietf.org; ietf-bounces@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point =20 =20 On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value.=20 [JD] Um, I don't think so.=20 Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically
On Jan 12, 2012, at 3:18 PM, John E = Drake wrote:

Snipped, comments = inline.


3. There seems to be quite a feeling on the mailing = lists that this document
should be run through the MPLS working group. The write-up makes = a case for
answer = are as follows. Do you have a view on these points before I make = a
decision on what to = do?

a. This is a = proposal to use an MPLS code point and so is part of MPLS by
definition.

b. The type of network being = managed by the OAM described in G.8113.1 is an MPLS
network. Therefore, this is = clearly relevant to the MPLS working .

Do you object to this going = through the MPLS on principle, or were you just
hoping to save the WG the work? = If the latter, and if the WG wants to look at
the draft, the easiest approach = seems to be to redirect the work to the working
group.

 [JD] =   Um, I don=92t think = so. 

Since, as you = state above, G.8113.1 is  effectively draft-bhh and since draft-bhh = was explicitly rejected by the MPLS WG, your draft, which requests a = code point for G.8113.1, is basically an attempt to subvert the decision = by the MPLS WG to reject draft-bhh by attempting to bypass the WG with = an individual submission. 

Incidentally, = the MPLS/GMPLS change process was put in place in reaction to the = publication of another individual submission, RFC3474, which was = completely non-interoperable with standard RSVP, a surprisingly similar = situation.