From nobody Tue Apr 1 04:58:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23EA1A0697 for ; Tue, 1 Apr 2014 04:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGmhEtTqJ5Tf for ; Tue, 1 Apr 2014 04:58:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 47F1D1A068C for ; Tue, 1 Apr 2014 04:58:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFD55792; Tue, 01 Apr 2014 11:58:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 12:57:38 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 12:58:19 +0100 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.104]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Tue, 1 Apr 2014 04:58:06 -0700 From: Rajiv Papneja To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-george-mpls-ipv6-only-gap a working group document Thread-Index: AQHPTLOZY4jN+Zzsn0OTWbl8I5hpQJr8qYLw Date: Tue, 1 Apr 2014 11:58:06 +0000 Message-ID: <52B0D42F4BADB144B850705C4549F6EA2145029A@dfweml703-chm.china.huawei.com> References: <53391A55.8000303@pi.nu> In-Reply-To: <53391A55.8000303@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7TcA4eYW9eYe_AA0rvOssdwXr6o Cc: "mpls-chairs@tools.ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-george-mpls-ipv6-only-gap a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 11:58:42 -0000 Support (as a contributor) Cheers, Rajiv -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, March 31, 2014 3:34 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-george-mpls-ipv6-only-gap@tools.ietf.= org Subject: [mpls] poll to see if we have consensus to make draft-george-mpls-= ipv6-only-gap a working group document Working Group, This is to start a two week poll on adopting draft-george-mpls-ipv6-only-ga= p as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There are no IPR claim against this document. The authors and contributors has stated on the working group mailing list t= hat they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. This poll ends April 14, 2014. /Loa for the MPLS wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 1 07:36:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DB71A07CA for ; Tue, 1 Apr 2014 07:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WuulJreCtBB for ; Tue, 1 Apr 2014 07:36:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9076D1A0858 for ; Tue, 1 Apr 2014 07:36:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401143648.11070.19462.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 07:36:48 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3j9n8qUXpCMdgN_Y6fC7UUobA2Y Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:36:51 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-applicability-label-adv for publication", set due date to May 2014 from December 2013. Changed milestone "Submit draft-ietf-mpls-ldp-multi-topology for publication", set due date to May 2014 from December 2013. Changed milestone "Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication", set due date to May 2014 from December 2013. Changed milestone "Submit draft-ietf-mpls-psc-updates for publication", set due date to May 2014 from March 2014. Changed milestone "Submit draft-ietf-mpls-ldp-ip-pw-capability for publication", set due date to June 2014 from November 2013. Changed milestone "Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication", set due date to June 2014 from December 2013. Changed milestone "Submit draft-ietf-mpls-tp-1ton-protection for publication", set due date to June 2014 from March 2014. Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to June 2014 from March 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Apr 1 07:43:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BA31A06C0 for ; Tue, 1 Apr 2014 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA3_OIbrsjNm for ; Tue, 1 Apr 2014 07:43:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 889281A0734 for ; Tue, 1 Apr 2014 07:43:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401144322.8919.43611.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 07:43:22 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2Jgul5ffHuEmIL1fBpRZWW7TY6o Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:43:24 -0000 Changed milestone "Submit draft-ietf-mpls-seamless-mcast for publication", set due date to August 2014 from April 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Apr 1 08:18:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DEC1A0852 for ; Tue, 1 Apr 2014 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib0TY2YljXhN for ; Tue, 1 Apr 2014 08:18:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C521A0870 for ; Tue, 1 Apr 2014 08:18:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401151855.27948.90984.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 08:18:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Y_l3tJlCatKSpusaeWKL7uHcL9E Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:18:58 -0000 Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to June 2014 from April 2014. Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to October 2014 from June 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Apr 1 08:26:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581531A06F4 for ; Tue, 1 Apr 2014 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmLRnzLbSpmB for ; Tue, 1 Apr 2014 08:26:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E61A098F for ; Tue, 1 Apr 2014 08:26:46 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5C5511802AB4; Tue, 1 Apr 2014 17:26:42 +0200 (CEST) Message-ID: <533ADAB5.30708@pi.nu> Date: Tue, 01 Apr 2014 17:26:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mpls@ietf.org, "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" References: <20140401143648.11070.19462.idtracker@ietfa.amsl.com> In-Reply-To: <20140401143648.11070.19462.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UZ7KXyoHdRaKK5NVzEYUZ9b-HWA Subject: Re: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:26:49 -0000 Working Group, I've updated our milestones - the list below is not the complete set of changes, new milestones need to be approved. What we've is to list all the working group documents as milestones. It is possible to discuss if this is the best way to do it, but please remember that the support in the tool for composite milestone are less than perfect. /Loa On 2014-04-01 16:36, IETF Secretariat wrote: > Changed milestone "Submit draft-ietf-mpls-ldp-applicability-label-adv > for publication", set due date to May 2014 from December 2013. > > Changed milestone "Submit draft-ietf-mpls-ldp-multi-topology for > publication", set due date to May 2014 from December 2013. > > Changed milestone "Submit draft-ietf-mpls-lsp-ping-ttl-tlv for > publication", set due date to May 2014 from December 2013. > > Changed milestone "Submit draft-ietf-mpls-psc-updates for > publication", set due date to May 2014 from March 2014. > > Changed milestone "Submit draft-ietf-mpls-ldp-ip-pw-capability for > publication", set due date to June 2014 from November 2013. > > Changed milestone "Submit draft-ietf-mpls-tp-temporal-hitless-psm for > publication", set due date to June 2014 from December 2013. > > Changed milestone "Submit draft-ietf-mpls-tp-1ton-protection for > publication", set due date to June 2014 from March 2014. > > Changed milestone "Submit draft-ietf-mpls-seamless-mpls for > publication", set due date to June 2014 from March 2014. > > URL: http://datatracker.ietf.org/wg/mpls/charter/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 1 12:13:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E371A09C0 for ; Tue, 1 Apr 2014 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQVdeNItK1PE for ; Tue, 1 Apr 2014 12:13:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F223D1A09D1 for ; Tue, 1 Apr 2014 12:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401191351.28670.81467.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 12:13:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_0mmzgp3kaqyF7yUBW-1msmwk-c Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 19:13:54 -0000 Changed milestone "Submit draft-ietf-mpls-forwardig for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-in-udp for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-lsp-ping-relay-reply for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-special-purpose-labels", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-tp-linear-protection-mib", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-rsvp-egress-protection for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-rsvp-ingress-protection for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-mldp-node-protection for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-proxy-lsp-ping fpr publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-rsvp-te-hsmp-lsp", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-te-express-path", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Tue Apr 1 14:39:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688DD1A0A1E for ; Tue, 1 Apr 2014 14:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.783 X-Spam-Level: X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdMsHKpILAAi for ; Tue, 1 Apr 2014 14:39:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 134521A0A1C for ; Tue, 1 Apr 2014 14:39:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s31LdIGT002157; Tue, 1 Apr 2014 22:39:18 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s31LdGAk002136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 22:39:17 +0100 From: "Adrian Farrel" To: Date: Tue, 1 Apr 2014 22:39:16 +0100 Message-ID: <03c401cf4df2$d627ca30$82775e90$@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: Ac9N8kx1cL8b2PMUSoyFxw1/FCDAQg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20604.002 X-TM-AS-Result: No--13.208-10.0-31-10 X-imss-scan-details: No--13.208-10.0-31-10 X-TMASE-MatchedRID: DANsujy0auPau9iF5mAFe3BRIrj8R47FlzlaNFD3vRTkZs+OkNvWw0j8 AtVpDcmg30nY8d71auLF1rvdxeAa7mJTY1vDl0cWaNnyr85zWcAfOdo4H355iFpbYq2f4jz+4p9 VExuMJHbCNxF9y1zOGmw5+PTV+KnKkVF44oU3/QiJQ9k+Ypk5CfSEh8AqyHUvqPm/sjj9KBghme lVTlWHljMbLTWWZMwUc3OQ9zX5ApfuHXE92Wk6HB3EEAbn+GRblnrMq7Sriu17S6iZgR95wW+3c txX3zZNdkUDNhT8G+NVfKyzj3O3ZZxjBzzEqmFVR+GtoiXVeDFwG8b5skjkoGu5u5lw5zS1IvN6 DT6Y2+zF0wMQNKBsD1GIlR8yc1Qba5G3lWay7IxhuzVIgfAISoB84MMvKleaYOY2t32U5vomfs5 a44EdZ23kc4jXAwhhsGGqb3k4Lx5Obz1XjUYragz4VsCc1YW+XcpmQXLhhkTxxaAXDrCns4gh8Y ej7yUhdWbFiPEQk8TLQze2Z7hVwyZ6N51eulrf7BI2Kjvg8mgh9mNF8ZPJ2OII2WRN/O8mjiZqR ZIhdsPgzNkZfrm4ESLpNjnIqSGObcsjJ6T7JLGmG+fak9r3alo1rFkFFs1aT73OZsJR5UWP4m/H HSQw+X6beeQtkrDhBKp+mv94eitJ7Hstr3M1wohaKK0I26Fp+w4HAoP6qDQWedCrEHXal9fpfO5 YhTb3yCuEf7tvABhvcmY92rn2+Vh7pGxMM9J9OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqrj YtFiRHZDhT9j/IAOwrcw7RYl9BDpmoaRYdtMH65HlFVzXhOn7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mOpQxTl-hqvir1RMQdOAaH940r4 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:39:26 -0000 Hello, I have done my usual AD review of your document upon receiving the publication request. The purpose is to catch any issues that might otherwise show up during IETF last call or IESG review and to get the document into good shape so that those later reviews have a clearer run. There are a few comments below that I would like you to look at. The I-D is very short and simple, so there is not much to comment on, but I have a few concerns, clarifications, and editorial points that I hope you will look at. You are, of course, welcome to dispute any of these points and discuss them with me on the WG mailing list. While you are working on this I will put the document into "Revised I-D Needed" state and I will ask the WG chairs to send a notice about this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they are aware of the draft and can comment immediately or during IETF last call if they have any concerns. Thanks for the work, Adrian === This document adds a sub-TLV. I think it is your intention that this is a sub-TLV of the Link TLV and not of the Administrative Group sub-TLV, itself. That seems pretty important, so it needs to be stated clearly. --- The use case in para 2 of Section 1 is, of course, predicated on using a single IGP domain (area/level) to cover the whole network that is being discussed. That is OK, but the text should note this caveat lest people think that admin colours are somehow globally unique. --- Section 2.1 The EAG may be of any length, but MUST be a multiple of 4 bytes. Is a zero-length TLV allowed? --- 2.3.1 If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. If the AG and EAG advertised for a link differ, the EAG MUST take priority. Aren't these two statements contradictory? I suspect the final "EAG" is supposed to read "AG" to be consistent with the first paragraph and also to match the first motivation given immediately after. This allows nodes which do not support EAG to obtain some link color information from the network, but also allow for an eventual migration away from AG. OTOH... 1. The second motivation seems to support EAG taking priority. 2. The first motivation seems to miss some really big issues concerning non-support of EAG. You need to discuss this processing in relation to signaling... Suppose a link is advertised with EAG and a node that does not support EAG signals an LSP? Suppose one end of a link supports EAG but the other does not and a signaling message includes EAG and the upstream end of the link ignores it? I think you have some edge conditions to describe in section 2.3 --- I read section 4.7.4 of RFC 3209 to compare it with what you say in section 2.3.2 of this document. I read it to say: - a link can only be excluded if it advertises a specific color - a link can only be included if it advertises a specific color Thus, failure to include AG means a link cannot be excluded according to an exclusion requirement. But it also means that it cannot be included according to an include or include-any requirement. Now, that is not how I read what you have said in 2.3.2. Here I see you saying that if a node does not advertise AG the path selection cannot decide whether an affinity is set of not. I believe that is subtly different from what 3209 says - I think that says that if an AG is not present then the inclusion test must fail as if the affinity was not set. Of course, you are right that a default advertisement of 0x0 is a good way around this, and you are correct that this becomes confusing with variable length EAGs. But it is important to note that a default advertisement of 0x0 is still an explicit advertisement of no affinities being set, and the default is being applied at the advertising node not at the receiver of the advertisement. You go on to say... Each implementation is free to choose its own method for handling this question. However, to allow for maximum interoperability an implementation MUST treat desired but unadvertised EAG bits as if they are set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node which wants the 127th EAG bit to be 1 MUST NOT use this link, as the assumption is than an unadvertised bit is set to 0. I think this is functionally equivalent to RFC 3209. That is, a link cannot be excluded on the basis of an unadvertised affinity because it is assumed to be 0. And a link cannot be included on the basis of an unadvertised affinity because it is assumed to be 0. So it all ends up right in the end, but it took a lot of words! --- In Section 2.3.2 you have an "interesting" mix of advice and 2119 words. Each implementation is free to choose its own method for handling this question. "Free to choose" is preparing me to not see any use of "MUST" However, to allow for maximum interoperability an implementation MUST treat desired but unadvertised EAG bits as if they are set to 0. Oh, so my implementation is not free to choose! Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node which wants the 127th EAG bit to be 1 MUST NOT use this link, as the assumption is than an unadvertised bit is set to 0. A node MAY provide other strategies for handling this case. Hello! I am now allowed to do something different from the "MUST" A strategy which deviates from the recommended behavior in this Although this is a lower case "recommended" I associate that word with "SHOULD" not the actual "MUST" that you used. document SHOULD be configurable, in order to provide maximum interoperability. If it is only "SHOULD be configurable" then you allow "not configurable" in which case you have a procedure that deviates from the "MUST" and is not configurable. Hmmmm. I think you wanted to say: - All implementations MUST support a mode of operation that assumes absent affinities are set to 0 - Implementations MAY support other modes of operation - Implementations that support other modes of operation MUST have allow configuration to select the mode of operation, and MUST default to assume that absent affinities are set to 0 But, one final question... Why do you want to allow other modes of operation? What is the benefit, and why didn't you call it out? --- Section 3 deliberately sidesteps the use of EAG in signaling. That is "interesting" and makes me assume that the use of EAG you have in mind applies only at the point of explicit path selection (i.e. no loose hop selection). I think that, in order to justify this work being limited to the IGPs you need to be a bit more explicit, up front, that *your* use case concerns pre-computation of paths. Now, there are two places where path selection will be done: 1. The head-end LSR 2. A PCE So, you should pick one or both of these as your use case and state it clearly. If you include PCE, you will need to look at the applicability to PCEP (see Section 7.11 of RFC 5440). --- Section 5 could be made clearer by breaking the text out into separate paragraphs or even separate sections. It would also be helpful to IANA if you made little tables showing the exact information you want recorded in each registry. From nobody Tue Apr 1 19:57:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583A1A00BB; Tue, 1 Apr 2014 19:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nu0EZf8ycVM; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A878C1A00BA; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3842; q=dns/txt; s=iport; t=1396407457; x=1397617057; h=from:to:subject:date:message-id:mime-version; bh=VHJu5v0zp2IkyLZ0szLVQryycztIHWyEOdXSNYSpCD0=; b=jgjFaNqywYtEQFUmDB+xp6pLrNfBci05D/YHytuOk4zTJGvSQscmcLHI YbZrPw65t6pPjA1OAk4yKjpV1zqiDGdido2hmv6BiVgeAhQvDAqx62ddg uWtVOW0EUCr1jmnCcSQr7icQTAA34dG2zGV/BJSaVVweV/InCNOGSJz/i w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEF8O1OtJA2B/2dsb2JhbABZgkJEO1fDZYEfFnSCJwEELV4BDB5WJgEEARoBh3AN0C4Xjj+DXIEUBKsPgzCCKw X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32155100" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 02 Apr 2014 02:57:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s322vZEl014567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 02:57:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 21:57:35 -0500 From: "Tissa Senevirathne (tsenevir)" To: "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVww== Date: Wed, 2 Apr 2014 02:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ccHKtX9ywemfaIGwuodAq8Xhtd4 Subject: [mpls] YANG model for protocol independent OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 02:57:42 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All In the draft below we present YANG model to abstract protocol dependent asp= ects of OAM and create a unified OAM API set. In a nutshell, ping is ping a= nd traceroute is traceroute and so on. Protocol independent API 's allow us= ers to exercise these OAM tools in the same manner across different technol= ogies and allow to integrate to their operations platforms. Appreciate your time on reviewing and providing comments, both on API's and= YANG model as well as OAM framework in it self. http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt Thanks Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API ‘s allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

 

Appreciate your time on reviewing and providing comm= ents, both on API’s and YANG model as well as OAM framework in it sel= f.

 

http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt<= /o:p>

 

Thanks

Tissa

--_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_-- From nobody Tue Apr 1 20:51:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957741A00EA; Tue, 1 Apr 2014 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqQPveb-UFwr; Tue, 1 Apr 2014 20:51:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE6E11A00E1; Tue, 1 Apr 2014 20:51:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCQ67856; Wed, 02 Apr 2014 03:51:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:50:14 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:51:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 2 Apr 2014 11:51:05 +0800 From: Haoweiguo To: "Tissa Senevirathne (tsenevir)" , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29 Date: Wed, 2 Apr 2014 03:51:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.248] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/POtbNczf7xvTNEZvfqDQ-Mdu4zs Subject: [mpls] =?gb2312?b?tPC4tDogWUFORyBtb2RlbCBmb3IgcHJvdG9jb2wgaW5k?= =?gb2312?b?ZXBlbmRlbnQgT0FN?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 03:51:15 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGlzc2EsDQoNClRoYW5rcyBmb3IgeW91ciBwcmVzZW50aW5nIHRoZSBkZXRhaWwgWWFuZyBt b2RlbCBvZiBUUklMTCBPQU0uIEFmdGVyIHJlYWQgdGhlIGRyYWZ0LCBpIGhhdmUgc29tZSBjb21t ZW50cyBhbmQgcHJvYmxlbXMgYXMgZm9sbG93cy4NCg0KDQoNCjEuIFRoZXJlIGlzIG5vIE1JUCBk YXRhIG1vZGVsIGluIHRoaXMgZHJhZnQsIGluIFRSSUxMIE9BTSBGcmFtZXdvcmsgTUlQIGlzIGRl ZmluaXRlbHkgZGVmaW5lZCB0byBmaWx0ZXIgT0FNIHBhY2tldCBiYXNlZCBvbiBNSVAgbGV2ZWwu DQoNCjIuIFRoZSByYW5nZSBvZiBNRVAgSUQgaXMgZnJvbSAxIHRvIDgxOTEuIEluIFRSSUxMIE9B TSBmcmFtZXdvcmssIHRyaWxsIGJhc2UgbW9kZSBpcyBkZWZpbmVkIHRvIGdlbmVyYXRlIE1ELCBN QSwgYW5kIE1FUCBhdXRvbWF0aWNhbGx5LCBNRVAgSUQgY2FuIHVzZSBSQidzIG5pY2tuYW1lIGFu ZCB3aWxsIGJlIGJleW9uZCA4MTkxLCBob3cgY2FuIGl0IGJlIG1hbmFnZWQgdGhyb3VnaCBZYW5n IG1vZGVsPw0KDQozLiBJbiB0cmlsbCBiYXNlIG1vZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1E IGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJ ZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNh biB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQpUaGFua3MNCg0Kd2VpZ3VvDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMgW21wbHMtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSBbdHNlbmV2aXJAY2lzY28uY29t XQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjLI1SAxMDo1Nw0KytW8/sjLOiBtcGxzQGlldGYub3JnOyBs MnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQrW98ziOiBbbXBsc10gWUFORyBtb2RlbCBm b3IgcHJvdG9jb2wgaW5kZXBlbmRlbnQgT0FNDQoNCkFsbA0KDQpJbiB0aGUgZHJhZnQgYmVsb3cg d2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHByb3RvY29sIGRlcGVuZGVudCBhc3Bl Y3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0gQVBJIHNldC4gSW4gYSBudXRzaGVs bCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRyYWNlcm91dGUgYW5kIHNvIG9uLiBQ cm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVzZXJzIHRvIGV4ZXJjaXNlIHRoZXNl IE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3NzIGRpZmZlcmVudCB0ZWNobm9sb2dp ZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBvcGVyYXRpb25zIHBsYXRmb3Jtcy4N Cg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5nIGFuZCBwcm92aWRpbmcgY29tbWVu dHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFzIHdlbGwgYXMgT0FNIGZyYW1ld29y ayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRpc3NhLW5ldG1v ZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tissa,

Thanks for your presenting the detail Yang model of TRILL OAM. Afte= r read the draft, i have some comments and problems as follows.

 

1. There is no MIP data model in this draft, in TRILL OAM Framework MIP = is definitely defined to filter OAM packet based on MIP level.


2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?


3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?


Thanks

weiguo

=B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@iet= f.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

All

 

In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API =A1=AEs allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

 

Appreciate your time on reviewing and providing comm= ents, both on API=A1=AFs and YANG model as well as OAM framework in it self= .

 

http://www.ietf.org/id/draft-tissa-netmod-oa= m-00.txt

 

Thanks

Tissa

--_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_-- From nobody Tue Apr 1 21:17:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4721A0108; Tue, 1 Apr 2014 21:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.06 X-Spam-Level: X-Spam-Status: No, score=-7.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQTLPmWj_tqA; Tue, 1 Apr 2014 21:17:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AC1A00F3; Tue, 1 Apr 2014 21:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17087; q=dns/txt; s=iport; t=1396412246; x=1397621846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xWXJ7RvcF0N3JMtcWXFj31UtU/LN9QjMGl4pWG63fy8=; b=P97sM57NGxIYnJmU1RzFTF2nha0zuWthVdl/PbB04rsVmgIw9UEoijvI VA00S6HJ5Irhj1wyBgmSq37Ot1IG4nprqdypixOJbGL7V+C7HXmwtpEiV ig0f5qyY7CRhGUOCVzbnuJlotAiBduwzF/RlPDpS0/UEC5AONGs1rRXOG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAB6DO1OtJA2J/2dsb2JhbABZgkJEO1eDCsBbGYEGFnSCJQEBAQQtTBACAQYCEQQBAQsdBQICMBQJCAEBBAENBQgBh3ANkUScEgiiPxeOPxYbBgGCazmBFASrD4Mwgis X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32171676" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 02 Apr 2014 04:17:26 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s324HPlb032517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 04:17:25 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 23:17:24 -0500 From: "Tissa Senevirathne (tsenevir)" To: Haoweiguo , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29AAESopA= Date: Wed, 2 Apr 2014 04:17:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hOiXog4Coc3IDwurLZVWg8cmZr0 Cc: "trill@ietf.org" Subject: Re: [mpls] YANG model for protocol independent OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 04:17:33 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2VpZ3VvDQoNClRoYW5rcyBmb3Igc29tZSB2ZXJ5IGdvb2Qgc2V0IG9mIHF1ZXN0aW9ucywg cGxlYXNlIHNlZSB0aGUgYW5zd2VycyBiZWxvdyBpbi1saW5lIHdpdGggW2Fuc3dlcl0NCg0KRnJv bTogSGFvd2VpZ3VvIFttYWlsdG86aGFvd2VpZ3VvQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAwMSwgMjAxNCA4OjUxIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZp cik7IG1wbHNAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmcNClN1Ympl Y3Q6ILTwuLQ6IFlBTkcgbW9kZWwgZm9yIHByb3RvY29sIGluZGVwZW5kZW50IE9BTQ0KDQoNCkhp IFRpc3NhLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJlc2VudGluZyB0aGUgZGV0YWlsIFlhbmcgbW9k ZWwgb2YgVFJJTEwgT0FNLiBBZnRlciByZWFkIHRoZSBkcmFmdCwgaSBoYXZlIHNvbWUgY29tbWVu dHMgYW5kIHByb2JsZW1zIGFzIGZvbGxvd3MuDQoNCg0KDQoxLiBUaGVyZSBpcyBubyBNSVAgZGF0 YSBtb2RlbCBpbiB0aGlzIGRyYWZ0LCBpbiBUUklMTCBPQU0gRnJhbWV3b3JrIE1JUCBpcyBkZWZp bml0ZWx5IGRlZmluZWQgdG8gZmlsdGVyIE9BTSBwYWNrZXQgYmFzZWQgb24gTUlQIGxldmVsLg0K DQpbYW5zd2VyXSBJIGludGVudGlvbmFsbHkgc2tpcHBlZCB0aGlzIGZvciB0aGUgaW5pdGlhbCBy ZXYsIGl0IGlzIGFzc3VtZWQgYWxsIE1JUCBhcmUgYXV0byBjcmVhdGVkIG9uIGFwcGxpY2FibGUg aW50ZXJmYWNlcy4gSW4gdGhlIG5leHQgcmV2LCBhdCB0aGUgTUEgbGV2ZWwgd2lsbCBpbmNsdWRl IG5vZGUgbWEtYXV0b2NyZWF0ZS4gV2hlbiBkaXNhYmxlLCB3aWxsIGFkZCBhYmlsaXR5IHRvIGNy ZWF0ZSBNSVAgbWFudWFsbHkuIFRoZXJlIHdpbGwgYmUgbm8gc3BlY2lmaWMgTUlQIGFkZHJlc3Mg bGlrZSBpbiBNRVAsIGJ1dCBqdXN0IHRoZSBkaXJlY3Rpb24gYW5kIGF0dGFjaGVkIGludGVyZmFj ZS4NCg0KMi4gVGhlIHJhbmdlIG9mIE1FUCBJRCBpcyBmcm9tIDEgdG8gODE5MS4gSW4gVFJJTEwg T0FNIGZyYW1ld29yaywgdHJpbGwgYmFzZSBtb2RlIGlzIGRlZmluZWQgdG8gZ2VuZXJhdGUgTUQs IE1BLCBhbmQgTUVQIGF1dG9tYXRpY2FsbHksIE1FUCBJRCBjYW4gdXNlIFJCJ3Mgbmlja25hbWUg YW5kIHdpbGwgYmUgYmV5b25kIDgxOTEsIGhvdyBjYW4gaXQgYmUgbWFuYWdlZCB0aHJvdWdoIFlh bmcgbW9kZWw/DQoNClthbnN3ZXJdIG9uIGEgZGlmZmVyZW50IHRocmVhZCBZaSB6aG91IGFsc28g YXNrZWQgbWUgdGhlIHNhbWUgcXVlc3Rpb24uIDgxOTEgdGFrZW4gZnJvbSB0aGUgQ0ZNIE1JQi4g QWx0aG91Z2ggYWN0dWFsIE1FUC1JRCBvbiB0aGUgd2lyZSBpcyAyIGJ5dGVzLCAoU2VjdGlvbiAy MS42IDgwMi4xYWcsIFRhYmxlIDIxLTE1KSBJIHdpbGwgY2hhbmdlIHRoZSByYW5nZSB0byBmdWxs IHJhbmdlIHdoZW4gdGVjaG5vbG9neSBpcyBub3QgQ0ZNLg0KDQozLiBJbiB0cmlsbCBiYXNlIG1v ZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1EIGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1 bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhl IGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQoNCg0K W2Fuc3dlcl0gQSBWZXJ5IGdvb2QgcXVlc3Rpb24sIEkgZGlkIG5vdCBpbmNsdWRlIHRoaXMgaW4g dGhlIGluaXRpYWwgdmVyc2lvbiB0byBrZWVwIGl0IHNpbXBsZSBidXQgeW91IGNhdWdodCBpdCA6 KS4NCg0KSW4gdGhlIG5leHQgcmV2IEkgd2lsbCBpbmNsdWRlIGFzIGZvbGxvd3MNCg0KVGhlcmUg Y2FuIGJlIG9uZSBhbmQgb25seSBvbmUgVHJpbGxCYXNlIG1vZGUgcGVyIE1BLg0KDQpJIHdpbGwg ZWl0aGVyIGludHJvZHVjZSB0cmlsbCBmZWF0dXJlIGFuZCBtYWtlIGlmLWZlYXR1cmUgb3Igd2hl biB0ZWNobm9sb2d5PXRyaWxsLCB0byBjcmVhdGUgQmFzZSBtb2RlIG5vZGUuICBNeSBjdXJyZW50 IHByZWZlcmVuY2UgaXMgdG8gdXNlIGlmLWZlYXR1cmUuDQoNClRoYW5rcw0KDQp3ZWlndW8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbXBscyBbbXBscy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIFt0c2VuZXZp ckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqNNTCMsjVIDEwOjU3DQrK1bz+yMs6IG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCtb3 zOI6IFttcGxzXSBZQU5HIG1vZGVsIGZvciBwcm90b2NvbCBpbmRlcGVuZGVudCBPQU0NCkFsbA0K DQpJbiB0aGUgZHJhZnQgYmVsb3cgd2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHBy b3RvY29sIGRlcGVuZGVudCBhc3BlY3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0g QVBJIHNldC4gSW4gYSBudXRzaGVsbCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRy YWNlcm91dGUgYW5kIHNvIG9uLiBQcm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVz ZXJzIHRvIGV4ZXJjaXNlIHRoZXNlIE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3Nz IGRpZmZlcmVudCB0ZWNobm9sb2dpZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBv cGVyYXRpb25zIHBsYXRmb3Jtcy4NCg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5n IGFuZCBwcm92aWRpbmcgY29tbWVudHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFz IHdlbGwgYXMgT0FNIGZyYW1ld29yayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Weiguo

 

Thanks for some very g= ood set of questions, please see the answers below in-line with [answer]

 

From: Haoweigu= o [mailto:haoweiguo@huawei.com]
Sent: Tuesday, April 01, 2014 8:51 PM
To: Tissa Senevirathne (tsenevir); mpls@ietf.org; l2vpn@ietf.org; ne= tmod@ietf.org
Subject: =B4=F0=B8=B4: YANG model for protocol ind= ependent OAM

 

Hi Tissa,

Thanks for your presenting the detail Yang = model of TRILL OAM. After read the draft, i have some comments an= d problems as follows.

 

1. There is no MIP data model in this draft, in = TRILL OAM Framework MIP is definitely defined to filter OAM packet based on= MIP level.

[answer] I intentionally skipped this for the = initial rev, it is assumed all MIP are auto created on applicable interface= s. In the next rev, at the MA level will include node ma-autocreate. When disable, will add ability to create MIP manually. Ther= e will be no specific MIP address like in MEP, but just the direction and a= ttached interface.


2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?

[answer] on a different thread Yi zhou also as= ked me the same question. 8191 taken from the CFM MIB. Although actual MEP-= ID on the wire is 2 bytes, (Section 21.6 802.1ag, Table 21-15) I will change the range to full range when technology is not CFM.


3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?

 

[answer] A Very good question, I did not incl= ude this in the initial version to keep it simple but you caught it J.

In the next rev I will include as follows

There can be one and only one TrillBase mode = per MA.

I will either introduce trill feature and mak= e if-feature or when technology=3Dtrill, to create Base mode node.  My= current preference is to use if-feature.


Thanks

weiguo

=B7=A2=BC=FE= =C8=CB: mpls [mpls-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org<= br> =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

All

 =

In the draft below we pr= esent YANG model to abstract protocol dependent aspects of OAM and create a= unified OAM API set. In a nutshell, ping is ping and traceroute is tracero= ute and so on. Protocol independent API =A1=AEs allow users to exercise these OAM tools in the same manner acr= oss different technologies and allow to integrate to their operations platf= orms.

 =

Appreciate your time on = reviewing and providing comments, both on API=A1=AFs and YANG model as well= as OAM framework in it self.

 =

http://www.ietf.= org/id/draft-tissa-netmod-oam-00.txt

 =

Thanks=

Tissa<= /p>

--_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_-- From nobody Wed Apr 2 02:11:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D051F1A017C; Wed, 2 Apr 2014 02:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh3LuFcr-xJx; Wed, 2 Apr 2014 02:11:03 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id AB5361A0178; Wed, 2 Apr 2014 02:11:03 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 783921802AB4; Wed, 2 Apr 2014 11:10:59 +0200 (CEST) Message-ID: <533BD426.4070909@pi.nu> Date: Wed, 02 Apr 2014 11:11:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ospf-request@ietf.org, "isis-wg@ietf.org" , "ccamp-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fPtSQEoRPdm4g8JR9peiC6cfhHE Cc: "mpls@ietf.org" , draft-ietf-mpls-extended-admin-group@tools.ietf.org Subject: [mpls] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:11:08 -0000 OSPF, ISIS and CCAMP working groups, (mpls wg cc'ed) The MPLS working group have requested that draft-ietf-mpls-extended-admin-group is published as a Standard Tracks RFC. The document is through the AD review; as part of the review we have agreed that we'd like to point out to the OSPF, ISIS and CCAMP working groups, that any comments should be sent as responses to the upcoming IETF Last call (the document is in what we hope will be a very quick and minor update). /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 2 07:52:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088F21A0221; Wed, 2 Apr 2014 07:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH1VL3v04VOT; Wed, 2 Apr 2014 07:52:23 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 885441A0245; Wed, 2 Apr 2014 07:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2677; q=dns/txt; s=iport; t=1396450340; x=1397659940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bqIwxSSAdJLbJjaqgZyFqzZ5Fk7YYnBbyEUDLNnSNyI=; b=d7Rrj/Q1H3jHOpnqfEcrVnW92m/A182QSjeyd2lfTofoPHy7XREqSa/J 8wSx620hTuXgs1oYDGSMZbX6X0qAf2U8QLI7pASMYWCHa2KuT9RUUggXS frmLReLjmfZY7itpYkuKB7BvbGIX1xkDyYrQiAbLhDYJAzrkT2SqcxwoB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAN8jPFOtJA2K/2dsb2JhbABZgwY7V7wyhzWBHhZ0giUBAQEEAQEBNzEDCwwCAgIBCBEEAQELFAkHGwwLFAkIAgQBDQUIh3ENzxgTBASOChEBHzEHBoMegRQEqw+DMIFyOQ X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="32304690" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 02 Apr 2014 14:52:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s32EqJAk015809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 14:52:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 09:52:19 -0500 From: "Les Ginsberg (ginsberg)" To: Loa Andersson , "ospf-request@ietf.org" , "isis-wg@ietf.org" , "ccamp-chairs@tools.ietf.org" Thread-Topic: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group Thread-Index: AQHPTlOLfcaTNk2730i4Eg0EETeVRpr+Y9OA Date: Wed, 2 Apr 2014 14:52:18 +0000 Message-ID: References: <533BD426.4070909@pi.nu> In-Reply-To: <533BD426.4070909@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QumOGgbVzPln03P-ThMqYI6bFto Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 14:52:28 -0000 Loa - In reading Section 2.3.1 the text seems contradictory: If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. If the AG and EAG advertised for a link differ, the EAG MUST take priority. The first quoted paragraph says when there is a conflict "AG SHOULD be used= ". The second quoted paragraph says when there is a conflict "EAG MUST take pr= iority". Which preference is intended?? I would think that AG MUST take priority in such cases - otherwise you will= have inconsistency between legacy nodes and nodes which support EAG. I would also note that conflict could be avoided entirely if you defined th= e EAG to be used only for additional (beyond the currently supported 32 gro= ups) rather than as a superset of AG. This would also eliminate the need to= advertise both AG and EAG solely as a transition strategy. Was this option= considered and if so why was it rejected? (Apologies if this was discussed= on mpls list - I do not routinely follow that list.) Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Loa Andersso= n > Sent: Wednesday, April 02, 2014 2:11 AM > To: ospf-request@ietf.org; isis-wg@ietf.org; ccamp-chairs@tools.ietf.org > Cc: mpls@ietf.org; Adrian Farrel; VIGOUREUX, MARTIN (MARTIN); draft-ietf- > mpls-extended-admin-group@tools.ietf.org > Subject: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-ad= min- > group >=20 > OSPF, ISIS and CCAMP working groups, > (mpls wg cc'ed) >=20 > The MPLS working group have requested that > draft-ietf-mpls-extended-admin-group is published as a Standard Tracks RF= C. >=20 > The document is through the AD review; as part of the review we have > agreed that we'd like to point out to the OSPF, ISIS and CCAMP working > groups, that any comments should be sent as responses to the upcoming > IETF Last call (the document is in what we hope will be a very > quick and minor update). >=20 > /Loa > for the mpls wg co-chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Wed Apr 2 08:33:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A641A026D; Wed, 2 Apr 2014 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlvmLxrBl-D7; Wed, 2 Apr 2014 08:33:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 655161A02A2; Wed, 2 Apr 2014 08:32:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402153258.14083.65019.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 08:32:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YIdmwPI0YYyXMXWeMY83ZXxcBDU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:33:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Relayed Echo Reply mechanism for LSP Ping Authors : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-03.txt Pages : 15 Date : 2014-04-02 Abstract: In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-relay-reply-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 2 08:38:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111091A028B; Wed, 2 Apr 2014 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4swy4KSyuTx; Wed, 2 Apr 2014 08:38:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 70F0E1A028A; Wed, 2 Apr 2014 08:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2728; q=dns/txt; s=iport; t=1396453084; x=1397662684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X/uqgHWL8tFMm9k2+jjTbs9XsbCTtRhAazSx34c0E28=; b=BDcDov8Yi3Ge8Mt+Js1iwxTE7rT7bUhwFzZ/NG/Gv9oo41YRk/R15jLc c2zNU5NO4k5X6EX4WE8iqqFrLZ4ja+/QXr9O7r6qY3cGlkalq9XYEMtCq Ry15vMwsyUSugxomzGaXnamAmqlxbLazsv+QpQU1nCmd1I8Lpj8kUKftR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHktPFOtJV2c/2dsb2JhbABZgwY7V7wyhzWBHhZ0giUBAQEEAQEBNzEDCwwCAgIBCBEEAQELFAkHGwwLFAkIAgQBDQUIh3ENzx0TBASOChEBHzEHBoMegRQEqw+DMIFyOQ X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="314693468" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 02 Apr 2014 15:38:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s32Fc35O030000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 15:38:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 10:38:03 -0500 From: "Les Ginsberg (ginsberg)" To: Loa Andersson , "isis-wg@ietf.org" , "ospf@ietf.org" , "ccamp@ietf.org" Thread-Topic: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group Thread-Index: AQHPTlOLfcaTNk2730i4Eg0EETeVRpr+Y9OA Date: Wed, 2 Apr 2014 15:38:02 +0000 Message-ID: References: <533BD426.4070909@pi.nu> In-Reply-To: <533BD426.4070909@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cJVTp3PxSWOiudOuNJIiwM_Be14 Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group@tools.ietf.org" Subject: Re: [mpls] [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:38:13 -0000 (Resending w corrected OSPF/CCAMP WG addresses) Loa - In reading Section 2.3.1 the text seems contradictory: If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. If the AG and EAG advertised for a link differ, the EAG MUST take priority. The first quoted paragraph says when there is a conflict "AG SHOULD be used= ". The second quoted paragraph says when there is a conflict "EAG MUST take pr= iority". Which preference is intended?? I would think that AG MUST take priority in such cases - otherwise you will= have inconsistency between legacy nodes and nodes which support EAG. I would also note that conflict could be avoided entirely if you defined th= e EAG to be used only for additional (beyond the currently supported 32 gro= ups) rather than as a superset of AG. This would also eliminate the need to= advertise both AG and EAG solely as a transition strategy. Was this option= considered and if so why was it rejected? (Apologies if this was discussed= on mpls list - I do not routinely follow that list.) Les > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Loa Andersso= n > Sent: Wednesday, April 02, 2014 2:11 AM > To: ospf-request@ietf.org; isis-wg@ietf.org; ccamp-chairs@tools.ietf.org > Cc: mpls@ietf.org; Adrian Farrel; VIGOUREUX, MARTIN (MARTIN); draft-ietf- > mpls-extended-admin-group@tools.ietf.org > Subject: [Isis-wg] Upcoming IETF Last Call on draft-ietf-mpls-extended-ad= min- > group >=20 > OSPF, ISIS and CCAMP working groups, > (mpls wg cc'ed) >=20 > The MPLS working group have requested that > draft-ietf-mpls-extended-admin-group is published as a Standard Tracks RF= C. >=20 > The document is through the AD review; as part of the review we have > agreed that we'd like to point out to the OSPF, ISIS and CCAMP working > groups, that any comments should be sent as responses to the upcoming > IETF Last call (the document is in what we hope will be a very > quick and minor update). >=20 > /Loa > for the mpls wg co-chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Wed Apr 2 09:44:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF69B1A02D1; Wed, 2 Apr 2014 09:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNQCrUpkK6xl; Wed, 2 Apr 2014 09:44:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 811181A0232; Wed, 2 Apr 2014 09:44:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402164404.7511.21729.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 09:44:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5OeSvQdU3QHAXPXarP6F0u5oViQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-applicability-label-adv-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:44:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Advertisement Discipline for LDP FECs Authors : Kamran Raza Sami Boutros Luca Martini Nicolai Leymann Filename : draft-ietf-mpls-ldp-applicability-label-adv-03.txt Pages : 8 Date : 2014-04-02 Abstract: The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, RFC 6388, and RFC 7140 by specifying the label advertisement mode for all currently defined LDP FEC types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-applicability-label-adv-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-applicability-label-adv-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 3 02:50:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030161A0020; Thu, 3 Apr 2014 02:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MyeQjx5v7k3; Thu, 3 Apr 2014 02:50:33 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 19AB01A001F; Thu, 3 Apr 2014 02:50:33 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8356C180150F; Thu, 3 Apr 2014 11:50:28 +0200 (CEST) Message-ID: <533D2EE3.3030709@pi.nu> Date: Thu, 03 Apr 2014 11:50:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" , karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/axdDPssbI2Mn0qaX-al8ejOD6GE Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org Subject: [mpls] Implementatins of draft-ietf-mpls-ldp-hello-crypto-auth ?? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:50:39 -0000 Working Group, We are preparing the Shepherd write-up for draft-ietf-mpls-ldp-hello-crypto-auth and need to know about existing implementations. If you have an implementation please send a mail to the working group mailing list, the working group chairs or the document shepherd to let us know. Mails directly to chairs or shepherd is fully acceptable. /Loa mpls wg co-chair document shepherd -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 3 15:55:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061341A0335 for ; Thu, 3 Apr 2014 15:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GywSorrt2c3Z for ; Thu, 3 Apr 2014 15:54:59 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8C1A0328 for ; Thu, 3 Apr 2014 15:54:58 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s33Mssi3031515 for ; Fri, 4 Apr 2014 07:54:54 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 3A888E015F for ; Fri, 4 Apr 2014 07:54:54 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 257A1E015A for ; Fri, 4 Apr 2014 07:54:54 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s33MssIp013571 for ; Fri, 4 Apr 2014 07:54:54 +0900 Message-ID: <533DE7E7.2050103@lab.ntt.co.jp> Date: Fri, 04 Apr 2014 07:59:51 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ro0ghIoLV_7X86uFhOLQggYsOKA Subject: [mpls] SDN/MPLS 2014 CFP Announcement X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 22:55:03 -0000 Hello all, The SDN/MPLS 2014 International Conference will be held on November 2 - 5, in Washington, DC, at the Marriott Wardman Park hotel. This event is the 17th annual conference organized by Isocore on Internet, MPLS, SDN, NFV, Cloud, and Related Technologies. The Technical Program Committee of SDN/MPLS 2014 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, network and cloud service providers, the research community, government agencies, and enterprise users. In 2014, the overarching themes of the conference will be on Virtualization, SDN, Cloud Evolution, Datacenter/Cloud Interconnection, Mobility, Security, and Service Resiliency. The deadline for submission of presentation proposals is April 29, 2014. Please submit your abstracts to cfp2014@isocore.com For further information on the SDN/MPLS 2014 conference and additional details on how to submit an abstract, please visit the following URL: http://www.isocore.com/sdn-mpls/cfp.htm Regards, Kohei Shiomoto From nobody Fri Apr 4 00:08:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8DB1A0394 for ; Fri, 4 Apr 2014 00:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znbUCZc-K6E6 for ; Fri, 4 Apr 2014 00:08:14 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE11A0213 for ; Fri, 4 Apr 2014 00:08:14 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 50C5C18015CD; Fri, 4 Apr 2014 09:08:05 +0200 (CEST) Message-ID: <533E5A55.9030302@pi.nu> Date: Fri, 04 Apr 2014 09:08:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6Slj8PscwR27i2HVgeRXhVQxRBs Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 07:08:19 -0000 Working Group, We are preparing draft-ietf-mpls-ldp-hello-crypto-auth to be submitted to the IESG requesting that it is published as an RFC on the standards track. Before we do that we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-ldp-hello- crypto-auth? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 4 00:17:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B61A0130 for ; Fri, 4 Apr 2014 00:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjcfAUUnTMut for ; Fri, 4 Apr 2014 00:17:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 961C31A00FC for ; Fri, 4 Apr 2014 00:17:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCS75079; Fri, 04 Apr 2014 07:17:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:16:21 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:17:19 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 4 Apr 2014 15:17:14 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth Thread-Index: AQHPT9Sr89hLoTOn30u/wnMmpECcjZsBC+Jw Date: Fri, 4 Apr 2014 07:17:13 +0000 Message-ID: References: <533E5A55.9030302@pi.nu> In-Reply-To: <533E5A55.9030302@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ftId12yhRkG4Mv-ccVJgq4duqQY Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 07:17:31 -0000 Hi Loa, I am not aware of any IPR that applies to this draft. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, April 04, 2014 3:08 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org > Subject: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth >=20 > Working Group, >=20 > We are preparing draft-ietf-mpls-ldp-hello-crypto-auth to be submitted t= o the > IESG requesting that it is published as an RFC on the standards track. >=20 > Before we do that we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-ldp-hello- crypt= o-auth? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs 3979, > 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his email > regardless of whether or not you are aware of any relevant IPR. *The resp= onse > needs to be sent to the MPLS wg mailing list.* The document will not adva= nce to > the next stage until a response has been received from each author and > contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or c= ontributor, > then please explicitly respond only if you are aware of any IPR that has = not yet > been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 4 00:27:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8A71A0019 for ; Fri, 4 Apr 2014 00:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVJo7SmB0RLZ for ; Fri, 4 Apr 2014 00:27:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE41A1A00E3 for ; Fri, 4 Apr 2014 00:27:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG28599; Fri, 04 Apr 2014 07:27:15 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:26:13 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:27:13 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.15]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Fri, 4 Apr 2014 15:27:09 +0800 From: Vero Zheng To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth Thread-Index: AQHPT9SqZBz96T1C/kGRjuo27PcogZsBDojQ Date: Fri, 4 Apr 2014 07:27:09 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C80BAB5@SZXEMA504-MBS.china.huawei.com> References: <533E5A55.9030302@pi.nu> In-Reply-To: <533E5A55.9030302@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/P8yTcOP18jSpB1i5mwPm3hoQwgM Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 07:27:26 -0000 Loa and folks, There is no IPR from my side. Cheers, Vero > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, April 04, 2014 3:08 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org > Subject: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth >=20 > Working Group, >=20 > We are preparing draft-ietf-mpls-ldp-hello-crypto-auth to be submitted t= o the > IESG requesting that it is published as an RFC on the standards track. >=20 > Before we do that we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-ldp-hello- crypt= o-auth? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. *Th= e > response needs to be sent to the MPLS wg mailing list.* The document will= not > advance to the next stage until a response has been received from each au= thor > and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR that > has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 4 00:47:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B184F1A0077 for ; Fri, 4 Apr 2014 00:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GM6B7i_szsW for ; Fri, 4 Apr 2014 00:47:33 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B11A0047 for ; Fri, 4 Apr 2014 00:47:33 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s347lRSM000693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Apr 2014 02:47:27 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s347lQRq021326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 03:47:27 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 Apr 2014 03:47:26 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.78]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Fri, 4 Apr 2014 15:46:27 +0800 From: "Bhatia, Manav (Manav)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll draft-ietf-mpls-ldp-hello-crypto-auth Thread-Index: AQHPT9TDhM7l0BX2ekatN2xnW9BoIZsBEqUg Date: Fri, 4 Apr 2014 07:46:26 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5D2939@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <533E5A55.9030302@pi.nu> In-Reply-To: <533E5A55.9030302@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mwaPMtUt8tT5p6BW31ZiHX_7KRI Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org" Subject: Re: [mpls] IPR poll draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 07:47:37 -0000 None from my side as well. Cheers, Manav > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, April 04, 2014 12:38 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); draft-ietf- > mpls-ldp-hello-crypto-auth@tools.ietf.org > Subject: IPR poll draft-ietf-mpls-ldp-hello-crypto-auth >=20 > Working Group, >=20 > We are preparing draft-ietf-mpls-ldp-hello-crypto-auth to be submitted > to the IESG requesting that it is published as an RFC on the standards > track. >=20 > Before we do that we want to do an IPR poll on the document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-ldp-hello- > crypto-auth? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are no IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of > any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Apr 7 08:04:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D81A0783 for ; Mon, 7 Apr 2014 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_M9-QZvYeR6 for ; Mon, 7 Apr 2014 08:04:39 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id C3A831A0455 for ; Mon, 7 Apr 2014 08:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3599; q=dns/txt; s=iport; t=1396883073; x=1398092673; h=message-id:date:from:reply-to:mime-version:to:subject; bh=AEdG299bt4gsOoSXemWSvEwtolIfUXLJXm+En7RKzDI=; b=GGCi62/v9u6MBeXUNTtuQGu/3LCHLJXq3UJz8eLoM9Vk741oXZjmi7Ad hbLZtuyWYQd8w9W5sP/2PtrS9MudShqtABp1T/gDZC0ygrJ6pHtL8XjP6 iqsAKYQjZ5wdNjlAldjb2NJnJHLPon+NDRZihqxpGjfw8mrkmBhwAztzK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAEm9QlOQ/khM/2dsb2JhbABZgwaJeLxbFnSDExEgHRYYAwIBAgFLDQgBAReHXppQhxaNX5woF5MwBJhbkj+DMQ X-IronPort-AV: E=Sophos;i="4.97,810,1389744000"; d="scan'208,217";a="9794817" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-3.cisco.com with ESMTP; 07 Apr 2014 15:04:32 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s37F4V0C001308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Apr 2014 15:04:32 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s37F4RN3017603; Mon, 7 Apr 2014 16:04:27 +0100 (BST) Message-ID: <5342BE7B.6020601@cisco.com> Date: Mon, 07 Apr 2014 16:04:27 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="------------000105030403010703020107" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EH6Hn_g27mr-rJ_dhrfByF0IH-s Subject: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:04:43 -0000 This is a multi-part message in MIME format. --------------000105030403010703020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MPLSers I have just uploaded draft-bryant-mpls-oam-udp-return-00 This is a short draft that explains how to send an RFC6374 MPLS(-TP) response back to the querying node over a UDP/IP path using a dynamic UDP port. The solution in a nutshell is to allocate a new non-mandatory TLV from the MPLS Loss/ Delay Measurement TLV Object Registry and use this four byte TLV to carry the UDP port that the Querying node will listen on. There already exists a definition for an address TLV. Thus with this new TLV the Responder will know how to encapsulate the response to the Querying node. The Response message is carried directly in UDP without the GACH since the message type information is known from the UDP port. Apart from the boiler plate and the various mandatory sections the rest of the document describes the straightforward procedures needed to use the information in the query to encapsulate the response. I notice in writing this summary that I did not specify the length in the TLV. This is defined in RFC6374 and so is not strictly necessary, but in the next version I will note that it is 2. I would request a review of the document, and hope that we can consider it for WG adoption without needing to first present it at an IETF. - Stewart --------------000105030403010703020107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MPLSers

I have just uploaded draft-bryant-mpls-oam-udp-return-00

This is a short draft that explains how to send an RFC6374
MPLS(-TP) response back to the querying node over a UDP/IP
path using a dynamic UDP port.

The solution in a nutshell is to allocate a new non-mandatory
TLV from the MPLS Loss/ Delay Measurement TLV Object Registry
and use this four byte TLV to carry the UDP port that the
Querying node will listen on. There already exists a definition
for an address TLV. Thus with this new TLV the Responder will
know how to encapsulate the response to the Querying node.

The Response message is carried directly in UDP without the
GACH since the message type information is known from the
UDP port.

Apart from the boiler plate and the various mandatory sections
the rest of the document describes the straightforward
procedures needed to use the information in the query to
encapsulate the response.

I notice in writing this summary that I did not specify the
length in the TLV. This is defined in RFC6374 and so is
not strictly necessary, but in the next version I will note that
it is 2.

I would request a review of the document, and hope that
we can consider it for WG adoption without needing to
first present it at an IETF.

- Stewart




--------------000105030403010703020107-- From nobody Mon Apr 7 08:08:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82191A0791; Mon, 7 Apr 2014 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwcVi42Tcxsj; Mon, 7 Apr 2014 08:08:34 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB991A0781; Mon, 7 Apr 2014 08:08:34 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id c6fb2435.0.5225.00-2354.15075.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 07 Apr 2014 15:08:29 +0000 (UTC) X-MXL-Hash: 5342bf6d19e1f23c-5fb45c684da7879e5b33af559819792bac94ee70 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s37F8RQp001117; Mon, 7 Apr 2014 11:08:28 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s37F8FNH000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 11:08:21 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 7 Apr 2014 15:08:01 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 11:08:01 -0400 From: "BRUNGARD, DEBORAH A" To: "mpls@ietf.org" , "rtg-bfd@ietf.org" Thread-Topic: Prep for IESG review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext Thread-Index: Ac9ScyqegRoGiALTRMWBWVujf+IFFg== Date: Mon, 7 Apr 2014 15:08:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.71.59] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=W6OPo2qk c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=jHPW6ygmP3IA:10 a=ofMgfj31e3cA:10 a=By6Mh84-ZgcA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=xT-_WGOjd] X-AnalysisOut: [5w2C3Hgg20A:9 a=CjuIK1q_8ugA:10 a=5v5zimUNW9oA:10 a=aQW1B-] X-AnalysisOut: [_K2K0A:10 a=gTNRcJHmHxC0pAnbdLYA:9 a=_W_S_7VecoQA:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=cjh8W46Ov5fGW6Oo:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9HNzXnnmAYh4iBODJPHeYRnc9aI Cc: "ccamp@ietf.org" Subject: [mpls] Prep for IESG review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:08:40 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS, BFD, CCAMP has submitted this draft for publication, it is currently being updat= ed for AD review comments. If any comments, please use the ccamp mailing list. Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
MPLS, BFD,
 
CCAMP has submitted this draft for publication, it is currently being = updated for AD review comments.
 
If any comments, please use the ccamp mailing list.
 
Thanks,
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_-- From nobody Mon Apr 7 20:41:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146A31A00BF for ; Mon, 7 Apr 2014 20:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3FGv0i7po2r for ; Mon, 7 Apr 2014 20:41:18 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5571A00B0 for ; Mon, 7 Apr 2014 20:41:18 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so387603pde.38 for ; Mon, 07 Apr 2014 20:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j3u+2NJBM8FluiNYDq9n0DCkatMF2HfX4EPIqQlwYcg=; b=wzvSe89wAN1p1MasMX5HoUuOUkT2+1wfmMSsOw6p2yx8ySpBdnH/YnURHW/P7M6ypM ovPhTgYh6HIMMdHpJ74h5Tf32IGJLkMN70PB/jIOMRcDHh9JuLgZJ2nZ3jitz9LNA5NE N5DnrEi7sB30cTnhVPVLpzYHcAgd4n/3cH7qVGpG3vQI4Qx0ZFXN80Ui4oRl26Mu5ztK jWtpw7bPZGszi5YVW2CG7iOOpOe3B3JluTJILaY7pyzK55VGcu3WnIRAKnBogaeIlyT2 2hrSQll+xXBcIhNAxFPoUCVgKN8bpjWoODWWzmhcfa54tp+hwCzC9whRZJiB2ehGO1v2 /gew== X-Received: by 10.68.250.3 with SMTP id yy3mr1600244pbc.56.1396928472836; Mon, 07 Apr 2014 20:41:12 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id sm5sm3487328pab.19.2014.04.07.20.41.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 20:41:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sam Aldrin In-Reply-To: <5342BE7B.6020601@cisco.com> Date: Mon, 7 Apr 2014 20:41:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> References: <5342BE7B.6020601@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BsU7RkgLZCEzysi58Z36G5UZiik Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 03:41:23 -0000 Hi Stewart, Didn't read the document to its entirety, but from what I gather, scope = of the draft is for Performance metric measurement only. Title indicates mpls-oam, which I do not believe is right and is = misleading. If you think the scope includes all of MPLS OAM, that including LSP ping = etc, I do not find how it is applicable in conjunction with RFC4379, = where return path via UDP is pretty much by default. I do not see any = text related to that, either. -sam On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: > MPLSers >=20 > I have just uploaded draft-bryant-mpls-oam-udp-return-00 >=20 > This is a short draft that explains how to send an RFC6374 > MPLS(-TP) response back to the querying node over a UDP/IP=20 > path using a dynamic UDP port. >=20 > The solution in a nutshell is to allocate a new non-mandatory > TLV from the MPLS Loss/ Delay Measurement TLV Object Registry > and use this four byte TLV to carry the UDP port that the=20 > Querying node will listen on. There already exists a definition > for an address TLV. Thus with this new TLV the Responder will > know how to encapsulate the response to the Querying node. >=20 > The Response message is carried directly in UDP without the=20 > GACH since the message type information is known from the=20 > UDP port. >=20 > Apart from the boiler plate and the various mandatory sections > the rest of the document describes the straightforward=20 > procedures needed to use the information in the query to > encapsulate the response. >=20 > I notice in writing this summary that I did not specify the > length in the TLV. This is defined in RFC6374 and so is=20 > not strictly necessary, but in the next version I will note that > it is 2. >=20 > I would request a review of the document, and hope that > we can consider it for WG adoption without needing to=20 > first present it at an IETF. >=20 > - Stewart >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 8 02:07:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E921A01BB for ; Tue, 8 Apr 2014 02:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VexbGwViQ8m for ; Tue, 8 Apr 2014 02:07:45 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BABD1A01CA for ; Tue, 8 Apr 2014 02:07:44 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-1a-5343ba079334 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.82.02828.70AB3435; Tue, 8 Apr 2014 10:57:43 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 05:07:37 -0400 From: Eric Gray To: Sam Aldrin , "stbryant@cisco.com" Thread-Topic: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 Thread-Index: AQHPUnK9SoDXIXlE306eMDkjSSjqKJsHVusAgAAVunA= Date: Tue, 8 Apr 2014 09:07:36 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A5281D@eusaamb107.ericsson.se> References: <5342BE7B.6020601@cisco.com> <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> In-Reply-To: <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPuC77Ludgg/+3ZS0mtH5htLi1dCWr xbmncxgdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcyctYe14IF4xaRti5ga GP8LdTFyckgImEj87vrIBGGLSVy4t56ti5GLQ0jgKKPE5OvN7BDOMkaJhx93soBUsQloSBy7 s5axi5GDQ0QgWGJtAyeIySygLHHqrgyIKSzgITFpYwpIsYiAp8SuzRNYIWwriUWHjrKAlLAI qEgsXGsAEuYV8JV4Pf8vM4gtJBAtsaDlPpjNKWAr8WRRMxuIzQh02fdTa8CuZBYQl7j1ZD7U xQISS/acZ4awRSVePv7HCmErSuzrn84OUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRbBaS sbOQtMxC0jILScsCRpZVjBylxalluelGBpsYgTFzTIJNdwfjnpeWhxilOViUxHm/vHUOEhJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cC4wrvVwW+qqHXNOddjjRODLoTvnRE9+f0G05/S9a/C HnVHd/7wUWvTj1231GL7Oj/VmO1VV7SennDIry1+bnjmnOPHvUzLNE7/u677e6bKgaP78z1W B27sPLeIM2iNbdhGBuvLRipBNq8OZ0lvS5uc8EKuNPmesM967vJJPw8teOOueff/xq3+SizF GYmGWsxFxYkAWLLCwGcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dHlHGs8qE3NzqLOHKGbJ-uG5rHg Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:07:49 -0000 Sam, I don't understand this comment. The title of the draft is: "MPLS Performance Measurement UDP Return Path" Are you referring to the draft name? If so, PM is part of OAM (some might argue that it is a big part). However, perhaps - if the draft is accepted as a WG draft - the name might be changed to "draft-ietf-mpls-pm-udp-return-??." Given the fact that the title itself is pretty unambiguous, I suspect that= there is little point in changing the name of the draft at this point... -- Eric -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Monday, April 07, 2014 11:41 PM To: stbryant@cisco.com Cc: mpls@ietf.org Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 Hi Stewart, Didn't read the document to its entirety, but from what I gather, scope of = the draft is for Performance metric measurement only. Title indicates mpls-oam, which I do not believe is right and is misleading= . If you think the scope includes all of MPLS OAM, that including LSP ping et= c, I do not find how it is applicable in conjunction with RFC4379, where re= turn path via UDP is pretty much by default. I do not see any text related = to that, either. -sam On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: > MPLSers >=20 > I have just uploaded draft-bryant-mpls-oam-udp-return-00 >=20 > This is a short draft that explains how to send an RFC6374 > MPLS(-TP) response back to the querying node over a UDP/IP=20 > path using a dynamic UDP port. >=20 > The solution in a nutshell is to allocate a new non-mandatory > TLV from the MPLS Loss/ Delay Measurement TLV Object Registry > and use this four byte TLV to carry the UDP port that the=20 > Querying node will listen on. There already exists a definition > for an address TLV. Thus with this new TLV the Responder will > know how to encapsulate the response to the Querying node. >=20 > The Response message is carried directly in UDP without the=20 > GACH since the message type information is known from the=20 > UDP port. >=20 > Apart from the boiler plate and the various mandatory sections > the rest of the document describes the straightforward=20 > procedures needed to use the information in the query to > encapsulate the response. >=20 > I notice in writing this summary that I did not specify the > length in the TLV. This is defined in RFC6374 and so is=20 > not strictly necessary, but in the next version I will note that > it is 2. >=20 > I would request a review of the document, and hope that > we can consider it for WG adoption without needing to=20 > first present it at an IETF. >=20 > - Stewart >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 8 04:21:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCEB1A011D for ; Tue, 8 Apr 2014 04:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsUqStYnKVeX for ; Tue, 8 Apr 2014 04:21:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 288BA1A00FD for ; Tue, 8 Apr 2014 04:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2599; q=dns/txt; s=iport; t=1396956086; x=1398165686; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j0h/ptyOUGYW70FQb8oR11zXUheHZwQFpCCw6reddJA=; b=jRxyXP3NQse9OJl6bsKgDQIJ2N52ypUPS0bg/7nKeu3uTJUT6GQFdbXc cpogWNdHi3Vrjk1uZaqlKMdkZAK3y6DdHyGffbkkgy4hV5MhKkYBzqI/z AfQUDjYpoavsGTwTS+/TUrUrhCjjnqqpLFNLboJyGf0DP5lZXVKpKHNO6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHnaQ1OQ/khN/2dsb2JhbABZgwY7vUSHN4EiFnSCJQEBAQMBAQEBNS8HCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQEXh1YIDa1hnEYXjkgiB4Q4BJhckkCDMQ X-IronPort-AV: E=Sophos;i="4.97,817,1389744000"; d="scan'208";a="9964613" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 08 Apr 2014 11:21:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s38BLO5T003264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 11:21:25 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s38BLOam006079; Tue, 8 Apr 2014 12:21:24 +0100 (BST) Message-ID: <5343DBB6.7060603@cisco.com> Date: Tue, 08 Apr 2014 12:21:26 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Sam Aldrin References: <5342BE7B.6020601@cisco.com> <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> In-Reply-To: <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LxgoiMuC-4EDKqvRaXnLM2ovkKg Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 11:21:37 -0000 Yes, the interest is in RFC6373 and I can clarify that. Indeed the TLV is only defines for RFC6373. It might be appropriate to s/OAM/RFC6373/ in a few places, although I would like to keep the draft name constant whilst this phase of the discussion goes on, and change if/when it becomes a WG draft. Stewart On 08/04/2014 04:41, Sam Aldrin wrote: > Hi Stewart, > > Didn't read the document to its entirety, but from what I gather, scope of the draft is for Performance metric measurement only. > Title indicates mpls-oam, which I do not believe is right and is misleading. > > If you think the scope includes all of MPLS OAM, that including LSP ping etc, I do not find how it is applicable in conjunction with RFC4379, where return path via UDP is pretty much by default. I do not see any text related to that, either. > > -sam > On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: > >> MPLSers >> >> I have just uploaded draft-bryant-mpls-oam-udp-return-00 >> >> This is a short draft that explains how to send an RFC6374 >> MPLS(-TP) response back to the querying node over a UDP/IP >> path using a dynamic UDP port. >> >> The solution in a nutshell is to allocate a new non-mandatory >> TLV from the MPLS Loss/ Delay Measurement TLV Object Registry >> and use this four byte TLV to carry the UDP port that the >> Querying node will listen on. There already exists a definition >> for an address TLV. Thus with this new TLV the Responder will >> know how to encapsulate the response to the Querying node. >> >> The Response message is carried directly in UDP without the >> GACH since the message type information is known from the >> UDP port. >> >> Apart from the boiler plate and the various mandatory sections >> the rest of the document describes the straightforward >> procedures needed to use the information in the query to >> encapsulate the response. >> >> I notice in writing this summary that I did not specify the >> length in the TLV. This is defined in RFC6374 and so is >> not strictly necessary, but in the next version I will note that >> it is 2. >> >> I would request a review of the document, and hope that >> we can consider it for WG adoption without needing to >> first present it at an IETF. >> >> - Stewart >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Apr 8 04:23:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFBA1A00FD for ; Tue, 8 Apr 2014 04:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5DFDUgrtu7t for ; Tue, 8 Apr 2014 04:23:01 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8435D1A0156 for ; Tue, 8 Apr 2014 04:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3279; q=dns/txt; s=iport; t=1396956175; x=1398165775; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b885vNzELNGp2EInLEzR2VnmOC4TD7ekniHkMBJoFuc=; b=IFyU85QMY+Tz8N2ieHMAZEt7rNs4xgpQIx0fdJ7U1t2bTBX1v3xNE3NO 1akDZshkni5EejkU2OvSq221tLJeKzcluh5nsgeswx6bDqzbe23w3fJ9a OxWZg0HjYPjgP68wvV9k0j69WAvMnLLq9wc58QQuWpOE28vZAJFLbGA6V Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADfbQ1OtJssU/2dsb2JhbABZgwY7vUSHN4EiFnSCJQEBAQQBAQE1LwcKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAReHXg2tYZxGF45IIgcGhDIEmFySQIMx X-IronPort-AV: E=Sophos;i="4.97,817,1389744000"; d="scan'208";a="9980341" Received: from aer-core-3.cisco.com ([173.38.203.20]) by aer-iport-3.cisco.com with ESMTP; 08 Apr 2014 11:22:53 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s38BMoVA018402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 11:22:50 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s38BMmML006126; Tue, 8 Apr 2014 12:22:49 +0100 (BST) Message-ID: <5343DC0A.5060403@cisco.com> Date: Tue, 08 Apr 2014 12:22:50 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Gray , Sam Aldrin References: <5342BE7B.6020601@cisco.com> <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632A5281D@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A5281D@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8WLb57GEyR3W5ui9NrgyDJMaxUQ Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 11:23:07 -0000 That would work for us. Stewart On 08/04/2014 10:07, Eric Gray wrote: > Sam, > > I don't understand this comment. > > The title of the draft is: > > "MPLS Performance Measurement UDP Return Path" > > Are you referring to the draft name? If so, PM is part of OAM (some might > argue that it is a big part). > > However, perhaps - if the draft is accepted as a WG draft - the name might > be changed to "draft-ietf-mpls-pm-udp-return-??." > > Given the fact that the title itself is pretty unambiguous, I suspect that there > is little point in changing the name of the draft at this point... > > -- > Eric > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Monday, April 07, 2014 11:41 PM > To: stbryant@cisco.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 > > Hi Stewart, > > Didn't read the document to its entirety, but from what I gather, scope of the draft is for Performance metric measurement only. > Title indicates mpls-oam, which I do not believe is right and is misleading. > > If you think the scope includes all of MPLS OAM, that including LSP ping etc, I do not find how it is applicable in conjunction with RFC4379, where return path via UDP is pretty much by default. I do not see any text related to that, either. > > -sam > On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: > >> MPLSers >> >> I have just uploaded draft-bryant-mpls-oam-udp-return-00 >> >> This is a short draft that explains how to send an RFC6374 >> MPLS(-TP) response back to the querying node over a UDP/IP >> path using a dynamic UDP port. >> >> The solution in a nutshell is to allocate a new non-mandatory >> TLV from the MPLS Loss/ Delay Measurement TLV Object Registry >> and use this four byte TLV to carry the UDP port that the >> Querying node will listen on. There already exists a definition >> for an address TLV. Thus with this new TLV the Responder will >> know how to encapsulate the response to the Querying node. >> >> The Response message is carried directly in UDP without the >> GACH since the message type information is known from the >> UDP port. >> >> Apart from the boiler plate and the various mandatory sections >> the rest of the document describes the straightforward >> procedures needed to use the information in the query to >> encapsulate the response. >> >> I notice in writing this summary that I did not specify the >> length in the TLV. This is defined in RFC6374 and so is >> not strictly necessary, but in the next version I will note that >> it is 2. >> >> I would request a review of the document, and hope that >> we can consider it for WG adoption without needing to >> first present it at an IETF. >> >> - 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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Tue Apr 8 06:11:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC51A03BC for ; Tue, 8 Apr 2014 06:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8nXU_8n1OAM for ; Tue, 8 Apr 2014 06:11:26 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFED1A0395 for ; Tue, 8 Apr 2014 06:11:22 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so990266pdi.33 for ; Tue, 08 Apr 2014 06:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tLJoKvufPozwj8ucSMPa4Zi53BOish5Dp8unO6YIHjY=; b=mHRCLbEwXbz8O8RxDCnyMja0zQV5fya7mo2b5Rk7EUs6dLMjSpRcPX1jQ6mvRCAsEJ fTTkJluf34AQlQ4lU3gukuEX/rUfMyyK+ih2MDs1Mnjoe1eWq7Lg9FKL7zdi9IG7yWzN 9kuXY50YHRM7ITCQPW3P/YYfY+r40q/QtnfDBMQAEZxyFuI+aG16QtcK2S9x5yhTrunc tc6+9YXrK130h3G2BeviggNMU/SXVu08yZklmBf/GpCbMyhLOnnuyay6Q/Cm5RwLYYf/ l4GaUHQGIBQztehva7qS/aBPo9lbTqxDX1Uqrkty4+TuTBjZFxvL08cpEHq86AkKhRuV RO5w== X-Received: by 10.66.156.164 with SMTP id wf4mr4595473pab.138.1396962683084; Tue, 08 Apr 2014 06:11:23 -0700 (PDT) Received: from [10.226.163.182] (mobile-198-228-223-223.mycingular.net. [198.228.223.223]) by mx.google.com with ESMTPSA id ek2sm4594892pbd.30.2014.04.08.06.11.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 06:11:21 -0700 (PDT) References: <5342BE7B.6020601@cisco.com> <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632A5281D@eusaamb107.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A5281D@eusaamb107.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <554010E8-9FB1-46C5-8186-457EB741F107@gmail.com> X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Date: Tue, 8 Apr 2014 06:11:19 -0700 To: Eric Gray Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U1zcSXlieQwBS-EXftPHc-2xfys Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:11:34 -0000 Eric, As I said in my earlier mail, tbd draft name says 'draft-mpls-oam-...' But t= he scope is only PM. Hence the question was, whether it covers beyond PM, as= we all know OAM covers more than PM.=20 Sam Sent from my iPhone > On Apr 8, 2014, at 2:07 AM, Eric Gray wrote: >=20 > Sam, >=20 > I don't understand this comment. >=20 > The title of the draft is: >=20 > "MPLS Performance Measurement UDP Return Path" >=20 > Are you referring to the draft name? If so, PM is part of OAM (some mi= ght > argue that it is a big part). >=20 > However, perhaps - if the draft is accepted as a WG draft - the name mi= ght > be changed to "draft-ietf-mpls-pm-udp-return-??." >=20 > Given the fact that the title itself is pretty unambiguous, I suspect t= hat there > is little point in changing the name of the draft at this point... >=20 > -- > Eric >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Monday, April 07, 2014 11:41 PM > To: stbryant@cisco.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 >=20 > Hi Stewart, >=20 > Didn't read the document to its entirety, but from what I gather, scope of= the draft is for Performance metric measurement only. > Title indicates mpls-oam, which I do not believe is right and is misleadin= g. >=20 > If you think the scope includes all of MPLS OAM, that including LSP ping e= tc, I do not find how it is applicable in conjunction with RFC4379, where re= turn path via UDP is pretty much by default. I do not see any text related t= o that, either. >=20 > -sam >> On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: >>=20 >> MPLSers >>=20 >> I have just uploaded draft-bryant-mpls-oam-udp-return-00 >>=20 >> This is a short draft that explains how to send an RFC6374 >> MPLS(-TP) response back to the querying node over a UDP/IP=20 >> path using a dynamic UDP port. >>=20 >> The solution in a nutshell is to allocate a new non-mandatory >> TLV from the MPLS Loss/ Delay Measurement TLV Object Registry >> and use this four byte TLV to carry the UDP port that the=20 >> Querying node will listen on. There already exists a definition >> for an address TLV. Thus with this new TLV the Responder will >> know how to encapsulate the response to the Querying node. >>=20 >> The Response message is carried directly in UDP without the=20 >> GACH since the message type information is known from the=20 >> UDP port. >>=20 >> Apart from the boiler plate and the various mandatory sections >> the rest of the document describes the straightforward=20 >> procedures needed to use the information in the query to >> encapsulate the response. >>=20 >> I notice in writing this summary that I did not specify the >> length in the TLV. This is defined in RFC6374 and so is=20 >> not strictly necessary, but in the next version I will note that >> it is 2. >>=20 >> I would request a review of the document, and hope that >> we can consider it for WG adoption without needing to=20 >> first present it at an IETF. >>=20 >> - Stewart >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 8 06:12:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899F81A03B5 for ; Tue, 8 Apr 2014 06:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aaba6QIgOJK for ; Tue, 8 Apr 2014 06:12:28 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 934E41A03BB for ; Tue, 8 Apr 2014 06:12:25 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id z10so990771pdj.18 for ; Tue, 08 Apr 2014 06:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tq7J6xGYwd+12n1xfjuR0S9swXQYRbVpXEJlNGHo/fQ=; b=VfMB2KQI52ndQxoXXmyBOVsOnr9ZLQeRZXfmSrj4/NIHVglPh8ne+SZfDjJsPlibkA QVhkbiSBzheHjimNPTTKyPJEgy7kUwq1bH9xfI8pPARuPh5x6TuzeeBZKu1mk1hqQO17 mYpVXVh1xF1o6JWVxGHXGFCS9+N5s5l8YYLMvO2uI66M+UwM1PoH+r77HzehCJuYGM8Y tsGyr67orR6or+DNsNVCqxLrrMDuZoDDL2FuumTgMwVUWhKvff2/W7zE4rFD30q2Fefw US1CDMlwy86FkZpflRc2vV6JrPX0a3zeNa2Pj688ytt0ANpsUELYkZ+Y/AAwp2YjXWDF N+rg== X-Received: by 10.66.139.70 with SMTP id qw6mr4416329pab.111.1396962745673; Tue, 08 Apr 2014 06:12:25 -0700 (PDT) Received: from [10.226.163.182] (mobile-198-228-223-223.mycingular.net. [198.228.223.223]) by mx.google.com with ESMTPSA id cz3sm4610228pbc.9.2014.04.08.06.12.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 06:12:24 -0700 (PDT) References: <5342BE7B.6020601@cisco.com> <21CC2B3D-867B-4A1A-BA7E-A075FF9668D5@gmail.com> <5343DBB6.7060603@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5343DBB6.7060603@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Date: Tue, 8 Apr 2014 06:12:21 -0700 To: "stbryant@cisco.com" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hA63gAdn3n7OHPeIH4wkujg7rCc Cc: "mpls@ietf.org" Subject: Re: [mpls] Review request : draft-bryant-mpls-oam-udp-return-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:12:33 -0000 That is fine. Thanks for the clarification. Sam Sent from my iPhone > On Apr 8, 2014, at 4:21 AM, Stewart Bryant wrote: >=20 >=20 > Yes, the interest is in RFC6373 and I can clarify that. > Indeed the TLV is only defines for RFC6373. > It might be appropriate to s/OAM/RFC6373/ > in a few places, although I would like to keep the > draft name constant whilst this phase of the discussion > goes on, and change if/when it becomes a WG draft. >=20 > Stewart >=20 >=20 >=20 >> On 08/04/2014 04:41, Sam Aldrin wrote: >> Hi Stewart, >>=20 >> Didn't read the document to its entirety, but from what I gather, scope o= f the draft is for Performance metric measurement only. >> Title indicates mpls-oam, which I do not believe is right and is misleadi= ng. >>=20 >> If you think the scope includes all of MPLS OAM, that including LSP ping e= tc, I do not find how it is applicable in conjunction with RFC4379, where re= turn path via UDP is pretty much by default. I do not see any text related t= o that, either. >>=20 >> -sam >>> On Apr 7, 2014, at 8:04 AM, Stewart Bryant wrote: >>>=20 >>> MPLSers >>>=20 >>> I have just uploaded draft-bryant-mpls-oam-udp-return-00 >>>=20 >>> This is a short draft that explains how to send an RFC6374 >>> MPLS(-TP) response back to the querying node over a UDP/IP >>> path using a dynamic UDP port. >>>=20 >>> The solution in a nutshell is to allocate a new non-mandatory >>> TLV from the MPLS Loss/ Delay Measurement TLV Object Registry >>> and use this four byte TLV to carry the UDP port that the >>> Querying node will listen on. There already exists a definition >>> for an address TLV. Thus with this new TLV the Responder will >>> know how to encapsulate the response to the Querying node. >>>=20 >>> The Response message is carried directly in UDP without the >>> GACH since the message type information is known from the >>> UDP port. >>>=20 >>> Apart from the boiler plate and the various mandatory sections >>> the rest of the document describes the straightforward >>> procedures needed to use the information in the query to >>> encapsulate the response. >>>=20 >>> I notice in writing this summary that I did not specify the >>> length in the TLV. This is defined in RFC6374 and so is >>> not strictly necessary, but in the next version I will note that >>> it is 2. >>>=20 >>> I would request a review of the document, and hope that >>> we can consider it for WG adoption without needing to >>> first present it at an IETF. >>>=20 >>> - Stewart >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> . >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From nobody Tue Apr 8 09:04:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57D51A03DF for ; Tue, 8 Apr 2014 09:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYYm7yhgWkSx for ; Tue, 8 Apr 2014 09:04:55 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 586791A048A for ; Tue, 8 Apr 2014 09:04:52 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-d0-53441bd059bb Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 31.51.02828.0DB14435; Tue, 8 Apr 2014 17:54:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 12:04:50 -0400 From: Gregory Mirsky To: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: Comments on draft-bryant-mpls-oam-udp-return Thread-Index: Ac9TQv9+alcZjjU8RACH2gnVvpbV4Q== Date: Tue, 8 Apr 2014 16:04:50 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B79D6DEeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXSPt+4FaZdgg0frRCwmfXvDbHFr6UpW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj7rl21oJ5chX/5jxnaWD8L9nFyMkhIWAi sWjWT3YIW0ziwr31bF2MXBxCAkcZJZo+/GOHcJYxSnxeeYcFpIpNwEjixcYesA4RgUyJiZua mLsYOTiYBZQlTt2VAQkLC5hJfFkylxGixFpi8rIdrBC2nkTzp/lsIOUsAioS23aLgIR5BXwl Fiz5DjadEeiG76fWMIHYzALiEreezGeCuE1AYsme88wQtqjEy8f/WCFsJYlJS8+xQtTnS/Te +8MMMVNQ4uTMJywTGIVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUj R2lxalluupHBJkZgjByTYNPdwbjnpeUhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MLp9FjWWzq++skwioGvpyxdBD3+/tddiF4rI9/bzYHBbmLBC+fzaSp4ou3Lx9VJH liw2VrWoP8v/9YTdBJMACRfBzjTujqWWKn+/pZ3cNtP9i0XKN+Gguo9hi96xyDAsDPp3wFah NtZR8wCfd05aQXuD2pk7v1edr31VeznQd2OP4ekZcgb3lFiKMxINtZiLihMBUqeCDV8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CpDglG0wjvcuV5yFoj4agmBktvg Cc: "mpls@ietf.org" Subject: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:04:58 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B79D6DEeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, I think this is interesting and timely proposal. But I think that this is o= nly part of bigger puzzle, part of MPLS PM Control Protocol. I think that n= eed to retrieve, fetch PM data is the most common in one-way active PM. If = that is the case, then there may be good reason to look at RFC 4656 One-Way= Active Measurement Protocol (OWAMP) by= IPPM WG. True, RFC 4656 has two protocols in itself - Control and Test. An= d with RFC 6374 being MPLS PM OAM Test protocol we might look at RFC 4656 a= s example of PM OAM Control protocol. And yes, there's Fetch function defin= ed. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B79D6DEeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et. al,

I think this is interesting and timely proposal. But= I think that this is only part of bigger puzzle, part of MPLS PM Control P= rotocol. I think that need to retrieve, fetch PM data is the most common in= one-way active PM. If that is the case, then there may be good reason to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) by IPPM WG. True, = RFC 4656 has two protocols in itself - Control and Test. And with RFC 6374 = being MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM = OAM Control protocol. And yes, there’s Fetch function defined.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B79D6DEeusaamb103erics_-- From nobody Wed Apr 9 04:59:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63791A0108 for ; Wed, 9 Apr 2014 04:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKS8afIcahfz for ; Wed, 9 Apr 2014 04:58:53 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D91A025A for ; Wed, 9 Apr 2014 04:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4647; q=dns/txt; s=iport; t=1397044730; x=1398254330; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=3d4AiBpHXzNRbL89xc3oQl5rufpZdhhvEWD7zIrNYkM=; b=mX5begJkPYts9V9/qsKf7NZKEyzYbAAlqnqkXA6Pb0dff8IWvvIZf0BE HjwQU78O9tf6hWuEQzsKlgHmlhvJZTvaBRrQODbu+1rpWgbUdfSUp5HPA rbI28nvbHHglDjf/dW8Cux/QQhMHm7wE+TRJy1VWpYpK1tJyZIuBVQGCX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFACM1RVOQ/khN/2dsb2JhbABZgkJEO4k+uySBIBZ0giUBAQEELUsBEAsYCRYPCQMCAQIBRQYBDAEHAQGHeA2vIJw6F45sB4Q4BJhegTWRDYMx X-IronPort-AV: E=Sophos; i="4.97,826,1389744000"; d="scan'208,217"; a="10129474" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 09 Apr 2014 11:58:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s39BwmOg023935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 11:58:48 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s39BwlWa011298; Wed, 9 Apr 2014 12:58:47 +0100 (BST) Message-ID: <534535F8.6090408@cisco.com> Date: Wed, 09 Apr 2014 12:58:48 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary="------------020302040006070005050002" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QQm2wCLmt5GrHWtMHMbCJ9g0M7Y Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:58:57 -0000 This is a multi-part message in MIME format. --------------020302040006070005050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/04/2014 17:04, Gregory Mirsky wrote: > > Dear Authors, et. al, > > I think this is interesting and timely proposal. But I think that this > is only part of bigger puzzle, part of MPLS PM Control Protocol. I > think that need to retrieve, fetch PM data is the most common in > one-way active PM. If that is the case, then there may be good reason > to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) > by IPPM WG. True, RFC 4656 has > two protocols in itself - Control and Test. And with RFC 6374 being > MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM > OAM Control protocol. And yes, there's Fetch function defined. > > Regards, > > Greg > Greg That is a very heavyweight approach to apply to RFC6374 compared to adding 4 bytes of data to the outgoing message to describe to the Responder how it should steer its response back. Stewart --------------020302040006070005050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/04/2014 17:04, Gregory Mirsky wrote:

Dear Authors, et. al,

I think this is interesting and timely proposal. But I think that this is only part of bigger puzzle, part of MPLS PM Control Protocol. I think that need to retrieve, fetch PM data is the most common in one-way active PM. If that is the case, then there may be good reason to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) by IPPM WG. True, RFC 4656 has two protocols in itself - Control and Test. And with RFC 6374 being MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM OAM Control protocol. And yes, there’s Fetch function defined.

 

                Regards,

                                Greg


Greg

That is a very heavyweight approach to apply to RFC6374 compared to adding 4 bytes of data to the outgoing message to describe to the Responder how it should steer its response back.

Stewart





--------------020302040006070005050002-- From nobody Wed Apr 9 05:59:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4A1A0299 for ; Wed, 9 Apr 2014 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPWU5h3t5t9l for ; Wed, 9 Apr 2014 05:58:55 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0461A028C for ; Wed, 9 Apr 2014 05:58:55 -0700 (PDT) X-AuditID: c6180641-b7f638e000005a82-df-534541263e2f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B4.F4.23170.62145435; Wed, 9 Apr 2014 14:46:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 08:58:53 -0400 From: Eric Gray To: "stbryant@cisco.com" , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: Ac9TQv9+alcZjjU8RACH2gnVvpbV4QAyZhMAAAb5dfA= Date: Wed, 9 Apr 2014 12:58:52 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> In-Reply-To: <534535F8.6090408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632A54011eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn666o2uwwSsNi0nf3jBb3Fq6ktXi 3NM5jA7MHlN+b2T1WLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgy2pYcYynY7lZxvPcsewPj Y5suRk4OCQETifaO3ewQtpjEhXvr2UBsIYGjjBKbHmZ1MXIB2csYJb7vXwWWYBPQkDh2Zy0j iC0icIxRYvNRjS5GDg5mAWWJU3dlQMLCAg4Sy+c+YoYocZT4sOAcK0iJiICVxOTFziBhFgEV idvLprOA2LwCvhIblv1jh1ibI9E5bybYJk4BTYldFyaxgtiMQKd9P7WGCcRmFhCXuPVkPhPE yQISS/acZ4awRSVePv7HCmErSuzrn84OUZ8vcXFfLzPELkGJkzOfsExgFJ2FZNQsJGWzkJRB xHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRoabGIExdkyCzXEH44JPlocY pTlYlMR5v7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAONU2gy1LZ99yxa7Snok/j3eZ le16z6gyb8G9ddO+c3k1eNhpn3l5dyH/s4cLtUT/3TXztNz1eKOPyvNyy73J9eseqNzoP7OY Nc9Q9m1/9wzrifZiNyQtpOZHMvnkZ2g5xFpvO5S01XGuZuqrbFNONjmx1TKhC97rGv9V3Mz4 WGLO929Lgxf+VWIpzkg01GIuKk4EAD6RzO5/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/338s857tmi1w8P6mlxMC-aCdhmc Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:58:59 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632A54011eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Well, you're adding 4 bytes to handle the case where the re= sponse is to be returned using UDP. This is in addition to the address information already= included in the message as defined by RFC 6374. It's certainly arguable that this new information does not = need to be carried in the test messages, assuming that there might be a control protocol used = instead. The question as to whether or not this is "heavy-weight" de= pends on how many additional ways one might envision returning the response. I suspect this is the "bigger puzzle" that Greg refers to..= . -- Eric From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 09, 2014 7:59 AM To: Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 08/04/2014 17:04, Gregory Mirsky wrote: Dear Authors, et. al, I think this is interesting and timely proposal. But I think that this is o= nly part of bigger puzzle, part of MPLS PM Control Protocol. I think that n= eed to retrieve, fetch PM data is the most common in one-way active PM. If = that is the case, then there may be good reason to look at RFC 4656 One-Way= Active Measurement Protocol (OWAMP) by= IPPM WG. True, RFC 4656 has two protocols in itself - Control and Test. An= d with RFC 6374 being MPLS PM OAM Test protocol we might look at RFC 4656 a= s example of PM OAM Control protocol. And yes, there's Fetch function defin= ed. Regards, Greg Greg That is a very heavyweight approach to apply to RFC6374 compared to adding = 4 bytes of data to the outgoing message to describe to the Responder how it= should steer its response back. Stewart --_000_48E1A67CB9CA044EADFEAB87D814BFF632A54011eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 

   &nbs= p;            Well, = you're adding 4 bytes to handle the case where the response is to be

returned using UDP.&nb= sp; This is in addition to the address information already included

in the message as defi= ned by RFC 6374.

 

   &nbs= p;            It's c= ertainly arguable that this new information does not need to be carried

in the test messages, = assuming that there might be a control protocol used instead.

 

   &nbs= p;            The qu= estion as to whether or not this is "heavy-weight" depends on how

many additional ways o= ne might envision returning the response.

 

   &nbs= p;            I susp= ect this is the "bigger puzzle" that Greg refers to…

 

--

Eric=

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, April 09, 2014 7:59 AM
To: Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org<= br> Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 08/04/2014 17:04, Gregory Mirsky wrote:

Dear Authors, et. al,

I think this is interesting and timely proposal. But= I think that this is only part of bigger puzzle, part of MPLS PM Control P= rotocol. I think that need to retrieve, fetch PM data is the most common in= one-way active PM. If that is the case, then there may be good reason to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) by IPPM WG. True, = RFC 4656 has two protocols in itself - Control and Test. And with RFC 6374 = being MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM = OAM Control protocol. And yes, there’s Fetch function defined.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=


Greg

That is a very heavyweight approach to apply to RFC6374 compared to adding = 4 bytes of data to the outgoing message to describe to the Responder how it= should steer its response back.

Stewart




--_000_48E1A67CB9CA044EADFEAB87D814BFF632A54011eusaamb107erics_-- From nobody Wed Apr 9 07:30:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E41A034A for ; Wed, 9 Apr 2014 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkAeJcsYJrhh for ; Wed, 9 Apr 2014 07:30:50 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC901A032F for ; Wed, 9 Apr 2014 07:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6202; q=dns/txt; s=iport; t=1397053849; x=1398263449; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=hWnqAWScVJBHR/ZdOjeoPwKKerxQuQQC+ktho78+jOw=; b=WP+uex+0W/upbjBjzXjgTG6AWU4IS467OHQWbxDFDgDw2WJYxYCkuyNZ CgnLp04gd/T4u+29aZ1zeYnRXgvEbT96Hvpoo245J7z/EFldKz8FZIuzv fbGwiiUwc8h3Cyc55DJ/5s6AkJMj6HRQw9o/0vyOi2SNg3pCnNanfBWoQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAMFYRVOQ/khR/2dsb2JhbABZgkJEiXm4FoMOgSAWdIIlAQEBAwEtOhEBBQsLGAkWDwkDAgECAUUGAQwBBwEBh3AIr3KcPReObAeEOASYXpJCgzE X-IronPort-AV: E=Sophos; i="4.97,826,1389744000"; d="scan'208,217"; a="10182814" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-4.cisco.com with ESMTP; 09 Apr 2014 14:30:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s39EUlrR020121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 14:30:47 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s39EUkvD020491; Wed, 9 Apr 2014 15:30:46 +0100 (BST) Message-ID: <53455996.9060407@cisco.com> Date: Wed, 09 Apr 2014 15:30:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Gray , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> Content-Type: multipart/alternative; boundary="------------030403000305090306080706" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/alajZm3pV1YgyHt2ATs1jPq1Cgg Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:30:51 -0000 This is a multi-part message in MIME format. --------------030403000305090306080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/04/2014 13:58, Eric Gray wrote: > > Stewart, > > Well, you're adding 4 bytes to handle the case where the response is to be > > returned using UDP. This is in addition to the address information > already included > > in the message as defined by RFC 6374. > Sure > > It's certainly arguable that this new information does not need to be > carried > > in the test messages, assuming that there might be a control protocol > used instead. > > The question as to whether or not this is "heavy-weight" depends on how > > many additional ways one might envision returning the response. > Well I am not convinced that you would want to send it over TCP. We already have a way to return it over MPLS - via LSP association or via the use of a first hop label encoded in the address field. That leaves UDP/IP which this draft deals with. Our first thoughts were BTW to request a UDP port, and we submitted a port request, but the port reviewers suggested that we should find a way to do it using dynamic ports, and that is what the draft describes. Stewart --------------030403000305090306080706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

                Well, you're adding 4 bytes to handle the case where the response is to be

returned using UDP.  This is in addition to the address information already included

in the message as defined by RFC 6374.

Sure

 

                It's certainly arguable that this new information does not need to be carried

in the test messages, assuming that there might be a control protocol used instead.


 

                The question as to whether or not this is "heavy-weight" depends on how

many additional ways one might envision returning the response.

Well I am not convinced that you would want to send it over TCP.
We already have a way to return it over MPLS - via LSP association
or via the use of a first hop label encoded in the address field.
That leaves UDP/IP which this draft deals with.

Our first thoughts were BTW to request a UDP port, and we submitted
a port request, but the port reviewers suggested that we should find a
way to do it using dynamic ports, and that is what the draft describes.

Stewart
--------------030403000305090306080706-- From nobody Wed Apr 9 14:18:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739F21A00EC for ; Wed, 9 Apr 2014 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTqnfoO1oLkX for ; Wed, 9 Apr 2014 14:18:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D702A1A024D for ; Wed, 9 Apr 2014 14:18:50 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-a3-5345b6e71e8d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 88.C2.02828.7E6B5435; Wed, 9 Apr 2014 23:08:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 17:18:48 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPU+saEJtSSVJZq0yj4ZIvBeRSWJsJx5zA Date: Wed, 9 Apr 2014 21:18:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B79F453@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> In-Reply-To: <534535F8.6090408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B79F453eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPlO7zba7BBp/+SlpM+vaG2eLW0pWs FueezmF0YPaY8nsjq8eSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlfFg0Q62gk/2Fb1/LjE1 MD4y62Lk5JAQMJHYcqKDCcIWk7hwbz1bFyMXh5DAUUaJpnMfGCGcZYwSK7susYJUsQkYSbzY 2MMOkhARmMYosf7aBqB2Dg5mAWWJU3dlQGqEBRwkls99xAxiiwg4SnxYcI4VwjaSWPvnKtg2 FgEViWePQeZwcvAK+EqcXnsArF5IIEeic95MNhCbU0BTYteFSWC9jEDXfT+1BqyXWUBc4taT +VBXC0gs2XOeGcIWlXj5+B8rhK0osa9/OjtEfb7EnGM3GSF2CUqcnPmEZQKj6Cwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtjECIy1YxJsujsY97y0 PMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG4IwkowWTN80sXPxs0qeO ZZdUupdzH/C9M4Nnn7j1nZ0zpv244Vay+EazQ8DviMsa71I7y11zd0wuSvBg8fG6dtbpwnSl dtaf9+YfcSz9l1ZwwtZ9mYinWvCqB0IH3b/wzp6fqff0hHgEc/e5iNM3pm9dkMjsNWXy6lvP l0jNM7i1fr+Y5RTvuUosxRmJhlrMRcWJAKRv/l+DAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iW_jI_FNgrRe6xbFSabEiczRAI0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:18:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B79F453eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, I agree with characterization of RFC 4656 and RFC 5357 in RFC 6374 in the l= ast paragraph of Introduction. But will point that both OWAMP and TWAMP RFC= s define two protocols: PM OAM control and PM OAM test protocols. I see RFC= 6374 as MPLS PM OAM test protocol, i.e. data plane, and think that there's= benefit in discussion of MPLS PM OAM control protocol. Regarding roles of Sender and Receiver/Responder. I think that proposal add= resses one-way performance measurement and then far end is Receiver, not Re= sponder. Fetching measurement data from Receiver may be viewed as operation= of PM OAM control protocol, not test protocol. Regards, Greg From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, April 09, 2014 4:59 AM To: Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 08/04/2014 17:04, Gregory Mirsky wrote: Dear Authors, et. al, I think this is interesting and timely proposal. But I think that this is o= nly part of bigger puzzle, part of MPLS PM Control Protocol. I think that n= eed to retrieve, fetch PM data is the most common in one-way active PM. If = that is the case, then there may be good reason to look at RFC 4656 One-Way= Active Measurement Protocol (OWAMP) by= IPPM WG. True, RFC 4656 has two protocols in itself - Control and Test. An= d with RFC 6374 being MPLS PM OAM Test protocol we might look at RFC 4656 a= s example of PM OAM Control protocol. And yes, there's Fetch function defin= ed. Regards, Greg Greg That is a very heavyweight approach to apply to RFC6374 compared to adding = 4 bytes of data to the outgoing message to describe to the Responder how it= should steer its response back. Stewart --_000_7347100B5761DC41A166AC17F22DF1121B79F453eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stewart,=

I agree with character= ization of RFC 4656 and RFC 5357 in RFC 6374 in the last paragraph of Intro= duction. But will point that both OWAMP and TWAMP RFCs define two protocols= : PM OAM control and PM OAM test protocols. I see RFC 6374 as MPLS PM OAM test protocol, i.e. data plane, and think th= at there’s benefit in discussion of MPLS PM OAM control protocol.

Regarding roles of Sen= der and Receiver/Responder. I think that proposal addresses one-way perform= ance measurement and then far end is Receiver, not Responder. Fetching meas= urement data from Receiver may be viewed as operation of PM OAM control protocol, not test protocol.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, April 09, 2014 4:59 AM
To: Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org<= br> Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

 

On 08/04/2014 17:04, Gregory Mirsky wrote:

Dear Authors, et. al,

I think this is interesting and timely proposal. But= I think that this is only part of bigger puzzle, part of MPLS PM Control P= rotocol. I think that need to retrieve, fetch PM data is the most common in= one-way active PM. If that is the case, then there may be good reason to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) by IPPM WG. True, = RFC 4656 has two protocols in itself - Control and Test. And with RFC 6374 = being MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM = OAM Control protocol. And yes, there’s Fetch function defined.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=


Greg

That is a very heavyweight approach to apply to RFC6374 compared to adding = 4 bytes of data to the outgoing message to describe to the Responder how it= should steer its response back.

Stewart




--_000_7347100B5761DC41A166AC17F22DF1121B79F453eusaamb103erics_-- From nobody Thu Apr 10 07:06:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577E01A02A5 for ; Thu, 10 Apr 2014 07:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkww_4yCqJPn for ; Thu, 10 Apr 2014 07:06:33 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E11ED1A029F for ; Thu, 10 Apr 2014 07:06:32 -0700 (PDT) X-AuditID: c6180641-b7f638e000005a82-0f-5346a2774b92 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.E4.23170.772A6435; Thu, 10 Apr 2014 15:53:59 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 10:06:21 -0400 From: Eric Gray To: "stbryant@cisco.com" , Gregory Mirsky , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: Ac9TQv9+alcZjjU8RACH2gnVvpbV4QAyZhMAAAb5dfD///KpAP/+t+LQ Date: Thu, 10 Apr 2014 14:06:20 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632A55453@eusaamb107.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <53455996.9060407@cisco.com> In-Reply-To: <53455996.9060407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632A55453eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXSPt275Irdgg8WL5C0mfXvDbHFr6UpW i3NP5zA6MHtM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyrj69TR7wSPriqWfnzM1 MDaadDFyckgImEh0buxggrDFJC7cW8/WxcjFISRwlFHi4b/5zBDOckaJlQfmMYNUsQloSBy7 s5YRxBYROMYosfmoRhcjBwezgLLEqbsyIGFhAQeJ5XMfMUOUOEp8WHCOFcJ2k5j3ZhkbiM0i oCqx98FhFhCbV8BXYk7TYajF5xklvuzfDNbAKaAp8WrbWbDrGIGu+35qDZjNLCAucevJfKir BSSW7DnPDGGLSrx8/I8VwlaSmLQUYjGzQL7E/32n2CCWCUqcnPmEZQKj6Cwko2YhKZuFpAwi riOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtzECIy1YxJsjjsYF3yyPMQo zcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGHVcLZ5Zc2nDkmdahL39XlrbN /e1U+Fb55A/3U5GR8m4nDTf8mOmy3EN13u2Vk/8cN9L5oXlveklh0fLzKkv/te6dOl1q44JN mdN4j5yTCe6Qdjob/ruhzfSUfp6A363w08c2zZuZccSASazhqchWj783FXreGpbGqq/YvK1u T3vb+aufbLboRSmxFGckGmoxFxUnAgDM48jCgwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-sqPwys2gmlt7lBPODFcnUNwLyI Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:06:35 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632A55453eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the port reviewers. A well-known port would have been a targe= t. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, April 09, 2014 10:31 AM To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.= org Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return Importance: High On 09/04/2014 13:58, Eric Gray wrote: Stewart, Well, you're adding 4 bytes to handle the case where the re= sponse is to be returned using UDP. This is in addition to the address information already= included in the message as defined by RFC 6374. Sure It's certainly arguable that this new information does not = need to be carried in the test messages, assuming that there might be a control protocol used = instead. The question as to whether or not this is "heavy-weight" de= pends on how many additional ways one might envision returning the response. Well I am not convinced that you would want to send it over TCP. We already have a way to return it over MPLS - via LSP association or via the use of a first hop label encoded in the address field. That leaves UDP/IP which this draft deals with. Our first thoughts were BTW to request a UDP port, and we submitted a port request, but the port reviewers suggested that we should find a way to do it using dynamic ports, and that is what the draft describes. Stewart --_000_48E1A67CB9CA044EADFEAB87D814BFF632A55453eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with the port = reviewers.  A well-known port would have been a target.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Wednesday, April 09, 2014 10:31 AM
To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tool= s.ietf.org
Cc: mpls@ietf.org
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
Importance: High

 

On 09/04/2014 13:58, Eric Gray wrote:

Stewart,

 

   &nbs= p;            Well, = you're adding 4 bytes to handle the case where the response is to be=

returned using UDP.&nb= sp; This is in addition to the address information already included<= o:p>

in the message as defi= ned by RFC 6374.

Sure

 

   &nbs= p;            It's c= ertainly arguable that this new information does not need to be carried

in the test messages, = assuming that there might be a control protocol used instead.



 

   &nbs= p;            The qu= estion as to whether or not this is "heavy-weight" depends on how

many additional ways o= ne might envision returning the response.

Well I am not convinced that you wou= ld want to send it over TCP.
We already have a way to return it over MPLS - via LSP association
or via the use of a first hop label encoded in the address field.
That leaves UDP/IP which this draft deals with.

Our first thoughts were BTW to request a UDP port, and we submitted
a port request, but the port reviewers suggested that we should find a
way to do it using dynamic ports, and that is what the draft describes.

Stewart

--_000_48E1A67CB9CA044EADFEAB87D814BFF632A55453eusaamb107erics_-- From nobody Thu Apr 10 09:21:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DCA1A0289 for ; Thu, 10 Apr 2014 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn60VXMcRFTt for ; Thu, 10 Apr 2014 09:21:48 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id DB04C1A02E0 for ; Thu, 10 Apr 2014 09:21:47 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGLjCd016982; Thu, 10 Apr 2014 17:21:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGLiYp016970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 17:21:45 +0100 From: "Adrian Farrel" To: References: <20140407070845.21053.96813.idtracker@ietfa.amsl.com> In-Reply-To: <20140407070845.21053.96813.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 17:21:45 +0100 Message-ID: <032601cf54d8$f78659c0$e6930d40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIb09UNl1WZcUhDeDuSzQmFxyU5h5pyCgfA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.000 X-TM-AS-Result: No--1.379-10.0-31-10 X-imss-scan-details: No--1.379-10.0-31-10 X-TMASE-MatchedRID: Uu3ZxWwlOVL8E3ZqfFM6yjYTypjB3iDVbuBXRGeJICadI/DikZ1UPLC/ bm0OVvm1GifkzUeg069O6CI7rIh2itcUNjoF7YuVIyvp1AQXH8vE+tSSoKDaKbV5fSMRD1zqcBd H+AtoPBohJnV8zCapXsEn4wci6rexfvoTjLA8+3L+OTCJja0mcmv34qCfZeB4InzOyTDR1usDfk WSPlPEf+fOVcxjDhcwEFY6gDmeXI0LbigRnpKlKZx+7GyJjhAUWGYdOJkYfSx71CGFcIdc/++L+ MHHnj8UMtJyBVjAtcvcq8op6LfK6EOiH4U8eWMLu84fsm48lvG2ge4DqEFqLUhV5Jb7qhfG5D9s mqVBD9yilnnVDECPd/H7AvsTxZMb7DafdH0+BI6wFMlIPaIBbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dlzZOjxYs_tBvBFEFrM20cZJ1xE Cc: mpls@ietf.org Subject: [mpls] FW: Last Call Expired: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 10 Apr 2014 16:21:49 -0000 Hi authors, I think you have a few minor points to look at coming out of Gen Art and = Rtg Dir reviews. Thanks, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker = Mail System > Sent: 07 April 2014 08:09 > To: iesg@ietf.org; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp-ping-ttl- > tlv@tools.ietf.org > Cc: iesg-secretary@ietf.org > Subject: Last Call Expired: >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. From nobody Thu Apr 10 09:33:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448C81A022A for ; Thu, 10 Apr 2014 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih2RD_PvWbWu for ; Thu, 10 Apr 2014 09:33:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17E1A02DA for ; Thu, 10 Apr 2014 09:33:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGXOAB025268; Thu, 10 Apr 2014 17:33:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGXN6j025257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 17:33:23 +0100 From: "Adrian Farrel" To: References: <20140409070804.21719.99786.idtracker@ietfa.amsl.com> In-Reply-To: <20140409070804.21719.99786.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 17:33:23 +0100 Message-ID: <033101cf54da$97f20ca0$c7d625e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdqCi7MFVemX8TwXUxa+813t/tNZvuY6gw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.000 X-TM-AS-Result: No--5.370-10.0-31-10 X-imss-scan-details: No--5.370-10.0-31-10 X-TMASE-MatchedRID: 9zTThWtzImszx9GDMr0HvzYTypjB3iDVbuBXRGeJICbFJnEpmt9OE3/2 0wqGUabSTWLw2jvbfpz8BlKEuOnqtFgFRUdvzHmkqsccGp7tYrE6Zh+V/s+OfbV5fSMRD1zqht0 RRlD9wRH3hMUSL9X4qrlyyqvvqzyXTQvN1Pi1FFDvVbHa5Rs8t4fGLZ++QpQz+OaK8BSkjbejxY yRBa/qJQPTK4qtAgwIEFY6gDmeXI0LbigRnpKlKSPzRlrdFGDwpphacCvbflDkoxFRJzwlCGfA5 zKPsONlvaNPfj7zXIpshqfJT8ezsw== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EB0KpsA6brz5b74M4uO3C00sb98 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call Expired: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 10 Apr 2014 16:33:34 -0000 Hi Eric, I think you have a few minor comments from IETF last call. Thanks, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker Mail System > Sent: 09 April 2014 08:08 > To: iesg@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-psc- > updates@tools.ietf.org > Cc: iesg-secretary@ietf.org > Subject: Last Call Expired: > > > Please DO NOT reply to this email. > > I-D: > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ > > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. From nobody Fri Apr 11 00:27:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74E41A0121 for ; Fri, 11 Apr 2014 00:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3n4Jaby-h8n for ; Fri, 11 Apr 2014 00:27:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 470241A0106 for ; Fri, 11 Apr 2014 00:27:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 21B2C18000C; Fri, 11 Apr 2014 00:27:14 -0700 (PDT) To: Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140411072714.21B2C18000C@rfc-editor.org> Date: Fri, 11 Apr 2014 00:27:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7TCHaTeo2FHf28zCDELS1u8nNQw Cc: mpls@ietf.org, bestman0729@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6371 (3956) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 07:27:28 -0000 The following errata report has been submitted for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3956 -------------------------------------- Type: Editorial Reported by: Liu Lin Section: 3.2 Original Text ------------- When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path. Corrected Text -------------- When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of no TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path. Notes ----- there is no TTL copying in short-pipe model Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 02:57:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA2D1A04A7 for ; Fri, 11 Apr 2014 02:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDLXAXAX18WW for ; Fri, 11 Apr 2014 02:57:19 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D2B571A03B6 for ; Fri, 11 Apr 2014 02:57:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3B9uWag028465; Fri, 11 Apr 2014 10:56:32 +0100 Received: from 950129200 ([149.254.182.58]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3B9uSnw028329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 10:56:29 +0100 From: "Adrian Farrel" To: References: <20140411072714.21B2C18000C@rfc-editor.org> In-Reply-To: <20140411072714.21B2C18000C@rfc-editor.org> Date: Fri, 11 Apr 2014 10:56:27 +0100 Message-ID: <009301cf556c$50f11700$f2d34500$@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: AQJq266mn2NRpbZ8INYQvsm4dejX8ZnVIB4Q Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.006 X-TM-AS-Result: No--10.738-10.0-31-10 X-imss-scan-details: No--10.738-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvgk7QoVXCbROOrxl/L0foaomdndBk1gfyXfUZT83lbkEMCS 2AMm1nQCIkJJMp14/2MPs83S68xkMBt/rO0PCXymgNMFzGNLElCFXSyuOiq3H45t/XRqktxJwua niM9QXy3tEQTZhWcluxPH6oJxm3jhAe7tDA1QuuH1RUeLAvHT8htPDNiPbNC6M/dZg2GSzOUFw6 pn+nZ+VnlKvYgwuaSuCwJtqSLMirfuHXE92Wk6HLrbxxduc6FPl0+NZmn0J7hrE1c4mB5Umgbgy 9blBBS5VcLRBrD+seKaVxA361Hfi0kjllSXrjtQOX/V8P8ail3InWAWA4yE6foA9r2LThYYKrau Xd3MZDXdR5sGC+05VVfXyGum/epYSfVO2LgcwUnH15totW+TrFqTVeFD5r+e Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bMVPtDTcWVsx4qvfwqz_OW7SQKg Cc: Italo.Busi@alcatel-lucent.com, rcallon@juniper.net, bestman0729@gmail.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6371 (3956) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Apr 2014 09:57:23 -0000 Working group, This definitely looks like a typo. I am inclined to think that better revised text would be... When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model, and may change for the uniform model if the SPME is not co-routed with the original path. Thus leaving out any mention of TTL copying. Thoughts? Thanks, Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 11 April 2014 08:27 > To: Italo.Busi@alcatel-lucent.com; david.i.allan@ericsson.com; > akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > rcallon@juniper.net > Cc: bestman0729@gmail.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6371 (3956) > > The following errata report has been submitted for RFC6371, > "Operations, Administration, and Maintenance Framework for MPLS-Based > Transport Networks". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3956 > > -------------------------------------- > Type: Editorial > Reported by: Liu Lin > > Section: 3.2 > > Original Text > ------------- > When an SPME is instantiated after the transport path has been > instantiated, the TTL distance to the MIPs may change for the > short-pipe model of TTL copying, and may change for the uniform > model if the SPME is not co-routed with the original path. > > Corrected Text > -------------- > When an SPME is instantiated after the transport path has been > instantiated, the TTL distance to the MIPs may change for the > short-pipe model of no TTL copying, and may change for the uniform > model if the SPME is not co-routed with the original path. > > Notes > ----- > there is no TTL copying in short-pipe model > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6371 (draft-ietf-mpls-tp-oam-framework-11) > -------------------------------------- > Title : Operations, Administration, and Maintenance Framework for MPLS- > Based Transport Networks > Publication Date : September 2011 > Author(s) : I. Busi, Ed., D. Allan, Ed. > Category : INFORMATIONAL > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Fri Apr 11 04:13:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC311A03EF for ; Fri, 11 Apr 2014 04:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNeHJWRwDRnh for ; Fri, 11 Apr 2014 04:13:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7CB1A02A8 for ; Fri, 11 Apr 2014 04:13:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 80CF918000C; Fri, 11 Apr 2014 04:13:14 -0700 (PDT) To: Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140411111314.80CF918000C@rfc-editor.org> Date: Fri, 11 Apr 2014 04:13:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kF1K0FzFQHopJrAouqPAPnV-mpE Cc: mpls@ietf.org, bestman0729@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6371 (3958) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 11:13:26 -0000 The following errata report has been submitted for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3958 -------------------------------------- Type: Editorial Reported by: Liu Lin Section: 3.3 Original Text ------------- Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4). Corrected Text -------------- Figure 3 describes four examples of per-interface MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4). Notes ----- per-interface Up MEPs ----> per-interface MEPs Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 08:53:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3AA1A06FC for ; Fri, 11 Apr 2014 08:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOmHDjHydU5c for ; Fri, 11 Apr 2014 08:53:26 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE61A06F7 for ; Fri, 11 Apr 2014 08:53:26 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-69-5347c182ec8d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 88.ED.05011.281C7435; Fri, 11 Apr 2014 12:18:43 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 11:53:24 -0400 From: David Allan I To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC6371 (3956) Thread-Index: AQHPVVd8MYHElmcNmkatFm4hp8D1zZsMcPuAgAAZHTA= Date: Fri, 11 Apr 2014 15:53:23 +0000 Message-ID: References: <20140411072714.21B2C18000C@rfc-editor.org> <009301cf556c$50f11700$f2d34500$@olddog.co.uk> In-Reply-To: <009301cf556c$50f11700$f2d34500$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPgm7zQfdgg7aFzBY/em4wW3x6eInZ 4tC/y+wWR7daWPybO4fZ4tbSlawWf1dcYbG4PaWJ0YHDo/XZXlaPKb83snrsnHWX3WPJkp9M HtebrrJ7rNi8ktFj1vQ2tgD2KC6blNSczLLUIn27BK6M3zva2QqOylR8ebKQqYHxpFgXIyeH hICJxIsVHxghbDGJC/fWs3UxcnEICRxllGi+eY4RwlnOKHFm5lVmkCo2AQOJPf+/gHWICARJ bHnUxgpSxCwwiUliV38PUIKDQ1jAXGLJYgmIGguJrsnr2EHCIgJWEjuW2IKEWQRUJVat28cC EuYV8JWYMT8WJCwkkCHxYsEkdhCbU8Ba4uKjb2wgNiPQbd9PrWECsZkFxCVuPZnPBHGzgMSS PeeZIWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVI0dpcWpZbrqRwSZGYDwek2DT3cG456XlIUYBDkYlHl6hmtwAIdbEsuLK 3EOM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg9P/0PPCF9olNfvEhM73u bdp4bcW14CeuygsaMuU05Cde7LipZhvY8M3D9gHH6tk/F2lph0252vKqU3eTz8unMyy8FyrH sKiZuh7d8vHJE76CuKa4L3tK7xT4KsifnWHcpRpeVJwt9PXCxqt1E485dZ70d6nS+6485/Wv 4krbH8dT2OoPnPN5o8RSnJFoqMVcVJwIAMLWdXqoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zpyCSQfkqJmPDYd7MhGZwtuojGU Cc: "Italo.Busi@alcatel-lucent.com" , "rcallon@juniper.net" , "bestman0729@gmail.com" Subject: Re: [mpls] [Editorial Errata Reported] RFC6371 (3956) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:53:31 -0000 Hi Adrian: I agree that your proposal circumvents any confusion, but frankly we had no= problem with the original text precisely because the mode of TTL copying f= or short pipe was "no copying". So there was an implied "this is why" in th= e choice of words. But as that has been called out as a problem, your proposal is the best way= to address it... Cheers Dave -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, April 11, 2014 2:56 AM To: mpls@ietf.org Cc: Italo.Busi@alcatel-lucent.com; David Allan I; akatlas@gmail.com; loa@pi= .nu; swallow@cisco.com; rcallon@juniper.net; bestman0729@gmail.com Subject: RE: [Editorial Errata Reported] RFC6371 (3956) Working group, This definitely looks like a typo. I am inclined to think that better revised text would be... When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model, and may change for the uniform model if the SPME is not co-routed with the original path. Thus leaving out any mention of TTL copying. Thoughts? Thanks, Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 11 April 2014 08:27 > To: Italo.Busi@alcatel-lucent.com; david.i.allan@ericsson.com;=20 > akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com;=20 > rcallon@juniper.net > Cc: bestman0729@gmail.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6371 (3956) >=20 > The following errata report has been submitted for RFC6371,=20 > "Operations, Administration, and Maintenance Framework for MPLS-Based=20 > Transport Networks". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6371&eid=3D3956 >=20 > -------------------------------------- > Type: Editorial > Reported by: Liu Lin >=20 > Section: 3.2 >=20 > Original Text > ------------- > When an SPME is instantiated after the transport path has been > instantiated, the TTL distance to the MIPs may change for the > short-pipe model of TTL copying, and may change for the uniform > model if the SPME is not co-routed with the original path. >=20 > Corrected Text > -------------- > When an SPME is instantiated after the transport path has been > instantiated, the TTL distance to the MIPs may change for the > short-pipe model of no TTL copying, and may change for the uniform > model if the SPME is not co-routed with the original path. >=20 > Notes > ----- > there is no TTL copying in short-pipe model >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6371 (draft-ietf-mpls-tp-oam-framework-11) > -------------------------------------- > Title : Operations, Administration, and Maintenance Framewo= rk for MPLS- > Based Transport Networks > Publication Date : September 2011 > Author(s) : I. Busi, Ed., D. Allan, Ed. > Category : INFORMATIONAL > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Fri Apr 11 09:03:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B71A06E3; Fri, 11 Apr 2014 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8gQ08WsRw6U; Fri, 11 Apr 2014 09:03:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id CE0101A020D; Fri, 11 Apr 2014 09:03:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94A1B18000D; Fri, 11 Apr 2014 09:03:25 -0700 (PDT) To: bestman0729@gmail.com, Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140411160325.94A1B18000D@rfc-editor.org> Date: Fri, 11 Apr 2014 09:03:25 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Xlw7Dw1qghRH7ozkV2Sy9Ez7k7Q Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Held for Document Update] RFC6371 (3958) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:03:41 -0000 The following errata report has been held for document update for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3958 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Liu Lin Date Reported: 2014-04-11 Held by: Adrian Farrel (IESG) Section: 3.3 Original Text ------------- Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4). Corrected Text -------------- Figure 3 describes four examples of per-interface MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4). Notes ----- per-interface Up MEPs ----> per-interface MEPs The four instances listed include Up and Down MEPs, so the text should be more general. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 09:08:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8341A04A1; Fri, 11 Apr 2014 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvthfdsBdJii; Fri, 11 Apr 2014 09:07:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB001A0285; Fri, 11 Apr 2014 09:07:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5F0FB18000D; Fri, 11 Apr 2014 09:07:33 -0700 (PDT) To: bestman0729@gmail.com, Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140411160733.5F0FB18000D@rfc-editor.org> Date: Fri, 11 Apr 2014 09:07:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iigAzDylS5QpW7pfQ36T-l79hPg Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC6371 (3956) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:07:50 -0000 The following errata report has been verified for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3956 -------------------------------------- Status: Verified Type: Editorial Reported by: Liu Lin Date Reported: 2014-04-10 Verified by: Adrian Farrel (IESG) Section: 3.2 Original Text ------------- When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path. Corrected Text -------------- When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model, and may change for the uniform model if the SPME is not co-routed with the original path. Notes ----- The original report notes that there is no TTL copying in short-pipe model and states confusion arising from the text. The suggestion was to change it to: When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of no TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path. The authors point out that the TTL copying mode in short-pipe is "no copying". This is true, but leaves some potential confusion in the text. The corrected text removes all mention of TTL copying (which is not relevant in this case). -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 11:42:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9931A034A for ; Fri, 11 Apr 2014 11:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REE7NFK0efJz for ; Fri, 11 Apr 2014 11:42:50 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0A1A02D6 for ; Fri, 11 Apr 2014 11:42:50 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so6395069qcx.13 for ; Fri, 11 Apr 2014 11:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1biEfkyoCyLmMAn+ta3pIt2DBnC/m0dtQdxzOAE7sa0=; b=ZEWuwI7UvQu+JrtstqKSpECc7V0550s6AY8jfZ0REWGbhFy+fPEANhAaBk55/4WQj/ 1xO8zFE7plw8RnzEzs7nL5ob9jln750tOuq7BGPMemKrpjncYK91uA4nLFhaeHfwlfkC oFT0r4a2gMoL2jJqX6JntPB0WfFePQnn5FV1vFUSr/oBEuYs6w1DL7W387v0mls9hZa8 FqG2qQ4GYMVaBItWdi5xpxejC+hcrOFj04DLV6xVNbvO4nn2AAsXxdfQ4XYrMtvY4uBB cQKXVrPi81ouZ7HOSAEmo+BcNeBplVOJKb/gRkSnudz8Wmgdg9bM/aEfr5dSzm86hCt8 wLrQ== MIME-Version: 1.0 X-Received: by 10.224.14.14 with SMTP id e14mr1050473qaa.80.1397241769027; Fri, 11 Apr 2014 11:42:49 -0700 (PDT) Received: by 10.96.134.132 with HTTP; Fri, 11 Apr 2014 11:42:48 -0700 (PDT) In-Reply-To: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> Date: Fri, 11 Apr 2014 11:42:48 -0700 Message-ID: From: Sam Aldrin To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=60eb69fdf4ef4eeb4b04f6c8b337 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/E2uiqNUpxyCaxxTuNKWkgJ0cW8Q Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:42:56 -0000 --60eb69fdf4ef4eeb4b04f6c8b337 Content-Type: text/plain; charset=ISO-8859-1 [Better late than never] Thank you Nobo, for replying to my comments with %sam. See inline for my comments. Removed ones which I considered were answered, for readability sake. Hope you don't mind it. -sam > > - In sec 2 > > Some return path(s) are more preferred than others, but preferred > > cannot be used in all cases. Thus implementations are required to > > compute when preferred return path encoding can and cannot be used, > > and that computation is becoming more and more difficult. > > > > As response code is initiated by the initiator, user in this case, the > preferred return path is for UI implementation and not the actual LSP ping > functionality. Which/what part of implementation are you referring to? > > > > [NOBO] Ok, this below text more clearer? > > > > [snip] > > Operators prefer some return path(s) over others for specific LSP > > types. To accommodate this, implementations may default to operator > > preferred return path (or allow default return path to be configured) > > for specific operation. However, if the sender of MPLS echo request > > knew that "preferred" return path will not be available at intended > > target node, then it is not very beneficial to specify Reply Mode > > corresponding to "preferred" return path (i.e. sender of MPLS echo > > request will not receive MPLS echo reply in the success case). What > > would be beneficial, for a given operation, is for the sender of MPLS > > echo request to determine which return path(s) can and cannot be used > > ahead of time. Thus implementations often compute when preferred > > return path encoding can and cannot be used, and that computation is > > becoming more and more difficult. > > [snip] > %sam - Looks ok, but don't mind removing last sentence. :D > > > - Sec 2 > > This document adds one Reply Mode to describe reverse LSP, and one > > optional TLV to describe ordered list of reply modes. Based on > > operational needs, the TLV can describe multiple Reply Mode values in > > preferred order to allow responder to use first available Reply Mode > > from the list. This eliminates the need for initiator to compute, or > > sometimes "guess", the "default" return path encoding. And that will > > result in simplified implementations across vendors, and result in > > improved usability to fit operational needs. > > > > > - Sec 3.1, how is this different from RFC 7110? If same, please call it > out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the > same. If different to the RFC, I would like to see those details here. > > > > [NOBO] Reply Mode introduced by RFC7110 specifies that MPLS echo reply is > to be sent on LSP corresponding to FEC described in Reply Path TLV. > Although Reply Path TLV has added B flag to indicate "reverse LSP", Reply > Mode 5 still require Reply Path TLV with B flag to describe "reverse LSP". > Reply Path TLV is good when wanting to use specific LSP as return path, but > it's more difficult than necessary when wanting to just use reverse LSP. I > will add some texts to clarify this. > %sam - Are you saying that reply mode 5 with B bit set is not solving the problem or not optimal (because a TLV is being added?). The text in RFC7110 says, "B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP. If B bit is set, there is no need to carry any specific reply path sub- TLVs, and when received, the sub-TLVs SHOULD be ignored." As author of RFC7110 is also author of this draft, it would be good to clarification. From what I see, this new reply mode proposed in this draft is already addressed in RFC7110. If the new reply mode adds optimization to the existing solution, why to add a new mode? I'll add more to this. Even with RFC7110 or this draft, there is no way to know the support for these new reply modes, when looking from the source node. So, if the request is received with this new reply mode, (depending on implementation) the request may get dropped? %sam - For RFC4379bis? In RFC4379 sec 4.5, it says "If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [LABEL-STACK ]).". > > > General comments: > > > > - I believe this new enhancement will only provide a degree of variance to > RFC4379, where the response could be received back at initiator. Here is why > > 1. If the response is not received back at source, even with the new TLV, > one cannot conclude that LSP is broken. > > > > [NOBO] It depends on how you look at this. With this new TLV, it is > difficult to figure out if lack of response is due to something broken or > responder didn't have the return path specified. With this new TLV, list of > return paths are provided. Thus lack of response means either something is > broken or none of the return paths specified were available at responder ... > which, if return path list contained everything, then it can only mean > something is broken. > %sam - the assumption you are making here is, the responding node is broken locally. If the reply path in the middle is broken, this will solution not help either, because responding node picks the top reply mode and sends it. It doesn't know to pick #2 or later in the list, because #1 response mode didn't make it to source. Is the scope limited to the ability of responding node to reply, hence providing multiple reply mode options? Thanks again -sam > > > > > > > --60eb69fdf4ef4eeb4b04f6c8b337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Better late than never]

Thank you Nobo= , for replying to my comments with %sam.
See inline for my commen= ts. Removed ones which I considered were answered, for readability sake. Ho= pe you don't mind it.

-sam



 

- In sec 2= 

Some return path(s) =
are more preferred than others, but preferred
   cannot =
be used in all cases.  Thus implementations are required to<=
/u>
   compute=
 when preferred return path encoding can and cannot be used,<=
/span>
   and tha=
t computation is becoming more and more difficult.



 

As response code is initiated b= y the initiator, user in this case, the preferred return path is for UI imp= lementation and not the actual LSP ping functionality. Which/what part of i= mplementation are you referring to?

 

[NOBO] Ok, this below t= ext more clearer?

 

[snip]

   Operators prefer some return path(s) over others = for specific LSP

   types.  To accommodate this, implementations= may default to operator

   preferred return path (or allow default return pa= th to be configured)

   for specific operation.  However, if the sen= der of MPLS echo request

   knew that "preferred" return path will = not be available at intended

   target node, then it is not very beneficial to sp= ecify Reply Mode

   corresponding to "preferred" return pat= h (i.e. sender of MPLS echo

   request will not receive MPLS echo reply in the s= uccess case).  What

   would be beneficial, for a given operation, is fo= r the sender of MPLS

   echo request to determine which return path(s) ca= n and cannot be used

   ahead of time.  Thus implementations often c= ompute when preferred

   return path encoding can and cannot be used, and = that computation is

   becoming more and more difficult.

[snip]

=
%sam - Looks ok, but don= 9;t mind removing last sentence. :D

 

- Sec 2 

This document adds o=
ne Reply Mode to describe reverse LSP, and one
   optiona=
l TLV to describe ordered list of reply modes.  Based on=

   operati=
onal needs, the TLV can describe multiple Reply Mode values in
   preferr=
ed order to allow responder to use first available Reply Mode=

   from th=
e list.  This eliminates the need for initiator to compute, or<=
u>
   sometim=
es "guess", the "default" return path encoding.  A=
nd that will
   result =
in simplified implementations across vendors, and result in
   improve=
d usability to fit operational needs.

 


- Sec 3.1, how is this differen= t from RFC 7110? If same, please call it out here and remove TBD1 as sec 4.= 1 of RFC7110 added reply mode 5 for the same. If different to the RFC, I wo= uld like to see those details here.

=  

[NOBO] Reply Mode introduced = by RFC7110 specifies that MPLS echo reply is to be sent on LSP correspondin= g to FEC described in Reply Path TLV. Although Reply Path TLV has added B flag to indicate &l= dquo;reverse LSP”, Reply Mode 5 still require Reply Path TLV with B f= lag to describe “reverse LSP”. Reply Path TLV is good when want= ing to use specific LSP as return path, but it’s more difficult than necessary when wanting to just use reverse LSP. I will add some texts= to clarify this.

%sam - Are you saying that reply mode 5 with B bit set is not solvin= g the problem or not optimal (because a TLV is being added?). The text in R= FC7110 says, "B (Bidire= ctional): the return path is required to follow the
         reverse direction of the tested bidirectional LSP. =
 If B bit is
         set, there is no need to carry any specific reply path sub- <=
/pre>
    &nbs=
p;    TLVs, and when received, the sub-TLVs SHOULD be ignored.&qu=
ot;
As author of RFC7110 is also author of this draft, it =
would be good to clarification. From what I see, this new reply mode  =
proposed in this draft is already addressed in RFC7110. If the new reply mo=
de adds optimization to the existing solution, why to add a new mode?



I'll add more to this. Even with RFC7110 or this dr=
aft, there is no way to know the support for these new reply modes, when lo=
oking from the source node. So, if the request is received with this new re=
ply mode, (depending on implementation) the request may get dropped?



%sam - For RFC4379bis? In RFC4379 sec 4.5, it says &quo=
t;If the reply is sent over =
an LSP, the
   topmost label MUST in this case be the Router Alert label (1) (see
   [LABEL-STACK]).". 









 





General comments:=







 






- I believe this new enhancemen=
t will only provide a degree of variance to RFC4379, where the response cou=
ld be received back at initiator. Here is why






1. If=
 the response is not received back at source, even with the new TLV, one ca=
nnot conclude that LSP is broken. 


 

[NOBO] It depends on ho=
w you look at this. With this new TLV, it is difficult to figure out if lac=
k of response is due
 to something broken or responder didn’t have the return path specifi=
ed. With this new TLV, list of return paths are provided. Thus lack of resp=
onse means either something is broken or none of the return paths specified=
 were available at responder … which,
 if return path list contained everything, then it can only mean something =
is broken.
=
%sam - the assumption you are making here is, the responding node is broken=
 locally. If the reply path in the middle is broken, this will solution not=
 help either, because responding node picks the top reply mode and sends it=
. It doesn't know to pick #2 or later in the list, because #1 response =
mode didn't make it to source. 


Is the scope limited to the ability of responding node to reply, hence=
 providing multiple reply mode options? 

Than=
ks again
-sam






 








 

--60eb69fdf4ef4eeb4b04f6c8b337-- From nobody Fri Apr 11 19:38:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF71A031B for ; Fri, 11 Apr 2014 19:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLVOqX6Wb29f for ; Fri, 11 Apr 2014 19:38:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C8F9C1A0010 for ; Fri, 11 Apr 2014 19:38:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D96E418000D; Fri, 11 Apr 2014 19:37:56 -0700 (PDT) To: Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140412023756.D96E418000D@rfc-editor.org> Date: Fri, 11 Apr 2014 19:37:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IThKM9ULTmRCHydWSbXm3D7Onxo Cc: mpls@ietf.org, bestman0729@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6371 (3961) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 02:38:11 -0000 The following errata report has been submitted for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3961 -------------------------------------- Type: Technical Reported by: Liu Lin Section: 3.7 Original Text ------------- This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at a shorter distance. Corrected Text -------------- This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at the same TTL distance of the target MIP or a shorter distance. Notes ----- The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 11 22:28:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EDF1A0180 for ; Fri, 11 Apr 2014 22:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FucBwQcc3RYJ for ; Fri, 11 Apr 2014 22:28:56 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0A76A1A0079 for ; Fri, 11 Apr 2014 22:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=754; q=dns/txt; s=iport; t=1397280534; x=1398490134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L8i3KDC0gfzwE31UPKXQ92NjqQOHt8rmjYpT/zgfXWk=; b=AEV6+C0a4PNDRISLQVswmyldDt/jEH8YYyD18MtcLHLvUpDGIdN8z+Wf j0mHtfMvHTacxSDQRm25Hd8qRHn2kKnhBDRT3GoAuaFaaWTcp6iyEEsdw FgBEnTQaoWrAY1j4RykszWoOeDF97z6f1TAQd45M9ouK/efiO8oUeb2Pe I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAATOSFOtJV2c/2dsb2JhbABYgwasBJg0gRsWdIIlAQEBAwE6PwULAgEIGB0BEDIlAgQOBYd0CMtPF445MweDJIEUAQOYYJJCgzE X-IronPort-AV: E=Sophos;i="4.97,847,1389744000"; d="scan'208";a="35190381" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 12 Apr 2014 05:28:54 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3C5SsD3003663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Apr 2014 05:28:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.175]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sat, 12 Apr 2014 00:28:53 -0500 From: "Stewart Bryant (stbryant)" To: RFC Errata System Thread-Topic: [mpls] [Technical Errata Reported] RFC6371 (3961) Thread-Index: AQHPVfhE5xGTT1AFAU2a2n+JwK/shZsNdD2b Date: Sat, 12 Apr 2014 05:28:52 +0000 Message-ID: References: <20140412023756.D96E418000D@rfc-editor.org> In-Reply-To: <20140412023756.D96E418000D@rfc-editor.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1NB1GHrCUzuLMXkUn74BYQXZWjA Cc: "mpls@ietf.org" , "Italo.Busi@alcatel-lucent.com" , "bestman0729@gmail.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Technical Errata Reported] RFC6371 (3961) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 05:28:57 -0000 Better replacement text would be: > This packet > will be delivered by the forwarding plane to all=20 > nodes at the same TTL distance as the target MIP and to any leaf > that is located at a shorter distance. This is shorter than the proposed replacement text. It works because all nodes is the union of all MIPs and all leaves at the T= TL distance. Stewart Sent from my iPad > On 12 Apr 2014, at 03:38, "RFC Errata System" = wrote: >=20 >=20 > Original Text > ------------- > This packet > will be delivered by the forwarding plane to all intermediate > nodes at the same TTL distance of the target MIP and to any leaf > that is located at a shorter distance. From nobody Sat Apr 12 07:02:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E51A017E; Sat, 12 Apr 2014 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPCpj1lqog7b; Sat, 12 Apr 2014 07:02:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D3B621A017C; Sat, 12 Apr 2014 07:02:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 60E0018000D; Sat, 12 Apr 2014 07:02:24 -0700 (PDT) To: bestman0729@gmail.com, Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140412140224.60E0018000D@rfc-editor.org> Date: Sat, 12 Apr 2014 07:02:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XMsGgYSeUOcTz8ZgrzzGyVlkGOc Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Held for Document Update] RFC6371 (3961) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 14:02:40 -0000 The following errata report has been held for document update for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3961 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Liu Lin Date Reported: 2014-04-11 Held by: Adrian Farrel (IESG) Section: 3.7 Original Text ------------- This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at a shorter distance. Corrected Text -------------- This packet will be delivered by the forwarding plane to all nodes at the same TTL distance as the target MIP and to any leaf that is located at a shorter distance. Notes ----- The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Apr 13 07:01:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C191A02C5 for ; Sun, 13 Apr 2014 07:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.072 X-Spam-Level: X-Spam-Status: No, score=-112.072 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ2f2WxqSIq2 for ; Sun, 13 Apr 2014 07:01:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C26791A0165 for ; Sun, 13 Apr 2014 07:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36979; q=dns/txt; s=iport; t=1397397684; x=1398607284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SPfwQXEYi7Q0NaARgY/gyEQV6vFo/wSthFbQCK0dlQY=; b=GSvAJCo1zr99t+Xuita2Jt7rX5/2YNIaMgUzuiwNWxkXO2cjaq0ehDbs +UD4QYopZy7aa5raEbJIwomQTWIyc6jrKnIH7wg21tR++l99HHLEQhbRY /W31Iky+Wt2KziKBzlqIQJFBFOr3/tl24ep9lkFsgqLMlfCcan2JISTQX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GAPGXSlOtJV2d/2dsb2JhbABYgkIjITtXujmIdIEZFnSCJQEBAQQtTBACAQgRBAEBCxYBBgchERQJCAIEDgUIE4dNAxEBDMMyDYZjF4lGgw+BQScxBgGDJIEUBJR0gX+DJIs+hU+DMYFpQg X-IronPort-AV: E=Sophos;i="4.97,851,1389744000"; d="scan'208,217";a="317168700" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 13 Apr 2014 14:01:22 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3DE1Mxq005787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 14:01:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 09:01:21 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: AQHPVbXZJ6LNrNHPL0mkFF9N1N/BxJsPiXbA Date: Sun, 13 Apr 2014 14:01:21 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.100] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E1072FBxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JE2Sg7iCV22_P9VJuSlOUrPbO3Q Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 14:01:31 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E1072FBxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, Please see in-line with [NOBO2]. From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Friday, April 11, 2014 2:43 PM To: Nobo Akiya (nobo) Cc: Mach Chen; mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-simple@t= ools.ietf.org; Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-= mode-simple [Better late than never] [NOBO2] Certainly, and thank you! Thank you Nobo, for replying to my comments with %sam. See inline for my comments. Removed ones which I considered were answered, = for readability sake. Hope you don't mind it. [NOBO2] Don't mind at all. -sam - In sec 2 Some return path(s) are more preferred than others, but preferred cannot be used in all cases. Thus implementations are required to compute when preferred return path encoding can and cannot be used, and that computation is becoming more and more difficult. As response code is initiated by the initiator, user in this case, the pref= erred return path is for UI implementation and not the actual LSP ping func= tionality. Which/what part of implementation are you referring to? [NOBO] Ok, this below text more clearer? [snip] Operators prefer some return path(s) over others for specific LSP types. To accommodate this, implementations may default to operator preferred return path (or allow default return path to be configured) for specific operation. However, if the sender of MPLS echo request knew that "preferred" return path will not be available at intended target node, then it is not very beneficial to specify Reply Mode corresponding to "preferred" return path (i.e. sender of MPLS echo request will not receive MPLS echo reply in the success case). What would be beneficial, for a given operation, is for the sender of MPLS echo request to determine which return path(s) can and cannot be used ahead of time. Thus implementations often compute when preferred return path encoding can and cannot be used, and that computation is becoming more and more difficult. [snip] %sam - Looks ok, but don't mind removing last sentence. :D [NOBO2] That's true. Last sentence removed (from -02 candidate). - Sec 2 This document adds one Reply Mode to describe reverse LSP, and one optional TLV to describe ordered list of reply modes. Based on operational needs, the TLV can describe multiple Reply Mode values in preferred order to allow responder to use first available Reply Mode from the list. This eliminates the need for initiator to compute, or sometimes "guess", the "default" return path encoding. And that will result in simplified implementations across vendors, and result in improved usability to fit operational needs. - Sec 3.1, how is this different from RFC 7110? If same, please call it out= here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the same= . If different to the RFC, I would like to see those details here. [NOBO] Reply Mode introduced by RFC7110 specifies that MPLS echo reply is t= o be sent on LSP corresponding to FEC described in Reply Path TLV. Although= Reply Path TLV has added B flag to indicate "reverse LSP", Reply Mode 5 st= ill require Reply Path TLV with B flag to describe "reverse LSP". Reply Pat= h TLV is good when wanting to use specific LSP as return path, but it's mor= e difficult than necessary when wanting to just use reverse LSP. I will add= some texts to clarify this. %sam - Are you saying that reply mode 5 with B bit set is not solving the p= roblem or not optimal (because a TLV is being added?). The text in RFC7110 = says, "B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP. If B bit is set, there is no need to carry any specific reply path sub- TLVs, and when received, the sub-TLVs SHOULD be ignored." As author of RFC7110 is also author of this draft, it would be good to clar= ification. From what I see, this new reply mode proposed in this draft is = already addressed in RFC7110. If the new reply mode adds optimization to th= e existing solution, why to add a new mode? [NOBO2] Reply mode 5 requires a TLV, whether or not B bit is used. The text= from RFC7110 above describes, further sub-TLV is not required when B bit i= s used. So yes, one aspect of this draft is optimization on how "Reply Mode= =3D Reverse LSP" is described (i.e. Reverse LSP Reply Mode value that does= not require any TLVs nor sub-TLVs). I'll add more to this. Even with RFC7110 or this draft, there is no way to = know the support for these new reply modes, when looking from the source no= de. So, if the request is received with this new reply mode, (depending on = implementation) the request may get dropped? [NOBO2] Exactly. This is why Reply Mode Order TLV optional TLV is beneficia= l. Implementations can continue to use currently used/computed "Reply Mode"= value in the MPLS echo request. Reply Mode Order TLV can provide ordered l= ist of Reply Modes, which can be used by the responder if responder underst= ands this draft (i.e. If not, responder will just use Reply Mode in receive= d MPLS echo request). And because responder is to set Reply Mode used (if c= hosen from Reply Mode Order TLV) in the Reply Mode field of MPLS echo repl= y, initiator knows what happened at the responder. This provide a clean tra= nsition. %sam - For RFC4379bis? In RFC4379 sec 4.5, it says "If the reply is sent ov= er an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [LABEL-STACK]).". [NOBO2] I agree. I think mandating RA label here is questionable. We should= list this up as a topic to follow up for bis. General comments: - I believe this new enhancement will only provide a degree of variance to = RFC4379, where the response could be received back at initiator. Here is wh= y 1. If the response is not received back at source, even with the new TLV, o= ne cannot conclude that LSP is broken. [NOBO] It depends on how you look at this. With this new TLV, it is difficu= lt to figure out if lack of response is due to something broken or responde= r didn't have the return path specified. With this new TLV, list of return = paths are provided. Thus lack of response means either something is broken = or none of the return paths specified were available at responder ... which= , if return path list contained everything, then it can only mean something= is broken. %sam - the assumption you are making here is, the responding node is broken= locally. If the reply path in the middle is broken, this will solution not= help either, because responding node picks the top reply mode and sends it= . It doesn't know to pick #2 or later in the list, because #1 response mode= didn't make it to source. Is the scope limited to the ability of responding node to reply, hence prov= iding multiple reply mode options? [NOBO2] You are absolutely right that responder will not have any knowledge= of what is available in transit node in the reverse direction. I think we = are discussing glass is half full or empty though. Let me give one scenario= . There's associated LSP between node A and node B. Let's say ping is done fr= om node A with just Reverse LSP Reply Mode. In the forward direction, a tra= nsit node X incorrectly forwards the packet to node Y. Node Y is not part o= f this LSP, thus node Y will obviously not have reverse LSP. In this case, = ping will just timeout (i.e. node Y cannot send MPLS echo reply due to lack= of reverse LSP). However, it is very beneficial for node A to still get "f= ec mismatch" error from node Y for diagnostic purpose, and that will be pos= sible if node Y can respond with IP path. In this case, Reply Mode Order T= LV can have (1. Reverse LSP, 2. IP) which satisfies operator needs whilst s= till providing good diagnostic in case of failure. This draft is indeed a small enhancements, but adds value to both simplicit= y and diagnostic aspect. Hopefully I was successful in swaying you in the d= irection of "supportive", let me know? -Nobo Thanks again -sam --_000_CECE764681BE964CBE1DFF78F3CDD3941E1072FBxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,=

 <= /p>

Please see in-line with [= NOBO2].

 <= /p>

From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]
Sent: Friday, April 11, 2014 2:43 PM
To: Nobo Akiya (nobo)
Cc: Mach Chen; mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode-s= imple@tools.ietf.org; Curtis Villamizar
Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping= -reply-mode-simple

 

[Better late than never]

 

[NOBO2] Certainly, and th= ank you!

 <= /p>

Thank you Nobo, for replying to my comments with %sa= m.

See inline for my comments. Removed ones which I con= sidered were answered, for readability sake. Hope you don't mind it.

 

[NOBO2] Don’t mind = at all.

 <= /p>

-sam

 

 

 =

- In sec 2

Some return path(s) =
are more preferred than others, but preferred
   cannot =
be used in all cases.  Thus implementations are required to
   compute=
 when preferred return path encoding can and cannot be used,
   and tha=
t computation is becoming more and more difficult.

 

As response code is initiated by the initiato= r, user in this case, the preferred return path is for UI implementation an= d not the actual LSP ping functionality. Which/what part of implementation are you referring to?<= /p>

 =

[NOBO] Ok, this below te= xt more clearer?

 =

[snip]=

   Operators prefer some return path(s) over others for specif= ic LSP

   types.  To accommodate this, implementations may defau= lt to operator

   preferred return path (or allow default return path to be c= onfigured)

   for specific operation.  However, if the sender of MPL= S echo request

   knew that "preferred" return path will not be ava= ilable at intended

   target node, then it is not very beneficial to specify Repl= y Mode

   corresponding to "preferred" return path (i.e. se= nder of MPLS echo

   request will not receive MPLS echo reply in the success cas= e).  What

   would be beneficial, for a given operation, is for the send= er of MPLS

   echo request to determine which return path(s) can and cann= ot be used

   ahead of time.  Thus implementations often compute whe= n preferred

   return path encoding can and cannot be used, and that compu= tation is

   becoming more and more difficult.

[snip]=

%sam - Looks ok, but don't mind removing last senten= ce. :D

 <= /p>

[NOBO2] That’s true= . Last sentence removed (from -02 candidate).

 =

- Sec 2

This document adds o=
ne Reply Mode to describe reverse LSP, and one
   optiona=
l TLV to describe ordered list of reply modes.  Based on
   operati=
onal needs, the TLV can describe multiple Reply Mode values in<=
/o:p>
   preferr=
ed order to allow responder to use first available Reply Mode
   from th=
e list.  This eliminates the need for initiator to compute, or<=
o:p>
   sometim=
es "guess", the "default" return path encoding.  A=
nd that will
   result =
in simplified implementations across vendors, and result in
   improve=
d usability to fit operational needs.

 

 

- Sec 3.1, how is this different from RFC 711= 0? If same, please call it out here and remove TBD1 as sec 4.1 of RFC7110 a= dded reply mode 5 for the same. If different to the RFC, I would like to see those details here.

 

[NOBO] Reply Mode introd= uced by RFC7110 specifies that MPLS echo reply is to be sent on LSP corresponding to FEC described in Reply Path TLV. Although Reply Pa= th TLV has added B flag to indicate “reverse LSP”, Reply Mode 5= still require Reply Path TLV with B flag to describe “reverse LSP= 221;. Reply Path TLV is good when wanting to use specific LSP as return path, but it’s more difficult than necessary when want= ing to just use reverse LSP. I will add some texts to clarify this.<= o:p>

%sam - Are you saying that reply mode 5 with B bit s= et is not solving the problem or not optimal (because a TLV is being added?= ). The text in RFC7110 says, "B (Bidirecti= onal): the return path is required to follow the

    &=
nbsp;    reverse direction of the tested bidirectional LSP.&=
nbsp; If B bit is
    &=
nbsp;    set, there is no need to carry any specific reply p=
ath sub- 

      &nb= sp;  TLVs, and when received, the sub-TLVs SHOULD be ignored."

As author of RFC7110 is also author of this draft, i= t would be good to clarification. From what I see, this new reply mode &nbs= p;proposed in this draft is already addressed in RFC7110. If the new reply = mode adds optimization to the existing solution, why to add a new mode?

 

[NOBO2] Reply mode 5 requ= ires a TLV, whether or not B bit is used. The text from RFC7110 above descr= ibes, further sub-TLV is not required when B bit is used. So yes, one aspect of this draft is optimization on how “Reply Mode = =3D Reverse LSP” is described (i.e. Reverse LSP Reply Mode value that= does not require any TLVs nor sub-TLVs).

 <= /p>

I'll add more to this. Even with RFC7110 or this dra= ft, there is no way to know the support for these new reply modes, when loo= king from the source node. So, if the request is received with this new rep= ly mode, (depending on implementation) the request may get dropped?

 

[NOBO2] Exactly. This is = why Reply Mode Order TLV optional TLV is beneficial. Implementations can co= ntinue to use currently used/computed “Reply Mode” value in the MPLS echo request. Reply Mode Order TLV can provide ordered list of= Reply Modes, which can be used by the responder if responder understands t= his draft (i.e. If not, responder will just use Reply Mode in received MPLS= echo request). And because responder is to set Reply Mode used (if chosen from Reply Mode Order TLV)  in t= he Reply Mode field of MPLS echo reply, initiator knows what happened at th= e responder. This provide a clean transition.

 <= /p>

%sam - For RFC4379bis? In RFC4379 sec 4.5, it says &= quot;If the reply is sent over an LSP, the

 <=
/pre>

   topmost labe=
l MUST in this case be the Router Alert label (1) (see

   [LABEL-STACK]).". 


 


[NOBO2] I agree. I think mandating RA label=
 here is questionable. We should list this up as a topic to follow up for b=
is.
















 






 =









General comments:






 






- I believe this new enhancement will only pr=
ovide a degree of variance to RFC4379, where the response could be received=
 back at initiator. Here is why











1. If the response is not received back at source, eve=
n with the new TLV, one cannot conclude that LSP is broken. 


 =





[NOBO] It depends on how=
 you look at this. With this new TLV, it is difficult to figure
 out if lack of response is due to something broken or responder didn’=
;t have the return path specified. With this new TLV, list of return paths =
are provided. Thus lack of response means either something is broken or non=
e of the return paths specified were available
 at responder … which, if return path list contained everything, then=
 it can only mean something is broken.


















%sam - the assumption you are making here is, the re=
sponding node is broken locally. If the reply path in the middle is broken,=
 this will solution not help either, because responding node picks the top =
reply mode and sends it. It doesn't
 know to pick #2 or later in the list, because #1 response mode didn't make=
 it to source. 






Is the scope limited to the ability of responding no=
de to reply, hence providing multiple reply mode options? <=
/p>

 <=
/p>

[NOBO2] You are absolutel=
y right that responder will not have any knowledge of what is available in =
transit node in the reverse direction. I think we are discussing
 glass is half full or empty though. Let me give one scenario.


 <=
/p>

There’s associated =
LSP between node A and node B. Let’s say ping is done from node A wit=
h just Reverse LSP Reply Mode. In the forward direction, a transit node
 X incorrectly forwards the packet to node Y. Node Y is not part of this LS=
P, thus node Y will obviously not have reverse LSP. In this case, ping will=
 just timeout (i.e. node Y cannot send MPLS echo reply due to lack of rever=
se LSP). However, it is very beneficial
 for node A to still get “fec mismatch” error from node Y for d=
iagnostic purpose, and that will be possible if node Y can respond with IP&=
nbsp; path. In this case, Reply Mode Order TLV can have (1. Reverse LSP, 2.=
 IP) which satisfies operator needs whilst still
 providing good diagnostic in case of failure.


 <=
/p>

This draft is indeed a sm=
all enhancements, but adds value to both simplicity and diagnostic aspect. =
Hopefully I was successful in swaying you in the direction
 of “supportive”, let me know?


 <=
/p>

-Nobo

 <=
/p>

 <=
/p>





 






Thanks again






-sam


















 =










 








 =









 
--_000_CECE764681BE964CBE1DFF78F3CDD3941E1072FBxmbalnx01ciscoc_-- From nobody Sun Apr 13 11:10:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979A1A01FF for ; Sun, 13 Apr 2014 11:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN7_urHZpQo9 for ; Sun, 13 Apr 2014 11:10:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D92351A020F for ; Sun, 13 Apr 2014 11:10:50 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3DIAlME011684; Sun, 13 Apr 2014 19:10:47 +0100 Received: from 950129200 (customer908.105.wv.cust.t-mobile.co.uk [178.105.3.139] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3DIAjNf011666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Apr 2014 19:10:46 +0100 From: "Adrian Farrel" To: Date: Sun, 13 Apr 2014 19:10:44 +0100 Message-ID: <002301cf5743$b1a74af0$14f5e0d0$@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: Ac9XQ4qnttK65JrbStiwuG/j7ZBucw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20630.001 X-TM-AS-Result: No--11.865-10.0-31-10 X-imss-scan-details: No--11.865-10.0-31-10 X-TMASE-MatchedRID: uM/FAQ+OoQenykMun0J1wnBRIrj8R47FJPNIV6GF8mtX14Hy+eYp70no Eo7WwNxnJKelhEebHIqIY102U/vYqLXIiX0OZIOabMGKOuLn5FUfXzVgO0hVqgDqzaYhcjeQboG JPDpzSEn90TkpI5Gh2pnmteZltT2lhzsX7/vYqPCeEco05hssvpZ6zKu0q4rt/LmQOavvaE2Pp7 xHKEBR4kBfeAaFhRvEYklZyHW6Io80Z9sXcK7F6biMC5wdwKqdLOOFU9c9B/i/7bplhbPCQggZ9 1sE6DJjvdPbwgcKBFHLi4BEWxALS3bOInuIcg6/YD9XTRdaMO2Vq+okl1rYD23D6f6IpbLIj9Fj +RtK2eDAv6Yogn/PGYpBtjH4AF7SSqSDOjH8JBprRpSjNebQNuAAYRasBjMex4FVLO4NFrDfl0P vqvMF9xWX2qCWKuyr7qXXLN2XZ6rTpWeic52qPLThj82FPFSCO1K5iM8Q6KC0rcU5V/oSe8uFW1 3cxnvTtz2oIRmoEs/mDTS+93LoejcpdZ3fQiLdOX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiRGmTunxbRYa1Zp3OFd2gwGs3YuIzwR6kX5W2zZKWc9/X7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BNCPqZ2-ITqo5G__RDVkQKEzvxI Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 13 Apr 2014 18:10:56 -0000 Hi authors, Thanks for progressing with this document. It is good to see security being taken seriously by the WG. I have done my usual AD review after receiving the publication request. This has led me to a small number of issues and questions, below. It would be nice to see these addressed, but I am open to discussion including the authors and WG saying that I am wrong or that the additions are out of scope. Thanks for your work, Adrian === I think that the threat analysis is a bit thin. As with all interior routing protocols, there seem to be two possibilities. The first is that a bad LDP message is admitted (directly or through a tunnel) into the network. The second is that there is a bad actor in the network. It would help if the document was a little clearer about which attacks it is defending against and why normal protection at the edge of the network is not considered enough for the former, and why a bad actor within the network would waste its time attacking LDP when there is so much else it can do! --- IANA stuff... Section 2.1 should use "TBD1" and Section 2..3 and 8 should be similarly updated to identify the new Cryptographic Authentication TLV. The back reference in section 8 should presumably say "2.3" not "3.2". --- Section 2.1 has The Cryptographic Authentication TLV Encoding is described in section 2.2. I think this should read 2.3. --- Section 2.2. o Security Association Identifier (SA ID) This is a 32-bit unsigned integer used to uniquely identify an LDP SA, as manually configured by the network operator. "Unique" in what scope? Presumably "globally unique" is not needed. I am also concerned by the requirement for manual configuration because that is open to error and attack. Each LDP speaker will have an SA with each of its peers and each peer must have the same SA ID for communication to work. If you are going to go to this extent, it seems like you don't actually need Hellos to do discovery and you will only use them for "keepalive" in which case, it might be better to replace that second aspect of the Hello with something like a KeepAlive message! It is perhaps ironic that part of the reasoning you apply against access lists is the resources they take up on each LSR, yet you are requesting that each peer that is allowed to communicate has an SA configured which seems to me to be more resources than a simple access list. Is there no way to generate the AD ID value from other known information or the LDP session? Perhaps this concern is best addressed by writing a Management Considerations section to describe: - what needs to be configurable in an implementation - what needs to be configured per SA - what needs to be made available for inspection - what logging takes place --- There is a small alignment error in the figure in Section 2.3 --- Section 4 is a little odd. The implication of the wording is that this document sets requirements on all implementations of all other protocols that use cryptographic authentication. I would suggest deleting the whole section and updating Section 5 as follows... OLD Ks is a Protocol Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet LDP Cryptographic Protocol ID appended. NEW Ks is a Protocol Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet LDP Cryptographic Protocol ID TBD2 (to be defined by IANA) from the "Authentication Cryptographic Protocol ID" registry. Ks is used to mitigate cross- protocol attacks when multiple protocols share a common key. END --- Section 6.2 if the locally computed Hash is not equal to the received value of the Authentication Data field, the received packet MUST be discarded, and an error event SHOULD be logged. It is customary to give some warning about rate limiting logging because logging usually takes more resources than receiving packets, so if you are subject to a storm of bad Hellos you could die trying to log them. From nobody Mon Apr 14 08:36:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C541A04AB for ; Mon, 14 Apr 2014 08:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-l2cSBE3lLX for ; Mon, 14 Apr 2014 08:36:34 -0700 (PDT) Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by ietfa.amsl.com (Postfix) with ESMTP id 551C51A02CF for ; Mon, 14 Apr 2014 08:36:34 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so8158994yha.24 for ; Mon, 14 Apr 2014 08:36:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RKXlTZ6qpInFoFxkwUvJmXlRa1QvpKKWeedHTe+ROYg=; b=OSKcIRKgeexA7088mtpc9dfMRu1fl2wCEAJgJLnvamZvrMxyQon0Kt/cNWDKM6m16/ xf00P/vSlo/eOOZfbf4Lua/2/tezaQJUSNK6CQ0jNeMaoXAwtV8J9m//efFnP0W9wHRR 8yi3RKIm0DQerKu3f1i41SbDQRW+fHBD27hFiSL425VpVRbdyntHY5Tz7Iw93BzaxBYT drpaqO/Um+9V2Mc6FfzVqsi2WeVjML/6UVlQFQEdHhy/hetFw96ILMzXkqxHQZENDMCU 18zli2/etdovjJlCdo3AukzoejkEGROVqBgyXRaQIkiB6qXi3LNSGFJIFVBTUAIDDoCu I1mw== X-Gm-Message-State: ALoCoQkgbbjqUCDJk2cFoZ+9bvzZ4831OTjaMUquI4IGBr865ndeLcULrTLOA8iGTk+rbiaAb3qV MIME-Version: 1.0 X-Received: by 10.236.102.70 with SMTP id c46mr9229430yhg.40.1397489791724; Mon, 14 Apr 2014 08:36:31 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Mon, 14 Apr 2014 08:36:31 -0700 (PDT) In-Reply-To: <033101cf54da$97f20ca0$c7d625e0$@olddog.co.uk> References: <20140409070804.21719.99786.idtracker@ietfa.amsl.com> <033101cf54da$97f20ca0$c7d625e0$@olddog.co.uk> Date: Mon, 14 Apr 2014 11:36:31 -0400 Message-ID: From: Eric Osborne To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/O9CzzMkLg_KsN0qTVXC1nQw8trg Cc: "mpls@ietf.org" , "draft-ietf-mpls-psc-updates@tools.ietf.org" Subject: Re: [mpls] Last Call Expired: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:36:38 -0000 (for the list) ACK. I replied back to the gen-art reviewer as I want to make sure I understand the severity of some of the comments, but they're pretty straightforward. eric On Thu, Apr 10, 2014 at 12:33 PM, Adrian Farrel wrote: > Hi Eric, > > I think you have a few minor comments from IETF last call. > > Thanks, > Adrian > >> -----Original Message----- >> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker Mail System >> Sent: 09 April 2014 08:08 >> To: iesg@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-psc- >> updates@tools.ietf.org >> Cc: iesg-secretary@ietf.org >> Subject: Last Call Expired: >> >> >> Please DO NOT reply to this email. >> >> I-D: >> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ >> >> IETF Last Call has ended, and the state has been changed to >> Waiting for AD Go-Ahead. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Apr 14 11:05:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0521F1A06AC; Mon, 14 Apr 2014 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTn_ILuRWRIz; Mon, 14 Apr 2014 11:05:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id CC9EE1A06C2; Mon, 14 Apr 2014 11:05:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C446A1801B0; Mon, 14 Apr 2014 11:05:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140414180520.C446A1801B0@rfc-editor.org> Date: Mon, 14 Apr 2014 11:05:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/i0tPsjvHKoa5iY5QCmPXb5uQB-s Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7167 on A Framework for Point-to-Multipoint MPLS in Transport Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:05:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7167 Title: A Framework for Point-to-Multipoint MPLS in Transport Networks Author: D. Frost, S. Bryant, M. Bocci, L. Berger Status: Informational Stream: IETF Date: April 2014 Mailbox: frost@mm.st, stbryant@cisco.com, matthew.bocci@alcatel-lucent.com, lberger@labn.net Pages: 12 Characters: 23842 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-p2mp-framework-06.txt URL: http://www.rfc-editor.org/rfc/rfc7167.txt The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 14 14:23:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A981A0738 for ; Mon, 14 Apr 2014 14:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.772 X-Spam-Level: X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ_UK9iWmovL for ; Mon, 14 Apr 2014 14:23:33 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 953031A072B for ; Mon, 14 Apr 2014 14:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11563; q=dns/txt; s=iport; t=1397510611; x=1398720211; h=from:to:cc:subject:date:message-id:mime-version; bh=q7QjXeB9KV2LHF03fnaeAxfaMI4ynjIUrVPsunzojKU=; b=TCOEz5njvXGVv0EaC0CjvVj4M4YWUec+bfWY0uuA57FFsJc0f/pvRJj8 Zry5FwD2IVdJZPwZS2nF8YDoNpj4nwbGDJfOv9aPZ0QyQ9dUdjlNA/5x5 AXDvavAfGNSZqpEKJa6oZv6iCtqAhNm4qG/GF2AWDhvbkJJg7nVqrdq8K A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJlQTFOtJA2B/2dsb2JhbABZgkJEgRLDMIEnFnSCLHkSAYEAJwQBDSCHYcwWF45uhD8EmGGSQ4Mxgis X-IronPort-AV: E=Sophos; i="4.97,859,1389744000"; d="scan'208,217"; a="35752226" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 14 Apr 2014 21:23:30 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3ELNUon013386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 21:23:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 16:23:30 -0500 From: "George Swallow (swallow)" To: Kireeti Kompella , John Drake , Shane Amante , Wim Henderickx , Lucy Yong Thread-Topic: RFC6790 and LDP independent mode Thread-Index: AQHPWCfHbdJJf2eTFE2eZHh7/E0oXA== Date: Mon, 14 Apr 2014 21:23:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.165] Content-Type: multipart/alternative; boundary="_000_CF71CA0FAAD60swallowciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rYF8OJI9wRg_dCxr99kl99yzfKI Cc: MPLS , "David Toscano \(dtoscano\)" Subject: [mpls] RFC6790 and LDP independent mode X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:23:34 -0000 --_000_CF71CA0FAAD60swallowciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors - We have uncovered what we believe to be a hole in the 6790 procedures when = it comes to ELC TLV redistribution in independent mode. Here's the text fr= om the RFC with the most problematic part in bold. 5.1.1. Processing the ELC TLV An LSR that receives a Label Mapping with the ELC TLV but does not understand it MUST propagate it intact to its neighbors and MUST NOT send a notification to the sender (following the meaning of the U- and F-bits). An LSR X may receive multiple Label Mappings for a given FEC F from its neighbors. In its turn, X may advertise a Label Mapping for F to its neighbors. If X understands the ELC TLV, and if any of the advertisements it received for FEC F does not include the ELC TLV, X MUST NOT include the ELC TLV in its own advertisements of F. If all the advertised Mappings for F include the ELC TLV, then X MUST advertise its Mapping for F with the ELC TLV. If any of X's neighbors resends its Mapping, sends a new Mapping or sends a Label Withdraw for a previously advertised Mapping for F, X MUST re- evaluate the status of ELC for FEC F, and, if there is a change, X MUST re-advertise its Mapping for F with the updated status of ELC. Consider a core LSR-A that is just re-booting. When LDP comes up it will b= egin advertising label mapping for all of it's IGP learned & installed pre= fixes. For any prefix the LSR-A has yet to receive a mapping with a TLV, L= SR-A will not send a TLV with the initial mapping. Suppose LSR-B is a neig= hbor of LSR-A. Following the text in bold LSR-B MUST re-advertise the FEC = without the TLV. It does not matter whether LSR-B is in independent or ord= ered mode. This likely will ripple through the entire network all the way = to the PE advertising the FEC. I don't see any procedure that would get th= e network out of this condition. Even if that PE withdrew it's advertiseme= nt, LSR-A would still advertise the FEC. I suppose the PE could remove the= prefix from the IGP and then re-advertise it. But you would still face a = race condition where LSR-A is more than likely going to re-advertise the ma= pping before it gets the TLV. We haven't come up with a clean solution, but the following change to the R= FC would greatly mitigate the situation. 1. include TLV if received from ALL next-hop neighbors 2. drop TLV if not advertised by ANY next-hop neighbor This amounts to imposing a kind of ordered mode on the ELC TLV irrespective= of the LDP advertisement mode. The fly in the ointment here is that you still have the possibility of caus= ing your upstream neighbors to drop the TLV if LSR-A becomes a next-hop tow= ards the FEC before LSR-A has 1) discovered the need to advertise the TLV a= nd 2) sent the label mapping. Depending on how the operator has the IGP-sy= nc timer configured, this may or may not be a big problem. George & Dave --_000_CF71CA0FAAD60swallowciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Authors -

We have uncovered what we believe to be a hole in the 6790 procedures = when it comes to ELC TLV redistribution in independent mode.  Here's t= he text from the RFC with the most problematic part in bold.

5.1.= 1.  Processing the ELC TLV

&nbs= p;

&nbs= p;  An LSR that receives a Label Mapping with the ELC TLV but does not=

&nbs= p;  understand it MUST propagate it intact to its neighbors and MUST N= OT

&nbs= p;  send a notification to the sender (following the meaning of the U-=

&nbs= p;  and F-bits).

&nbs= p;

&nbs= p;  An LSR X may receive multiple Label Mappings for a given FEC F fro= m

&nbs= p;  its neighbors.  In its turn, X may advertise a Label Mapping = for F to

&nbs= p;  its neighbors.  If X understands the ELC TLV, and if = any of the

&= nbsp;  advertisements it received for FEC F does not include the ELC T= LV, X

&= nbsp;  MUST NOT include the ELC TLV in its own advertisements of F.  If all

&nbs= p;  the advertised Mappings for F include the ELC TLV, then X MUST

&nbs= p;  advertise its Mapping for F with the ELC TLV.  If any of X's<= o:p>

&nbs= p;  neighbors resends its Mapping, sends a new Mapping or sends a Labe= l

&nbs= p;  Withdraw for a previously advertised Mapping for F, X MUST re-

&nbs= p;  evaluate the status of ELC for FEC F, and, if there is a change, X=

&nbs= p;  MUST re-advertise its Mapping for F with the updated status of ELC= .

Consider a core LSR-A that is just re-booting.  When LDP comes up= it will begin advertising label mapping for all of it's IGP learned & = installed  prefixes.  For any prefix the LSR-A has yet to receive= a mapping with a TLV, LSR-A will not send a TLV with the initial mapping.  Suppose LSR-B is a neighbor of LSR-A.  Fol= lowing the text in bold LSR-B MUST re-advertise the FEC wi= thout the TLV.  It does not matter whether LSR-B is in independent or = ordered mode.  This likely will ripple through the entire network all the way to the PE advertising the FEC.  I don't see any p= rocedure that would get the network out of this condition.  Even if th= at PE withdrew it's advertisement, LSR-A would still advertise the FEC. &nb= sp;I suppose the PE could remove the prefix from the IGP and then re-advertise it.  But you would still face a race co= ndition where LSR-A is more than likely going to re-advertise the mapping b= efore it gets the TLV.


We haven't come up with a clean solution, but the following change to = the RFC would greatly mitigate the situation.


1. include TLV if = received from ALL next-hop neighbors
2. drop TLV if not= advertised by ANY next-hop neighbor

This amounts to im= posing a kind of ordered mode on the ELC TLV irrespective of the = LDP advertisement mode.

The fly in the oin= tment here is that you still have the possibility of causing your upstream = neighbors to drop the TLV if LSR-A becomes a next-hop towards the = ;FEC before LSR-A has 1) discovered the need to advertise the TLV and 2) sent the label mapping.  Depending on how= the operator has the IGP-sync timer configured, this may or may not be a b= ig problem.

George & Dave<= /div>


--_000_CF71CA0FAAD60swallowciscocom_-- From nobody Mon Apr 14 15:54:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667921A045F for ; Mon, 14 Apr 2014 15:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI20oae8-hO5 for ; Mon, 14 Apr 2014 15:54:03 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D9C861A035F for ; Mon, 14 Apr 2014 15:54:02 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so9667674qcx.32 for ; Mon, 14 Apr 2014 15:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F9wkhIVsO5LIIEEgd9A0G+8z2DcYqXDqLda4c1fKSZs=; b=xK7HIujIpf1AzqJCJJdxYa5XNNlDZPEE5wEG40zhaEM8jSSXwqj5ejVcDWQiA5aJgl cVby06ubXemGcdGRFfUDbGvK2AMFPPVLJ3aTCVfbiXDFtseMEYyRMFmWNGzgKLPp2s0K V/4N1NfmFAj1B0u2LNb0ZjcM7vBvfoTwUALl2RHGyu8DUQbUHhT2n8m0vVEcsVwyo14i qWpnwVMQOxjWlTwR+oGEMYcZP2dhSmvGaTKnyM/GBi72Iv5y9xJCgY5qescwCY4qje41 xyESDyCBhoWhradEo0QWE8cZrbG8bVSrQcy4KsWNhGd/9HqPnI25WFgnvLdMfAw0Lb+r m/+g== MIME-Version: 1.0 X-Received: by 10.140.44.2 with SMTP id f2mr51571418qga.73.1397516040090; Mon, 14 Apr 2014 15:54:00 -0700 (PDT) Received: by 10.96.64.69 with HTTP; Mon, 14 Apr 2014 15:53:59 -0700 (PDT) In-Reply-To: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> Date: Mon, 14 Apr 2014 15:53:59 -0700 Message-ID: From: Sam Aldrin To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a1139f9b8233a0404f7088f6b Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lDkqpIcp9pUHsJ5aJMja5XYUpfQ Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:54:05 -0000 --001a1139f9b8233a0404f7088f6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nobo, Thanks again for the reply. Find my replies inline with %sam2. Kept only relevant text for readability sakes. > > > - Sec 2 > > This document adds one Reply Mode to describe reverse LSP, and one > > optional TLV to describe ordered list of reply modes. Based on > > operational needs, the TLV can describe multiple Reply Mode values in > > preferred order to allow responder to use first available Reply Mode > > from the list. This eliminates the need for initiator to compute, or > > sometimes "guess", the "default" return path encoding. And that will > > result in simplified implementations across vendors, and result in > > improved usability to fit operational needs. > > > > > > - Sec 3.1, how is this different from RFC 7110? If same, please call it > out here and remove TBD1 as sec 4.1 of RFC7110 added reply mode 5 for the > same. If different to the RFC, I would like to see those details here. > > > > [NOBO] Reply Mode introduced by RFC7110 specifies that MPLS echo reply is > to be sent on LSP corresponding to FEC described in Reply Path TLV. > Although Reply Path TLV has added B flag to indicate =E2=80=9Creverse LSP= =E2=80=9D, Reply > Mode 5 still require Reply Path TLV with B flag to describe =E2=80=9Creve= rse LSP=E2=80=9D. > Reply Path TLV is good when wanting to use specific LSP as return path, b= ut > it=E2=80=99s more difficult than necessary when wanting to just use rever= se LSP. I > will add some texts to clarify this. > > %sam - Are you saying that reply mode 5 with B bit set is not solving > the problem or not optimal (because a TLV is being added?). The text in > RFC7110 says, "B (Bidirectional): the return path is required to follow > the > > reverse direction of the tested bidirectional LSP. If B bit is > > set, there is no need to carry any specific reply path sub- > > TLVs, and when received, the sub-TLVs SHOULD be ignored." > > As author of RFC7110 is also author of this draft, it would be good to > clarification. From what I see, this new reply mode proposed in this dra= ft > is already addressed in RFC7110. If the new reply mode adds optimization = to > the existing solution, why to add a new mode? > > > > [NOBO2] Reply mode 5 requires a TLV, whether or not B bit is used. The > text from RFC7110 above describes, further sub-TLV is not required when B > bit is used. So yes, one aspect of this draft is optimization on how =E2= =80=9CReply > Mode =3D Reverse LSP=E2=80=9D is described (i.e. Reverse LSP Reply Mode v= alue that > does not require any TLVs nor sub-TLVs). > %sam2 - We may disagree here but that is exactly my point. Why to introduce one more mode for the same functionality? If we take this path, then we will end up with too many options, with optimization as a reason. As the functionality is already solved by RFC7110, albeit extra TLV which is harmless, I'd rather not have this new mode. > > > > General comments: > > > > - I believe this new enhancement will only provide a degree of variance t= o > RFC4379, where the response could be received back at initiator. Here is = why > > 1. If the response is not received back at source, even with the new TLV, > one cannot conclude that LSP is broken. > > > > [NOBO] It depends on how you look at this. With this new TLV, it is > difficult to figure out if lack of response is due to something broken or > responder didn=E2=80=99t have the return path specified. With this new TL= V, list of > return paths are provided. Thus lack of response means either something i= s > broken or none of the return paths specified were available at responder = =E2=80=A6 > which, if return path list contained everything, then it can only mean > something is broken. > > %sam - the assumption you are making here is, the responding node is > broken locally. If the reply path in the middle is broken, this will > solution not help either, because responding node picks the top reply mod= e > and sends it. It doesn't know to pick #2 or later in the list, because #1 > response mode didn't make it to source. > > Is the scope limited to the ability of responding node to reply, hence > providing multiple reply mode options? > > > > [NOBO2] You are absolutely right that responder will not have any > knowledge of what is available in transit node in the reverse direction. = I > think we are discussing glass is half full or empty though. Let me give o= ne > scenario. > > > > There=E2=80=99s associated LSP between node A and node B. Let=E2=80=99s s= ay ping is done > from node A with just Reverse LSP Reply Mode. In the forward direction, a > transit node X incorrectly forwards the packet to node Y. Node Y is not > part of this LSP, thus node Y will obviously not have reverse LSP. In thi= s > case, ping will just timeout (i.e. node Y cannot send MPLS echo reply due > to lack of reverse LSP). However, it is very beneficial for node A to sti= ll > get =E2=80=9Cfec mismatch=E2=80=9D error from node Y for diagnostic purpo= se, and that will > be possible if node Y can respond with IP path. In this case, Reply Mode > Order TLV can have (1. Reverse LSP, 2. IP) which satisfies operator needs > whilst still providing good diagnostic in case of failure. > > > > This draft is indeed a small enhancements, but adds value to both > simplicity and diagnostic aspect. Hopefully I was successful in swaying y= ou > in the direction of =E2=80=9Csupportive=E2=80=9D, let me know? > %sam2 - This above works only if node Y is upgraded to support this new TLV :D. My take is, you could still detect the error in the above scenario, without any upgrade, albeit with an extra request with different reply mode type. I think we both agree that this enhancement is not to discover errors, which cannot be discovered with RFC4379. Rather, it optimises how it is discovered i.e. one request vs multiple requests. With your proposal, in order to gain the real optimization, you need to have the support on devices across the core. On the contrary, if you build application, which is just a workflow upgrade, all it has do is issue multiple requests when timeout happens. This doesn't require any upgrade of s/w on the network devices. In fact I know of applications which already do that. Having said that, we both have clarified the understanding of what this draft means. What we differ is not technical content, rather the need to have this standardized, considering cost of upgrading Vs optimisation gain. I'll leave it to WG to see, if it really feels the need to enhance by standardizing it. cheers -sam > > > -Nobo > > > > > > > > Thanks again > > -sam > > > > > > > > > > --001a1139f9b8233a0404f7088f6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Thanks again for the reply.
Find my replies inline with %sam2. Kept only relevant text for read= ability sakes.


=C2=A0

- Sec 2 

This document adds o=
ne Reply Mode to describe reverse LSP, and one
=C2=A0=C2=A0 optiona=
l TLV to describe ordered list of reply modes.=C2=A0 Based on=

=C2=A0=C2=A0 operati=
onal needs, the TLV can describe multiple Reply Mode values in
=C2=A0=C2=A0 preferr=
ed order to allow responder to use first available Reply Mode=

=C2=A0=C2=A0 from th=
e list.=C2=A0 This eliminates the need for initiator to compute, or<=
u>
=C2=A0=C2=A0 sometim=
es "guess", the "default" return path encoding.=C2=A0 A=
nd that will
=C2=A0=C2=A0 result =
in simplified implementations across vendors, and result in
=C2=A0=C2=A0 improve=
d usability to fit operational needs.

=C2=A0

=C2=A0

- Sec 3.1, how is this differen= t from RFC 7110? If same, please call it out here and remove TBD1 as sec 4.= 1 of RFC7110 added reply mode 5 for the same. If different to the RFC, I would like to see those details here.

=C2=A0<= /span>

[NOBO] Rep= ly Mode introduced by RFC7110 specifies that MPLS echo reply is to be sent on LSP corresponding to FEC described in Reply Path TLV. Although Reply Pa= th TLV has added B flag to indicate =E2=80=9Creverse LSP=E2=80=9D, Reply Mo= de 5 still require Reply Path TLV with B flag to describe =E2=80=9Creverse = LSP=E2=80=9D. Reply Path TLV is good when wanting to use specific LSP as return path, but it=E2=80=99s more difficult than necessary when wa= nting to just use reverse LSP. I will add some texts to clarify this.

%sam - Are you saying that reply mode 5 with B bit s= et is not solving the problem or not optimal (because a TLV is being added?= ). The text in RFC7110 says, "B (Bidirectional): the retur= n path is required to follow the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 reverse direction of the tested bidirectional LSP.=C2=A0 If B =
bit is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 set, there is no need to carry any specific reply path sub-=C2=
=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLVs, = and when received, the sub-TLVs SHOULD be ignored."

As author of RFC7110 is also author of this draft, i= t would be good to clarification. From what I see, this new reply mode =C2= =A0proposed in this draft is already addressed in RFC7110. If the new reply= mode adds optimization to the existing solution, why to add a new mode?

=C2=A0

[NOBO2] Reply mode 5 requ= ires a TLV, whether or not B bit is used. The text from RFC7110 above descr= ibes, further sub-TLV is not required when B bit is used. So yes, one aspect of this draft is optimization on how =E2=80=9CReply Mod= e =3D Reverse LSP=E2=80=9D is described (i.e. Reverse LSP Reply Mode value = that does not require any TLVs nor sub-TLVs).

<= /div>
%sam2 - We may disagree here but that is exac= tly my point. Why to introduce one more mode for the same functionality? If= we take this path, then we will end up with too many options, with optimiz= ation as a reason. As the functionality is already solved by RFC7110, albei= t extra TLV which is harmless, I'd rather not have this new mode.

=C2=A0

=C2=A0

General comments:=

=C2=A0

- I believe this new enhancemen= t will only provide a degree of variance to RFC4379, where the response cou= ld be received back at initiator. Here is why

1. If the response is not received back at source, eve= n with the new TLV, one cannot conclude that LSP is broken.=C2=A0=

=C2=A0

[NOBO] It = depends on how you look at this. With this new TLV, it is difficult to figu= re out if lack of response is due to something broken or responder didn=E2=80= =99t have the return path specified. With this new TLV, list of return path= s are provided. Thus lack of response means either something is broken or n= one of the return paths specified were available at responder =E2=80=A6 which, if return path list contained everything, th= en it can only mean something is broken.

%sam - the assumption you are making here is, the re= sponding node is broken locally. If the reply path in the middle is broken,= this will solution not help either, because responding node picks the top = reply mode and sends it. It doesn't know to pick #2 or later in the list, because #1 response mode didn't = make it to source.=C2=A0

Is the scope limited to the ability of responding no= de to reply, hence providing multiple reply mode options?=C2=A0

=C2=A0

[NOBO2] You are abs= olutely right that responder will not have any knowledge of what is availab= le in transit node in the reverse direction. I think we are discussing glass is half full or empty though. Let me give one scenario.

=C2=A0

There=E2=80=99s associate= d LSP between node A and node B. Let=E2=80=99s say ping is done from node A= with just Reverse LSP Reply Mode. In the forward direction, a transit node X incorrectly forwards the packet to node Y. Node Y is not part of this LS= P, thus node Y will obviously not have reverse LSP. In this case, ping will= just timeout (i.e. node Y cannot send MPLS echo reply due to lack of rever= se LSP). However, it is very beneficial for node A to still get =E2=80=9Cfec mismatch=E2=80=9D error from node Y f= or diagnostic purpose, and that will be possible if node Y can respond with= IP=C2=A0 path. In this case, Reply Mode Order TLV can have (1. Reverse LSP= , 2. IP) which satisfies operator needs whilst still providing good diagnostic in case of failure.

=C2=A0

This draft is indeed a sm= all enhancements, but adds value to both simplicity and diagnostic aspect. = Hopefully I was successful in swaying you in the direction of =E2=80=9Csupportive=E2=80=9D, let me know?

=

%sam2 - This= above works only if node Y is upgraded to support this new TLV :D. My take= is, you could still detect the error in the above scenario, without any up= grade, albeit with an extra request with different reply mode type. I think= we both agree that this enhancement is not to discover errors, which canno= t be discovered with RFC4379. Rather, it optimises how it is discovered i.e= . one request vs multiple requests. With your proposal, in order to gain th= e real optimization, you need to have the support on devices across the cor= e. On the contrary, if you build application, which is just a workflow upgr= ade, all it has do is issue multiple requests when timeout happens. This do= esn't require any upgrade of s/w on the network devices. In fact I know= of applications which already do that.

Having said that, we both have clarified the understand= ing of what this draft means. What we differ is not technical content, rath= er the need to have this standardized, considering cost of upgrading Vs opt= imisation gain. I'll leave it to WG to see, if it really feels the need= to enhance by standardizing it.=C2=A0

cheers
-sam
=C2=A0

=

=C2=A0

-Nobo

=C2=A0

=C2=A0

=C2=A0

Thanks again

-sam

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a1139f9b8233a0404f7088f6b-- From nobody Tue Apr 15 01:54:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54F41A0294 for ; Tue, 15 Apr 2014 01:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLnCQe0DnTFW for ; Tue, 15 Apr 2014 01:54:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD21A0290 for ; Tue, 15 Apr 2014 01:54:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D91301801A3; Tue, 15 Apr 2014 01:54:02 -0700 (PDT) To: Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140415085402.D91301801A3@rfc-editor.org> Date: Tue, 15 Apr 2014 01:54:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MlZJoQb3w59c0LMUX-jEHogS7J4 Cc: mpls@ietf.org, bestman0729@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6371 (3963) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 08:54:32 -0000 The following errata report has been submitted for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3963 -------------------------------------- Type: Editorial Reported by: Liu Lin Section: 7.1.2 Original Text ------------- The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction. Corrected Text -------------- The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LKI removal reply OAM packet indicating whether or not it has accepted the instruction. Notes ----- LK ---> LKI Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 15 02:31:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B81A033C; Tue, 15 Apr 2014 02:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrHDMpHLsOfC; Tue, 15 Apr 2014 02:31:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 457F61A02D3; Tue, 15 Apr 2014 02:31:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CE8A31801A3; Tue, 15 Apr 2014 02:31:28 -0700 (PDT) To: bestman0729@gmail.com, Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140415093128.CE8A31801A3@rfc-editor.org> Date: Tue, 15 Apr 2014 02:31:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7Gixrdu73s8nmlMI3K4lr6lc4iE Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Held for Document Update] RFC6371 (3963) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 09:31:55 -0000 The following errata report has been held for document update for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6371&eid=3963 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Liu Lin Date Reported: 2014-04-15 Held by: Adrian Farrel (IESG) Section: 7.1.2 Original Text ------------- The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction. Corrected Text -------------- The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LKI removal reply OAM packet indicating whether or not it has accepted the instruction. Notes ----- LK ---> LKI -------------------------------------- RFC6371 (draft-ietf-mpls-tp-oam-framework-11) -------------------------------------- Title : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Publication Date : September 2011 Author(s) : I. Busi, Ed., D. Allan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 15 05:46:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC61A03FC for ; Tue, 15 Apr 2014 05:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.772 X-Spam-Level: X-Spam-Status: No, score=-114.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGpeybYbnkeq for ; Tue, 15 Apr 2014 05:46:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 723AB1A0285 for ; Tue, 15 Apr 2014 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39322; q=dns/txt; s=iport; t=1397566004; x=1398775604; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qFeNpN9mO2mYbhEDo5WJvekZyRt2T9fQhZiyj3RO2Kc=; b=bVHdZewutNqQnSzVVcSlgBc+jCFfnfApdlYoXchL0coEgO0Aqw1gZVt1 E0e5Rm23SyAqS4D9uwAqdEJkCGoJF+jaIhLWKlKxLWXzCCVciu0qhoquh L0OeT9mGVaZz/GzX+Td40vr80aaLs6mLmHlE+oDPvK1g1SLcwQ7IE1N1l o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAOMoTVOtJA2J/2dsb2JhbABZgkIjITtXgxDAGBmBCRZ0giUBAQEEIwo/CgMQAgEIEQQBAQsWAQYDAgICHxEUCQgCBA4FCBOHTQMRAalCnAANhmMXjEqBQRYRMQYBgm81gRQElHWBf45khU+DMYFpAh4i X-IronPort-AV: E=Sophos;i="4.97,864,1389744000"; d="scan'208,217";a="317882172" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 15 Apr 2014 12:46:43 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3FCkg8t032533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 12:46:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 07:46:42 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: AQHPVbXZJ6LNrNHPL0mkFF9N1N/BxJsPiXbAgAKHx4CAAJLWMA== Date: Tue, 15 Apr 2014 12:46:41 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E108735xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hruvUvoAJ9VhIHuA65g8k_GcUtw Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:46:50 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E108735xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpUaGFua3MgZm9yIHlvdXIgcGF0aWVuY2UgYW5kIGNvbnRpbnVlZCBkaXNjdXNz aW9ucy4NCkkgYWdyZWUgdGhhdCB3ZSBoYXZlIHJlYWNoZWQgc2F0dXJhdGlvbiBiZXR3ZWVuIHVz Lg0KV2Ugd2lsbCBwcm9jZWVkIHRvIHJvbGwgb3V0IC0wMiBzaG9ydGx5LCBhZGRyZXNzaW5nIGNv bW1lbnRzIHlvdeKAmXZlIHByb3ZpZGVkLg0KDQotTm9ibw0KDQpGcm9tOiBTYW0gQWxkcmluIFtt YWlsdG86YWxkcmluLmlldGZAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxNCwgMjAx NCA2OjU0IFBNDQpUbzogTm9ibyBBa2l5YSAobm9ibykNCkNjOiBNYWNoIENoZW47IG1wbHNAaWV0 Zi5vcmc7IGRyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctcmVwbHktbW9kZS1zaW1wbGVAdG9vbHMu aWV0Zi5vcmc7IEN1cnRpcyBWaWxsYW1pemFyDQpTdWJqZWN0OiBSZTogW21wbHNdIFRoYW5rcyBm b3IgY29tbWVudHMgb24gZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBs ZQ0KDQpIaSBOb2JvLA0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSByZXBseS4NCkZpbmQgbXkgcmVw bGllcyBpbmxpbmUgd2l0aCAlc2FtMi4gS2VwdCBvbmx5IHJlbGV2YW50IHRleHQgZm9yIHJlYWRh YmlsaXR5IHNha2VzLg0KDQoNCg0KLSBTZWMgMg0KDQpUaGlzIGRvY3VtZW50IGFkZHMgb25lIFJl cGx5IE1vZGUgdG8gZGVzY3JpYmUgcmV2ZXJzZSBMU1AsIGFuZCBvbmUNCg0KICAgb3B0aW9uYWwg VExWIHRvIGRlc2NyaWJlIG9yZGVyZWQgbGlzdCBvZiByZXBseSBtb2Rlcy4gIEJhc2VkIG9uDQoN CiAgIG9wZXJhdGlvbmFsIG5lZWRzLCB0aGUgVExWIGNhbiBkZXNjcmliZSBtdWx0aXBsZSBSZXBs eSBNb2RlIHZhbHVlcyBpbg0KDQogICBwcmVmZXJyZWQgb3JkZXIgdG8gYWxsb3cgcmVzcG9uZGVy IHRvIHVzZSBmaXJzdCBhdmFpbGFibGUgUmVwbHkgTW9kZQ0KDQogICBmcm9tIHRoZSBsaXN0LiAg VGhpcyBlbGltaW5hdGVzIHRoZSBuZWVkIGZvciBpbml0aWF0b3IgdG8gY29tcHV0ZSwgb3INCg0K ICAgc29tZXRpbWVzICJndWVzcyIsIHRoZSAiZGVmYXVsdCIgcmV0dXJuIHBhdGggZW5jb2Rpbmcu ICBBbmQgdGhhdCB3aWxsDQoNCiAgIHJlc3VsdCBpbiBzaW1wbGlmaWVkIGltcGxlbWVudGF0aW9u cyBhY3Jvc3MgdmVuZG9ycywgYW5kIHJlc3VsdCBpbg0KDQogICBpbXByb3ZlZCB1c2FiaWxpdHkg dG8gZml0IG9wZXJhdGlvbmFsIG5lZWRzLg0KDQoNCi0gU2VjIDMuMSwgaG93IGlzIHRoaXMgZGlm ZmVyZW50IGZyb20gUkZDIDcxMTA/IElmIHNhbWUsIHBsZWFzZSBjYWxsIGl0IG91dCBoZXJlIGFu ZCByZW1vdmUgVEJEMSBhcyBzZWMgNC4xIG9mIFJGQzcxMTAgYWRkZWQgcmVwbHkgbW9kZSA1IGZv ciB0aGUgc2FtZS4gSWYgZGlmZmVyZW50IHRvIHRoZSBSRkMsIEkgd291bGQgbGlrZSB0byBzZWUg dGhvc2UgZGV0YWlscyBoZXJlLg0KDQpbTk9CT10gUmVwbHkgTW9kZSBpbnRyb2R1Y2VkIGJ5IFJG QzcxMTAgc3BlY2lmaWVzIHRoYXQgTVBMUyBlY2hvIHJlcGx5IGlzIHRvIGJlIHNlbnQgb24gTFNQ IGNvcnJlc3BvbmRpbmcgdG8gRkVDIGRlc2NyaWJlZCBpbiBSZXBseSBQYXRoIFRMVi4gQWx0aG91 Z2ggUmVwbHkgUGF0aCBUTFYgaGFzIGFkZGVkIEIgZmxhZyB0byBpbmRpY2F0ZSDigJxyZXZlcnNl IExTUOKAnSwgUmVwbHkgTW9kZSA1IHN0aWxsIHJlcXVpcmUgUmVwbHkgUGF0aCBUTFYgd2l0aCBC IGZsYWcgdG8gZGVzY3JpYmUg4oCccmV2ZXJzZSBMU1DigJ0uIFJlcGx5IFBhdGggVExWIGlzIGdv b2Qgd2hlbiB3YW50aW5nIHRvIHVzZSBzcGVjaWZpYyBMU1AgYXMgcmV0dXJuIHBhdGgsIGJ1dCBp dOKAmXMgbW9yZSBkaWZmaWN1bHQgdGhhbiBuZWNlc3Nhcnkgd2hlbiB3YW50aW5nIHRvIGp1c3Qg dXNlIHJldmVyc2UgTFNQLiBJIHdpbGwgYWRkIHNvbWUgdGV4dHMgdG8gY2xhcmlmeSB0aGlzLg0K JXNhbSAtIEFyZSB5b3Ugc2F5aW5nIHRoYXQgcmVwbHkgbW9kZSA1IHdpdGggQiBiaXQgc2V0IGlz IG5vdCBzb2x2aW5nIHRoZSBwcm9ibGVtIG9yIG5vdCBvcHRpbWFsIChiZWNhdXNlIGEgVExWIGlz IGJlaW5nIGFkZGVkPykuIFRoZSB0ZXh0IGluIFJGQzcxMTAgc2F5cywgIkIgKEJpZGlyZWN0aW9u YWwpOiB0aGUgcmV0dXJuIHBhdGggaXMgcmVxdWlyZWQgdG8gZm9sbG93IHRoZQ0KDQogICAgICAg ICByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgdGVzdGVkIGJpZGlyZWN0aW9uYWwgTFNQLiAgSWYg QiBiaXQgaXMNCg0KICAgICAgICAgc2V0LCB0aGVyZSBpcyBubyBuZWVkIHRvIGNhcnJ5IGFueSBz cGVjaWZpYyByZXBseSBwYXRoIHN1Yi0NCiAgICAgICAgIFRMVnMsIGFuZCB3aGVuIHJlY2VpdmVk LCB0aGUgc3ViLVRMVnMgU0hPVUxEIGJlIGlnbm9yZWQuIg0KQXMgYXV0aG9yIG9mIFJGQzcxMTAg aXMgYWxzbyBhdXRob3Igb2YgdGhpcyBkcmFmdCwgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZp Y2F0aW9uLiBGcm9tIHdoYXQgSSBzZWUsIHRoaXMgbmV3IHJlcGx5IG1vZGUgIHByb3Bvc2VkIGlu IHRoaXMgZHJhZnQgaXMgYWxyZWFkeSBhZGRyZXNzZWQgaW4gUkZDNzExMC4gSWYgdGhlIG5ldyBy ZXBseSBtb2RlIGFkZHMgb3B0aW1pemF0aW9uIHRvIHRoZSBleGlzdGluZyBzb2x1dGlvbiwgd2h5 IHRvIGFkZCBhIG5ldyBtb2RlPw0KDQpbTk9CTzJdIFJlcGx5IG1vZGUgNSByZXF1aXJlcyBhIFRM Viwgd2hldGhlciBvciBub3QgQiBiaXQgaXMgdXNlZC4gVGhlIHRleHQgZnJvbSBSRkM3MTEwIGFi b3ZlIGRlc2NyaWJlcywgZnVydGhlciBzdWItVExWIGlzIG5vdCByZXF1aXJlZCB3aGVuIEIgYml0 IGlzIHVzZWQuIFNvIHllcywgb25lIGFzcGVjdCBvZiB0aGlzIGRyYWZ0IGlzIG9wdGltaXphdGlv biBvbiBob3cg4oCcUmVwbHkgTW9kZSA9IFJldmVyc2UgTFNQ4oCdIGlzIGRlc2NyaWJlZCAoaS5l LiBSZXZlcnNlIExTUCBSZXBseSBNb2RlIHZhbHVlIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBhbnkg VExWcyBub3Igc3ViLVRMVnMpLg0KJXNhbTIgLSBXZSBtYXkgZGlzYWdyZWUgaGVyZSBidXQgdGhh dCBpcyBleGFjdGx5IG15IHBvaW50LiBXaHkgdG8gaW50cm9kdWNlIG9uZSBtb3JlIG1vZGUgZm9y IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHk/IElmIHdlIHRha2UgdGhpcyBwYXRoLCB0aGVuIHdlIHdp bGwgZW5kIHVwIHdpdGggdG9vIG1hbnkgb3B0aW9ucywgd2l0aCBvcHRpbWl6YXRpb24gYXMgYSBy ZWFzb24uIEFzIHRoZSBmdW5jdGlvbmFsaXR5IGlzIGFscmVhZHkgc29sdmVkIGJ5IFJGQzcxMTAs IGFsYmVpdCBleHRyYSBUTFYgd2hpY2ggaXMgaGFybWxlc3MsIEknZCByYXRoZXIgbm90IGhhdmUg dGhpcyBuZXcgbW9kZS4NCg0KDQoNCkdlbmVyYWwgY29tbWVudHM6DQoNCi0gSSBiZWxpZXZlIHRo aXMgbmV3IGVuaGFuY2VtZW50IHdpbGwgb25seSBwcm92aWRlIGEgZGVncmVlIG9mIHZhcmlhbmNl IHRvIFJGQzQzNzksIHdoZXJlIHRoZSByZXNwb25zZSBjb3VsZCBiZSByZWNlaXZlZCBiYWNrIGF0 IGluaXRpYXRvci4gSGVyZSBpcyB3aHkNCjEuIElmIHRoZSByZXNwb25zZSBpcyBub3QgcmVjZWl2 ZWQgYmFjayBhdCBzb3VyY2UsIGV2ZW4gd2l0aCB0aGUgbmV3IFRMViwgb25lIGNhbm5vdCBjb25j bHVkZSB0aGF0IExTUCBpcyBicm9rZW4uDQoNCltOT0JPXSBJdCBkZXBlbmRzIG9uIGhvdyB5b3Ug bG9vayBhdCB0aGlzLiBXaXRoIHRoaXMgbmV3IFRMViwgaXQgaXMgZGlmZmljdWx0IHRvIGZpZ3Vy ZSBvdXQgaWYgbGFjayBvZiByZXNwb25zZSBpcyBkdWUgdG8gc29tZXRoaW5nIGJyb2tlbiBvciBy ZXNwb25kZXIgZGlkbuKAmXQgaGF2ZSB0aGUgcmV0dXJuIHBhdGggc3BlY2lmaWVkLiBXaXRoIHRo aXMgbmV3IFRMViwgbGlzdCBvZiByZXR1cm4gcGF0aHMgYXJlIHByb3ZpZGVkLiBUaHVzIGxhY2sg b2YgcmVzcG9uc2UgbWVhbnMgZWl0aGVyIHNvbWV0aGluZyBpcyBicm9rZW4gb3Igbm9uZSBvZiB0 aGUgcmV0dXJuIHBhdGhzIHNwZWNpZmllZCB3ZXJlIGF2YWlsYWJsZSBhdCByZXNwb25kZXIg4oCm IHdoaWNoLCBpZiByZXR1cm4gcGF0aCBsaXN0IGNvbnRhaW5lZCBldmVyeXRoaW5nLCB0aGVuIGl0 IGNhbiBvbmx5IG1lYW4gc29tZXRoaW5nIGlzIGJyb2tlbi4NCiVzYW0gLSB0aGUgYXNzdW1wdGlv biB5b3UgYXJlIG1ha2luZyBoZXJlIGlzLCB0aGUgcmVzcG9uZGluZyBub2RlIGlzIGJyb2tlbiBs b2NhbGx5LiBJZiB0aGUgcmVwbHkgcGF0aCBpbiB0aGUgbWlkZGxlIGlzIGJyb2tlbiwgdGhpcyB3 aWxsIHNvbHV0aW9uIG5vdCBoZWxwIGVpdGhlciwgYmVjYXVzZSByZXNwb25kaW5nIG5vZGUgcGlj a3MgdGhlIHRvcCByZXBseSBtb2RlIGFuZCBzZW5kcyBpdC4gSXQgZG9lc24ndCBrbm93IHRvIHBp Y2sgIzIgb3IgbGF0ZXIgaW4gdGhlIGxpc3QsIGJlY2F1c2UgIzEgcmVzcG9uc2UgbW9kZSBkaWRu J3QgbWFrZSBpdCB0byBzb3VyY2UuDQpJcyB0aGUgc2NvcGUgbGltaXRlZCB0byB0aGUgYWJpbGl0 eSBvZiByZXNwb25kaW5nIG5vZGUgdG8gcmVwbHksIGhlbmNlIHByb3ZpZGluZyBtdWx0aXBsZSBy ZXBseSBtb2RlIG9wdGlvbnM/DQoNCltOT0JPMl0gWW91IGFyZSBhYnNvbHV0ZWx5IHJpZ2h0IHRo YXQgcmVzcG9uZGVyIHdpbGwgbm90IGhhdmUgYW55IGtub3dsZWRnZSBvZiB3aGF0IGlzIGF2YWls YWJsZSBpbiB0cmFuc2l0IG5vZGUgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLiBJIHRoaW5rIHdl IGFyZSBkaXNjdXNzaW5nIGdsYXNzIGlzIGhhbGYgZnVsbCBvciBlbXB0eSB0aG91Z2guIExldCBt ZSBnaXZlIG9uZSBzY2VuYXJpby4NCg0KVGhlcmXigJlzIGFzc29jaWF0ZWQgTFNQIGJldHdlZW4g bm9kZSBBIGFuZCBub2RlIEIuIExldOKAmXMgc2F5IHBpbmcgaXMgZG9uZSBmcm9tIG5vZGUgQSB3 aXRoIGp1c3QgUmV2ZXJzZSBMU1AgUmVwbHkgTW9kZS4gSW4gdGhlIGZvcndhcmQgZGlyZWN0aW9u LCBhIHRyYW5zaXQgbm9kZSBYIGluY29ycmVjdGx5IGZvcndhcmRzIHRoZSBwYWNrZXQgdG8gbm9k ZSBZLiBOb2RlIFkgaXMgbm90IHBhcnQgb2YgdGhpcyBMU1AsIHRodXMgbm9kZSBZIHdpbGwgb2J2 aW91c2x5IG5vdCBoYXZlIHJldmVyc2UgTFNQLiBJbiB0aGlzIGNhc2UsIHBpbmcgd2lsbCBqdXN0 IHRpbWVvdXQgKGkuZS4gbm9kZSBZIGNhbm5vdCBzZW5kIE1QTFMgZWNobyByZXBseSBkdWUgdG8g bGFjayBvZiByZXZlcnNlIExTUCkuIEhvd2V2ZXIsIGl0IGlzIHZlcnkgYmVuZWZpY2lhbCBmb3Ig bm9kZSBBIHRvIHN0aWxsIGdldCDigJxmZWMgbWlzbWF0Y2jigJ0gZXJyb3IgZnJvbSBub2RlIFkg Zm9yIGRpYWdub3N0aWMgcHVycG9zZSwgYW5kIHRoYXQgd2lsbCBiZSBwb3NzaWJsZSBpZiBub2Rl IFkgY2FuIHJlc3BvbmQgd2l0aCBJUCAgcGF0aC4gSW4gdGhpcyBjYXNlLCBSZXBseSBNb2RlIE9y ZGVyIFRMViBjYW4gaGF2ZSAoMS4gUmV2ZXJzZSBMU1AsIDIuIElQKSB3aGljaCBzYXRpc2ZpZXMg b3BlcmF0b3IgbmVlZHMgd2hpbHN0IHN0aWxsIHByb3ZpZGluZyBnb29kIGRpYWdub3N0aWMgaW4g Y2FzZSBvZiBmYWlsdXJlLg0KDQpUaGlzIGRyYWZ0IGlzIGluZGVlZCBhIHNtYWxsIGVuaGFuY2Vt ZW50cywgYnV0IGFkZHMgdmFsdWUgdG8gYm90aCBzaW1wbGljaXR5IGFuZCBkaWFnbm9zdGljIGFz cGVjdC4gSG9wZWZ1bGx5IEkgd2FzIHN1Y2Nlc3NmdWwgaW4gc3dheWluZyB5b3UgaW4gdGhlIGRp cmVjdGlvbiBvZiDigJxzdXBwb3J0aXZl4oCdLCBsZXQgbWUga25vdz8NCg0KJXNhbTIgLSBUaGlz IGFib3ZlIHdvcmtzIG9ubHkgaWYgbm9kZSBZIGlzIHVwZ3JhZGVkIHRvIHN1cHBvcnQgdGhpcyBu ZXcgVExWIDpELiBNeSB0YWtlIGlzLCB5b3UgY291bGQgc3RpbGwgZGV0ZWN0IHRoZSBlcnJvciBp biB0aGUgYWJvdmUgc2NlbmFyaW8sIHdpdGhvdXQgYW55IHVwZ3JhZGUsIGFsYmVpdCB3aXRoIGFu IGV4dHJhIHJlcXVlc3Qgd2l0aCBkaWZmZXJlbnQgcmVwbHkgbW9kZSB0eXBlLiBJIHRoaW5rIHdl IGJvdGggYWdyZWUgdGhhdCB0aGlzIGVuaGFuY2VtZW50IGlzIG5vdCB0byBkaXNjb3ZlciBlcnJv cnMsIHdoaWNoIGNhbm5vdCBiZSBkaXNjb3ZlcmVkIHdpdGggUkZDNDM3OS4gUmF0aGVyLCBpdCBv cHRpbWlzZXMgaG93IGl0IGlzIGRpc2NvdmVyZWQgaS5lLiBvbmUgcmVxdWVzdCB2cyBtdWx0aXBs ZSByZXF1ZXN0cy4gV2l0aCB5b3VyIHByb3Bvc2FsLCBpbiBvcmRlciB0byBnYWluIHRoZSByZWFs IG9wdGltaXphdGlvbiwgeW91IG5lZWQgdG8gaGF2ZSB0aGUgc3VwcG9ydCBvbiBkZXZpY2VzIGFj cm9zcyB0aGUgY29yZS4gT24gdGhlIGNvbnRyYXJ5LCBpZiB5b3UgYnVpbGQgYXBwbGljYXRpb24s IHdoaWNoIGlzIGp1c3QgYSB3b3JrZmxvdyB1cGdyYWRlLCBhbGwgaXQgaGFzIGRvIGlzIGlzc3Vl IG11bHRpcGxlIHJlcXVlc3RzIHdoZW4gdGltZW91dCBoYXBwZW5zLiBUaGlzIGRvZXNuJ3QgcmVx dWlyZSBhbnkgdXBncmFkZSBvZiBzL3cgb24gdGhlIG5ldHdvcmsgZGV2aWNlcy4gSW4gZmFjdCBJ IGtub3cgb2YgYXBwbGljYXRpb25zIHdoaWNoIGFscmVhZHkgZG8gdGhhdC4NCg0KSGF2aW5nIHNh aWQgdGhhdCwgd2UgYm90aCBoYXZlIGNsYXJpZmllZCB0aGUgdW5kZXJzdGFuZGluZyBvZiB3aGF0 IHRoaXMgZHJhZnQgbWVhbnMuIFdoYXQgd2UgZGlmZmVyIGlzIG5vdCB0ZWNobmljYWwgY29udGVu dCwgcmF0aGVyIHRoZSBuZWVkIHRvIGhhdmUgdGhpcyBzdGFuZGFyZGl6ZWQsIGNvbnNpZGVyaW5n IGNvc3Qgb2YgdXBncmFkaW5nIFZzIG9wdGltaXNhdGlvbiBnYWluLiBJJ2xsIGxlYXZlIGl0IHRv IFdHIHRvIHNlZSwgaWYgaXQgcmVhbGx5IGZlZWxzIHRoZSBuZWVkIHRvIGVuaGFuY2UgYnkgc3Rh bmRhcmRpemluZyBpdC4NCg0KY2hlZXJzDQotc2FtDQoNCg0KLU5vYm8NCg0KDQoNClRoYW5rcyBh Z2Fpbg0KLXNhbQ0KDQoNCg0KDQoNCg== --_000_CECE764681BE964CBE1DFF78F3CDD3941E108735xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU2FtLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIHBhdGllbmNlIGFuZCBjb250aW51ZWQgZGlzY3Vzc2lvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB3ZSBoYXZlIHJlYWNoZWQgc2F0 dXJhdGlvbiBiZXR3ZWVuIHVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSB3aWxs IHByb2NlZWQgdG8gcm9sbCBvdXQgLTAyIHNob3J0bHksIGFkZHJlc3NpbmcgY29tbWVudHMgeW91 4oCZdmUgcHJvdmlkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTm9ibzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNhbSBBbGRyaW4g W21haWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBcHJpbCAxNCwgMjAxNCA2OjU0IFBNPGJyPg0KPGI+VG86PC9iPiBOb2JvIEFraXlhIChub2Jv KTxicj4NCjxiPkNjOjwvYj4gTWFjaCBDaGVuOyBtcGxzQGlldGYub3JnOyBkcmFmdC1ha2l5YS1t cGxzLWxzcC1waW5nLXJlcGx5LW1vZGUtc2ltcGxlQHRvb2xzLmlldGYub3JnOyBDdXJ0aXMgVmls bGFtaXphcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIFRoYW5rcyBmb3IgY29tbWVu dHMgb24gZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOb2JvLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFnYWlu IGZvciB0aGUgcmVwbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5GaW5kIG15IHJlcGxpZXMgaW5saW5lIHdpdGggJXNhbTIuIEtlcHQgb25seSBy ZWxldmFudCB0ZXh0IGZvciByZWFkYWJpbGl0eSBzYWtlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4tIFNlYyAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkb2N1bWVudCBh ZGRzIG9uZSBSZXBseSBNb2RlIHRvIGRlc2NyaWJlIHJldmVyc2UgTFNQLCBhbmQgb25lPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgb3B0aW9uYWwgVExWIHRvIGRlc2NyaWJlIG9yZGVy ZWQgbGlzdCBvZiByZXBseSBtb2Rlcy4mbmJzcDsgQmFzZWQgb248L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyBvcGVyYXRpb25hbCBuZWVkcywgdGhlIFRMViBjYW4gZGVzY3JpYmUgbXVs dGlwbGUgUmVwbHkgTW9kZSB2YWx1ZXMgaW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyBwcmVmZXJyZWQgb3JkZXIgdG8gYWxsb3cgcmVzcG9uZGVyIHRvIHVzZSBmaXJzdCBhdmFpbGFi bGUgUmVwbHkgTW9kZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1o ZWlnaHQ6MTQuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZyb20gdGhlIGxp c3QuJm5ic3A7IFRoaXMgZWxpbWluYXRlcyB0aGUgbmVlZCBmb3IgaW5pdGlhdG9yIHRvIGNvbXB1 dGUsIG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDox NC40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgc29tZXRpbWVzICZxdW90O2d1 ZXNzJnF1b3Q7LCB0aGUgJnF1b3Q7ZGVmYXVsdCZxdW90OyByZXR1cm4gcGF0aCBlbmNvZGluZy4m bmJzcDsgQW5kIHRoYXQgd2lsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHJlc3Vs dCBpbiBzaW1wbGlmaWVkIGltcGxlbWVudGF0aW9ucyBhY3Jvc3MgdmVuZG9ycywgYW5kIHJlc3Vs dCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQu NHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGltcHJvdmVkIHVzYWJpbGl0eSB0 byBmaXQgb3BlcmF0aW9uYWwgbmVlZHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ LSBTZWMgMy4xLCBob3cgaXMgdGhpcyBkaWZmZXJlbnQgZnJvbSBSRkMgNzExMD8gSWYgc2FtZSwg cGxlYXNlIGNhbGwgaXQgb3V0IGhlcmUgYW5kIHJlbW92ZSBUQkQxIGFzIHNlYyA0LjEgb2YgUkZD NzExMCBhZGRlZCByZXBseSBtb2RlIDUgZm9yIHRoZSBzYW1lLiBJZiBkaWZmZXJlbnQNCiB0byB0 aGUgUkZDLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRob3NlIGRldGFpbHMgaGVyZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W05PQk9dIFJlcGx5IE1vZGUg aW50cm9kdWNlZCBieSBSRkM3MTEwIHNwZWNpZmllcyB0aGF0IE1QTFMgZWNobyByZXBseSBpcyB0 byBiZSBzZW50DQogb24gTFNQIGNvcnJlc3BvbmRpbmcgdG8gRkVDIGRlc2NyaWJlZCBpbiBSZXBs eSBQYXRoIFRMVi4gQWx0aG91Z2ggUmVwbHkgUGF0aCBUTFYgaGFzIGFkZGVkIEIgZmxhZyB0byBp bmRpY2F0ZSDigJxyZXZlcnNlIExTUOKAnSwgUmVwbHkgTW9kZSA1IHN0aWxsIHJlcXVpcmUgUmVw bHkgUGF0aCBUTFYgd2l0aCBCIGZsYWcgdG8gZGVzY3JpYmUg4oCccmV2ZXJzZSBMU1DigJ0uIFJl cGx5IFBhdGggVExWIGlzIGdvb2Qgd2hlbiB3YW50aW5nIHRvIHVzZSBzcGVjaWZpYw0KIExTUCBh cyByZXR1cm4gcGF0aCwgYnV0IGl04oCZcyBtb3JlIGRpZmZpY3VsdCB0aGFuIG5lY2Vzc2FyeSB3 aGVuIHdhbnRpbmcgdG8ganVzdCB1c2UgcmV2ZXJzZSBMU1AuIEkgd2lsbCBhZGQgc29tZSB0ZXh0 cyB0byBjbGFyaWZ5IHRoaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+JXNhbSAtIEFyZSB5b3Ugc2F5aW5nIHRoYXQgcmVwbHkgbW9k ZSA1IHdpdGggQiBiaXQgc2V0IGlzIG5vdCBzb2x2aW5nIHRoZSBwcm9ibGVtIG9yIG5vdCBvcHRp bWFsIChiZWNhdXNlIGEgVExWIGlzIGJlaW5nIGFkZGVkPykuIFRoZSB0ZXh0IGluIFJGQzcxMTAg c2F5cywgJnF1b3Q7QiAoQmlkaXJlY3Rpb25hbCk6IHRoZQ0KIHJldHVybiBwYXRoIGlzIHJlcXVp cmVkIHRvIGZvbGxvdyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSB0ZXN0ZWQgYmlkaXJlY3Rpb25h bCBMU1AuJm5ic3A7IElmIEIgYml0IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc2V0LCB0aGVyZSBpcyBubyBuZWVkIHRvIGNhcnJ5IGFueSBz cGVjaWZpYyByZXBseSBwYXRoIHN1Yi0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtUTFZzLCBhbmQgd2hlbiByZWNlaXZlZCwgdGhlIHN1Yi1UTFZzIFNIT1VMRCBiZSBpZ25v cmVkLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BcyBhdXRob3Igb2YgUkZDNzExMCBpcyBhbHNvIGF1dGhvciBvZiB0aGlzIGRyYWZ0 LCBpdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZmljYXRpb24uIEZyb20gd2hhdCBJIHNlZSwgdGhp cyBuZXcgcmVwbHkgbW9kZSAmbmJzcDtwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGlzIGFscmVhZHkg YWRkcmVzc2VkIGluIFJGQzcxMTAuDQogSWYgdGhlIG5ldyByZXBseSBtb2RlIGFkZHMgb3B0aW1p emF0aW9uIHRvIHRoZSBleGlzdGluZyBzb2x1dGlvbiwgd2h5IHRvIGFkZCBhIG5ldyBtb2RlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bTk9CTzJdIFJlcGx5IG1vZGUgNSByZXF1aXJlcyBhIFRMViwgd2hldGhl ciBvciBub3QgQiBiaXQgaXMgdXNlZC4gVGhlIHRleHQgZnJvbSBSRkM3MTEwIGFib3ZlIGRlc2Ny aWJlcywNCiBmdXJ0aGVyIHN1Yi1UTFYgaXMgbm90IHJlcXVpcmVkIHdoZW4gQiBiaXQgaXMgdXNl ZC4gU28geWVzLCBvbmUgYXNwZWN0IG9mIHRoaXMgZHJhZnQgaXMgb3B0aW1pemF0aW9uIG9uIGhv dyDigJxSZXBseSBNb2RlID0gUmV2ZXJzZSBMU1DigJ0gaXMgZGVzY3JpYmVkIChpLmUuIFJldmVy c2UgTFNQIFJlcGx5IE1vZGUgdmFsdWUgdGhhdCBkb2VzIG5vdCByZXF1aXJlIGFueSBUTFZzIG5v ciBzdWItVExWcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4lc2FtMiAtIFdlIG1heSBkaXNhZ3JlZSBoZXJl IGJ1dCB0aGF0IGlzIGV4YWN0bHkgbXkgcG9pbnQuIFdoeSB0byBpbnRyb2R1Y2Ugb25lIG1vcmUg bW9kZSBmb3IgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eT8gSWYgd2UgdGFrZSB0aGlzIHBhdGgsIHRo ZW4gd2Ugd2lsbCBlbmQgdXAgd2l0aCB0b28gbWFueSBvcHRpb25zLCB3aXRoIG9wdGltaXphdGlv biBhcyBhIHJlYXNvbi4gQXMgdGhlIGZ1bmN0aW9uYWxpdHkgaXMNCiBhbHJlYWR5IHNvbHZlZCBi eSBSRkM3MTEwLCBhbGJlaXQgZXh0cmEgVExWIHdoaWNoIGlzIGhhcm1sZXNzLCBJJ2QgcmF0aGVy IG5vdCBoYXZlIHRoaXMgbmV3IG1vZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5HZW5lcmFsIGNvbW1l bnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi Pi0gSSBiZWxpZXZlIHRoaXMgbmV3IGVuaGFuY2VtZW50IHdpbGwgb25seSBwcm92aWRlIGEgZGVn cmVlIG9mIHZhcmlhbmNlIHRvIFJGQzQzNzksIHdoZXJlIHRoZSByZXNwb25zZSBjb3VsZCBiZSBy ZWNlaXZlZCBiYWNrIGF0IGluaXRpYXRvci4gSGVyZSBpcyB3aHk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1pbmRlbnQ6Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjEuIElmIHRoZSByZXNwb25z ZSBpcyBub3QgcmVjZWl2ZWQgYmFjayBhdCBzb3VyY2UsIGV2ZW4gd2l0aCB0aGUgbmV3IFRMViwg b25lIGNhbm5vdCBjb25jbHVkZSB0aGF0IExTUCBpcyBicm9rZW4uJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltOT0JPXSBJdCBkZXBlbmRzIG9u IGhvdyB5b3UgbG9vayBhdCB0aGlzLiBXaXRoIHRoaXMgbmV3IFRMViwgaXQgaXMgZGlmZmljdWx0 IHRvIGZpZ3VyZQ0KIG91dCBpZiBsYWNrIG9mIHJlc3BvbnNlIGlzIGR1ZSB0byBzb21ldGhpbmcg YnJva2VuIG9yIHJlc3BvbmRlciBkaWRu4oCZdCBoYXZlIHRoZSByZXR1cm4gcGF0aCBzcGVjaWZp ZWQuIFdpdGggdGhpcyBuZXcgVExWLCBsaXN0IG9mIHJldHVybiBwYXRocyBhcmUgcHJvdmlkZWQu IFRodXMgbGFjayBvZiByZXNwb25zZSBtZWFucyBlaXRoZXIgc29tZXRoaW5nIGlzIGJyb2tlbiBv ciBub25lIG9mIHRoZSByZXR1cm4gcGF0aHMgc3BlY2lmaWVkIHdlcmUgYXZhaWxhYmxlDQogYXQg cmVzcG9uZGVyIOKApiB3aGljaCwgaWYgcmV0dXJuIHBhdGggbGlzdCBjb250YWluZWQgZXZlcnl0 aGluZywgdGhlbiBpdCBjYW4gb25seSBtZWFuIHNvbWV0aGluZyBpcyBicm9rZW4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JXNhbSAt IHRoZSBhc3N1bXB0aW9uIHlvdSBhcmUgbWFraW5nIGhlcmUgaXMsIHRoZSByZXNwb25kaW5nIG5v ZGUgaXMgYnJva2VuIGxvY2FsbHkuIElmIHRoZSByZXBseSBwYXRoIGluIHRoZSBtaWRkbGUgaXMg YnJva2VuLCB0aGlzIHdpbGwgc29sdXRpb24gbm90IGhlbHAgZWl0aGVyLCBiZWNhdXNlIHJlc3Bv bmRpbmcNCiBub2RlIHBpY2tzIHRoZSB0b3AgcmVwbHkgbW9kZSBhbmQgc2VuZHMgaXQuIEl0IGRv ZXNuJ3Qga25vdyB0byBwaWNrICMyIG9yIGxhdGVyIGluIHRoZSBsaXN0LCBiZWNhdXNlICMxIHJl c3BvbnNlIG1vZGUgZGlkbid0IG1ha2UgaXQgdG8gc291cmNlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J cyB0aGUgc2NvcGUgbGltaXRlZCB0byB0aGUgYWJpbGl0eSBvZiByZXNwb25kaW5nIG5vZGUgdG8g cmVwbHksIGhlbmNlIHByb3ZpZGluZyBtdWx0aXBsZSByZXBseSBtb2RlIG9wdGlvbnM/Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltOT0JPMl0gWW91IGFyZSBhYnNvbHV0ZWx5IHJpZ2h0IHRoYXQgcmVz cG9uZGVyIHdpbGwgbm90IGhhdmUgYW55IGtub3dsZWRnZSBvZiB3aGF0IGlzIGF2YWlsYWJsZQ0K IGluIHRyYW5zaXQgbm9kZSBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uIEkgdGhpbmsgd2UgYXJl IGRpc2N1c3NpbmcgZ2xhc3MgaXMgaGFsZiBmdWxsIG9yIGVtcHR5IHRob3VnaC4gTGV0IG1lIGdp dmUgb25lIHNjZW5hcmlvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJl4oCZcyBhc3NvY2lhdGVkIExTUCBi ZXR3ZWVuIG5vZGUgQSBhbmQgbm9kZSBCLiBMZXTigJlzIHNheSBwaW5nIGlzIGRvbmUgZnJvbSBu b2RlIEEgd2l0aCBqdXN0IFJldmVyc2UNCiBMU1AgUmVwbHkgTW9kZS4gSW4gdGhlIGZvcndhcmQg ZGlyZWN0aW9uLCBhIHRyYW5zaXQgbm9kZSBYIGluY29ycmVjdGx5IGZvcndhcmRzIHRoZSBwYWNr ZXQgdG8gbm9kZSBZLiBOb2RlIFkgaXMgbm90IHBhcnQgb2YgdGhpcyBMU1AsIHRodXMgbm9kZSBZ IHdpbGwgb2J2aW91c2x5IG5vdCBoYXZlIHJldmVyc2UgTFNQLiBJbiB0aGlzIGNhc2UsIHBpbmcg d2lsbCBqdXN0IHRpbWVvdXQgKGkuZS4gbm9kZSBZIGNhbm5vdCBzZW5kIE1QTFMgZWNobyByZXBs eQ0KIGR1ZSB0byBsYWNrIG9mIHJldmVyc2UgTFNQKS4gSG93ZXZlciwgaXQgaXMgdmVyeSBiZW5l ZmljaWFsIGZvciBub2RlIEEgdG8gc3RpbGwgZ2V0IOKAnGZlYyBtaXNtYXRjaOKAnSBlcnJvciBm cm9tIG5vZGUgWSBmb3IgZGlhZ25vc3RpYyBwdXJwb3NlLCBhbmQgdGhhdCB3aWxsIGJlIHBvc3Np YmxlIGlmIG5vZGUgWSBjYW4gcmVzcG9uZCB3aXRoIElQJm5ic3A7IHBhdGguIEluIHRoaXMgY2Fz ZSwgUmVwbHkgTW9kZSBPcmRlciBUTFYgY2FuIGhhdmUgKDEuIFJldmVyc2UNCiBMU1AsIDIuIElQ KSB3aGljaCBzYXRpc2ZpZXMgb3BlcmF0b3IgbmVlZHMgd2hpbHN0IHN0aWxsIHByb3ZpZGluZyBn b29kIGRpYWdub3N0aWMgaW4gY2FzZSBvZiBmYWlsdXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZHJh ZnQgaXMgaW5kZWVkIGEgc21hbGwgZW5oYW5jZW1lbnRzLCBidXQgYWRkcyB2YWx1ZSB0byBib3Ro IHNpbXBsaWNpdHkgYW5kIGRpYWdub3N0aWMgYXNwZWN0Lg0KIEhvcGVmdWxseSBJIHdhcyBzdWNj ZXNzZnVsIGluIHN3YXlpbmcgeW91IGluIHRoZSBkaXJlY3Rpb24gb2Yg4oCcc3VwcG9ydGl2ZeKA nSwgbGV0IG1lIGtub3c/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0yIC0gVGhpcyBhYm92ZSB3b3Jr cyBvbmx5IGlmIG5vZGUgWSBpcyB1cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgbmV3IFRMViA6RC4g TXkgdGFrZSBpcywgeW91IGNvdWxkIHN0aWxsIGRldGVjdCB0aGUgZXJyb3IgaW4gdGhlIGFib3Zl IHNjZW5hcmlvLCB3aXRob3V0IGFueSB1cGdyYWRlLCBhbGJlaXQgd2l0aCBhbiBleHRyYSByZXF1 ZXN0IHdpdGggZGlmZmVyZW50IHJlcGx5IG1vZGUgdHlwZS4gSSB0aGluaw0KIHdlIGJvdGggYWdy ZWUgdGhhdCB0aGlzIGVuaGFuY2VtZW50IGlzIG5vdCB0byBkaXNjb3ZlciBlcnJvcnMsIHdoaWNo IGNhbm5vdCBiZSBkaXNjb3ZlcmVkIHdpdGggUkZDNDM3OS4gUmF0aGVyLCBpdCBvcHRpbWlzZXMg aG93IGl0IGlzIGRpc2NvdmVyZWQgaS5lLiBvbmUgcmVxdWVzdCB2cyBtdWx0aXBsZSByZXF1ZXN0 cy4gV2l0aCB5b3VyIHByb3Bvc2FsLCBpbiBvcmRlciB0byBnYWluIHRoZSByZWFsIG9wdGltaXph dGlvbiwgeW91IG5lZWQgdG8NCiBoYXZlIHRoZSBzdXBwb3J0IG9uIGRldmljZXMgYWNyb3NzIHRo ZSBjb3JlLiBPbiB0aGUgY29udHJhcnksIGlmIHlvdSBidWlsZCBhcHBsaWNhdGlvbiwgd2hpY2gg aXMganVzdCBhIHdvcmtmbG93IHVwZ3JhZGUsIGFsbCBpdCBoYXMgZG8gaXMgaXNzdWUgbXVsdGlw bGUgcmVxdWVzdHMgd2hlbiB0aW1lb3V0IGhhcHBlbnMuIFRoaXMgZG9lc24ndCByZXF1aXJlIGFu eSB1cGdyYWRlIG9mIHMvdyBvbiB0aGUgbmV0d29yayBkZXZpY2VzLiBJbiBmYWN0DQogSSBrbm93 IG9mIGFwcGxpY2F0aW9ucyB3aGljaCBhbHJlYWR5IGRvIHRoYXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyBzYWlkIHRoYXQsIHdl IGJvdGggaGF2ZSBjbGFyaWZpZWQgdGhlIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0aGlzIGRyYWZ0 IG1lYW5zLiBXaGF0IHdlIGRpZmZlciBpcyBub3QgdGVjaG5pY2FsIGNvbnRlbnQsIHJhdGhlciB0 aGUgbmVlZCB0byBoYXZlIHRoaXMgc3RhbmRhcmRpemVkLCBjb25zaWRlcmluZyBjb3N0IG9mIHVw Z3JhZGluZyBWcyBvcHRpbWlzYXRpb24gZ2Fpbi4gSSdsbCBsZWF2ZSBpdCB0bw0KIFdHIHRvIHNl ZSwgaWYgaXQgcmVhbGx5IGZlZWxzIHRoZSBuZWVkIHRvIGVuaGFuY2UgYnkgc3RhbmRhcmRpemlu ZyBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Y2hlZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tc2FtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LU5vYm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgYWdhaW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LXNhbTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E108735xmbalnx01ciscoc_-- From nobody Tue Apr 15 18:08:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73941A0099 for ; Tue, 15 Apr 2014 18:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tybn-jsRpy4m for ; Tue, 15 Apr 2014 18:08:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 148391A00A7 for ; Tue, 15 Apr 2014 18:08:11 -0700 (PDT) Received: from mail14-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Apr 2014 01:07:29 +0000 Received: from mail14-va3 (localhost [127.0.0.1]) by mail14-va3-R.bigfish.com (Postfix) with ESMTP id D17FFC00C8 for ; Wed, 16 Apr 2014 01:07:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z579ehz9371I936eI542I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail14-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sesale@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(189002)(199002)(377454003)(164054003)(377424004)(81542001)(80976001)(81342001)(86362001)(92566001)(2656002)(4396001)(83322001)(76576001)(79102001)(15975445006)(19580405001)(19580395003)(15202345003)(77982001)(74316001)(80022001)(99286001)(99396002)(83072002)(85852003)(87936001)(66066001)(54356999)(50986999)(46102001)(74502001)(20776003)(33646001)(74662001)(76482001)(31966008)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB189; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:BC38FDBD.AEF22FCA.75DD034F.4F05051.202E5; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail14-va3 (localhost.localdomain [127.0.0.1]) by mail14-va3 (MessageSwitch) id 1397610446141758_19255; Wed, 16 Apr 2014 01:07:26 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.237]) by mail14-va3.bigfish.com (Postfix) with ESMTP id 1E04D1E0093 for ; Wed, 16 Apr 2014 01:07:26 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Apr 2014 01:07:21 +0000 Received: from BY2PR05MB189.namprd05.prod.outlook.com (10.242.39.140) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 16 Apr 2014 01:07:59 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB189.namprd05.prod.outlook.com (10.242.39.140) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 01:07:57 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.129]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.129]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 01:07:57 +0000 From: Santosh Esale To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt Thread-Index: AQHPTrZIrf3aXa2OXEWkCtZkrKP8TpsLOKRw Date: Wed, 16 Apr 2014 01:07:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 01834E39B7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/f5bjoLF-1YpzqlRIJp5sAOuq_kE Subject: [mpls] FW: New Version Notification for draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:08:14 -0000 V2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgLSBodHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWVzYWxlLW1wbHMtYXBwbC1hd2FyZS1sZHAtdGFyZ2V0ZWQtc2Vzc2lvbi0wMC50eHQNCnRo YXQgZGVzY3JpYmVzIGFwcGxpY2F0aW9uIGF3YXJlIHRhcmdldGVkIGxkcCBzZXNzaW9uLiBXZSB3 b3VsZCBhcHByZWNpYXRlIHlvdXIgZmVlZGJhY2sgYW5kIGFueSBjb21tZW50cyBvbiBpdC4NCg0K VGhhbmtzLA0KU2FudG9zaA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDIsIDIwMTQgMTo1NyBQTQ0KVG86IFJhdmVlbmRyYSBU b3J2aTsgU2FudG9zaCBFc2FsZTsgQ2hyaXMgQm93ZXJzOyBTYW50b3NoIEVzYWxlOyBDaHJpcyBC b3dlcnM7IFJhdmVlbmRyYSBUb3J2aQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1lc2FsZS1tcGxzLWFwcGwtYXdhcmUtbGRwLXRhcmdldGVkLXNlc3Npb24tMDAu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWVzYWxlLW1wbHMtYXBwbC1hd2Fy ZS1sZHAtdGFyZ2V0ZWQtc2Vzc2lvbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgU2FudG9zaCBFc2FsZSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQtZXNhbGUtbXBscy1hcHBsLWF3YXJlLWxkcC10YXJnZXRlZC1zZXNz aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQXBwbGljYXRpb25zIGF3YXJlIExEUCBUYXJnZXRl ZCBTZXNzaW9uDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA0LTAyDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWVzYWxlLW1wbHMtYXBwbC1hd2FyZS1sZHAtdGFyZ2V0 ZWQtc2Vzc2lvbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1lc2FsZS1tcGxzLWFwcGwtYXdhcmUtbGRwLXRhcmdldGVkLXNlc3Np b24vDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZXNh bGUtbXBscy1hcHBsLWF3YXJlLWxkcC10YXJnZXRlZC1zZXNzaW9uLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBSZWNlbnQgVGFyZ2V0ZWQgTERQIGFwcGxpY2F0aW9ucyBzdWNoIGFzIFJlbW90ZSBMRkEg YW5kIEJHUCBhdXRvDQogICBkaXNjb3ZlcnkgRkVDIDEyOSBwc2V1ZG93aXJlIG1heSBhdXRvbWF0 aWNhbGx5IGVzdGFibGlzaCBhIHRhcmdldGVkDQogICBMRFAgc2Vzc2lvbiB0byBhbnkgTFNSIGlu IHRoZSBjb3JlIG5ldHdvcmsuIFRoZSBzZW5kZXIgTFNSIGhhcw0KICAgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHRhcmdldGVkIGFwcGxpY2F0aW9ucyB0byBhZG1pbmlzdHJhdGl2ZWx5DQogICBjb250 cm9sIGluaXRpYXRpb24gb2YgdGhlIHNlc3Npb24uIEhvd2V2ZXIgdGhlIHJlY2VpdmVyIExTUiBo YXMgbm8NCiAgIHN1Y2ggaW5mb3JtYXRpb24gdG8gY29udHJvbCB0aGUgYWNjZXB0YW5jZSBvZiB0 aGlzIHNlc3Npb24uIFRoaXMNCiAgIGRvY3VtZW50IGRlZmluZXMgYSBtZWNoYW5pc20gdG8gYWR2 ZXJ0aXNlIFRhcmdldGVkIEFwcGxpY2F0aW9uDQogICBDYXBhYmlsaXR5IGR1cmluZyBzZXNzaW9u IGluaXRpYWxpemF0aW9uLiBBcyB0aGUgcmVjZWl2ZXIgTFNSIGJlY29tZXMNCiAgIGF3YXJlIG9m IHRhcmdldGVkIExEUCBhcHBsaWNhdGlvbnMsIGl0IG1heSBlc3RhYmxpc2ggYSBsaW1pdGVkIG51 bWJlcg0KICAgb2Ygc2Vzc2lvbnMgZm9yIGNlcnRhaW4gYXBwbGljYXRpb25zLiBJbiBhZGRpdGlv biwgZWFjaCB0YXJnZXRlZA0KICAgYXBwbGljYXRpb24gaXMgbWFwcGVkIHRvIExEUCBGRUMgRWxl bWVudHMgdG8gYWR2ZXJ0aXNlIG9ubHkgbmVjZXNzYXJ5DQogICBMRFAgRkVDIGxhYmVsIGJpbmRp bmdzIG92ZXIgdGhlIHNlc3Npb24uDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg0KDQo= From nobody Wed Apr 16 08:01:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3B61A01B0 for ; Wed, 16 Apr 2014 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Z4bKSN2KGM for ; Wed, 16 Apr 2014 08:01:17 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7481A01BC for ; Wed, 16 Apr 2014 08:01:17 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 79so10216564ykr.37 for ; Wed, 16 Apr 2014 08:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/Yti+8E/bs9mF0YppfBOFVdOcPqjdZD/T808w0gc36M=; b=YZ9JKLZZWuuLPVGF7mNCIlIv+JLCQChOH952tk8frQ7tRI68bBfT/wb4qUOvA9bAE8 ACOze4gwOgQu4QjN9w/ul6OOdJdigz6qVwJsbg3XhoNKfrcphFxpqbENZ/QjZrIRbedu Vco9W7svM0IiQZMPZfsFek0irUs8rPMD0j0/Mg3yG/psSz0HEzmzYRynC9D2JIKU6I0P +IHyomRnM5fFuwpfEUGpTYG/2K6eHmqRIN6C0Chd603M88E6CSXHdGtWMesPMFNMwpJe Km9HvXehXDlTTsRjeWkDNVDGa3h3wQFKSNI9Lb5RBB26MCyHuIGdLBAjw5tKn8jbYvLc vHrg== X-Gm-Message-State: ALoCoQlKBw3lzsLO2KBd9K4PquKACSeUZbf3m4OQ5DPme94O91BsAo+JGSfwQhL8X56dSIoDxDS2 MIME-Version: 1.0 X-Received: by 10.236.102.70 with SMTP id c46mr13337468yhg.40.1397660473651; Wed, 16 Apr 2014 08:01:13 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Wed, 16 Apr 2014 08:01:13 -0700 (PDT) In-Reply-To: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> Date: Wed, 16 Apr 2014 11:01:13 -0400 Message-ID: From: Eric Osborne To: Adrian Farrel Content-Type: multipart/mixed; boundary=20cf301af4530c9f5304f72a30d9 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mg-q5PxMirBO8g8cMFd19lBz_8g Cc: "mpls@ietf.org" , draft-ietf-mpls-extended-admin-group.all@tools.ietf.org, "mpls-chairs@tools.ietf.org" , ginsberg@cisco.com Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:01:22 -0000 --20cf301af4530c9f5304f72a30d9 Content-Type: text/plain; charset=UTF-8 HI Adrian- I'm ccing Les as well; he had some comments around section 2.3.1 (as did everyone else, and rightly so). Inline with EO#. Since the thread is rather large and it's easy to lose the changes, I have attached the candidate-05 draft to this email. It can be compared to draft-04, which is the latest posted version. Summary: most of the changes are no big deal, but I'm wrestling with how to exclude PCE cleanly. On Tue, Apr 1, 2014 at 5:39 PM, Adrian Farrel wrote: > Hello, > > I have done my usual AD review of your document upon receiving the > publication request. The purpose is to catch any issues that might > otherwise show up during IETF last call or IESG review and to get the > document into good shape so that those later reviews have a clearer > run. > > There are a few comments below that I would like you to look at. The > I-D is very short and simple, so there is not much to comment on, but > I have a few concerns, clarifications, and editorial points that I > hope you will look at. You are, of course, welcome to dispute any of > these points and discuss them with me on the WG mailing list. > > While you are working on this I will put the document into "Revised > I-D Needed" state and I will ask the WG chairs to send a notice about > this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they are > aware of the draft and can comment immediately or during IETF last call > if they have any concerns. > > Thanks for the work, > Adrian > > === > > This document adds a sub-TLV. I think it is your intention that this is > a sub-TLV of the Link TLV and not of the Administrative Group sub-TLV, > itself. That seems pretty important, so it needs to be stated clearly. > EO# Fixed. Old: --- 2. Extended Administrative Groups sub-TLV The Extended Administrative Groups sub-TLV is used... --- New: ---- 2. Extended Administrative Groups sub-TLV This document defines a sub-TLV of the Link TLV for both OSPF [RFC3630] and ISIS [RFC5305] called the Extended Administrative Groups (EAG) sub-TLV. The EAG sub-TLV is used... ---- OK? > --- > > The use case in para 2 of Section 1 is, of course, predicated on using > a single IGP domain (area/level) to cover the whole network that is > being discussed. That is OK, but the text should note this caveat lest > people think that admin colours are somehow globally unique. > EO# I agree that the use case you cite is probably a single-level case. But that doesn't mean EAG must be constrained to only a single level. An implementation that signals AG in RSVP can use it across multiple areas (that's really the point of signaling AG at all). I don't want to preclude that happening with EAG should someone decide to implement signaling of EAG in RSVP. To address your comment I have added a sentence to section 3. In its entirety: --- OLD ---- 3. Signaling Extended Administrative Groups in RSVP RSVP provides the ability to signal link affinity via the SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. Signaling EAG in RSVP is not addressed in this document. This document does not preclude addressing this in the future should it be deemed necessary ---- ---- NEW ---- 3. Signaling Extended Administrative Groups in RSVP RSVP provides the ability to signal link affinity via the SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. Signaling EAG in RSVP is not addressed in this document. This document does not preclude addressing this in the future should it be deemed necessary. Note that signaling EAG is RSVP is likely to be necessary to expand the use of EAG outside a single area/level, just as it is with AG --- but please see my comments later in this mail about PCEP. > --- > > Section 2.1 > > The EAG may > be of any length, but MUST be a multiple of 4 bytes. > > Is a zero-length TLV allowed? > EO# I'm not sure what it would actually *do*. Making clear that a TLV must actually contain some information in order to be useful is probably more necessary than I'd like to think. I live in a country where we have to say "this plastic bag is not a toy, do not give to infants" just in case someone thought otherwise...it is for those people that I propose the following text: --- OLD --- The EAG may be of any length, but MUST be a multiple of 4 bytes. ---- --- NEW ---- The EAG may be of any non-zero length, but MUST be a multiple of 4 bytes ----- OK? > --- > > 2.3.1 > EO# This section is rather confusing...multiple reviewers caught it. The current text in its entirety is: ---- OLD ---- 2.3.1. AG and EAG coexistence If a node advertises EAG it MAY also advertise AG. If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. If the AG and EAG advertised for a link differ, the EAG MUST take priority. This allows nodes which do not support EAG to obtain some link color information from the network, but also allow for an eventual migration away from AG. ---- and it was worded that way after a discussion on the list with Andy Malis and Tarek Saad. The intent is straightforward: in the event of a mismatch, prefer AG. > If a receiving node > notices that the AG differs from the first 32 bits of the EAG, it > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD > indicate this mismatch to the operator. > > If the AG and EAG advertised for a link differ, the EAG MUST take > priority. > > Aren't these two statements contradictory? > I suspect the final "EAG" is supposed to read "AG" to be consistent > with the first paragraph and also to match the first motivation given > immediately after. EO# Sort of. There are a few options here in the event of a mismatch: 1) use only AG 2) overwrite the first 32 bits of EAG with AG, then use the entire EAG. 3) use only EAG In the discussion with Andy and Tarek we came to agreement on #2. That's what the text in section 2.3.1 needs to say. I therefore propose the following for the entirety of section 2.3.1: ---- NEW ---- If a node advertises EAG it MAY also advertise AG. If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If a receiving node notices that the AG differs from the first 32 bits of the EAG, it SHOULD use the AG as the first 32 bits of the EAG, and SHOULD indicate this mismatch to the operator. This allows nodes which do not support EAG to obtain some link color information from the network, but also allow for an eventual migration away from AG. --- all this does is drop the sentence "If the AG and EAG advertised for a link differ, the EAG MUST take priority." as that clearly contradicted everything else in that section. > > This allows nodes which do not support EAG to obtain some > link color information from the network, but also allow for an > eventual migration away from AG. > > OTOH... > > 1. The second motivation seems to support EAG taking priority. > > 2. The first motivation seems to miss some really big issues concerning > non-support of EAG. You need to discuss this processing in relation > to signaling... > > Suppose a link is advertised with EAG and a node that does not > support EAG signals an LSP? EO# I don't think this applies, since there is no support for signaled EAG. It's purely for headend calculation. > > Suppose one end of a link supports EAG but the other does not and > a signaling message includes EAG and the upstream end of the link > ignores it? > EO# The same is true of one end signaling AG and the other not signaling anything; despite its widespread advertisement, AG is optional. I never thought there was any requirement for a TE link to have identical properties in both directions. Neither rfc3630 nor rfc5305 concern themselves with bidirectionality in any of the TE TLVs, nor does rfc5307. The implementations I'm familiar with perform a basic two-way connectivity check, but that's it. I would prefer to stay away from prescribing behavior here that is more restrictive than what's specified in the base documents. > I think you have some edge conditions to describe in section 2.3 > EO# No such conditions are discussed in any other RFC which specifies TE link properties, and we seem to have gotten along just fine. If you feel strongly about this then we can sort something out, but I'm reluctant to make the EAG document the place where all sorts of assumptions about CSPF get spelled out. > --- > > I read section 4.7.4 of RFC 3209 to compare it with what you say in > section 2.3.2 of this document. > > I read it to say: > - a link can only be excluded if it advertises a specific color > - a link can only be included if it advertises a specific color > Thus, failure to include AG means a link cannot be excluded according > to an exclusion requirement. But it also means that it cannot be > included according to an include or include-any requirement. EO# Right. It's a hole in 3209; that section assumes AG is always advertised. In my experience this is generally true in practice, and the implementations I know best have some default they assume if AG is not advertised. .... > I think this is functionally equivalent to RFC 3209. > That is, a link cannot be excluded on the basis of an unadvertised > affinity because it is assumed to be 0. > And a link cannot be included on the basis of an unadvertised affinity > because it is assumed to be 0. > > So it all ends up right in the end, but it took a lot of words! EO# Yeah...I wanted to make clear what 4.7.4 meant without adding some backdoor requirements to it. > > --- > > In Section 2.3.2 you have an "interesting" mix of advice and 2119 words. > .... Yes. Yes I did. I think s/MUST/SHOULD/ for the first MUST in 2.3.2, as well as some tweaking, fixes it. I propose: --- OLD---- Each implementation is free to choose its own method for handling this question. However, to allow for maximum interoperability an implementation MUST treat desired but unadvertised EAG bits as if they are set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node which wants the 127th EAG bit to be 1 MUST NOT use this link, as the assumption is than an unadvertised bit is set to 0. ---- --- NEW --- Each implementation is free to choose its own method for handling this question. However, to allow for maximum interoperability an implementation SHOULD treat desired but unadvertised EAG bits as if they are set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node which wants the 127th EAG bit to be 1 MUST NOT use this link when implementing the recommended behavior, as the assumption is than an unadvertised bit is set to 0. --- ... > But, one final question... > Why do you want to allow other modes of operation? > What is the benefit, and why didn't you call it out? EO# As with other uses of SHOULD (e.g., section 2.3.1) there is already at least one implementation out there and while it hews in large part to the document as written, I did not want to inadvertently deprecate it. > > --- > > Section 3 deliberately sidesteps the use of EAG in signaling. That is > "interesting" EO# You may recall from (Berlin? Orlando?) that I had a much longer section which wrestled with this. I took it out and swept the whole thing under the rug under direct advice of an AD at the mic. :) > and makes me assume that the use of EAG you have in mind > applies only at the point of explicit path selection (i.e. no loose > hop selection). > EO# Yes, that's the problem I'm trying to solve. I don't see much relevant to PCE (if the PCE is going to hand down an explicit path then why does it need to include any AG/EAG information at all?) and while I don't want to completely rule it out it seems like more than needs to be solved in this document. > I think that, in order to justify this work being limited to the IGPs > you need to be a bit more explicit, up front, that *your* use case > concerns pre-computation of paths. EO# well, no...not pre-computation. Headend computation. Pre-computation (at least the way I understand it) means offline+config push or something PCE-ish like that. > > Now, there are two places where path selection will be done: > 1. The head-end LSR > 2. A PCE > > So, you should pick one or both of these as your use case and state it > clearly. If you include PCE, you will need to look at the applicability > to PCEP (see Section 7.11 of RFC 5440). EO# If I'm sidestepping RSVP I might as well sidestep PCEP too. It isn't necessary for the use case EAG was developed for, and I'm not sure I see it being all that big of an issue. However....rfc5440 section 7.11 provides an LSPA which is a copy of the SESSION_ATTRIBUTE of C-Type 1 (that is, the one with the three link attribute tests). I did not see anything in 5440 which provided a copy of SESSION_ATTRIBUTE of C-Type 7 (with setup/holding prio but no attribute tests). This means that, as far as I can tell, it's not possible to emulate C-Type 7 in PCEP. This is really quite far outside the scope of the EAG document, but sweeping it under the rug gets ugly. I propose the following: - retitle section to "Signaling Extended Administrative Groups in RSVP and PCEP" - making the entirety of section 3 into: ---- 3. Signaling Extended Administrative Groups in RSVP and PCEP RSVP provides the ability to signal link affinity via the SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. Signaling EAG in RSVP is not addressed in this document. This document does not preclude addressing this in the future should it be deemed necessary.Note that signaling EAG is RSVP is likely to be necessary to expand the use of EAG outside a single area/level, just as it is with AG. The PCE Communication Protocol, or PCEP ( [RFC5440]) specifies an LSPA object which is essentially a copy of RFC3209's SESSION_ATTRIBUTE with C-Type 1. It does not provide a copy of the SESSION_ATTRIBUTE with C-Type 7. Thus, the only way to indicate setup/holding priority in PCEP is to also signal 32-bit AG values for Exclude-any, Include-any and Include-all. If a node which implements both EAG and PCEP wishes to signal setup and holding priorities in PCEP's LSPA, it has no choice but to use the LSPA with affinity constraints. A node which sends an LSPA in PCEP MUST populate the affinity constraint fields (Exclude-any, Include-any, Include-all) with the lower 32 bits of the relevant EAG. This document does not preclude addressing this in the future should it be deemed necessary. One possible approach is to standardize a PCEP object which is a mirror of the SESSION_ATTRIBUTE of C-Type 7. Another is to standardize a PCEP object which directly contains support for EAG. There may be other approaches. Any and all such approaches are outside the scope of this document ---------- I'm not sure I like it all that much but I can't think of a better approach that doesn't involve wrestling with the whole signaling question again. > > --- > > Section 5 could be made clearer by breaking the text out into separate > paragraphs or even separate sections. It would also be helpful to IANA > if you made little tables showing the exact information you want > recorded in each registry. > EO# I put in some paragraph breaks and cleaned the text up a bit.. If those aren't clear enough it's easy enough to work with IANA when they get around to allocating the codepoint. eric --20cf301af4530c9f5304f72a30d9 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-mpls-extended-admin-group-05-candidate.txt" Content-Disposition: attachment; filename="draft-ietf-mpls-extended-admin-group-05-candidate.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hu2qxxfe0 DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEUuIE9zYm9ybmUNCkludGVybmV0LURyYWZ0DQpJbnRlbmRlZCBzdGF0dXM6 IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMTYsIDIwMTQN CkV4cGlyZXM6IE9jdG9iZXIgMTgsIDIwMTQNCg0KDQogICAgICAgICAgICAgICBFeHRlbmRlZCBB ZG1pbmlzdHJhdGl2ZSBHcm91cHMgaW4gTVBMUy1URQ0KICAgICAgICAgICBkcmFmdC1pZXRmLW1w bHMtZXh0ZW5kZWQtYWRtaW4tZ3JvdXAtMDUtY2FuZGlkYXRlDQoNCkFic3RyYWN0DQoNCiAgIE1Q TFMtVEUgYWR2ZXJ0aXNlcyAzMiBhZG1pbmlzdHJhdGl2ZSBncm91cHMgKGNvbW1vbmx5IHJlZmVy cmVkIHRvIGFzDQogICAiY29sb3JzIiBvciAibGluayBjb2xvcnMiKSB1c2luZyB0aGUgQWRtaW5p c3RyYXRpdmUgR3JvdXAgc3ViLVRMViBvZg0KICAgdGhlIExpbmsgVExWLiAgVGhpcyBpcyBkZWZp bmVkIGZvciBPU1BGdjIgKFJGQzM2MzApLCBPU1BGdjMgKFJGQzUzMjkpDQogICBhbmQgSVNJUyAo UkZDNTMwNSkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYWRkcyBhIHN1Yi1UTFYgdG8gdGhlIElHUCBU RSBleHRlbnNpb25zLCAiRXh0ZW5kZWQNCiAgIEFkbWluaXN0cmF0aXZlIEdyb3VwIi4gIFRoaXMg c3ViLVRMViBwcm92aWRlcyBmb3IgYWRkaXRpb25hbA0KICAgYWRtaW5pc3RyYXRpdmUgZ3JvdXBz IChsaW5rIGNvbG9ycykgYmV5b25kIHRoZSBjdXJyZW50IGxpbWl0IG9mIDMyLg0KDQpSZXF1aXJl bWVudHMgTGFuZ3VhZ2UNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIx MTldLg0KDQpTdGF0dXMgb2YgVGhpcyBNZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMg c3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2Yg QkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC0NCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1 cnJlbnQvLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mu Ig0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9iZXIgMTgsIDIw MTQuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDE0IElFVEYgVHJ1 c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3Jz LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KDQoNCg0KT3Nib3JuZSAgICAgICAgICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgIGV4dGVuZGVkLWFkbWluLWdyb3VwcyAgICAgICAgICAgICAg IEFwcmlsIDIwMTQNCg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYg RG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBl ZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlz IGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQg bXVzdA0KICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNC5lIG9mDQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZS4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVj dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAy DQogICAyLiAgRXh0ZW5kZWQgQWRtaW5pc3RyYXRpdmUgR3JvdXBzIHN1Yi1UTFYgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDMNCiAgICAgMi4xLiAgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgICAyLjIuICBBZG1pbiBncm91 cCBudW1iZXJpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAg IDIuMy4gIEJhY2t3YXJkIGNvbXBhdGFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDQNCiAgICAgICAyLjMuMS4gIEFHIGFuZCBFQUcgY29leGlzdGVuY2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAgIDIuMy4yLiAgRGVzaXJlIGZvciB1 bmFkdmVydGlzZWQgRUFHIGJpdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAzLiAgU2ln bmFsaW5nIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQICBhbmQgUENFUCAg LiAgIDUNCiAgIDQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNg0KICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICA2LiAgQWNrbm93bGVk Z2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYN CiAgIDcuICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNg0KICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICAgIDcuMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgIEF1 dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNw0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIERvIHdlIG5lZWQgbW9yZSB0aGFu IDMyIGJpdHM/DQoNCiAgIFRoZSBJR1AgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IE1QTFMtVEUgKFJG Q3MgMzYzMCBbUkZDMzYzMF0gYW5kIDUzMDUNCiAgIFtSRkM1MzA1XSkgZGVmaW5lIGEgbGluayBU TFYga25vd24gYXMgQWRtaW5pc3RyYXRpdmUgR3JvdXAgKEFHKSB3aXRoDQogICBhIGxpbWl0IG9m IDMyIEFHcyBwZXIgbGluay4gIFRoZSBjb25jZXB0IG9mIEFkbWluaXN0cmF0aXZlIEdyb3Vwcw0K ICAgY29tZXMgZnJvbSBzZWN0aW9uIDYuMiBvZiBSRkMgMjcwMiBbUkZDMjcwMl0sIHdoaWNoIGNh bGxzIHRoZW0NCiAgIFJlc291cmNlIENsYXNzZXMuICBSRkNzIDM2MzAgW1JGQzM2MzBdIGFuZCA1 MzA1IFtSRkM1MzA1XSBkZXNjcmliZQ0KICAgdGhlIG1lY2hhbmljcyBvZiB0aGUgVExWIGFuZCB1 c2UgdGhlIHRlcm0gQWRtaW5pc3RyYXRpdmUgR3JvdXBzDQogICAoc29tZXRpbWVzIGFiYnJldmlh dGVkIGhlcmVpbiBhcyBBR3MpLCBhcyBkb2VzIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5ldHdvcmtz IGhhdmUgZ3Jvd24gb3ZlciB0aW1lLCBhbmQgTVBMUy1URSBoYXMgZ3Jvd24gcmlnaHQgYWxvbmcg d2l0aA0KICAgdGhlbS4gIEFkbWluaXN0YXRpdmUgR3JvdXBzIGFzIGFyZSBhZHZlcnRpc2VkIGFz IGEgZml4ZWQtbGVuZ3RoDQogICAzMi1iaXQgYml0bWFzay4gIFRoaXMgY2FuIGJlIHF1aXRlIGNv bnN0cmFpbmluZywgYXMgaXQgaXMgcG9zc2libGUgdG8NCiAgIHJ1biBvdXQgb2YgdmF1ZXMgcmF0 aGVyIHF1aWNrbHkuICBPbmUgc3VjaCB1c2UgY2FzZSBpcyAjNSBpbg0KICAgU2VjdGlvbiA2LjIg b2YgUkZDIDI3MDIgW1JGQzI3MDJdLCB1c2luZyBBR3MgdG8gY29uc3RyYWluIHRyYWZmaWMNCiAg IHdpdGhpbiBzcGVjaWZpYyB0b3BvbG9naWNhbCByZWdpb25zIG9mIHRoZSBuZXR3b3JrLiAgQSBs YXJnZSBuZXR3b3JrDQogICBtYXkgd2VsbCBoYXZlIGZhciBtb3JlIHRoYW4gMzIgZ2VvZ3JhcGhp YyByZWdpb25zLiAgT25lIHBhcnRpY3VsYXINCiAgIG9wZXJhdG9yIGJ1aWxkcyB0aGVpciBuZXR3 b3JrIGFsb25nIHRoZSBsaW5lcyBvZiB0aGlzIHVzZSBjYXNlLCB1c2luZw0KDQoNCg0KT3Nib3Ju ZSAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDE4LCAyMDE0ICAgICAgICAgICAgICAg IFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIGV4dGVuZGVkLWFkbWluLWdy b3VwcyAgICAgICAgICAgICAgIEFwcmlsIDIwMTQNCg0KDQogICBBR3MgdG8gZmxhZyBuZXR3b3Jr IHJlZ2lvbnMgZG93biB0byB0aGUgbWV0cm8gc2NhbGUsIGUuZy4gU2VhdHRsZSwNCiAgIFNhbiBG cmFuY2lzY28sIERhbGxhcywgQ2hpY2FnbywgU3QuIExvdWlzLCBldGMuICBNUExTLVRFIHR1bm5l bHMgYXJlDQogICB0aGVuIHNwZWNpZmllZCB3aXRoIGFmZmluaXRpZXMgdG8gaW5jbHVkZSBvciBl eGNsdWRlIHNwZWNpZmljIG1ldHJvDQogICByZWdpb25zIGluIHRoZWlyIHBhdGggY2FsY3VsYXRp b24uICBFYWNoIG1ldHJvIHJlZ2lvbiBpcyBnaXZlbiBpdHMNCiAgIG93biBiaXQgaW4gdGhlIEFH IGJpdG1hc2suICBUaGlzIG1lYW5zIHRoYXQgMzIgYml0cyBjYW4gb25seQ0KICAgKGNsZWFubHkp IHJlcHJlc2VudCAzMiBtZXRybyBhcmVhcy4gIEl0IHNob3VsZCBiZSBvYnZpb3VzIHRoYXQgMzIg bWF5DQogICBub3QgYmUgZW5vdWdoIGV2ZW4gZm9yIGEgVVMtYmFzZWQgbmV0d29yaywgbmV2ZXJt aW5kIGEgd29ybGR3aWRlDQogICBuZXR3b3JrLg0KDQogICBUaGVyZSBtYXkgYmUgc29tZSBvcHBv cnR1bml0eSBmb3IgY29sb3IgcmV1c2U7IHRoYXQgaXMsIGJpdCAweDggbWF5DQogICBtZWFuICdT ZWF0dGxlJyBvciAnUHJhZ3VlJyBvciAnU2luZ2Fwb3JlJyBkZXBlbmRpbmcgb24gdGhlIGdlb2dy YXBoeQ0KICAgaW4gd2hpY2ggaXQgaXMgdXNlZC4gIEluIHByYWN0aWNlLCBjb29yZGluYXRpbmcg dGhpcyByZXVzZSBpcyBmcmF1Z2h0DQogICB3aXRoIHBlcmlsIGFuZCB0aGUgcmV1c2UgZWZmZWN0 aXZlbHkgYmVjb21lcyB0aGUgbGltaXRpbmcgZmFjdG9yIGluDQogICBNUExTLVRFIGRlcGxveW1l bnQuICBXaXRoIHRoaXMgZXhhbXBsZSBpdCBpcyBub3QgcG9zc2libGUgdG8gYnVpbGQgYW4NCiAg IExTUCB3aGljaCBhdm9pZHMgU2VhdHRsZSB3aGlsZSBpbmNsdWRpbmcgUHJhZ3VlLCBhcyBpdCBp cyB0aGUgc2FtZSBBRw0KICAgdmFsdWUuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgRXh0 ZW5kZWQgQWRtaW5pc3RyYXRpdmUgR3JvdXBzIChFQUdzKS4gIFRoZQ0KICAgbnVtYmVyIG9mIEVB R3MgaGFzIG5vIGZpeGVkIGxpbWl0LCBpdCBpcyBjb25zdHJhaW5lZCBvbmx5IGJ5DQogICBwcm90 b2NvbC1zcGVjaWZpYyByZXN0cmljdGlvbnMgc3VjaCBhcyBMU0Egb3IgTVRVIHNpemUuICBXaGls ZSBhbg0KICAgb3BlcmF0b3IgbWF5IG9uZSBkYXkgbmVlZCB0byBnbyBiZXlvbmQgdGhlc2UgcHJv dG9jb2wtc3BlY2lmaWMNCiAgIHJlc3RyaWN0aW9ucywgYWxsb3cgZm9yIGFuIGFyYml0cmFyeSBu dW1iZXIgb2YgRUFHcyBzaG91bGQgZWFzaWx5DQogICBwcm92aWRlIHRoZSBvcGVyYXRvciB3aXRo IGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZiBiaXQgdmFsdWVzLCB0aHVzDQogICBubyBsb25nZXIg bWFraW5nIHRoZSBudW1iZXIgb2YgQUdzIGFuIGltcGVkaW1lbnQgdG8gbmV0d29yayBncm93dGgu DQoNCjIuICBFeHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBHcm91cHMgc3ViLVRMVg0KDQogICBUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBzdWItVExWIG9mIHRoZSBMaW5rIFRMViBmb3IgYm90aCBPU1BG DQogICBbUkZDMzYzMF0gYW5kIElTSVMgW1JGQzUzMDVdIGNhbGxlZCB0aGUgRXh0ZW5kZWQgQWRt aW5pc3RyYXRpdmUNCiAgIEdyb3VwcyAoRUFHKSBzdWItVExWLiAgVGhlIEVBRyBzdWItVExWIGlz IHVzZWQgaW4gYWRkaXRpb24gdG8gdGhlDQogICBBZG1pbmlzdHJhdGl2ZSBHcm91cHMgd2hlbiBh IG5vZGUgd2lzaGVzIHRvIGFkdmVydGlzZSBtb3JlIHRoYW4gMzINCiAgIGNvbG9ycyBmb3IgYSBs aW5rLiAgVGhlIEVBRyBzdWItVExWIGlzIG9wdGlvbmFsLiAgQ29leGlzdGVuY2Ugb2YgRUFHDQog ICBhbmQgQUcgVExWcyBpcyBjb3ZlcmVkIGluIFNlY3Rpb24gMi4zLjEgb2YgdGhpcyBkb2N1bWVu dC4NCg0KICAgVGhpcyBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtICdjb2xvcnMnIGFzIGEgc2hvcnRo YW5kIHRvIHJlZmVyIHRvDQogICBwYXJ0aWN1bGFyIGJpdHMgd2l0aCBhbiBBRyBvciBFQUcuICBU aGUgZXhhbXBsZXMgaW4gdGhpcyBkb2N1bWVudCB1c2UNCiAgICdyZWQnIHRvIHJlcHJlc2VudCB0 aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0IGluIHRoZSBBRyAocmVkID09IDB4MSksDQogICAnYmx1 ZScgdG8gcmVwcmVzZW50IHRoZSBzZWNvbmQgYml0IChibHVlID09IDB4MikuICBUbyBzYXkgdGhh dCBhIGxpbmsNCiAgIGhhcyBhIGdpdmVuIGNvbG9yIG9yIHRoYXQgdGhlIHNwZWNpZmllZCBjb2xv ciBpcyBzZXQgb24gdGhlIGxpbmsgaXMNCiAgIHRvIHNheSB0aGF0IHRoZSBjb3JyZXNwb25kaW5n IGJpdCBvciBiaXRzIGluIHRoZSBsaW5rJ3MgQUcgYXJlIHNldCB0bw0KICAgMS4NCg0KMi4xLiAg UGFja2V0IEZvcm1hdA0KDQogICBUaGUgZm9ybWF0IG9mIHRoZSBFeHRlbmRlZCBBZG1pbmlzdHJh dGl2ZSBHcm91cHMgc3ViLVRMViBpcyB0aGUgc2FtZQ0KICAgZm9yIGJvdGggT1NQRiBhbmQgSVNJ UzoNCg0KDQoNCg0KDQpPc2Jvcm5lICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMTgs IDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgZXh0ZW5kZWQtYWRtaW4tZ3JvdXBzICAgICAgICAgICAgICAgQXByaWwgMjAxNA0KDQoNCiAg ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgICAg ICAgICAgICAgICAgICAgRXh0ZW5kZWQgQWRtaW4gR3JvdXAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgLi4u Li4uLi4uLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgICAgfCAgICAgICAgICAgICAgICAgICBFeHRlbmRlZCBBZG1pbiBHcm91cCAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCg0KICAgVGhlIFR5cGUgb2YgdGhl IHN1Yi1UTFYgZm9yIE9TUEYgYW5kIElTSVMgaXMgVEJELiAgVGhlIExlbmd0aCBpcyB0aGUNCiAg IHNpemUgb2YgdGhlIEV4dGVuZGVkIEFkbWluIEdyb3VwIChFQUcpIHZhbHVlIGluIGJ5dGVzLiAg VGhlIEVBRyBtYXkNCiAgIGJlIG9mIGFueSBub24temVybyBsZW5ndGgsIGJ1dCBNVVNUIGJlIGEg bXVsdGlwbGUgb2YgNCBieXRlcy4gIFRoZQ0KICAgb25seSBsaW1pdHMgb24gRUFHIHNpemUgYXJl IHRob3NlIHdoaWNoIGFyZSBpbXBvc2VkIGJ5IHByb3RvY29sLQ0KICAgc3BlY2lmaWMgb3IgbWVk aWEtc3BlY2lmaWMgY29uc3RyYWludHMgKGUuZy4gbWF4IHBhY2tldCBsZW5ndGgpLg0KDQoyLjIu ICBBZG1pbiBncm91cCBudW1iZXJpbmcNCg0KICAgQnkgY29udmVudGlvbiwgdGhlIGV4aXN0aW5n IEFkbWluaXN0cmF0aXZlIEdyb3VwIFRMVnMgYXJlIG51bWJlcmVkIDANCiAgIChMU0IpIHRvIDMx IChNU0IpLiAgVGhlIEVBRyB2YWx1ZXMgYXJlIGEgc3VwZXJzZXQgb2YgQUcuICBUaGF0IGlzLA0K ICAgYml0cyAwLTMxIGluIHRoZSBFQUcgaGF2ZSB0aGUgc2FtZSBtZWFuaW5nIGFuZCBNVVNUIGhh dmUgdGhlIHNhbWUNCiAgIHZhbHVlcyBhcyBhbiBBRyBmbG9vZGVkIGZvciB0aGUgc2FtZSBsaW5r LiAgSWYgYW4gRUFHJ3MgbGVuZ3RoIGlzDQogICBtb3JlIHRoYW4gNCBieXRlcywgbnVtYmVyaW5n IGZvciB0aGVzZSBhZGRpdGlvbmFsIGJ5dGVzIHBpY2tzIHVwDQogICB3aGVyZSB0aGUgcHJldmlv dXMgYnl0ZSBsZWZ0IG9mZi4gIEZvciBleGFtcGxlLCB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQNCiAg IGJpdCBpbiB0aGUgNXRoIGJ5dGUgb2YgYW4gOC1ieXRlIEVBRyBpcyByZWZlcnJlZCB0byBhcyBi aXQgMzIuDQoNCjIuMy4gIEJhY2t3YXJkIGNvbXBhdGFiaWxpdHkNCg0KICAgVGhlcmUgYXJlIHR3 byBxdWVzdGlvbnMgdG8gY29uc2lkZXIgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aA0K ICAgZXhpc3RpbmcgQUcgaW1wbGVtZW50YXRpb25zIC0gaG93IGRvIEFHIGFuZCBFQUcgY29leGlz dCwgYW5kIHdoYXQNCiAgIGhhcHBlbnMgaWYgYSBub2RlIGhhcyBtYXRjaGluZyBjcml0ZXJpYSBm b3IgdW5hZHZlcnRpc2VkIEVBRyBiaXRzPw0KDQoyLjMuMS4gIEFHIGFuZCBFQUcgY29leGlzdGVu Y2UNCg0KICAgSWYgYSBub2RlIGFkdmVydGlzZXMgRUFHIGl0IE1BWSBhbHNvIGFkdmVydGlzZSBB Ry4NCg0KICAgSWYgYSBub2RlIGFkdmVydGlzZXMgYm90aCBBRyBhbmQgRUFHIHRoZW4gdGhlIGZp cnN0IDMyIGJpdHMgb2YgdGhlDQogICBFQUcgTVVTVCBiZSBpZGVudGljYWwgdG8gdGhlIGFkdmVy dGlzZWQgQUcuICBJZiBhIHJlY2VpdmluZyBub2RlDQogICBub3RpY2VzIHRoYXQgdGhlIEFHIGRp ZmZlcnMgZnJvbSB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgRUFHLCBpdA0KICAgU0hPVUxEIHVz ZSB0aGUgQUcgYXMgdGhlIGZpcnN0IDMyIGJpdHMgb2YgdGhlIEVBRywgYW5kIFNIT1VMRA0KICAg aW5kaWNhdGUgdGhpcyBtaXNtYXRjaCB0byB0aGUgb3BlcmF0b3IuICBUaGlzIGFsbG93cyBub2Rl cyB3aGljaCBkbw0KICAgbm90IHN1cHBvcnQgRUFHIHRvIG9idGFpbiBzb21lIGxpbmsgY29sb3Ig aW5mb3JtYXRpb24gZnJvbSB0aGUNCiAgIG5ldHdvcmssIGJ1dCBhbHNvIGFsbG93IGZvciBhbiBl dmVudHVhbCBtaWdyYXRpb24gYXdheSBmcm9tIEFHLg0KDQoNCg0KDQoNCg0KT3Nib3JuZSAgICAg ICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdl IDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIGV4dGVuZGVkLWFkbWluLWdyb3VwcyAg ICAgICAgICAgICAgIEFwcmlsIDIwMTQNCg0KDQoyLjMuMi4gIERlc2lyZSBmb3IgdW5hZHZlcnRp c2VkIEVBRyBiaXRzDQoNCiAgIFRoZSBleGlzdGluZyBBRyBzdWItVExWIGlzIG9wdGlvbmFsOyB0 aHVzIGEgbm9kZSBtYXkgYmUgY29uZmlndXJlZA0KICAgd2l0aCBhIHByZWZlcmVuY2UgdG8gaW5j bHVkZSByZWQgb3IgZXhjbHVkZSBibHVlLCBhbmQgYmUgZmFjZWQgd2l0aCBhDQogICBsaW5rIHRo YXQgaXMgbm90IGFkdmVydGlzaW5nIGEgdmFsdWUgZm9yIGVpdGhlciBibHVlIG9yIHJlZC4gIFdo YXQNCiAgIGRvZXMgYW4gaW1wbGVtZW50YXRpb24gZG8gaW4gdGhpcyBjYXNlPyAgSXQgc2hvdWxk bid0IGFzc3VtZSB0aGF0IHJlZA0KICAgaXMgc2V0LCBidXQgaXQgaXMgYWxzbyBhcmd1YWJseSBp bmNvcnJlY3QgdG8gYXNzdW1lIHRoYXQgcmVkIGlzIE5PVA0KICAgc2V0LCBhcyBhIGJpdCBtdXN0 IGZpcnN0IGV4aXN0IGJlZm9yZSBpdCBjYW4gYmUgc2V0IHRvIDAuDQoNCiAgIFByYWN0aWNhbGx5 IHNwZWFraW5nIHRoaXMgaGFzIG5vdCBiZWVuIGFuIGlzc3VlIGZvciBkZXBsb3ltZW50cywgYXMN CiAgIG1hbnkgaW1wbGVtZW50YXRpb25zIGFsd2F5cyBhZHZlcnRpc2UgdGhlIEFHIGJpdHMsIG9m dGVuIHdpdGggYQ0KICAgZGVmYXVsdCB2YWx1ZSBvZiAweDAwMDAwMDAwLiAgSG93ZXZlciwgdGhp cyBpc3N1ZSBtYXkgYmUgb2YgbW9yZQ0KICAgY29uY2VybiBvbmNlIEVBR3MgYXJlIGFkZGVkIHRv IHRoZSBuZXR3b3JrLiAgRUFHcyBtYXkgZXhpc3Qgb24gc29tZQ0KICAgbm9kZXMgYnV0IG5vdCBv dGhlcnMsIGFuZCB0aGUgRUFHIGxlbmd0aCBtYXkgYmUgbG9uZ2VyIGZvciBzb21lIGxpbmtzDQog ICB0aGFuIGZvciBvdGhlcnMuDQoNCiAgIEVhY2ggaW1wbGVtZW50YXRpb24gaXMgZnJlZSB0byBj aG9vc2UgaXRzIG93biBtZXRob2QgZm9yIGhhbmRsaW5nDQogICB0aGlzIHF1ZXN0aW9uLiAgSG93 ZXZlciwgdG8gYWxsb3cgZm9yIG1heGltdW0gaW50ZXJvcGVyYWJpbGl0eSBhbg0KICAgaW1wbGVt ZW50YXRpb24gU0hPVUxEIHRyZWF0IGRlc2lyZWQgYnV0IHVuYWR2ZXJ0aXNlZCBFQUcgYml0cyBh cyBpZg0KICAgdGhleSBhcmUgc2V0IHRvIDAuICBDb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIG5v ZGUgd2FudHMgdG8gb25seSB1c2UNCiAgIGxpbmtzIHdoZXJlIHRoZSAxMjd0aCBiaXQgb2YgYW4g RUFHIGlzIHNldCB0byAxLiAgSWYgYSBsaW5rIGlzIG9ubHkNCiAgIGFkdmVydGlzaW5nIDY0IEVB RyBiaXRzLCBjbGVhcmx5IHRoZSAxMjd0aCBFQUcgYml0IGlzIG5vdCBkZWZpbmVkIC0NCiAgIHRo YXQgaXMsIGl0IGlzIG5laXRoZXIgZXhwbGljaXRseSAwIG5vciAxLiAgVGhlIG5vZGUgd2hpY2gg d2FudHMgdGhlDQogICAxMjd0aCBFQUcgYml0IHRvIGJlIDEgTVVTVCBOT1QgdXNlIHRoaXMgbGlu ayB3aGVuIGltcGxlbWVudGluZyB0aGUNCiAgIHJlY29tbWVuZGVkIGJlaGF2aW9yLCBhcyB0aGUg YXNzdW1wdGlvbiBpcyB0aGFuIGFuIHVuYWR2ZXJ0aXNlZCBiaXQNCiAgIGlzIHNldCB0byAwLg0K DQogICBBIG5vZGUgTUFZIHByb3ZpZGUgb3RoZXIgc3RyYXRlZ2llcyBmb3IgaGFuZGxpbmcgdGhp cyBjYXNlLiAgQQ0KICAgc3RyYXRlZ3kgd2hpY2ggZGV2aWF0ZXMgZnJvbSB0aGUgcmVjb21tZW5k ZWQgYmVoYXZpb3IgaW4gdGhpcw0KICAgZG9jdW1lbnQgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZSwg aW4gb3JkZXIgdG8gcHJvdmlkZSBtYXhpbXVtDQogICBpbnRlcm9wZXJhYmlsaXR5Lg0KDQozLiAg U2lnbmFsaW5nIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQIGFuZCBQQ0VQ DQoNCiAgIFJTVlAgcHJvdmlkZXMgdGhlIGFiaWxpdHkgdG8gc2lnbmFsIGxpbmsgYWZmaW5pdHkg dmlhIHRoZQ0KICAgU0VTU0lPTl9BVFRSSUJVVEUgb2JqZWN0IHdpdGggQy1UeXBlIDEgaW4gUkZD IDMyMDkgW1JGQzMyMDldLg0KICAgU2lnbmFsaW5nIEVBRyBpbiBSU1ZQIGlzIG5vdCBhZGRyZXNz ZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoaXMNCiAgIGRvY3VtZW50IGRvZXMgbm90IHByZWNsdWRl IGFkZHJlc3NpbmcgdGhpcyBpbiB0aGUgZnV0dXJlIHNob3VsZCBpdCBiZQ0KICAgZGVlbWVkIG5l Y2Vzc2FyeS4gIE5vdGUgdGhhdCBzaWduYWxpbmcgRUFHIGlzIFJTVlAgaXMgbGlrZWx5IHRvIGJl DQogICBuZWNlc3NhcnkgdG8gZXhwYW5kIHRoZSB1c2Ugb2YgRUFHIG91dHNpZGUgYSBzaW5nbGUg YXJlYS9sZXZlbCwganVzdA0KICAgYXMgaXQgaXMgd2l0aCBBRy4NCg0KICAgVGhlIFBDRSBDb21t dW5pY2F0aW9uIFByb3RvY29sLCBvciBQQ0VQIFtSRkM1NDQwXSBzcGVjaWZpZXMgYW4gTFNQQQ0K ICAgb2JqZWN0IHdoaWNoIGlzIGVzc2VudGlhbGx5IGEgY29weSBvZiBSRkMzMjA5J3MgU0VTU0lP Tl9BVFRSSUJVVEUNCiAgIHdpdGggQy1UeXBlIDEuICBJdCBkb2VzIG5vdCBwcm92aWRlIGEgY29w eSBvZiB0aGUgU0VTU0lPTl9BVFRSSUJVVEUNCiAgIHdpdGggQy1UeXBlIDcuICBUaHVzLCB0aGUg b25seSB3YXkgdG8gaW5kaWNhdGUgc2V0dXAvaG9sZGluZyBwcmlvcml0eQ0KICAgaW4gUENFUCBp cyB0byBhbHNvIHNpZ25hbCAzMi1iaXQgQUcgdmFsdWVzIGZvciBFeGNsdWRlLWFueSwgSW5jbHVk ZS0NCiAgIGFueSBhbmQgSW5jbHVkZS1hbGwuDQoNCg0KDQpPc2Jvcm5lICAgICAgICAgICAgICAg ICBFeHBpcmVzIE9jdG9iZXIgMTgsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgZXh0ZW5kZWQtYWRtaW4tZ3JvdXBzICAgICAgICAgICAg ICAgQXByaWwgMjAxNA0KDQoNCiAgIElmIGEgbm9kZSB3aGljaCBpbXBsZW1lbnRzIGJvdGggRUFH IGFuZCBQQ0VQIHdpc2hlcyB0byBzaWduYWwgc2V0dXANCiAgIGFuZCBob2xkaW5nIHByaW9yaXRp ZXMgaW4gUENFUCdzIExTUEEsIGl0IGhhcyBubyBjaG9pY2UgYnV0IHRvIHVzZQ0KICAgdGhlIExT UEEgd2l0aCBhZmZpbml0eSBjb25zdHJhaW50cy4gIEEgbm9kZSB3aGljaCBzZW5kcyBhbiBMU1BB IGluDQogICBQQ0VQIE1VU1QgcG9wdWxhdGUgdGhlIGFmZmluaXR5IGNvbnN0cmFpbnQgZmllbGRz IChFeGNsdWRlLWFueSwNCiAgIEluY2x1ZGUtYW55LCBJbmNsdWRlLWFsbCkgd2l0aCB0aGUgbG93 ZXIgMzIgYml0cyBvZiB0aGUgcmVsZXZhbnQgRUFHLg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMg bm90IHByZWNsdWRlIGFkZHJlc3NpbmcgdGhpcyBpbiB0aGUgZnV0dXJlIHNob3VsZA0KICAgaXQg YmUgZGVlbWVkIG5lY2Vzc2FyeS4gIE9uZSBwb3NzaWJsZSBhcHByb2FjaCBpcyB0byBzdGFuZGFy ZGl6ZSBhDQogICBQQ0VQIG9iamVjdCB3aGljaCBpcyBhIG1pcnJvciBvZiB0aGUgU0VTU0lPTl9B VFRSSUJVVEUgb2YgQy1UeXBlIDcuDQogICBBbm90aGVyIGlzIHRvIHN0YW5kYXJkaXplIGEgUENF UCBvYmplY3Qgd2hpY2ggZGlyZWN0bHkgY29udGFpbnMNCiAgIHN1cHBvcnQgZm9yIEVBRy4gIFRo ZXJlIG1heSBiZSBvdGhlciBhcHByb2FjaGVzLiAgQW55IGFuZCBhbGwgc3VjaA0KICAgYXBwcm9h Y2hlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KNC4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZXh0ZW5zaW9uIGFkZHMgbm8gbmV3IHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zLg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlz IGRvY3VtZW50IHJlcXVlc3RzIGEgc3ViLVRMViBhbGxvY2F0aW9uIGluIGJvdGggT1NQRiBhbmQg SVNJUy4NCg0KICAgRm9yIE9TUEYsIHRoZSBuYW1lIHNwYWNlIGlzICJUeXBlcyBmb3Igc3ViLVRM VnMgb2YgVEUgTGluayBUTFYgKFZhbHVlDQogICAyKSIgaW4gdGhlICJPcGVuIFNob3J0ZXN0IFBh dGggRmlyc3QgKE9TUEYpIFRyYWZmaWMgRW5naW5lZXJpbmcNCiAgIFRMVnMiLg0KDQogICBGb3Ig SVNJUywgaXQgaXMgIlN1Yi1UTFZzIGZvciBUTFYgMjIsIDE0MSwgYW5kIDIyMiIgaW4gdGhlICJJ Uy1JUyBUTFYNCiAgIENvZGVwb2ludHMiIHJlZ2lzdHJ5LiAgRm9yIElTLUlTIHRoZSB2YWx1ZSBz aG91bGQgYmUgbWFya2VkICd5JyBmb3INCiAgIFN1Yi1UTFZzIDIyLCAxNDEgYW5kIDIyMjsgdGhp cyBpcyBpZGVudGljYWwgdG8gdGhlIGFsbG9jYXRpb24gZm9yIHRoZQ0KICAgQWRtaW5pc3RyYXRp dmUgR3JvdXAgc3ViLVRMViAodmFsdWUgMykuDQoNCiAgIEluIGJvdGggcmVnaXN0cmllcyB0aGUg Zmlyc3QgZnJlZSB2YWx1ZSBzaG91bGQgYmUgYXNzaWduZWQuICBBcyBvZg0KICAgdGhpcyB3cml0 aW5nLCB0aGF0J3MgMjYgaW4gdGhlIE9TUEYgcmVnaXN0cnkgYW5kIDE0IGluIHRoZSBJUy1JUw0K ICAgcmVnaXN0cnkuICBUaGUgU3ViLVRMViBzaG91bGQgYmUgY2FsZWQgIkV4dGVuZGVkIEFkbWlu aXN0cmF0aXZlDQogICBHcm91cCIuDQoNCjYuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoYW5r cyB0byBTYW50aWFnbyBBbHZhcmV6LCBSb2hpdCBHdXB0YSwgTGllbSBOZ3V5ZW4sIFRhcmVrIFNh YWQsDQogICBSb2JlcnQgU2F3YXlhLCBBbmR5IE1hbGlzLCBMZXMgR2luc2JlcmcgYW5kIEFkcmlh biBGYXJyZWwgZm9yIHRoZWlyDQogICByZXZpZXcgYW5kIGNvbW1lbnRzLg0KDQo3LiAgUmVmZXJl bmNlcw0KDQo3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0K DQoNCg0KDQpPc2Jvcm5lICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMTgsIDIwMTQg ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgZXh0 ZW5kZWQtYWRtaW4tZ3JvdXBzICAgICAgICAgICAgICAgQXByaWwgMjAxNA0KDQoNCiAgIFtSRkMz MjA5XSAgQXdkdWNoZSwgRC4sIEJlcmdlciwgTC4sIEdhbiwgRC4sIExpLCBULiwgU3Jpbml2YXNh biwgVi4sDQogICAgICAgICAgICAgIGFuZCBHLiBTd2FsbG93LCAiUlNWUC1URTogRXh0ZW5zaW9u cyB0byBSU1ZQIGZvciBMU1ANCiAgICAgICAgICAgICAgVHVubmVscyIsIFJGQyAzMjA5LCBEZWNl bWJlciAyMDAxLg0KDQogICBbUkZDMzYzMF0gIEthdHosIEQuLCBLb21wZWxsYSwgSy4sIGFuZCBE LiBZZXVuZywgIlRyYWZmaWMgRW5naW5lZXJpbmcNCiAgICAgICAgICAgICAgKFRFKSBFeHRlbnNp b25zIHRvIE9TUEYgVmVyc2lvbiAyIiwgUkZDIDM2MzAsIFNlcHRlbWJlcg0KICAgICAgICAgICAg ICAyMDAzLg0KDQogICBbUkZDNTMwNV0gIExpLCBULiBhbmQgSC4gU21pdCwgIklTLUlTIEV4dGVu c2lvbnMgZm9yIFRyYWZmaWMNCiAgICAgICAgICAgICAgRW5naW5lZXJpbmciLCBSRkMgNTMwNSwg T2N0b2JlciAyMDA4Lg0KDQogICBbUkZDNTQ0MF0gIFZhc3NldXIsIEpQLiBhbmQgSkwuIExlIFJv dXgsICJQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQNCiAgICAgICAgICAgICAgKFBDRSkgQ29tbXVu aWNhdGlvbiBQcm90b2NvbCAoUENFUCkiLCBSRkMgNTQ0MCwgTWFyY2gNCiAgICAgICAgICAgICAg MjAwOS4NCg0KNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjcwMl0gIEF3 ZHVjaGUsIEQuLCBNYWxjb2xtLCBKLiwgQWdvZ2J1YSwgSi4sIE8nRGVsbCwgTS4sIGFuZCBKLg0K ICAgICAgICAgICAgICBNY01hbnVzLCAiUmVxdWlyZW1lbnRzIGZvciBUcmFmZmljIEVuZ2luZWVy aW5nIE92ZXIgTVBMUyIsDQogICAgICAgICAgICAgIFJGQyAyNzAyLCBTZXB0ZW1iZXIgMTk5OS4N Cg0KQXV0aG9yJ3MgQWRkcmVzcw0KDQogICBFcmljIE9zYm9ybmUNCg0KICAgRW1haWw6IGVyaWMu b3Nib3JuZUBub3Rjb20uY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCk9zYm9ybmUgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAxOCwg MjAxNCAgICAgICAgICAgICAgICBbUGFnZSA3XQ0K --20cf301af4530c9f5304f72a30d9-- From nobody Wed Apr 16 08:46:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642A01A0249 for ; Wed, 16 Apr 2014 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHumfvwChKSi for ; Wed, 16 Apr 2014 08:45:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BAF941A01AC for ; Wed, 16 Apr 2014 08:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25268; q=dns/txt; s=iport; t=1397663146; x=1398872746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5hBgfHTyuD13JIcVZHnRWGPlEUe14F3pwscjThObiuk=; b=fdwDAGm2+My0Iuwombp1Lkym3VcHpYXwNt0LiBcX3m5dNZ2dscjkFfRF LfZPbcHHiLvjkqVfpuMIL2Z8n7aF+z8ra/3fksJAsjdr+1rTGw1lNYHk/ kJbwXrWpyyrHbe4oulHaH9YJWB7uiqWOpQtp3hPQScBKFyUyn+VgiZRJf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFANakTlOtJV2d/2dsb2JhbABYgwaBEoMSwCMZgQgWdIIlAQEBAwEjERMnBAcFBwQCAQgRBAEBAQICBh0DAgICMBQBCAgCBAENBQiHbAilX4IKggiecxeBKYgUhEMKBgIBHjEHBoJpNYEUBJR5ljaDMYFpQg X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="318199782" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 16 Apr 2014 15:45:44 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3GFjiaA018880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 15:45:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 10:45:44 -0500 From: "Les Ginsberg (ginsberg)" To: Eric Osborne , Adrian Farrel Thread-Topic: AD review of draft-ietf-mpls-extended-admin-group Thread-Index: AQHPWYS49Zd+mwmEgEaj6NTc1415IJsUYTFA Date: Wed, 16 Apr 2014 15:45:43 +0000 Message-ID: References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.102.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qZ32hOrblAAYgb27EoF4-B4vhQA Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:45:57 -0000 RXJpYyAtDQoNClRoZSByZXZpc2VkIHRleHQgaW4gU2VjdGlvbiAyLjMuMSBhZGRyZXNzZXMgbXkg Y29uY2VybiAtIHRoYW54Lg0KDQpCdXQgSSBoYWQgYWxzbyBhc2tlZCB3aHkgdGhlIHBvdGVudGlh bCBjb25mbGljdCBiZXR3ZWVuIEFHIGFuZCBFQUcgY291bGQgbm90IGJlIGF2b2lkZWQgYWx0b2dl dGhlciBieSBkZWZpbmluZyBFQUcgYXMgcmVwcmVzZW50aW5nIHRoZSBncm91cHMgYmV5b25kIHRo ZSBmaXJzdCAzMiBkZWZpbmVkIGJ5IEFHLiBDb3VsZCB5b3UgcmVzcG9uZCB0byB0aGF0Pw0KDQpJ ZiB0aGUgYXJndW1lbnQgaXMgdGhhdCB5b3Ugd291bGQgbGlrZSBzb21lZGF5IHRvIGRlcHJlY2F0 ZSB0aGUgdXNlIG9mIEFHIEkgaGF2ZSB0byBzYXkgdGhhdCBJIGRvbuKAmXQgZmluZCB0aGF0IHZl cnkgY29tcGVsbGluZy4NCg0KICAgTGVzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBFcmljIE9zYm9ybmUgW21haWx0bzplcmljQG5vdGNvbS5jb21dDQo+IFNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgODowMSBBTQ0KPiBUbzogQWRyaWFuIEZhcnJlbA0K PiBDYzogZHJhZnQtaWV0Zi1tcGxzLWV4dGVuZGVkLWFkbWluLWdyb3VwLmFsbEB0b29scy5pZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsNCj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IExlcyBH aW5zYmVyZyAoZ2luc2JlcmcpDQo+IFN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1tcGxzLWV4dGVuZGVkLWFkbWluLWdyb3VwDQo+IA0KPiBISSBBZHJpYW4tDQo+IA0KPiAgIEkn bSBjY2luZyBMZXMgYXMgd2VsbDsgaGUgaGFkIHNvbWUgY29tbWVudHMgYXJvdW5kIHNlY3Rpb24g Mi4zLjEgKGFzDQo+IGRpZCBldmVyeW9uZSBlbHNlLCBhbmQgcmlnaHRseSBzbykuDQo+IElubGlu ZSB3aXRoIEVPIy4gIFNpbmNlIHRoZSB0aHJlYWQgaXMgcmF0aGVyIGxhcmdlIGFuZCBpdCdzIGVh c3kgdG8NCj4gbG9zZSB0aGUgY2hhbmdlcywgSSBoYXZlIGF0dGFjaGVkIHRoZSBjYW5kaWRhdGUt MDUgZHJhZnQgdG8gdGhpcw0KPiBlbWFpbC4gICBJdCBjYW4gYmUgY29tcGFyZWQgdG8gZHJhZnQt MDQsIHdoaWNoIGlzIHRoZSBsYXRlc3QgcG9zdGVkDQo+IHZlcnNpb24uDQo+IA0KPiBTdW1tYXJ5 OiBtb3N0IG9mIHRoZSBjaGFuZ2VzIGFyZSBubyBiaWcgZGVhbCwgYnV0IEknbSB3cmVzdGxpbmcg d2l0aA0KPiBob3cgdG8gZXhjbHVkZSBQQ0UgY2xlYW5seS4NCj4gDQo+IE9uIFR1ZSwgQXByIDEs IDIwMTQgYXQgNTozOSBQTSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gd3Jv dGU6DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBJIGhhdmUgZG9uZSBteSB1c3VhbCBBRCByZXZpZXcg b2YgeW91ciBkb2N1bWVudCB1cG9uIHJlY2VpdmluZyB0aGUNCj4gPiBwdWJsaWNhdGlvbiByZXF1 ZXN0LiBUaGUgcHVycG9zZSBpcyB0byBjYXRjaCBhbnkgaXNzdWVzIHRoYXQgbWlnaHQNCj4gPiBv dGhlcndpc2Ugc2hvdyB1cCBkdXJpbmcgSUVURiBsYXN0IGNhbGwgb3IgSUVTRyByZXZpZXcgYW5k IHRvIGdldCB0aGUNCj4gPiBkb2N1bWVudCBpbnRvIGdvb2Qgc2hhcGUgc28gdGhhdCB0aG9zZSBs YXRlciByZXZpZXdzIGhhdmUgYSBjbGVhcmVyDQo+ID4gcnVuLg0KPiA+DQo+ID4gVGhlcmUgYXJl IGEgZmV3IGNvbW1lbnRzIGJlbG93IHRoYXQgSSB3b3VsZCBsaWtlIHlvdSB0byBsb29rIGF0LiBU aGUNCj4gPiBJLUQgaXMgdmVyeSBzaG9ydCBhbmQgc2ltcGxlLCBzbyB0aGVyZSBpcyBub3QgbXVj aCB0byBjb21tZW50IG9uLCBidXQNCj4gPiBJIGhhdmUgYSBmZXcgY29uY2VybnMsIGNsYXJpZmlj YXRpb25zLCBhbmQgZWRpdG9yaWFsIHBvaW50cyB0aGF0IEkNCj4gPiBob3BlIHlvdSB3aWxsIGxv b2sgYXQuIFlvdSBhcmUsIG9mIGNvdXJzZSwgd2VsY29tZSB0byBkaXNwdXRlIGFueSBvZg0KPiA+ IHRoZXNlIHBvaW50cyBhbmQgZGlzY3VzcyB0aGVtIHdpdGggbWUgb24gdGhlIFdHIG1haWxpbmcg bGlzdC4NCj4gPg0KPiA+IFdoaWxlIHlvdSBhcmUgd29ya2luZyBvbiB0aGlzIEkgd2lsbCBwdXQg dGhlIGRvY3VtZW50IGludG8gIlJldmlzZWQNCj4gPiBJLUQgTmVlZGVkIiBzdGF0ZSBhbmQgSSB3 aWxsIGFzayB0aGUgV0cgY2hhaXJzIHRvIHNlbmQgYSBub3RpY2UgYWJvdXQNCj4gPiB0aGlzIEkt RCB0byB0aGUgT1NQRiwgSVNJUywgYW5kIENDQU1QIG1haWxpbmcgbGlzdHMgc28gdGhhdCB0aGV5 IGFyZQ0KPiA+IGF3YXJlIG9mIHRoZSBkcmFmdCBhbmQgY2FuIGNvbW1lbnQgaW1tZWRpYXRlbHkg b3IgZHVyaW5nIElFVEYgbGFzdCBjYWxsDQo+ID4gaWYgdGhleSBoYXZlIGFueSBjb25jZXJucy4N Cj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIHdvcmssDQo+ID4gQWRyaWFuDQo+ID4NCj4gPiA9PT0N Cj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgYWRkcyBhIHN1Yi1UTFYuIEkgdGhpbmsgaXQgaXMgeW91 ciBpbnRlbnRpb24gdGhhdCB0aGlzIGlzDQo+ID4gYSBzdWItVExWIG9mIHRoZSBMaW5rIFRMViBh bmQgbm90IG9mIHRoZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCBzdWItVExWLA0KPiA+IGl0c2VsZi4g VGhhdCBzZWVtcyBwcmV0dHkgaW1wb3J0YW50LCBzbyBpdCBuZWVkcyB0byBiZSBzdGF0ZWQgY2xl YXJseS4NCj4gPg0KPiANCj4gRU8jICBGaXhlZC4NCj4gDQo+IE9sZDoNCj4gLS0tDQo+IA0KPiAy LiAgRXh0ZW5kZWQgQWRtaW5pc3RyYXRpdmUgR3JvdXBzIHN1Yi1UTFYNCj4gDQo+ICAgIFRoZSBF eHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBHcm91cHMgc3ViLVRMViBpcyB1c2VkLi4uDQo+IC0tLQ0K PiANCj4gDQo+IE5ldzoNCj4gLS0tLQ0KPiAyLiAgRXh0ZW5kZWQgQWRtaW5pc3RyYXRpdmUgR3Jv dXBzIHN1Yi1UTFYNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN1Yi1UTFYgb2Yg dGhlIExpbmsgVExWIGZvciBib3RoIE9TUEYNCj4gICAgW1JGQzM2MzBdIGFuZCBJU0lTIFtSRkM1 MzA1XSBjYWxsZWQgdGhlIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlDQo+ICAgIEdyb3VwcyAoRUFH KSBzdWItVExWLiAgVGhlIEVBRyBzdWItVExWIGlzIHVzZWQuLi4NCj4gLS0tLQ0KPiANCj4gT0s/ DQo+IA0KPiA+IC0tLQ0KPiA+DQo+ID4gVGhlIHVzZSBjYXNlIGluIHBhcmEgMiBvZiBTZWN0aW9u IDEgaXMsIG9mIGNvdXJzZSwgcHJlZGljYXRlZCBvbiB1c2luZw0KPiA+IGEgc2luZ2xlIElHUCBk b21haW4gKGFyZWEvbGV2ZWwpIHRvIGNvdmVyIHRoZSB3aG9sZSBuZXR3b3JrIHRoYXQgaXMNCj4g PiBiZWluZyBkaXNjdXNzZWQuICBUaGF0IGlzIE9LLCBidXQgdGhlIHRleHQgc2hvdWxkIG5vdGUg dGhpcyBjYXZlYXQgbGVzdA0KPiA+IHBlb3BsZSB0aGluayB0aGF0IGFkbWluIGNvbG91cnMgYXJl IHNvbWVob3cgZ2xvYmFsbHkgdW5pcXVlLg0KPiA+DQo+IA0KPiBFTyMgICBJIGFncmVlIHRoYXQg dGhlIHVzZSBjYXNlIHlvdSBjaXRlIGlzIHByb2JhYmx5IGEgc2luZ2xlLWxldmVsDQo+IGNhc2Uu ICBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gRUFHIG11c3QgYmUgY29uc3RyYWluZWQgdG8gb25seSBh IHNpbmdsZQ0KPiBsZXZlbC4gIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgc2lnbmFscyBBRyBpbiBS U1ZQIGNhbiB1c2UgaXQgYWNyb3NzDQo+IG11bHRpcGxlIGFyZWFzICh0aGF0J3MgcmVhbGx5IHRo ZSBwb2ludCBvZiBzaWduYWxpbmcgQUcgYXQgYWxsKS4gIEkNCj4gZG9uJ3Qgd2FudCB0byBwcmVj bHVkZSB0aGF0IGhhcHBlbmluZyB3aXRoIEVBRyBzaG91bGQgc29tZW9uZSBkZWNpZGUNCj4gdG8g aW1wbGVtZW50IHNpZ25hbGluZyBvZiBFQUcgaW4gUlNWUC4NCj4gDQo+IFRvIGFkZHJlc3MgeW91 ciBjb21tZW50IEkgaGF2ZSBhZGRlZCBhIHNlbnRlbmNlIHRvIHNlY3Rpb24gMy4gIEluIGl0cw0K PiBlbnRpcmV0eToNCj4gDQo+IC0tLSBPTEQgLS0tLQ0KPiAzLiAgU2lnbmFsaW5nIEV4dGVuZGVk IEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQDQo+IA0KPiAgICBSU1ZQIHByb3ZpZGVzIHRo ZSBhYmlsaXR5IHRvIHNpZ25hbCBsaW5rIGFmZmluaXR5IHZpYSB0aGUNCj4gICAgU0VTU0lPTl9B VFRSSUJVVEUgb2JqZWN0IHdpdGggQy1UeXBlIDEgaW4gUkZDIDMyMDkgW1JGQzMyMDldLg0KPiAg ICBTaWduYWxpbmcgRUFHIGluIFJTVlAgaXMgbm90IGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50 LiAgVGhpcw0KPiAgICBkb2N1bWVudCBkb2VzIG5vdCBwcmVjbHVkZSBhZGRyZXNzaW5nIHRoaXMg aW4gdGhlIGZ1dHVyZSBzaG91bGQgaXQgYmUNCj4gICAgZGVlbWVkIG5lY2Vzc2FyeQ0KPiAtLS0t DQo+IA0KPiAtLS0tIE5FVyAtLS0tDQo+IDMuICBTaWduYWxpbmcgRXh0ZW5kZWQgQWRtaW5pc3Ry YXRpdmUgR3JvdXBzIGluIFJTVlANCj4gDQo+ICAgIFJTVlAgcHJvdmlkZXMgdGhlIGFiaWxpdHkg dG8gc2lnbmFsIGxpbmsgYWZmaW5pdHkgdmlhIHRoZQ0KPiAgICBTRVNTSU9OX0FUVFJJQlVURSBv YmplY3Qgd2l0aCBDLVR5cGUgMSBpbiBSRkMgMzIwOSBbUkZDMzIwOV0uDQo+ICAgIFNpZ25hbGlu ZyBFQUcgaW4gUlNWUCBpcyBub3QgYWRkcmVzc2VkIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzDQo+ ICAgIGRvY3VtZW50IGRvZXMgbm90IHByZWNsdWRlIGFkZHJlc3NpbmcgdGhpcyBpbiB0aGUgZnV0 dXJlIHNob3VsZCBpdCBiZQ0KPiAgICBkZWVtZWQgbmVjZXNzYXJ5Lg0KPiANCj4gICAgTm90ZSB0 aGF0IHNpZ25hbGluZyBFQUcgaXMgUlNWUCBpcyBsaWtlbHkgdG8gYmUgbmVjZXNzYXJ5IHRvIGV4 cGFuZA0KPiAgICB0aGUgdXNlIG9mIEVBRyBvdXRzaWRlIGEgc2luZ2xlIGFyZWEvbGV2ZWwsIGp1 c3QgYXMgaXQgaXMgd2l0aCBBRw0KPiAtLS0NCj4gDQo+IGJ1dCBwbGVhc2Ugc2VlIG15IGNvbW1l bnRzIGxhdGVyIGluIHRoaXMgbWFpbCBhYm91dCBQQ0VQLg0KPiANCj4gPiAtLS0NCj4gPg0KPiA+ IFNlY3Rpb24gMi4xDQo+ID4NCj4gPiAgIFRoZSBFQUcgbWF5DQo+ID4gICAgYmUgb2YgYW55IGxl bmd0aCwgYnV0IE1VU1QgYmUgYSBtdWx0aXBsZSBvZiA0IGJ5dGVzLg0KPiA+DQo+ID4gSXMgYSB6 ZXJvLWxlbmd0aCBUTFYgYWxsb3dlZD8NCj4gPg0KPiANCj4gRU8jICBJJ20gbm90IHN1cmUgd2hh dCBpdCB3b3VsZCBhY3R1YWxseSAqZG8qLiAgTWFraW5nIGNsZWFyIHRoYXQgYQ0KPiBUTFYgbXVz dCBhY3R1YWxseSBjb250YWluIHNvbWUgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gYmUgdXNlZnVs IGlzDQo+IHByb2JhYmx5IG1vcmUgbmVjZXNzYXJ5IHRoYW4gSSdkIGxpa2UgdG8gdGhpbmsuICBJ IGxpdmUgaW4gYSBjb3VudHJ5DQo+IHdoZXJlIHdlIGhhdmUgdG8gc2F5ICJ0aGlzIHBsYXN0aWMg YmFnIGlzIG5vdCBhIHRveSwgZG8gbm90IGdpdmUgdG8NCj4gaW5mYW50cyIganVzdCBpbiBjYXNl IHNvbWVvbmUgdGhvdWdodCBvdGhlcndpc2UuLi5pdCBpcyBmb3IgdGhvc2UNCj4gcGVvcGxlIHRo YXQgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4gDQo+IC0tLSBPTEQgLS0tDQo+IA0K PiBUaGUgRUFHIG1heQ0KPiAgICBiZSBvZiBhbnkgbGVuZ3RoLCBidXQgTVVTVCBiZSBhIG11bHRp cGxlIG9mIDQgYnl0ZXMuDQo+IC0tLS0NCj4gDQo+IA0KPiAtLS0gTkVXIC0tLS0NCj4gDQo+IFRo ZSBFQUcgbWF5IGJlIG9mIGFueSBub24temVybyBsZW5ndGgsIGJ1dCBNVVNUIGJlIGEgbXVsdGlw bGUgb2YgNCBieXRlcw0KPiAtLS0tLQ0KPiANCj4gT0s/DQo+IA0KPiANCj4gDQo+ID4gLS0tDQo+ ID4NCj4gPiAyLjMuMQ0KPiA+DQo+IA0KPiBFTyMgIFRoaXMgc2VjdGlvbiBpcyByYXRoZXIgY29u ZnVzaW5nLi4ubXVsdGlwbGUgcmV2aWV3ZXJzIGNhdWdodCBpdC4NCj4gVGhlIGN1cnJlbnQgdGV4 dCBpbiBpdHMgZW50aXJldHkgaXM6DQo+IA0KPiAtLS0tIE9MRCAtLS0tDQo+IDIuMy4xLiAgQUcg YW5kIEVBRyBjb2V4aXN0ZW5jZQ0KPiANCj4gICAgSWYgYSBub2RlIGFkdmVydGlzZXMgRUFHIGl0 IE1BWSBhbHNvIGFkdmVydGlzZSBBRy4NCj4gDQo+ICAgIElmIGEgbm9kZSBhZHZlcnRpc2VzIGJv dGggQUcgYW5kIEVBRyB0aGVuIHRoZSBmaXJzdCAzMiBiaXRzIG9mIHRoZQ0KPiAgICBFQUcgTVVT VCBiZSBpZGVudGljYWwgdG8gdGhlIGFkdmVydGlzZWQgQUcuICBJZiBhIHJlY2VpdmluZyBub2Rl DQo+ICAgIG5vdGljZXMgdGhhdCB0aGUgQUcgZGlmZmVycyBmcm9tIHRoZSBmaXJzdCAzMiBiaXRz IG9mIHRoZSBFQUcsIGl0DQo+ICAgIFNIT1VMRCB1c2UgdGhlIEFHIGFzIHRoZSBmaXJzdCAzMiBi aXRzIG9mIHRoZSBFQUcsIGFuZCBTSE9VTEQNCj4gICAgaW5kaWNhdGUgdGhpcyBtaXNtYXRjaCB0 byB0aGUgb3BlcmF0b3IuDQo+IA0KPiAgICBJZiB0aGUgQUcgYW5kIEVBRyBhZHZlcnRpc2VkIGZv ciBhIGxpbmsgZGlmZmVyLCB0aGUgRUFHIE1VU1QgdGFrZQ0KPiAgICBwcmlvcml0eS4gIFRoaXMg YWxsb3dzIG5vZGVzIHdoaWNoIGRvIG5vdCBzdXBwb3J0IEVBRyB0byBvYnRhaW4gc29tZQ0KPiAg ICBsaW5rIGNvbG9yIGluZm9ybWF0aW9uIGZyb20gdGhlIG5ldHdvcmssIGJ1dCBhbHNvIGFsbG93 IGZvciBhbg0KPiAgICBldmVudHVhbCBtaWdyYXRpb24gYXdheSBmcm9tIEFHLg0KPiAtLS0tDQo+ IA0KPiBhbmQgaXQgd2FzIHdvcmRlZCB0aGF0IHdheSBhZnRlciBhIGRpc2N1c3Npb24gb24gdGhl IGxpc3Qgd2l0aCBBbmR5DQo+IE1hbGlzIGFuZCBUYXJlayBTYWFkLg0KPiBUaGUgaW50ZW50IGlz IHN0cmFpZ2h0Zm9yd2FyZDogaW4gdGhlIGV2ZW50IG9mIGEgbWlzbWF0Y2gsIHByZWZlciBBRy4N Cj4gDQo+ID4gICAgSWYgYSByZWNlaXZpbmcgbm9kZQ0KPiA+ICAgIG5vdGljZXMgdGhhdCB0aGUg QUcgZGlmZmVycyBmcm9tIHRoZSBmaXJzdCAzMiBiaXRzIG9mIHRoZSBFQUcsIGl0DQo+ID4gICAg U0hPVUxEIHVzZSB0aGUgQUcgYXMgdGhlIGZpcnN0IDMyIGJpdHMgb2YgdGhlIEVBRywgYW5kIFNI T1VMRA0KPiA+ICAgIGluZGljYXRlIHRoaXMgbWlzbWF0Y2ggdG8gdGhlIG9wZXJhdG9yLg0KPiA+ DQo+ID4gICAgSWYgdGhlIEFHIGFuZCBFQUcgYWR2ZXJ0aXNlZCBmb3IgYSBsaW5rIGRpZmZlciwg dGhlIEVBRyBNVVNUIHRha2UNCj4gPiAgICBwcmlvcml0eS4NCj4gPg0KPiA+IEFyZW4ndCB0aGVz ZSB0d28gc3RhdGVtZW50cyBjb250cmFkaWN0b3J5Pw0KPiA+IEkgc3VzcGVjdCB0aGUgZmluYWwg IkVBRyIgaXMgc3VwcG9zZWQgdG8gcmVhZCAiQUciIHRvIGJlIGNvbnNpc3RlbnQNCj4gPiB3aXRo IHRoZSBmaXJzdCBwYXJhZ3JhcGggYW5kIGFsc28gdG8gbWF0Y2ggdGhlIGZpcnN0IG1vdGl2YXRp b24gZ2l2ZW4NCj4gPiBpbW1lZGlhdGVseSBhZnRlci4NCj4gDQo+IEVPIyAgU29ydCBvZi4gIFRo ZXJlIGFyZSBhIGZldyBvcHRpb25zIGhlcmUgaW4gdGhlIGV2ZW50IG9mIGEgbWlzbWF0Y2g6DQo+ IA0KPiAxKSB1c2Ugb25seSBBRw0KPiAyKSBvdmVyd3JpdGUgdGhlIGZpcnN0IDMyIGJpdHMgb2Yg RUFHIHdpdGggQUcsIHRoZW4gdXNlIHRoZSBlbnRpcmUgRUFHLg0KPiAzKSB1c2Ugb25seSBFQUcN Cj4gDQo+IA0KPiBJbiB0aGUgZGlzY3Vzc2lvbiB3aXRoIEFuZHkgYW5kIFRhcmVrIHdlIGNhbWUg dG8gYWdyZWVtZW50IG9uICMyLg0KPiBUaGF0J3Mgd2hhdCB0aGUgdGV4dCBpbiBzZWN0aW9uIDIu My4xIG5lZWRzIHRvIHNheS4NCj4gDQo+IEkgdGhlcmVmb3JlIHByb3Bvc2UgdGhlIGZvbGxvd2lu ZyBmb3IgdGhlIGVudGlyZXR5IG9mIHNlY3Rpb24gMi4zLjE6DQo+IA0KPiAtLS0tIE5FVyAtLS0t DQo+IA0KPiAgICBJZiBhIG5vZGUgYWR2ZXJ0aXNlcyBFQUcgaXQgTUFZIGFsc28gYWR2ZXJ0aXNl IEFHLg0KPiANCj4gICBJZiBhIG5vZGUgYWR2ZXJ0aXNlcyBib3RoIEFHIGFuZCBFQUcgdGhlbiB0 aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUNCj4gICAgRUFHIE1VU1QgYmUgaWRlbnRpY2FsIHRvIHRo ZSBhZHZlcnRpc2VkIEFHLiAgSWYgYSByZWNlaXZpbmcgbm9kZQ0KPiAgICBub3RpY2VzIHRoYXQg dGhlIEFHIGRpZmZlcnMgZnJvbSB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgRUFHLCBpdA0KPiAg ICBTSE9VTEQgdXNlIHRoZSBBRyBhcyB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgRUFHLCBhbmQg U0hPVUxEDQo+ICAgIGluZGljYXRlIHRoaXMgbWlzbWF0Y2ggdG8gdGhlIG9wZXJhdG9yLiAgVGhp cyBhbGxvd3Mgbm9kZXMgd2hpY2ggZG8NCj4gbm90IHN1cHBvcnQgRUFHIHRvIG9idGFpbiBzb21l DQo+ICAgIGxpbmsgY29sb3IgaW5mb3JtYXRpb24gZnJvbSB0aGUgbmV0d29yaywgYnV0IGFsc28g YWxsb3cgZm9yIGFuDQo+ICAgIGV2ZW50dWFsIG1pZ3JhdGlvbiBhd2F5IGZyb20gQUcuDQo+IC0t LQ0KPiANCj4gYWxsIHRoaXMgZG9lcyBpcyBkcm9wIHRoZSBzZW50ZW5jZSAiSWYgdGhlIEFHIGFu ZCBFQUcgYWR2ZXJ0aXNlZCBmb3IgYQ0KPiBsaW5rIGRpZmZlciwgdGhlIEVBRyBNVVNUIHRha2UN Cj4gICAgcHJpb3JpdHkuIiBhcyB0aGF0IGNsZWFybHkgY29udHJhZGljdGVkIGV2ZXJ5dGhpbmcg ZWxzZSBpbiB0aGF0IHNlY3Rpb24uDQo+IA0KPiANCj4gPg0KPiA+ICAgIFRoaXMgYWxsb3dzIG5v ZGVzIHdoaWNoIGRvIG5vdCBzdXBwb3J0IEVBRyB0byBvYnRhaW4gc29tZQ0KPiA+ICAgIGxpbmsg Y29sb3IgaW5mb3JtYXRpb24gZnJvbSB0aGUgbmV0d29yaywgYnV0IGFsc28gYWxsb3cgZm9yIGFu DQo+ID4gICAgZXZlbnR1YWwgbWlncmF0aW9uIGF3YXkgZnJvbSBBRy4NCj4gPg0KPiA+IE9UT0gu Li4NCj4gPg0KPiA+IDEuIFRoZSBzZWNvbmQgbW90aXZhdGlvbiBzZWVtcyB0byBzdXBwb3J0IEVB RyB0YWtpbmcgcHJpb3JpdHkuDQo+ID4NCj4gPiAyLiBUaGUgZmlyc3QgbW90aXZhdGlvbiBzZWVt cyB0byBtaXNzIHNvbWUgcmVhbGx5IGJpZyBpc3N1ZXMgY29uY2VybmluZw0KPiA+ICAgIG5vbi1z dXBwb3J0IG9mIEVBRy4gWW91IG5lZWQgdG8gZGlzY3VzcyB0aGlzIHByb2Nlc3NpbmcgaW4gcmVs YXRpb24NCj4gPiAgICB0byBzaWduYWxpbmcuLi4NCj4gPg0KPiA+ICAgIFN1cHBvc2UgYSBsaW5r IGlzIGFkdmVydGlzZWQgd2l0aCBFQUcgYW5kIGEgbm9kZSB0aGF0IGRvZXMgbm90DQo+ID4gICAg c3VwcG9ydCBFQUcgc2lnbmFscyBhbiBMU1A/DQo+IA0KPiBFTyMgIEkgZG9uJ3QgdGhpbmsgdGhp cyBhcHBsaWVzLCBzaW5jZSB0aGVyZSBpcyBubyBzdXBwb3J0IGZvcg0KPiBzaWduYWxlZCBFQUcu ICBJdCdzIHB1cmVseSBmb3IgaGVhZGVuZCBjYWxjdWxhdGlvbi4NCj4gDQo+ID4NCj4gPiAgICBT dXBwb3NlIG9uZSBlbmQgb2YgYSBsaW5rIHN1cHBvcnRzIEVBRyBidXQgdGhlIG90aGVyIGRvZXMg bm90IGFuZA0KPiA+ICAgIGEgc2lnbmFsaW5nIG1lc3NhZ2UgaW5jbHVkZXMgRUFHIGFuZCB0aGUg dXBzdHJlYW0gZW5kIG9mIHRoZSBsaW5rDQo+ID4gICAgaWdub3JlcyBpdD8NCj4gPg0KPiANCj4g RU8jICBUaGUgc2FtZSBpcyB0cnVlIG9mIG9uZSBlbmQgc2lnbmFsaW5nIEFHIGFuZCB0aGUgb3Ro ZXIgbm90DQo+IHNpZ25hbGluZyBhbnl0aGluZzsgZGVzcGl0ZSBpdHMgd2lkZXNwcmVhZCBhZHZl cnRpc2VtZW50LCBBRyBpcw0KPiBvcHRpb25hbC4NCj4gDQo+IEkgbmV2ZXIgdGhvdWdodCB0aGVy ZSB3YXMgYW55IHJlcXVpcmVtZW50IGZvciBhIFRFIGxpbmsgdG8gaGF2ZQ0KPiBpZGVudGljYWwg cHJvcGVydGllcyBpbiBib3RoIGRpcmVjdGlvbnMuICBOZWl0aGVyIHJmYzM2MzAgbm9yIHJmYzUz MDUNCj4gY29uY2VybiB0aGVtc2VsdmVzIHdpdGggYmlkaXJlY3Rpb25hbGl0eSBpbiBhbnkgb2Yg dGhlIFRFIFRMVnMsIG5vcg0KPiBkb2VzIHJmYzUzMDcuICBUaGUgaW1wbGVtZW50YXRpb25zIEkn bSBmYW1pbGlhciB3aXRoIHBlcmZvcm0gYSBiYXNpYw0KPiB0d28td2F5IGNvbm5lY3Rpdml0eSBj aGVjaywgYnV0IHRoYXQncyBpdC4NCj4gDQo+IEkgd291bGQgcHJlZmVyIHRvIHN0YXkgYXdheSBm cm9tIHByZXNjcmliaW5nIGJlaGF2aW9yIGhlcmUgdGhhdCBpcw0KPiBtb3JlIHJlc3RyaWN0aXZl IHRoYW4gd2hhdCdzIHNwZWNpZmllZCBpbiB0aGUgYmFzZSBkb2N1bWVudHMuDQo+IA0KPiA+ICAg IEkgdGhpbmsgeW91IGhhdmUgc29tZSBlZGdlIGNvbmRpdGlvbnMgdG8gZGVzY3JpYmUgaW4gc2Vj dGlvbiAyLjMNCj4gPg0KPiANCj4gRU8jICBObyBzdWNoIGNvbmRpdGlvbnMgYXJlIGRpc2N1c3Nl ZCBpbiBhbnkgb3RoZXIgUkZDIHdoaWNoIHNwZWNpZmllcw0KPiBURSBsaW5rIHByb3BlcnRpZXMs IGFuZCB3ZSBzZWVtIHRvIGhhdmUgZ290dGVuIGFsb25nIGp1c3QgZmluZS4gIElmDQo+IHlvdSBm ZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXMgdGhlbiB3ZSBjYW4gc29ydCBzb21ldGhpbmcgb3V0LCBi dXQgSSdtDQo+IHJlbHVjdGFudCB0byBtYWtlIHRoZSBFQUcgZG9jdW1lbnQgdGhlIHBsYWNlIHdo ZXJlIGFsbCBzb3J0cyBvZg0KPiBhc3N1bXB0aW9ucyBhYm91dCBDU1BGIGdldCBzcGVsbGVkIG91 dC4NCj4gDQo+ID4gLS0tDQo+ID4NCj4gPiBJIHJlYWQgc2VjdGlvbiA0LjcuNCBvZiBSRkMgMzIw OSB0byBjb21wYXJlIGl0IHdpdGggd2hhdCB5b3Ugc2F5IGluDQo+ID4gc2VjdGlvbiAyLjMuMiBv ZiB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gSSByZWFkIGl0IHRvIHNheToNCj4gPiAtIGEgbGlu ayBjYW4gb25seSBiZSBleGNsdWRlZCBpZiBpdCBhZHZlcnRpc2VzIGEgc3BlY2lmaWMgY29sb3IN Cj4gPiAtIGEgbGluayBjYW4gb25seSBiZSBpbmNsdWRlZCBpZiBpdCBhZHZlcnRpc2VzIGEgc3Bl Y2lmaWMgY29sb3INCj4gPiBUaHVzLCBmYWlsdXJlIHRvIGluY2x1ZGUgQUcgbWVhbnMgYSBsaW5r IGNhbm5vdCBiZSBleGNsdWRlZCBhY2NvcmRpbmcNCj4gPiB0byBhbiBleGNsdXNpb24gcmVxdWly ZW1lbnQuIEJ1dCBpdCBhbHNvIG1lYW5zIHRoYXQgaXQgY2Fubm90IGJlDQo+ID4gaW5jbHVkZWQg YWNjb3JkaW5nIHRvIGFuIGluY2x1ZGUgb3IgaW5jbHVkZS1hbnkgcmVxdWlyZW1lbnQuDQo+IA0K PiANCj4gRU8jICBSaWdodC4gIEl0J3MgYSBob2xlIGluIDMyMDk7IHRoYXQgc2VjdGlvbiBhc3N1 bWVzIEFHIGlzIGFsd2F5cw0KPiBhZHZlcnRpc2VkLiAgSW4gbXkgZXhwZXJpZW5jZSB0aGlzIGlz IGdlbmVyYWxseSB0cnVlIGluIHByYWN0aWNlLCBhbmQNCj4gdGhlIGltcGxlbWVudGF0aW9ucyBJ IGtub3cgYmVzdCBoYXZlIHNvbWUgZGVmYXVsdCB0aGV5IGFzc3VtZSBpZiBBRyBpcw0KPiBub3Qg YWR2ZXJ0aXNlZC4NCj4gDQo+IC4uLi4NCj4gDQo+ID4gSSB0aGluayB0aGlzIGlzIGZ1bmN0aW9u YWxseSBlcXVpdmFsZW50IHRvIFJGQyAzMjA5Lg0KPiA+IFRoYXQgaXMsIGEgbGluayBjYW5ub3Qg YmUgZXhjbHVkZWQgb24gdGhlIGJhc2lzIG9mIGFuIHVuYWR2ZXJ0aXNlZA0KPiA+IGFmZmluaXR5 IGJlY2F1c2UgaXQgaXMgYXNzdW1lZCB0byBiZSAwLg0KPiA+IEFuZCBhIGxpbmsgY2Fubm90IGJl IGluY2x1ZGVkIG9uIHRoZSBiYXNpcyBvZiBhbiB1bmFkdmVydGlzZWQgYWZmaW5pdHkNCj4gPiBi ZWNhdXNlIGl0IGlzIGFzc3VtZWQgdG8gYmUgMC4NCj4gPg0KPiA+IFNvIGl0IGFsbCBlbmRzIHVw IHJpZ2h0IGluIHRoZSBlbmQsIGJ1dCBpdCB0b29rIGEgbG90IG9mIHdvcmRzIQ0KPiANCj4gRU8j ICBZZWFoLi4uSSB3YW50ZWQgdG8gbWFrZSBjbGVhciB3aGF0IDQuNy40IG1lYW50IHdpdGhvdXQg YWRkaW5nDQo+IHNvbWUgYmFja2Rvb3IgcmVxdWlyZW1lbnRzIHRvIGl0Lg0KPiANCj4gPg0KPiA+ IC0tLQ0KPiA+DQo+ID4gSW4gU2VjdGlvbiAyLjMuMiB5b3UgaGF2ZSBhbiAiaW50ZXJlc3Rpbmci IG1peCBvZiBhZHZpY2UgYW5kIDIxMTkgd29yZHMuDQo+ID4NCj4gDQo+IC4uLi4NCj4gDQo+IFll cy4NCj4gWWVzIEkgZGlkLg0KPiANCj4gSSB0aGluayBzL01VU1QvU0hPVUxELyBmb3IgdGhlIGZp cnN0IE1VU1QgaW4gMi4zLjIsIGFzIHdlbGwgYXMgc29tZQ0KPiB0d2Vha2luZywgZml4ZXMgaXQu ICBJIHByb3Bvc2U6DQo+IA0KPiANCj4gLS0tICBPTEQtLS0tDQo+IA0KPiAgIEVhY2ggaW1wbGVt ZW50YXRpb24gaXMgZnJlZSB0byBjaG9vc2UgaXRzIG93biBtZXRob2QgZm9yIGhhbmRsaW5nDQo+ ICAgIHRoaXMgcXVlc3Rpb24uICBIb3dldmVyLCB0byBhbGxvdyBmb3IgbWF4aW11bSBpbnRlcm9w ZXJhYmlsaXR5IGFuDQo+ICAgIGltcGxlbWVudGF0aW9uIE1VU1QgdHJlYXQgZGVzaXJlZCBidXQg dW5hZHZlcnRpc2VkIEVBRyBiaXRzIGFzIGlmDQo+ICAgIHRoZXkgYXJlIHNldCB0byAwLiAgQ29u c2lkZXIgdGhlIGNhc2Ugd2hlcmUgYSBub2RlIHdhbnRzIHRvIG9ubHkgdXNlDQo+ICAgIGxpbmtz IHdoZXJlIHRoZSAxMjd0aCBiaXQgb2YgYW4gRUFHIGlzIHNldCB0byAxLiAgSWYgYSBsaW5rIGlz IG9ubHkNCj4gICAgYWR2ZXJ0aXNpbmcgNjQgRUFHIGJpdHMsIGNsZWFybHkgdGhlIDEyN3RoIEVB RyBiaXQgaXMgbm90IGRlZmluZWQgLQ0KPiAgICB0aGF0IGlzLCBpdCBpcyBuZWl0aGVyIGV4cGxp Y2l0bHkgMCBub3IgMS4gIFRoZSBub2RlIHdoaWNoIHdhbnRzIHRoZQ0KPiAgICAxMjd0aCBFQUcg Yml0IHRvIGJlIDEgTVVTVCBOT1QgdXNlIHRoaXMgbGluaywgYXMgdGhlIGFzc3VtcHRpb24gaXMN Cj4gICAgdGhhbiBhbiB1bmFkdmVydGlzZWQgYml0IGlzIHNldCB0byAwLg0KPiAtLS0tDQo+IA0K PiANCj4gLS0tIE5FVyAtLS0NCj4gDQo+ICAgRWFjaCBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRv IGNob29zZSBpdHMgb3duIG1ldGhvZCBmb3IgaGFuZGxpbmcNCj4gICAgdGhpcyBxdWVzdGlvbi4g IEhvd2V2ZXIsIHRvIGFsbG93IGZvciBtYXhpbXVtIGludGVyb3BlcmFiaWxpdHkgYW4NCj4gICAg aW1wbGVtZW50YXRpb24gU0hPVUxEIHRyZWF0IGRlc2lyZWQgYnV0IHVuYWR2ZXJ0aXNlZCBFQUcg Yml0cyBhcyBpZg0KPiAgICB0aGV5IGFyZSBzZXQgdG8gMC4gIENvbnNpZGVyIHRoZSBjYXNlIHdo ZXJlIGEgbm9kZSB3YW50cyB0byBvbmx5IHVzZQ0KPiAgICBsaW5rcyB3aGVyZSB0aGUgMTI3dGgg Yml0IG9mIGFuIEVBRyBpcyBzZXQgdG8gMS4gIElmIGEgbGluayBpcyBvbmx5DQo+ICAgIGFkdmVy dGlzaW5nIDY0IEVBRyBiaXRzLCBjbGVhcmx5IHRoZSAxMjd0aCBFQUcgYml0IGlzIG5vdCBkZWZp bmVkIC0NCj4gICAgdGhhdCBpcywgaXQgaXMgbmVpdGhlciBleHBsaWNpdGx5IDAgbm9yIDEuICBU aGUgbm9kZSB3aGljaCB3YW50cyB0aGUNCj4gICAgMTI3dGggRUFHIGJpdCB0byBiZSAxIE1VU1Qg Tk9UIHVzZSB0aGlzIGxpbmsgd2hlbiBpbXBsZW1lbnRpbmcgdGhlDQo+IHJlY29tbWVuZGVkIGJl aGF2aW9yLCBhcyB0aGUgYXNzdW1wdGlvbiBpcw0KPiAgICB0aGFuIGFuIHVuYWR2ZXJ0aXNlZCBi aXQgaXMgc2V0IHRvIDAuDQo+IC0tLQ0KPiANCj4gDQo+IC4uLg0KPiANCj4gPiBCdXQsIG9uZSBm aW5hbCBxdWVzdGlvbi4uLg0KPiA+IFdoeSBkbyB5b3Ugd2FudCB0byBhbGxvdyBvdGhlciBtb2Rl cyBvZiBvcGVyYXRpb24/DQo+ID4gV2hhdCBpcyB0aGUgYmVuZWZpdCwgYW5kIHdoeSBkaWRuJ3Qg eW91IGNhbGwgaXQgb3V0Pw0KPiANCj4gDQo+IEVPIyAgQXMgd2l0aCBvdGhlciB1c2VzIG9mIFNI T1VMRCAoZS5nLiwgc2VjdGlvbiAyLjMuMSkgdGhlcmUgaXMNCj4gYWxyZWFkeSBhdCBsZWFzdCBv bmUgaW1wbGVtZW50YXRpb24gb3V0IHRoZXJlIGFuZCB3aGlsZSBpdCBoZXdzIGluDQo+IGxhcmdl IHBhcnQgdG8gdGhlIGRvY3VtZW50IGFzIHdyaXR0ZW4sIEkgZGlkIG5vdCB3YW50IHRvIGluYWR2 ZXJ0ZW50bHkNCj4gZGVwcmVjYXRlIGl0Lg0KPiANCj4gPg0KPiA+IC0tLQ0KPiA+DQo+ID4gU2Vj dGlvbiAzIGRlbGliZXJhdGVseSBzaWRlc3RlcHMgdGhlIHVzZSBvZiBFQUcgaW4gc2lnbmFsaW5n LiBUaGF0IGlzDQo+ID4gImludGVyZXN0aW5nIg0KPiANCj4gRU8jICBZb3UgbWF5IHJlY2FsbCBm cm9tIChCZXJsaW4/ICBPcmxhbmRvPykgdGhhdCBJIGhhZCBhIG11Y2ggbG9uZ2VyDQo+IHNlY3Rp b24gd2hpY2ggd3Jlc3RsZWQgd2l0aCB0aGlzLiAgSSB0b29rIGl0IG91dCBhbmQgc3dlcHQgdGhl IHdob2xlDQo+IHRoaW5nIHVuZGVyIHRoZSBydWcgdW5kZXIgZGlyZWN0IGFkdmljZSBvZiBhbiBB RCBhdCB0aGUgbWljLiA6KQ0KPiANCj4gPiBhbmQgbWFrZXMgbWUgYXNzdW1lIHRoYXQgdGhlIHVz ZSBvZiBFQUcgeW91IGhhdmUgaW4gbWluZA0KPiA+IGFwcGxpZXMgb25seSBhdCB0aGUgcG9pbnQg b2YgZXhwbGljaXQgcGF0aCBzZWxlY3Rpb24gKGkuZS4gbm8gbG9vc2UNCj4gPiBob3Agc2VsZWN0 aW9uKS4NCj4gPg0KPiANCj4gRU8jICBZZXMsIHRoYXQncyB0aGUgcHJvYmxlbSBJJ20gdHJ5aW5n IHRvIHNvbHZlLiAgSSBkb24ndCBzZWUgbXVjaA0KPiByZWxldmFudCB0byBQQ0UgKGlmIHRoZSBQ Q0UgaXMgZ29pbmcgdG8gaGFuZCBkb3duIGFuIGV4cGxpY2l0IHBhdGgNCj4gdGhlbiB3aHkgZG9l cyBpdCBuZWVkIHRvIGluY2x1ZGUgYW55IEFHL0VBRyBpbmZvcm1hdGlvbiBhdCBhbGw/KSBhbmQN Cj4gd2hpbGUgSSBkb24ndCB3YW50IHRvIGNvbXBsZXRlbHkgcnVsZSBpdCBvdXQgaXQgc2VlbXMg bGlrZSBtb3JlIHRoYW4NCj4gbmVlZHMgdG8gYmUgc29sdmVkIGluIHRoaXMgZG9jdW1lbnQuDQo+ IA0KPiANCj4gPiBJIHRoaW5rIHRoYXQsIGluIG9yZGVyIHRvIGp1c3RpZnkgdGhpcyB3b3JrIGJl aW5nIGxpbWl0ZWQgdG8gdGhlIElHUHMNCj4gPiB5b3UgbmVlZCB0byBiZSBhIGJpdCBtb3JlIGV4 cGxpY2l0LCB1cCBmcm9udCwgdGhhdCAqeW91ciogdXNlIGNhc2UNCj4gPiBjb25jZXJucyBwcmUt Y29tcHV0YXRpb24gb2YgcGF0aHMuDQo+IA0KPiBFTyMgIHdlbGwsIG5vLi4ubm90IHByZS1jb21w dXRhdGlvbi4gIEhlYWRlbmQgY29tcHV0YXRpb24uDQo+IFByZS1jb21wdXRhdGlvbiAoYXQgbGVh c3QgdGhlIHdheSBJIHVuZGVyc3RhbmQgaXQpIG1lYW5zDQo+IG9mZmxpbmUrY29uZmlnIHB1c2gg b3Igc29tZXRoaW5nIFBDRS1pc2ggbGlrZSB0aGF0Lg0KPiANCj4gPg0KPiA+IE5vdywgdGhlcmUg YXJlIHR3byBwbGFjZXMgd2hlcmUgcGF0aCBzZWxlY3Rpb24gd2lsbCBiZSBkb25lOg0KPiA+IDEu IFRoZSBoZWFkLWVuZCBMU1INCj4gPiAyLiBBIFBDRQ0KPiA+DQo+ID4gU28sIHlvdSBzaG91bGQg cGljayBvbmUgb3IgYm90aCBvZiB0aGVzZSBhcyB5b3VyIHVzZSBjYXNlIGFuZCBzdGF0ZSBpdA0K PiA+IGNsZWFybHkuIElmIHlvdSBpbmNsdWRlIFBDRSwgeW91IHdpbGwgbmVlZCB0byBsb29rIGF0 IHRoZSBhcHBsaWNhYmlsaXR5DQo+ID4gdG8gUENFUCAoc2VlIFNlY3Rpb24gNy4xMSBvZiBSRkMg NTQ0MCkuDQo+IA0KPiBFTyMgIElmIEknbSBzaWRlc3RlcHBpbmcgUlNWUCBJIG1pZ2h0IGFzIHdl bGwgc2lkZXN0ZXAgUENFUCB0b28uICBJdA0KPiBpc24ndCBuZWNlc3NhcnkgZm9yIHRoZSB1c2Ug Y2FzZSBFQUcgd2FzIGRldmVsb3BlZCBmb3IsIGFuZCBJJ20gbm90DQo+IHN1cmUgSSBzZWUgaXQg YmVpbmcgYWxsIHRoYXQgYmlnIG9mIGFuIGlzc3VlLg0KPiANCj4gSG93ZXZlci4uLi5yZmM1NDQw IHNlY3Rpb24gNy4xMSBwcm92aWRlcyBhbiBMU1BBIHdoaWNoIGlzIGEgY29weSBvZg0KPiB0aGUg U0VTU0lPTl9BVFRSSUJVVEUgb2YgQy1UeXBlIDEgKHRoYXQgaXMsIHRoZSBvbmUgd2l0aCB0aGUg dGhyZWUNCj4gbGluayBhdHRyaWJ1dGUgdGVzdHMpLiAgSSBkaWQgbm90IHNlZSBhbnl0aGluZyBp biA1NDQwIHdoaWNoIHByb3ZpZGVkDQo+IGEgY29weSBvZiBTRVNTSU9OX0FUVFJJQlVURSBvZiBD LVR5cGUgNyAod2l0aCBzZXR1cC9ob2xkaW5nIHByaW8gYnV0DQo+IG5vIGF0dHJpYnV0ZSB0ZXN0 cykuDQo+IA0KPiBUaGlzIG1lYW5zIHRoYXQsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBpdCdzIG5v dCBwb3NzaWJsZSB0byBlbXVsYXRlDQo+IEMtVHlwZSA3IGluIFBDRVAuICBUaGlzIGlzIHJlYWxs eSBxdWl0ZSBmYXIgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlDQo+IEVBRyBkb2N1bWVudCwgYnV0 IHN3ZWVwaW5nIGl0IHVuZGVyIHRoZSBydWcgZ2V0cyB1Z2x5Lg0KPiANCj4gSSBwcm9wb3NlIHRo ZSBmb2xsb3dpbmc6DQo+IA0KPiAtIHJldGl0bGUgc2VjdGlvbiB0byAiU2lnbmFsaW5nIEV4dGVu ZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQDQo+ICBhbmQgUENFUCINCj4gLSBtYWtp bmcgdGhlIGVudGlyZXR5IG9mIHNlY3Rpb24gMyBpbnRvOg0KPiANCj4gLS0tLQ0KPiAzLiAgU2ln bmFsaW5nIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQIGFuZCBQQ0VQDQo+ IA0KPiAgICBSU1ZQIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIHNpZ25hbCBsaW5rIGFmZmluaXR5 IHZpYSB0aGUNCj4gICAgU0VTU0lPTl9BVFRSSUJVVEUgb2JqZWN0IHdpdGggQy1UeXBlIDEgaW4g UkZDIDMyMDkgW1JGQzMyMDldLg0KPiAgICBTaWduYWxpbmcgRUFHIGluIFJTVlAgaXMgbm90IGFk ZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KPiAgICBkb2N1bWVudCBkb2VzIG5vdCBw cmVjbHVkZSBhZGRyZXNzaW5nIHRoaXMgaW4gdGhlIGZ1dHVyZSBzaG91bGQgaXQgYmUNCj4gICAg ZGVlbWVkIG5lY2Vzc2FyeS5Ob3RlIHRoYXQgc2lnbmFsaW5nIEVBRyBpcyBSU1ZQIGlzIGxpa2Vs eSB0byBiZQ0KPiAgICBuZWNlc3NhcnkgdG8gZXhwYW5kIHRoZSB1c2Ugb2YgRUFHIG91dHNpZGUg YSBzaW5nbGUgYXJlYS9sZXZlbCwganVzdA0KPiAgICBhcyBpdCBpcyB3aXRoIEFHLg0KPiANCj4g ICAgVGhlIFBDRSBDb21tdW5pY2F0aW9uIFByb3RvY29sLCBvciBQQ0VQICggW1JGQzU0NDBdKSBz cGVjaWZpZXMgYW4NCj4gICAgTFNQQSBvYmplY3Qgd2hpY2ggaXMgZXNzZW50aWFsbHkgYSBjb3B5 IG9mIFJGQzMyMDkncw0KPiAgICBTRVNTSU9OX0FUVFJJQlVURSB3aXRoIEMtVHlwZSAxLiAgSXQg ZG9lcyBub3QgcHJvdmlkZSBhIGNvcHkgb2YgdGhlDQo+ICAgIFNFU1NJT05fQVRUUklCVVRFIHdp dGggQy1UeXBlIDcuICBUaHVzLCB0aGUgb25seSB3YXkgdG8gaW5kaWNhdGUNCj4gICAgc2V0dXAv aG9sZGluZyBwcmlvcml0eSBpbiBQQ0VQIGlzIHRvIGFsc28gc2lnbmFsIDMyLWJpdCBBRyB2YWx1 ZXMgZm9yDQo+ICAgIEV4Y2x1ZGUtYW55LCBJbmNsdWRlLWFueSBhbmQgSW5jbHVkZS1hbGwuDQo+ IA0KPiAgICBJZiBhIG5vZGUgd2hpY2ggaW1wbGVtZW50cyBib3RoIEVBRyBhbmQgUENFUCB3aXNo ZXMgdG8gc2lnbmFsIHNldHVwDQo+ICAgIGFuZCBob2xkaW5nIHByaW9yaXRpZXMgaW4gUENFUCdz IExTUEEsIGl0IGhhcyBubyBjaG9pY2UgYnV0IHRvIHVzZQ0KPiAgICB0aGUgTFNQQSB3aXRoIGFm ZmluaXR5IGNvbnN0cmFpbnRzLiAgQSBub2RlIHdoaWNoIHNlbmRzIGFuIExTUEEgaW4NCj4gICAg UENFUCBNVVNUIHBvcHVsYXRlIHRoZSBhZmZpbml0eSBjb25zdHJhaW50IGZpZWxkcyAoRXhjbHVk ZS1hbnksDQo+ICAgIEluY2x1ZGUtYW55LCBJbmNsdWRlLWFsbCkgd2l0aCB0aGUgbG93ZXIgMzIg Yml0cyBvZiB0aGUgcmVsZXZhbnQgRUFHLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBkb2VzIG5v dCBwcmVjbHVkZSBhZGRyZXNzaW5nIHRoaXMgaW4gdGhlIGZ1dHVyZSBzaG91bGQNCj4gICAgaXQg YmUgZGVlbWVkIG5lY2Vzc2FyeS4gIE9uZSBwb3NzaWJsZSBhcHByb2FjaCBpcyB0byBzdGFuZGFy ZGl6ZSBhDQo+ICAgIFBDRVAgb2JqZWN0IHdoaWNoIGlzIGEgbWlycm9yIG9mIHRoZSBTRVNTSU9O X0FUVFJJQlVURSBvZiBDLVR5cGUgNy4NCj4gICAgQW5vdGhlciBpcyB0byBzdGFuZGFyZGl6ZSBh IFBDRVAgb2JqZWN0IHdoaWNoIGRpcmVjdGx5IGNvbnRhaW5zDQo+ICAgIHN1cHBvcnQgZm9yIEVB Ry4gIFRoZXJlIG1heSBiZSBvdGhlciBhcHByb2FjaGVzLiAgQW55IGFuZCBhbGwgc3VjaA0KPiAg ICBhcHByb2FjaGVzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50DQo+IA0K PiAtLS0tLS0tLS0tDQo+IA0KPiBJJ20gbm90IHN1cmUgSSBsaWtlIGl0IGFsbCB0aGF0IG11Y2gg YnV0IEkgY2FuJ3QgdGhpbmsgb2YgYSBiZXR0ZXINCj4gYXBwcm9hY2ggdGhhdCBkb2Vzbid0IGlu dm9sdmUgd3Jlc3RsaW5nIHdpdGggdGhlIHdob2xlIHNpZ25hbGluZw0KPiBxdWVzdGlvbiBhZ2Fp bi4NCj4gDQo+IA0KPiA+DQo+ID4gLS0tDQo+ID4NCj4gPiBTZWN0aW9uIDUgY291bGQgYmUgbWFk ZSBjbGVhcmVyIGJ5IGJyZWFraW5nIHRoZSB0ZXh0IG91dCBpbnRvIHNlcGFyYXRlDQo+ID4gcGFy YWdyYXBocyBvciBldmVuIHNlcGFyYXRlIHNlY3Rpb25zLiBJdCB3b3VsZCBhbHNvIGJlIGhlbHBm dWwgdG8gSUFOQQ0KPiA+IGlmIHlvdSBtYWRlIGxpdHRsZSB0YWJsZXMgc2hvd2luZyB0aGUgZXhh Y3QgaW5mb3JtYXRpb24geW91IHdhbnQNCj4gPiByZWNvcmRlZCBpbiBlYWNoIHJlZ2lzdHJ5Lg0K PiA+DQo+IA0KPiBFTyMNCj4gSSBwdXQgaW4gc29tZSBwYXJhZ3JhcGggYnJlYWtzIGFuZCBjbGVh bmVkIHRoZSB0ZXh0IHVwIGEgYml0Li4gIElmDQo+IHRob3NlIGFyZW4ndCBjbGVhciBlbm91Z2gg aXQncyBlYXN5IGVub3VnaCB0byB3b3JrIHdpdGggSUFOQSB3aGVuIHRoZXkNCj4gZ2V0IGFyb3Vu ZCB0byBhbGxvY2F0aW5nIHRoZSBjb2RlcG9pbnQuDQo+IA0KPiANCj4gDQo+IGVyaWMNCg== From nobody Wed Apr 16 13:34:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141E1A0323 for ; Wed, 16 Apr 2014 13:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkm83K9L5EPR for ; Wed, 16 Apr 2014 13:34:48 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 17C961A0319 for ; Wed, 16 Apr 2014 13:34:47 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3GKYc5O013492; Wed, 16 Apr 2014 21:34:40 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3GKYb87013484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2014 21:34:38 +0100 From: "Adrian Farrel" To: "'Eric Osborne'" References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> In-Reply-To: Date: Wed, 16 Apr 2014 21:34:37 +0100 Message-ID: <026f01cf59b3$498206f0$dc8614d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKpL5+W0sa6mJDOUSo4Td2X+AZh7QIeJXIimVAFJfA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20636.002 X-TM-AS-Result: No--41.916-10.0-31-10 X-imss-scan-details: No--41.916-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBqia4DgZhuqkKcYi5Qw/RV4B7aueLmU0DRqlQSmOxzwSpf 0VJZhlxPxILoPou7rql4pCeR88U2tLlepOYfePOtjHD5RTSnfNYL8TGleseLPOouc5Rcf1B0rQX C1SFTGNKRQDQlsTzp4FcwU7sUg1nXzXJtm1treZzPfDU9TFrh71p4YXccYb4Aut/GVGOoEnfK6Q TLokP+5vr9EKYdevQDKjAaBfogMSzC5N8cNUn/XpRrnSy7UTtb4NWkOcSKu5SPaLJ/Ca3STx2zS NU8sHP2Iy3HDLsnLN4XEwVubrp8YflYy+7Yif7Jw69AIwXJn0a/yN2q8U674qvM+zzl/BST2swx lZZYMJYsaIhkWkXTGZCCPgbCpGAQ75CbtOD2Mbdor4yxPAz7WaHErxDyhjvn7Mph6duptjjUZkF 1QAMbmbE6r97RMXlAUprcJdSjBlNMYGDZwqUelFrg+64w70HIXs5nqGvDCfNq4coTktrGX3L8Lj gGIWWC+ZkmrqBQPhlw/kDAWT5EzpHy7oM4lvOn9Ib/6w+1lWTS82QW/rFQIwlbhF7ZTanLaWb+H 6zFWTgYm40je29QvgpFnoQqvQIhGjOqfdkgWO0gKw/iul4Zx9GOcAfHKa6uYOY2t32U5vomfs5a 44EdZ/cHVq8TMhwbqxCKfoQYPAWFAkj1gUYTeg44iiXIXUwcINC+F8tjh5XIs4CjQ/C5uUdIauW 0nwSG7wl/zyfIag94ACv80RlEImpw4IniioZq2Hdvv/MGE3UyGiaSs0n67Luqk4cq52pzjd4YOV wZNZQ2k3XExUp4OnGACX4W17aanQmRYcv5/FmeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dTJEZ5_ArJhdzZePJUNoqDg3wkc Cc: mpls@ietf.org, draft-ietf-mpls-extended-admin-group.all@tools.ietf.org, mpls-chairs@tools.ietf.org, ginsberg@cisco.com Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 20:34:52 -0000 Hi Eric, Comments in line with appropriate snipping. Update and post when ready. Thanks, Adrian > > The use case in para 2 of Section 1 is, of course, predicated on = using > > a single IGP domain (area/level) to cover the whole network that is > > being discussed. That is OK, but the text should note this caveat = lest > > people think that admin colours are somehow globally unique. > > >=20 > EO# I agree that the use case you cite is probably a single-level > case. But that doesn't mean EAG must be constrained to only a single > level. An implementation that signals AG in RSVP can use it across > multiple areas (that's really the point of signaling AG at all). I > don't want to preclude that happening with EAG should someone decide > to implement signaling of EAG in RSVP. >=20 > To address your comment I have added a sentence to section 3. In its = entirety: >=20 > --- OLD ---- > 3. Signaling Extended Administrative Groups in RSVP >=20 > RSVP provides the ability to signal link affinity via the > SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. > Signaling EAG in RSVP is not addressed in this document. This > document does not preclude addressing this in the future should it = be > deemed necessary > ---- >=20 > ---- NEW ---- > 3. Signaling Extended Administrative Groups in RSVP >=20 > RSVP provides the ability to signal link affinity via the > SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. > Signaling EAG in RSVP is not addressed in this document. This > document does not preclude addressing this in the future should it = be > deemed necessary. >=20 > Note that signaling EAG is RSVP is likely to be necessary to expand > the use of EAG outside a single area/level, just as it is with AG s/is RSVP/in RSVP/ This change helps. But I think it slightly misses my point that the colors have meaning = specific to an administrative domain. It is unclear how one = administrative domain knows the meanings of the colors in another = domain. And this is worse than an ERO: an ERO can be encoded (perhaps = from the CLI) to span multiple domains because the addresses/labels/etc = only have meaning at the point they are examined. The color is applied = to the whole LSP not embedded in the ERO with the result that the domain = boundary may have to translate the colors for use in the next domain. I would argue that it is not practical for two domains to coordinate = their use of colors. > > Section 2.1 > > > > The EAG may > > be of any length, but MUST be a multiple of 4 bytes. > > > > Is a zero-length TLV allowed? > > >=20 > EO# I'm not sure what it would actually *do*. Making clear that a > TLV must actually contain some information in order to be useful is > probably more necessary than I'd like to think. I live in a country > where we have to say "this plastic bag is not a toy, do not give to > infants" just in case someone thought otherwise...it is for those > people that I propose the following text: >=20 > --- OLD --- >=20 > The EAG may > be of any length, but MUST be a multiple of 4 bytes. > ---- >=20 >=20 > --- NEW ---- >=20 > The EAG may be of any non-zero length, but MUST be a multiple of 4 = bytes > ----- >=20 > OK? Yes. (I'd hate for your code to crash in the field when my code sends it = a 0-length EAG :-) > > 2.3.1 > > >=20 > EO# This section is rather confusing...multiple reviewers caught it. > The current text in its entirety is: >=20 > ---- OLD ---- > 2.3.1. AG and EAG coexistence >=20 > If a node advertises EAG it MAY also advertise AG. >=20 > If a node advertises both AG and EAG then the first 32 bits of the > EAG MUST be identical to the advertised AG. If a receiving node > notices that the AG differs from the first 32 bits of the EAG, it > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD > indicate this mismatch to the operator. >=20 > If the AG and EAG advertised for a link differ, the EAG MUST take > priority. This allows nodes which do not support EAG to obtain = some > link color information from the network, but also allow for an > eventual migration away from AG. > ---- >=20 > and it was worded that way after a discussion on the list with Andy > Malis and Tarek Saad. > The intent is straightforward: in the event of a mismatch, prefer AG. >=20 > > If a receiving node > > notices that the AG differs from the first 32 bits of the EAG, it > > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD > > indicate this mismatch to the operator. > > > > If the AG and EAG advertised for a link differ, the EAG MUST take > > priority. > > > > Aren't these two statements contradictory? > > I suspect the final "EAG" is supposed to read "AG" to be consistent > > with the first paragraph and also to match the first motivation = given > > immediately after. >=20 > EO# Sort of. There are a few options here in the event of a = mismatch: >=20 > 1) use only AG > 2) overwrite the first 32 bits of EAG with AG, then use the entire = EAG. > 3) use only EAG >=20 > In the discussion with Andy and Tarek we came to agreement on #2. > That's what the text in section 2.3.1 needs to say. >=20 > I therefore propose the following for the entirety of section 2.3.1: >=20 > ---- NEW ---- >=20 > If a node advertises EAG it MAY also advertise AG. >=20 > If a node advertises both AG and EAG then the first 32 bits of the > EAG MUST be identical to the advertised AG. If a receiving node > notices that the AG differs from the first 32 bits of the EAG, it > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD > indicate this mismatch to the operator. This allows nodes which do > not support EAG to obtain some > link color information from the network, but also allow for an > eventual migration away from AG. > --- >=20 > all this does is drop the sentence "If the AG and EAG advertised for a > link differ, the EAG MUST take > priority." as that clearly contradicted everything else in that = section. I feel the need to mutter :-) Why the first SHOULD? (And actually, why the need to compare the values?) I'd suggest If a node advertises EAG it MAY also advertise AG. =20 If a node advertises both AG and EAG then the first 32 bits of the EAG MUST be identical to the advertised AG. If both an AG and EAG are present, a receiving node MUST use the AG as the first 32 bits (0-31) of administrative color and use the = EAG for bits 32 and higher if present. A receiving node that notices that the AG differs from the first 32 bits of the EAG, SHOULD report this mismatch to the operator. =20 This process allows nodes which do not support EAG to obtain some link color information from the network, but also allow for an eventual migration away from AG. > > 2. The first motivation seems to miss some really big issues = concerning > > non-support of EAG. You need to discuss this processing in = relation > > to signaling... OK, I re-read Section 3. You are punting on signaling. And in fact Section 3 is completely factually correct, while my review = suffered from being written front-to-back as I read the draft. > > I read section 4.7.4 of RFC 3209 to compare it with what you say in > > section 2.3.2 of this document. > > > > I read it to say: > > - a link can only be excluded if it advertises a specific color > > - a link can only be included if it advertises a specific color > > Thus, failure to include AG means a link cannot be excluded = according > > to an exclusion requirement. But it also means that it cannot be > > included according to an include or include-any requirement. >=20 > EO# Right. It's a hole in 3209; that section assumes AG is always > advertised. In my experience this is generally true in practice, and > the implementations I know best have some default they assume if AG is > not advertised. Oh, I don't think it is a hole at all! The text is clear (to me) and works (IMHO) when AG is not advertised. Recall, 3209 is about signaling not path computation. We want to avoid: "I want chocolate ice cream." "Here is some ice cream, = I have no idea what flavor it is." However, you are saying that most implementations are saying "If you = don't tell me, I will assume all ice cream is raspberry." But this is a side-track... > > So it all ends up right in the end, but it took a lot of words! > > --- =20 > > But, one final question... > > Why do you want to allow other modes of operation? > > What is the benefit, and why didn't you call it out? >=20 > EO# As with other uses of SHOULD (e.g., section 2.3.1) there is > already at least one implementation out there and while it hews in > large part to the document as written, I did not want to inadvertently > deprecate it. I appreciate your sensitivity. But tough! :-) We are documenting how things should work according to WG consensus, not = how we hope things work in the field already. So I stick with my suggested summary... |- All implementations MUST support a mode of operation that assumes | absent affinities are set to 0 |- Implementations MAY support other modes of operation |- Implementations that support other modes of operation MUST have allow | configuration to select the mode of operation, and MUST default to | assume that absent affinities are set to 0 > > Section 3 deliberately sidesteps the use of EAG in signaling. That = is > > "interesting" >=20 > EO# You may recall from (Berlin? Orlando?) that I had a much longer > section which wrestled with this. I took it out and swept the whole > thing under the rug under direct advice of an AD at the mic. :) >=20 > > and makes me assume that the use of EAG you have in mind > > applies only at the point of explicit path selection (i.e. no loose > > hop selection). >=20 > EO# Yes, that's the problem I'm trying to solve. I don't see much > relevant to PCE (if the PCE is going to hand down an explicit path > then why does it need to include any AG/EAG information at all?) and > while I don't want to completely rule it out it seems like more than > needs to be solved in this document. >=20 > > I think that, in order to justify this work being limited to the = IGPs > > you need to be a bit more explicit, up front, that *your* use case > > concerns pre-computation of paths. >=20 > EO# well, no...not pre-computation. Headend computation. > Pre-computation (at least the way I understand it) means > offline+config push or something PCE-ish like that. If you lived in a transit node, you would see "pre-computation" as the = path was already computed when I received the signaling message. Looking at all of this, I think the hole I fell into is found under the = question "Why is AG present in signaling in RFC 3209?" The answer to = that question, I believe, is to allow transit nodes to expand loose = hops, and to allow transit nodes to verify that a signaled path conforms = to the admin colors requested for the LSP (also applies to local = repair). What you are saying (and it is fine to say it, although it would be = better to say it in the I-D :-) is that at the moment, all envisaged = usage of EAG is achieved at the headend or in a PCE. That means that = there is no perceived use of EAG in signaling just as (you presumably = contend) AG is not used in signaling today. > > Now, there are two places where path selection will be done: > > 1. The head-end LSR > > 2. A PCE > > > > So, you should pick one or both of these as your use case and state = it > > clearly. If you include PCE, you will need to look at the = applicability > > to PCEP (see Section 7.11 of RFC 5440). >=20 > EO# If I'm sidestepping RSVP I might as well sidestep PCEP too. It > isn't necessary for the use case EAG was developed for, and I'm not > sure I see it being all that big of an issue. This is OK. The use case you described in the document did not explain = that the intent is headend computation of a full explicit path. Maybe = just a few words in the Introduction would clean all this up. > However....rfc5440 section 7.11 provides an LSPA which is a copy of > the SESSION_ATTRIBUTE of C-Type 1 (that is, the one with the three > link attribute tests). I did not see anything in 5440 which provided > a copy of SESSION_ATTRIBUTE of C-Type 7 (with setup/holding prio but > no attribute tests). >=20 > This means that, as far as I can tell, it's not possible to emulate > C-Type 7 in PCEP. This is really quite far outside the scope of the > EAG document, but sweeping it under the rug gets ugly. >=20 > I propose the following: Well, look, that text is OK, but it seems unnecessary if your motivation = is as you describe. In fact, Section 3 is unnecessary with your = motivation.=20 So don't go down that path if you don't want to. Just state your = objective is to enable headend computation as described above. From nobody Thu Apr 17 01:05:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD631A00F9 for ; Thu, 17 Apr 2014 01:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I417IFHdppgn for ; Thu, 17 Apr 2014 01:04:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF1A21A00CD for ; Thu, 17 Apr 2014 01:04:57 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EE6D21800905; Thu, 17 Apr 2014 10:04:53 +0200 (CEST) Message-ID: <534F8B25.80802@pi.nu> Date: Thu, 17 Apr 2014 10:04:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KEX2xmskf_as0jlLGSLY9JQo0s0 Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: [mpls] IPR poll on draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 08:05:02 -0000 Working Group, The authors of draft-ietf-mpls-lsp-ping-relay-reply has informed us that the draft is ready for working groups last call. Before starting the working group last call we want to run an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-lsp-ping-relay-reply? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are two IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 17 04:13:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6EB1A0090 for ; Thu, 17 Apr 2014 04:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btHsQVwe3WY8 for ; Thu, 17 Apr 2014 04:12:57 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 15C1C1A004A for ; Thu, 17 Apr 2014 04:12:56 -0700 (PDT) Received: from [192.168.0.123] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7EF201800905; Thu, 17 Apr 2014 13:12:52 +0200 (CEST) Message-ID: <534FB734.2020005@pi.nu> Date: Thu, 17 Apr 2014 13:12:52 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> In-Reply-To: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RjDGcXYvfRfeuXpB7e6BVAn7wJM Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 11:13:02 -0000 Adrian, Given my limited understanding of the security mechanisms, I nevertheless have one question I need to ask. You say: On 2014-04-13 20:10, Adrian Farrel wrote: > It would help if the document was a > little clearer about which attacks it is defending against and why normal > protection at the edge of the network is not considered enough for the former, > and why a bad actor within the network would waste its time attacking LDP when > there is so much else it can do! My understanding is that this document was written as a response to the risk analysis in RFC 6952. If I remember correctly you had a number of questions, but also said that you had no objections after having these question answered. Since RFC 6952 says we have a security hole that we need to close, you said that you approve of that, we tried to fill the hole; how should I understand the comment above? Do you just want another reference to RFC 6952? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 17 05:55:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC47F1A02BE for ; Thu, 17 Apr 2014 05:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H50ZvaGc3oDK for ; Thu, 17 Apr 2014 05:54:58 -0700 (PDT) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9991A0150 for ; Thu, 17 Apr 2014 05:54:55 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so282920ykq.35 for ; Thu, 17 Apr 2014 05:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cSDo5IBJxKuXHFEPb2X3Tl8g31KS8jtQNDTWkKFny10=; b=B8lrvDrk/vBObqSDLshmCTRr7IoMC4KauISv1101OPZWgIgrU5Ed4moc//FQKqE3fd Uz05SN/z9Kk9wqYnSR11TLE2iSJ7G1ko0DIjrtw/fsmoQZbyY3Bo4foWObngMrN9Oa7V JiKfP0Io39DHnPpAOFphIsTMMcrCIA34l8rWxeexUbmhXnRn0sWAL1+NvkJWKy2vLJvS AiCiEyqweyXjJmIonKIZYQyCjvWsc8sHwU+NWZk3Nn2wQsiyJFZDVvRuv78U0akVugU4 76ChT7LHg8Myiq38gsXZsFFFsfBj1oThptaoosgtOIaoRuauuP/VPCbQEuVA+ZpS8T5R QeEg== X-Gm-Message-State: ALoCoQkJTZlCjPGMG85LR5QplcK2LB+emp4UTmi3pt6NT00RI2SZM0W6nUdnK2mZUrWeWcISEo2C MIME-Version: 1.0 X-Received: by 10.236.116.99 with SMTP id f63mr21317752yhh.10.1397739291619; Thu, 17 Apr 2014 05:54:51 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Thu, 17 Apr 2014 05:54:51 -0700 (PDT) In-Reply-To: References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> Date: Thu, 17 Apr 2014 08:54:51 -0400 Message-ID: From: Eric Osborne To: "Les Ginsberg (ginsberg)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qMFpthnYb7TJMVYXnXGVhZYQP_g Cc: "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:55:02 -0000 Hi Les- Thanks for the review, glad those changes worked for you. As far as the conflict, we went back and forth and this during initial development. There are probably good arguments on both sides, and as long as a device is compliant none of this should matter. The reason we did what we did is that AG is widespread but optional, and if we define EAG to start at bit 32 we then have to define what you do if a node advertises EAG and not AG, and another node has desire for bits in the AG space. It gets just as ugly, if not uglier; we'd have to say something like "if there is EAG and no AG, assume AG =3D=3D 0x0", and this creates two problems: 1) some implementations have default assumptions in the case of missing AG, and they may not all be 0x0 2) it mandates that 'undefined' =3D=3D 0x0, which makes me feel all weir= d. It *is* true that by defining EAG to start at bit 0 rather than bit 32 we can someday replace AG, but that's not the motivation. The motivation is simply to not _require_ AG in the face of EAG when AG by itself is optional. Tarek, please chime in if I missed anything. eric On Wed, Apr 16, 2014 at 11:45 AM, Les Ginsberg (ginsberg) wrote: > Eric - > > The revised text in Section 2.3.1 addresses my concern - thanx. > > But I had also asked why the potential conflict between AG and EAG could = not be avoided altogether by defining EAG as representing the groups beyond= the first 32 defined by AG. Could you respond to that? > > If the argument is that you would like someday to deprecate the use of AG= I have to say that I don=E2=80=99t find that very compelling. > > Les > > >> -----Original Message----- >> From: Eric Osborne [mailto:eric@notcom.com] >> Sent: Wednesday, April 16, 2014 8:01 AM >> To: Adrian Farrel >> Cc: draft-ietf-mpls-extended-admin-group.all@tools.ietf.org; mpls@ietf.o= rg; >> mpls-chairs@tools.ietf.org; Les Ginsberg (ginsberg) >> Subject: Re: AD review of draft-ietf-mpls-extended-admin-group >> >> HI Adrian- >> >> I'm ccing Les as well; he had some comments around section 2.3.1 (as >> did everyone else, and rightly so). >> Inline with EO#. Since the thread is rather large and it's easy to >> lose the changes, I have attached the candidate-05 draft to this >> email. It can be compared to draft-04, which is the latest posted >> version. >> >> Summary: most of the changes are no big deal, but I'm wrestling with >> how to exclude PCE cleanly. >> >> On Tue, Apr 1, 2014 at 5:39 PM, Adrian Farrel wrot= e: >> > Hello, >> > >> > I have done my usual AD review of your document upon receiving the >> > publication request. The purpose is to catch any issues that might >> > otherwise show up during IETF last call or IESG review and to get the >> > document into good shape so that those later reviews have a clearer >> > run. >> > >> > There are a few comments below that I would like you to look at. The >> > I-D is very short and simple, so there is not much to comment on, but >> > I have a few concerns, clarifications, and editorial points that I >> > hope you will look at. You are, of course, welcome to dispute any of >> > these points and discuss them with me on the WG mailing list. >> > >> > While you are working on this I will put the document into "Revised >> > I-D Needed" state and I will ask the WG chairs to send a notice about >> > this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they are >> > aware of the draft and can comment immediately or during IETF last cal= l >> > if they have any concerns. >> > >> > Thanks for the work, >> > Adrian >> > >> > =3D=3D=3D >> > >> > This document adds a sub-TLV. I think it is your intention that this i= s >> > a sub-TLV of the Link TLV and not of the Administrative Group sub-TLV, >> > itself. That seems pretty important, so it needs to be stated clearly. >> > >> >> EO# Fixed. >> >> Old: >> --- >> >> 2. Extended Administrative Groups sub-TLV >> >> The Extended Administrative Groups sub-TLV is used... >> --- >> >> >> New: >> ---- >> 2. Extended Administrative Groups sub-TLV >> >> This document defines a sub-TLV of the Link TLV for both OSPF >> [RFC3630] and ISIS [RFC5305] called the Extended Administrative >> Groups (EAG) sub-TLV. The EAG sub-TLV is used... >> ---- >> >> OK? >> >> > --- >> > >> > The use case in para 2 of Section 1 is, of course, predicated on using >> > a single IGP domain (area/level) to cover the whole network that is >> > being discussed. That is OK, but the text should note this caveat les= t >> > people think that admin colours are somehow globally unique. >> > >> >> EO# I agree that the use case you cite is probably a single-level >> case. But that doesn't mean EAG must be constrained to only a single >> level. An implementation that signals AG in RSVP can use it across >> multiple areas (that's really the point of signaling AG at all). I >> don't want to preclude that happening with EAG should someone decide >> to implement signaling of EAG in RSVP. >> >> To address your comment I have added a sentence to section 3. In its >> entirety: >> >> --- OLD ---- >> 3. Signaling Extended Administrative Groups in RSVP >> >> RSVP provides the ability to signal link affinity via the >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> Signaling EAG in RSVP is not addressed in this document. This >> document does not preclude addressing this in the future should it be >> deemed necessary >> ---- >> >> ---- NEW ---- >> 3. Signaling Extended Administrative Groups in RSVP >> >> RSVP provides the ability to signal link affinity via the >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> Signaling EAG in RSVP is not addressed in this document. This >> document does not preclude addressing this in the future should it be >> deemed necessary. >> >> Note that signaling EAG is RSVP is likely to be necessary to expand >> the use of EAG outside a single area/level, just as it is with AG >> --- >> >> but please see my comments later in this mail about PCEP. >> >> > --- >> > >> > Section 2.1 >> > >> > The EAG may >> > be of any length, but MUST be a multiple of 4 bytes. >> > >> > Is a zero-length TLV allowed? >> > >> >> EO# I'm not sure what it would actually *do*. Making clear that a >> TLV must actually contain some information in order to be useful is >> probably more necessary than I'd like to think. I live in a country >> where we have to say "this plastic bag is not a toy, do not give to >> infants" just in case someone thought otherwise...it is for those >> people that I propose the following text: >> >> --- OLD --- >> >> The EAG may >> be of any length, but MUST be a multiple of 4 bytes. >> ---- >> >> >> --- NEW ---- >> >> The EAG may be of any non-zero length, but MUST be a multiple of 4 bytes >> ----- >> >> OK? >> >> >> >> > --- >> > >> > 2.3.1 >> > >> >> EO# This section is rather confusing...multiple reviewers caught it. >> The current text in its entirety is: >> >> ---- OLD ---- >> 2.3.1. AG and EAG coexistence >> >> If a node advertises EAG it MAY also advertise AG. >> >> If a node advertises both AG and EAG then the first 32 bits of the >> EAG MUST be identical to the advertised AG. If a receiving node >> notices that the AG differs from the first 32 bits of the EAG, it >> SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> indicate this mismatch to the operator. >> >> If the AG and EAG advertised for a link differ, the EAG MUST take >> priority. This allows nodes which do not support EAG to obtain some >> link color information from the network, but also allow for an >> eventual migration away from AG. >> ---- >> >> and it was worded that way after a discussion on the list with Andy >> Malis and Tarek Saad. >> The intent is straightforward: in the event of a mismatch, prefer AG. >> >> > If a receiving node >> > notices that the AG differs from the first 32 bits of the EAG, it >> > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> > indicate this mismatch to the operator. >> > >> > If the AG and EAG advertised for a link differ, the EAG MUST take >> > priority. >> > >> > Aren't these two statements contradictory? >> > I suspect the final "EAG" is supposed to read "AG" to be consistent >> > with the first paragraph and also to match the first motivation given >> > immediately after. >> >> EO# Sort of. There are a few options here in the event of a mismatch: >> >> 1) use only AG >> 2) overwrite the first 32 bits of EAG with AG, then use the entire EAG. >> 3) use only EAG >> >> >> In the discussion with Andy and Tarek we came to agreement on #2. >> That's what the text in section 2.3.1 needs to say. >> >> I therefore propose the following for the entirety of section 2.3.1: >> >> ---- NEW ---- >> >> If a node advertises EAG it MAY also advertise AG. >> >> If a node advertises both AG and EAG then the first 32 bits of the >> EAG MUST be identical to the advertised AG. If a receiving node >> notices that the AG differs from the first 32 bits of the EAG, it >> SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> indicate this mismatch to the operator. This allows nodes which do >> not support EAG to obtain some >> link color information from the network, but also allow for an >> eventual migration away from AG. >> --- >> >> all this does is drop the sentence "If the AG and EAG advertised for a >> link differ, the EAG MUST take >> priority." as that clearly contradicted everything else in that secti= on. >> >> >> > >> > This allows nodes which do not support EAG to obtain some >> > link color information from the network, but also allow for an >> > eventual migration away from AG. >> > >> > OTOH... >> > >> > 1. The second motivation seems to support EAG taking priority. >> > >> > 2. The first motivation seems to miss some really big issues concernin= g >> > non-support of EAG. You need to discuss this processing in relation >> > to signaling... >> > >> > Suppose a link is advertised with EAG and a node that does not >> > support EAG signals an LSP? >> >> EO# I don't think this applies, since there is no support for >> signaled EAG. It's purely for headend calculation. >> >> > >> > Suppose one end of a link supports EAG but the other does not and >> > a signaling message includes EAG and the upstream end of the link >> > ignores it? >> > >> >> EO# The same is true of one end signaling AG and the other not >> signaling anything; despite its widespread advertisement, AG is >> optional. >> >> I never thought there was any requirement for a TE link to have >> identical properties in both directions. Neither rfc3630 nor rfc5305 >> concern themselves with bidirectionality in any of the TE TLVs, nor >> does rfc5307. The implementations I'm familiar with perform a basic >> two-way connectivity check, but that's it. >> >> I would prefer to stay away from prescribing behavior here that is >> more restrictive than what's specified in the base documents. >> >> > I think you have some edge conditions to describe in section 2.3 >> > >> >> EO# No such conditions are discussed in any other RFC which specifies >> TE link properties, and we seem to have gotten along just fine. If >> you feel strongly about this then we can sort something out, but I'm >> reluctant to make the EAG document the place where all sorts of >> assumptions about CSPF get spelled out. >> >> > --- >> > >> > I read section 4.7.4 of RFC 3209 to compare it with what you say in >> > section 2.3.2 of this document. >> > >> > I read it to say: >> > - a link can only be excluded if it advertises a specific color >> > - a link can only be included if it advertises a specific color >> > Thus, failure to include AG means a link cannot be excluded according >> > to an exclusion requirement. But it also means that it cannot be >> > included according to an include or include-any requirement. >> >> >> EO# Right. It's a hole in 3209; that section assumes AG is always >> advertised. In my experience this is generally true in practice, and >> the implementations I know best have some default they assume if AG is >> not advertised. >> >> .... >> >> > I think this is functionally equivalent to RFC 3209. >> > That is, a link cannot be excluded on the basis of an unadvertised >> > affinity because it is assumed to be 0. >> > And a link cannot be included on the basis of an unadvertised affinity >> > because it is assumed to be 0. >> > >> > So it all ends up right in the end, but it took a lot of words! >> >> EO# Yeah...I wanted to make clear what 4.7.4 meant without adding >> some backdoor requirements to it. >> >> > >> > --- >> > >> > In Section 2.3.2 you have an "interesting" mix of advice and 2119 word= s. >> > >> >> .... >> >> Yes. >> Yes I did. >> >> I think s/MUST/SHOULD/ for the first MUST in 2.3.2, as well as some >> tweaking, fixes it. I propose: >> >> >> --- OLD---- >> >> Each implementation is free to choose its own method for handling >> this question. However, to allow for maximum interoperability an >> implementation MUST treat desired but unadvertised EAG bits as if >> they are set to 0. Consider the case where a node wants to only use >> links where the 127th bit of an EAG is set to 1. If a link is only >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined - >> that is, it is neither explicitly 0 nor 1. The node which wants the >> 127th EAG bit to be 1 MUST NOT use this link, as the assumption is >> than an unadvertised bit is set to 0. >> ---- >> >> >> --- NEW --- >> >> Each implementation is free to choose its own method for handling >> this question. However, to allow for maximum interoperability an >> implementation SHOULD treat desired but unadvertised EAG bits as if >> they are set to 0. Consider the case where a node wants to only use >> links where the 127th bit of an EAG is set to 1. If a link is only >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined - >> that is, it is neither explicitly 0 nor 1. The node which wants the >> 127th EAG bit to be 1 MUST NOT use this link when implementing the >> recommended behavior, as the assumption is >> than an unadvertised bit is set to 0. >> --- >> >> >> ... >> >> > But, one final question... >> > Why do you want to allow other modes of operation? >> > What is the benefit, and why didn't you call it out? >> >> >> EO# As with other uses of SHOULD (e.g., section 2.3.1) there is >> already at least one implementation out there and while it hews in >> large part to the document as written, I did not want to inadvertently >> deprecate it. >> >> > >> > --- >> > >> > Section 3 deliberately sidesteps the use of EAG in signaling. That is >> > "interesting" >> >> EO# You may recall from (Berlin? Orlando?) that I had a much longer >> section which wrestled with this. I took it out and swept the whole >> thing under the rug under direct advice of an AD at the mic. :) >> >> > and makes me assume that the use of EAG you have in mind >> > applies only at the point of explicit path selection (i.e. no loose >> > hop selection). >> > >> >> EO# Yes, that's the problem I'm trying to solve. I don't see much >> relevant to PCE (if the PCE is going to hand down an explicit path >> then why does it need to include any AG/EAG information at all?) and >> while I don't want to completely rule it out it seems like more than >> needs to be solved in this document. >> >> >> > I think that, in order to justify this work being limited to the IGPs >> > you need to be a bit more explicit, up front, that *your* use case >> > concerns pre-computation of paths. >> >> EO# well, no...not pre-computation. Headend computation. >> Pre-computation (at least the way I understand it) means >> offline+config push or something PCE-ish like that. >> >> > >> > Now, there are two places where path selection will be done: >> > 1. The head-end LSR >> > 2. A PCE >> > >> > So, you should pick one or both of these as your use case and state it >> > clearly. If you include PCE, you will need to look at the applicabilit= y >> > to PCEP (see Section 7.11 of RFC 5440). >> >> EO# If I'm sidestepping RSVP I might as well sidestep PCEP too. It >> isn't necessary for the use case EAG was developed for, and I'm not >> sure I see it being all that big of an issue. >> >> However....rfc5440 section 7.11 provides an LSPA which is a copy of >> the SESSION_ATTRIBUTE of C-Type 1 (that is, the one with the three >> link attribute tests). I did not see anything in 5440 which provided >> a copy of SESSION_ATTRIBUTE of C-Type 7 (with setup/holding prio but >> no attribute tests). >> >> This means that, as far as I can tell, it's not possible to emulate >> C-Type 7 in PCEP. This is really quite far outside the scope of the >> EAG document, but sweeping it under the rug gets ugly. >> >> I propose the following: >> >> - retitle section to "Signaling Extended Administrative Groups in RSVP >> and PCEP" >> - making the entirety of section 3 into: >> >> ---- >> 3. Signaling Extended Administrative Groups in RSVP and PCEP >> >> RSVP provides the ability to signal link affinity via the >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> Signaling EAG in RSVP is not addressed in this document. This >> document does not preclude addressing this in the future should it be >> deemed necessary.Note that signaling EAG is RSVP is likely to be >> necessary to expand the use of EAG outside a single area/level, just >> as it is with AG. >> >> The PCE Communication Protocol, or PCEP ( [RFC5440]) specifies an >> LSPA object which is essentially a copy of RFC3209's >> SESSION_ATTRIBUTE with C-Type 1. It does not provide a copy of the >> SESSION_ATTRIBUTE with C-Type 7. Thus, the only way to indicate >> setup/holding priority in PCEP is to also signal 32-bit AG values for >> Exclude-any, Include-any and Include-all. >> >> If a node which implements both EAG and PCEP wishes to signal setup >> and holding priorities in PCEP's LSPA, it has no choice but to use >> the LSPA with affinity constraints. A node which sends an LSPA in >> PCEP MUST populate the affinity constraint fields (Exclude-any, >> Include-any, Include-all) with the lower 32 bits of the relevant EAG. >> >> This document does not preclude addressing this in the future should >> it be deemed necessary. One possible approach is to standardize a >> PCEP object which is a mirror of the SESSION_ATTRIBUTE of C-Type 7. >> Another is to standardize a PCEP object which directly contains >> support for EAG. There may be other approaches. Any and all such >> approaches are outside the scope of this document >> >> ---------- >> >> I'm not sure I like it all that much but I can't think of a better >> approach that doesn't involve wrestling with the whole signaling >> question again. >> >> >> > >> > --- >> > >> > Section 5 could be made clearer by breaking the text out into separate >> > paragraphs or even separate sections. It would also be helpful to IANA >> > if you made little tables showing the exact information you want >> > recorded in each registry. >> > >> >> EO# >> I put in some paragraph breaks and cleaned the text up a bit.. If >> those aren't clear enough it's easy enough to work with IANA when they >> get around to allocating the codepoint. >> >> >> >> eric From nobody Thu Apr 17 06:09:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A11A0150 for ; Thu, 17 Apr 2014 06:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OmP0mHaFROX for ; Thu, 17 Apr 2014 06:09:35 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D21A0144 for ; Thu, 17 Apr 2014 06:09:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HD9SqV004272; Thu, 17 Apr 2014 14:09:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HD9P1I004258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 14:09:26 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> <534FB734.2020005@pi.nu> In-Reply-To: <534FB734.2020005@pi.nu> Date: Thu, 17 Apr 2014 14:09:25 +0100 Message-ID: <03d801cf5a3e$4327fcc0$c977f640$@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: AQGwZu0InfoAc9cYjGAjs7sJWmJQfAHiEHL1m0SW27A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20638.002 X-TM-AS-Result: No--25.990-10.0-31-10 X-imss-scan-details: No--25.990-10.0-31-10 X-TMASE-MatchedRID: dL10VBB8yofdFc7KmVSFInBRIrj8R47FhK6MUk5fDP27+NPPxj+R6q0R omhWPJaQ/36awnwEWWtQ8Bt3H6q/bOLEx8K5SmHZDRBjlWdDIA1PIpLM1lKFW7ELn336s0giika 0Ka6FTusSfRocOFS0In3+sfWGTE7hMH15eekLeUiEJ5wBUYI5/UDwj88nLgRTfKNVzc7XpNqdAR h7bKcmDWNw+CBvj5ATS68xji9Qa4RlZa1Ry9qdoFPjo7D4SFg4QG66tTRoP+drMbakJN8OefWnL 2FmW8ATAgfqSVHxppENJdWbfnv8KoxOAnnhEoAzHLEq6GCOQFaK6IJmwLQESLvsTEW9zEoTtPh3 CmINV9Ok1WcEVWC5ZhM1yubxgLEE1xQ2OgXti5VHFWsq1vzd1BmyTBaqiJvcf7FDYGpyXq1Vrl4 dPkDCJj74qz4vOyGQTTus4Pg7jbn5V22kT3/19k9GwoJMN6MPju+GX08gELBBDVeC8J7uwbBCWJ YFsTZpjfgUYGMwHqCFzkxNEN20m9e3wqXmlnx9Q1OcCEvT+bchauGyjTkf9ThjAM9APH53o8WMk QWv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSk+Mqg+CyrtwA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bB-NE8a6eIq5VFUqJ-NqR8iuEjc Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 13:09:40 -0000 Hello, I don't think that is the history at all! This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October 2010. Before that the issue with the Hello was discussed and batted around for a while. There is a risk with the Hello and it needs a solution. No issue with that, and I support this draft. RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note that the discussion of LDP Hellos didn't make it into this document until -01 in May 2011). But who cares? RFC 6952 does not describe the attacks or their mitigations. It just notes that spoofing a Hello can have some bad effects. As a deployer, I need help to explain when I need to insist on having this feature implemented by my supplier (BTW, it looks like none of the suppliers is implementing it) and when I need to enable it. It seems to me that this feature is needed to protect against attacks (which 6952 claims have been seen in the wild), but that those attacks only arise in specific situations. Since the security mechanisms defined in this document are pretty heavy-weight (compare with simple text passwords so loved for IGP security :-) it would be great to get some help on this topic. Are all networks always exposed (if so it looks like a must-have feature)? Are the risks only significant for targeted LDP? Is the network safe if it applies access controls at the edges and assumes no subversion of routers? Does applying an access list at the LDP speakers provide protection against everything except address spoofing? Cheers, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 17 April 2014 12:13 > To: adrian@olddog.co.uk; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth > > Adrian, > > Given my limited understanding of the security mechanisms, I > nevertheless have one question I need to ask. > > You say: > > On 2014-04-13 20:10, Adrian Farrel wrote: > > It would help if the document was a > > little clearer about which attacks it is defending against and why normal > > protection at the edge of the network is not considered enough for the former, > > and why a bad actor within the network would waste its time attacking LDP > when > > there is so much else it can do! > > My understanding is that this document was written as a response to the > risk analysis in RFC 6952. If I remember correctly you had a number of > questions, but also said that you had no objections after having these > question answered. > > Since RFC 6952 says we have a security hole that we need to close, you > said that you approve of that, we tried to fill the hole; how should I > understand the comment above? Do you just want another reference to > RFC 6952? > > /Loa From nobody Thu Apr 17 06:29:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF31A0127 for ; Thu, 17 Apr 2014 06:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwjuYUVFGTwu for ; Thu, 17 Apr 2014 06:28:53 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 90CC71A014E for ; Thu, 17 Apr 2014 06:28:53 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BB98C1800905; Thu, 17 Apr 2014 15:28:49 +0200 (CEST) Message-ID: <534FD712.8080004@pi.nu> Date: Thu, 17 Apr 2014 15:28:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <53391A55.8000303@pi.nu> In-Reply-To: <53391A55.8000303@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sSOIZXTXonpzJovW_9Sj8G52YLE Cc: "mpls-chairs@tools.ietf.org" , "draft-george-mpls-ipv6-only-gap@tools.ietf.org" Subject: [mpls] WG Poll closed - Re: poll to see if we have consensus to make draft-george-mpls-ipv6-only-gap a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:28:58 -0000 Working Group, This wg poll is closed and we have a new working group document. Authors, Can you please re-post the document as draft-mpls-ietf-ipv6-only-gap-00.txt without any other changes and dates. /Loa On 2014-03-31 09:33, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-george-mpls-ipv6-only-gap as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR claim against this document. > > The authors and contributors has stated on the working group mailing > list that they are not aware of any other IPR claims against this draft. > > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > This poll ends April 14, 2014. > > /Loa > > for the MPLS wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 17 06:41:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7D1A0106 for ; Thu, 17 Apr 2014 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK8qoxWMHQu7 for ; Thu, 17 Apr 2014 06:41:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1360C1A0175 for ; Thu, 17 Apr 2014 06:41:41 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 32EEE1800905; Thu, 17 Apr 2014 15:41:37 +0200 (CEST) Message-ID: <534FDA11.4030209@pi.nu> Date: Thu, 17 Apr 2014 15:41:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> <534FB734.2020005@pi.nu> <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> In-Reply-To: <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/spGapdCH7l5BuUaTXYGGllftf-0 Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:41:45 -0000 Adrian, Sorry if I don't have the history right, but it is not really the that is my problem. It is the tension between > There is a risk with the Hello and it needs a solution. > No issue with that, and I support this draft. and > why a bad actor within the network would waste its time attacking LDP > when there is so much else it can do! The first seems says that there is a risk that needs to be taken care of, the second seems to say that this is moot. /Loa On 2014-04-17 15:09, Adrian Farrel wrote: > Hello, > > I don't think that is the history at all! > This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October 2010. > Before that the issue with the Hello was discussed and batted around for a > while. > There is a risk with the Hello and it needs a solution. > No issue with that, and I support this draft. > > RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted > by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first > posted in February 2011 (note that the discussion of LDP Hellos didn't make it > into this document until -01 in May 2011). > > But who cares? > > RFC 6952 does not describe the attacks or their mitigations. It just notes that > spoofing a Hello can have some bad effects. > > As a deployer, I need help to explain when I need to insist on having this > feature implemented by my supplier (BTW, it looks like none of the suppliers is > implementing it) and when I need to enable it. It seems to me that this feature > is needed to protect against attacks (which 6952 claims have been seen in the > wild), but that those attacks only arise in specific situations. > > Since the security mechanisms defined in this document are pretty heavy-weight > (compare with simple text passwords so loved for IGP security :-) it would be > great to get some help on this topic. Are all networks always exposed (if so it > looks like a must-have feature)? Are the risks only significant for targeted > LDP? Is the network safe if it applies access controls at the edges and assumes > no subversion of routers? Does applying an access list at the LDP speakers > provide protection against everything except address spoofing? > > Cheers, > Adrian > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: 17 April 2014 12:13 >> To: adrian@olddog.co.uk; > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth >> >> Adrian, >> >> Given my limited understanding of the security mechanisms, I >> nevertheless have one question I need to ask. >> >> You say: >> >> On 2014-04-13 20:10, Adrian Farrel wrote: >>> It would help if the document was a >>> little clearer about which attacks it is defending against and why normal >>> protection at the edge of the network is not considered enough for the > former, >>> and why a bad actor within the network would waste its time attacking LDP >> when >>> there is so much else it can do! >> >> My understanding is that this document was written as a response to the >> risk analysis in RFC 6952. If I remember correctly you had a number of >> questions, but also said that you had no objections after having these >> question answered. >> >> Since RFC 6952 says we have a security hole that we need to close, you >> said that you approve of that, we tried to fill the hole; how should I >> understand the comment above? Do you just want another reference to >> RFC 6952? >> >> /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 17 07:37:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17C1A00DD; Thu, 17 Apr 2014 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taQb0l5CET_A; Thu, 17 Apr 2014 07:37:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA31A019C; Thu, 17 Apr 2014 07:37:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417143724.2132.2661.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 07:37:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Zy-Ba1wictlFWvruBqJcAqUjC_8 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ipv6-only-gap-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:37:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Gap Analysis for Operating IPv6-only MPLS Networks Authors : Wesley George Carlos Pignataro Filename : draft-ietf-mpls-ipv6-only-gap-00.txt Pages : 24 Date : 2014-04-17 Abstract: This document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS- related protocols and applications to be used with IPv6-only networks. This document is not intended to highlight a particular vendor's implementation (or lack thereof) in the context of IPv6-only MPLS functionality, but rather to focus on gaps in the standards defining the MPLS suite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ipv6-only-gap-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 17 07:50:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FC61A01E1 for ; Thu, 17 Apr 2014 07:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2Av0T_6qOjq for ; Thu, 17 Apr 2014 07:50:48 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79CA11A020E for ; Thu, 17 Apr 2014 07:50:48 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lj1so457298pab.20 for ; Thu, 17 Apr 2014 07:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=hLaPgxfKIE5YfXTJtauCc0rtBW99gTa/lxYVs2avbcY=; b=GXVTAsMBjFTZiIOr40/vnVzV/D4LTPXkYDZ1oVdZNS9B1cdGXPrzynDbqPvkEiHdb5 AvJi8ZUqO0IeP3L6Ofw+IzehRUnvoRym0VHE3aXQdSE6BmZgOH3Fl0AgCVq8mmg3pI9j 6CW23p6JYZEJ852xV+MQeAwhBvJqOekayT9cRZ9HMeow55WW6VbqgaT49vJLmjH8AO4E aYWtPeqQX3l6JMNviliMWWHAauEYY+agD3D5tgRp4V2ztRqzDSE0p6y3t5r4W5eFiaVn w+MVcKtGs+AZkP0JQGLRaVbXuXctgs/a2x8HV+o+u5o/HNHcendG+Jks02+9+4F14ep5 UTTA== X-Received: by 10.66.124.137 with SMTP id mi9mr16073724pab.111.1397746245010; Thu, 17 Apr 2014 07:50:45 -0700 (PDT) Received: from LizhongPC ([140.206.240.249]) by mx.google.com with ESMTPSA id pe3sm54053453pbc.23.2014.04.17.07.50.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Apr 2014 07:50:44 -0700 (PDT) From: "Lizhong Jin" To: "'Loa Andersson'" , References: <534F8B25.80802@pi.nu> In-Reply-To: <534F8B25.80802@pi.nu> Date: Thu, 17 Apr 2014 22:50:21 +0800 Message-ID: <534fea44.43da440a.764d.08ac@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9aE8c0bkV8yOKeRZK5Ztdjz+MdvQANCk0Q Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/t_9g9xy9j2m4s7iN3VkPbqAnMU0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:50:53 -0000 Hi, I'm not aware of any other IPRs other than those already disclosed. Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, April 17, 2014 4:05 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); > draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org; 'Ryan Zheng' > Subject: IPR poll on draft-ietf-mpls-lsp-ping-relay-reply > > Working Group, > > The authors of draft-ietf-mpls-lsp-ping-relay-reply has informed us > that the draft is ready for working groups last call. > > Before starting the working group last call we want to run an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ietf-mpls-lsp-ping-relay-reply? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are two IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 17 08:42:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6A1A0138 for ; Thu, 17 Apr 2014 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVla4W9J_Dbo for ; Thu, 17 Apr 2014 08:42:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CB6901A01CF for ; Thu, 17 Apr 2014 08:42:00 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HFfsqE031597; Thu, 17 Apr 2014 16:41:54 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HFfrpH031563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 16:41:53 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> <534FB734.2020005@pi.nu> <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> <534FDA11.4030209@pi.nu> In-Reply-To: <534FDA11.4030209@pi.nu> Date: Thu, 17 Apr 2014 16:41:52 +0100 Message-ID: <046e01cf5a53$8e97c450$abc74cf0$@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: AQGwZu0InfoAc9cYjGAjs7sJWmJQfAHiEHL1AZxSIA8Bc3vq05ssSeWw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20640.000 X-TM-AS-Result: No--9.843-10.0-31-10 X-imss-scan-details: No--9.843-10.0-31-10 X-TMASE-MatchedRID: L8tZF6zWW2o4HKI/yaqRm0hEDfw/93BucW+VwHmrYOUJW4Re2U2py/QU BVrvaj2G3DfT9CKnIuC9v9L+KFaMuTJz3NGP4sGiDPhWwJzVhb6/yN2q8U674v4cj3aFGgp+7fz mCh2mgXjrttvG+I9eG3ZyKEHm4INSaTj+BID98+H87vS8PQu3wFxIyn/X4Smn+156Tr76priYpu G7kpoKR1weZNvdNfWqYwDLmNorhQg5r0DUFZTrCh/XcAla9LsVAHN/Ezu9EnGbKItl61J/yS57h WH2lkqmfeZdJ1Xsorg65tgsJWcFUSAHAopEd76vkBZSQuWsIXiBLeDNHajavTwpzo1dKfKFzt6h LfwMm7zIhKAzwXkOdg== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gLgre9Mv37uMsGUw1iXnlkIdL3M Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 17 Apr 2014 15:42:02 -0000 > It is the tension between > > > There is a risk with the Hello and it needs a solution. > > No issue with that, and I support this draft. > > and > > > why a bad actor within the network would waste its time attacking LDP > > when there is so much else it can do! > > The first seems says that there is a risk that needs to be taken care > of, the second seems to say that this is moot. *If* a bad actor within the network is the only vulnerability, and *if*all* such bad actors are compromised routers, then it is moot. But "moot" means "subject to debate, dispute, or uncertainty." Let's debate :-) Without seeing the text that describes how the attacks might be made, I (probably like the rest of the WG) am assuming "Here is a security hole: we had better plug it." Knowing there is a hole, and knowing what the fix is, is really important. That means the I-D should be published as an RFC, whatever. Knowing when the solution needs to be used is an important piece of additional guidance to make the document more useful. Adrian From nobody Thu Apr 17 20:08:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD31A01E8 for ; Thu, 17 Apr 2014 20:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bQ4cEHgbz4O for ; Thu, 17 Apr 2014 20:08:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 516671A00CB for ; Thu, 17 Apr 2014 20:08:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFU69682; Fri, 18 Apr 2014 03:08:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 04:06:31 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 04:08:11 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.15]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 11:08:05 +0800 From: Vero Zheng To: "adrian@olddog.co.uk" , "'Loa Andersson'" , "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth Thread-Index: AQHPWi4DA6B4NIA6W0uW6/7VuK7Yn5sVQgqAgAFuc0A= Date: Fri, 18 Apr 2014 03:08:04 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98@SZXEMA504-MBS.china.huawei.com> References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> <534FB734.2020005@pi.nu> <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> In-Reply-To: <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zorAZUf-eFXMYHud7ZfzuMkKRzM Cc: "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 03:08:25 -0000 --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was = adopted by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-a= nalysis first posted in February 2011 (note that the discussion of LDP Hellos didn't make it into this document u= ntil -01 in May2011). Adrian, That is not correct. The discussion of LDP Hellos was in the document from = the very beginning. The hello spoofing was discussed in both the discussion= on current state/optimal state of the protocols in -00. Obviously, the document authors care:) Cheers, Vero > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, April 17, 2014 9:09 PM > To: 'Loa Andersson'; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf= .org > Cc: mpls@ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth > > Hello, > > I don't think that is the history at all! > This document started as draft-zheng-mpls-ldp-hello-crypto-auth in Octobe= r > 2010. > Before that the issue with the Hello was discussed and batted around for = a > while. > There is a risk with the Hello and it needs a solution. > No issue with that, and I support this draft. > > RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was > adopted by KARP in June 2011. That derives from > draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note th= at > the discussion of LDP Hellos didn't make it into this document until -01 = in May > 2011). > > But who cares? > > RFC 6952 does not describe the attacks or their mitigations. It just note= s that > spoofing a Hello can have some bad effects. > > As a deployer, I need help to explain when I need to insist on having thi= s feature > implemented by my supplier (BTW, it looks like none of the suppliers is > implementing it) and when I need to enable it. It seems to me that this f= eature > is needed to protect against attacks (which 6952 claims have been seen in= the > wild), but that those attacks only arise in specific situations. > > Since the security mechanisms defined in this document are pretty > heavy-weight (compare with simple text passwords so loved for IGP securit= y :-) > it would be great to get some help on this topic. Are all networks always > exposed (if so it looks like a must-have feature)? Are the risks only sig= nificant > for targeted LDP? Is the network safe if it applies access controls at th= e edges > and assumes no subversion of routers? Does applying an access list at the= LDP > speakers provide protection against everything except address spoofing? > > Cheers, > Adrian > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: 17 April 2014 12:13 > > To: adrian@olddog.co.uk; > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth > > > > Adrian, > > > > Given my limited understanding of the security mechanisms, I > > nevertheless have one question I need to ask. > > > > You say: > > > > On 2014-04-13 20:10, Adrian Farrel wrote: > > > It would help if the document was a > > > little clearer about which attacks it is defending against and why > > > normal protection at the edge of the network is not considered > > > enough for the > former, > > > and why a bad actor within the network would waste its time > > > attacking LDP > > when > > > there is so much else it can do! > > > > My understanding is that this document was written as a response to > > the risk analysis in RFC 6952. If I remember correctly you had a > > number of questions, but also said that you had no objections after > > having these question answered. > > > > Since RFC 6952 says we have a security hole that we need to close, you > > said that you approve of that, we tried to fill the hole; how should I > > understand the comment above? Do you just want another reference to > > RFC 6952? > > > > /Loa > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> RFC 6952 comes from dra= ft-ietf-karp-routing-tcp-analysis-00.txt that was adopted by KARP in June 2= 011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first posted in F= ebruary 2011

(note that the discussion of= LDP Hellos didn't make it into this document until -01 in May2011).

 

Adrian,

That is not correct. The dis= cussion of LDP Hellos was in the document from the very beginning. The hell= o spoofing was discussed in both the discussion on current state/optimal st= ate of the protocols in -00.

Obviously, the document auth= ors careJ

 

Cheers, Vero

 

> -----Original Message--= ---

> From: mpls [mailto:mpls= -bounces@ietf.org] On Behalf Of Adrian Farrel

> Sent: Thursday, April 1= 7, 2014 9:09 PM

> To: 'Loa Andersson'; dr= aft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org

> Cc: mpls@ietf.org<= /o:p>

> Subject: Re: [mpls] AD = review of draft-ietf-mpls-ldp-hello-crypto-auth

>

> Hello,

>

> I don't think that is t= he history at all!

> This document started a= s draft-zheng-mpls-ldp-hello-crypto-auth in October

> 2010.=

> Before that the issue w= ith the Hello was discussed and batted around for a

> while.

> There is a risk with th= e Hello and it needs a solution.

> No issue with that, and= I support this draft.

>

> RFC 6952 comes from dra= ft-ietf-karp-routing-tcp-analysis-00.txt that was

> adopted by KARP in June= 2011. That derives from

> draft-mahesh-bgp-ldp-ms= dp-analysis first posted in February 2011 (note that

> the discussion of LDP H= ellos didn't make it into this document until -01 in May<= /p>

> 2011).

>

> But who cares?

>

> RFC 6952 does not descr= ibe the attacks or their mitigations. It just notes that<= /p>

> spoofing a Hello can ha= ve some bad effects.

>

> As a deployer, I need h= elp to explain when I need to insist on having this feature

> implemented by my suppl= ier (BTW, it looks like none of the suppliers is

> implementing it) and wh= en I need to enable it. It seems to me that this feature<= /p>

> is needed to protect ag= ainst attacks (which 6952 claims have been seen in the

> wild), but that those a= ttacks only arise in specific situations.

>

> Since the security mech= anisms defined in this document are pretty

> heavy-weight (compare w= ith simple text passwords so loved for IGP security :-)

> it would be great to ge= t some help on this topic. Are all networks always

> exposed (if so it looks= like a must-have feature)? Are the risks only significant

> for targeted LDP? Is th= e network safe if it applies access controls at the edges=

> and assumes no subversi= on of routers? Does applying an access list at the LDP

> speakers provide protec= tion against everything except address spoofing?

>

> Cheers,

> Adrian

>

> > -----Original Mess= age-----

> > From: Loa Andersso= n [mailto:loa@pi.nu]

> > Sent: 17 April 201= 4 12:13

> > To: adrian@olddog.co.uk;

> draft-ietf-mpls-ldp-h= ello-crypto-auth.all@tools.ietf.org

> > Cc: mpls@ietf.org<= /a>

> > Subject: Re: AD re= view of draft-ietf-mpls-ldp-hello-crypto-auth

> ><= /p>

> > Adrian,=

> ><= /p>

> > Given my limited u= nderstanding of the security mechanisms, I

> > nevertheless have = one question I need to ask.

> ><= /p>

> > You say:

> ><= /p>

> > On 2014-04-13 20:1= 0, Adrian Farrel wrote:

> > > It would help= if the document was a

> > > little cleare= r about which attacks it is defending against and why

> > > normal protec= tion at the edge of the network is not considered

> > > enough for th= e

> former,

> > > and why a bad= actor within the network would waste its time

> > > attacking LDP=

> > when

> > > there is so m= uch else it can do!

> ><= /p>

> > My understanding i= s that this document was written as a response to

> > the risk analysis = in RFC 6952. If I remember correctly you had a

> > number of question= s, but also said that you had no objections after

> > having these quest= ion answered.

> ><= /p>

> > Since RFC 6952 say= s we have a security hole that we need to close, you

> > said that you appr= ove of that, we tried to fill the hole; how should I

> > understand the com= ment above? Do you just want another reference to

> > RFC 6952?

> ><= /p>

> > /Loa

>

> _______________________= ________________________

> mpls mailing list<= /o:p>

> mpls@ietf.o= rg

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

--_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98SZXEMA504MBSchi_-- From nobody Fri Apr 18 06:30:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABECB1A0158 for ; Fri, 18 Apr 2014 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIgIyn0MGp98 for ; Fri, 18 Apr 2014 06:30:16 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by ietfa.amsl.com (Postfix) with ESMTP id 43C741A0152 for ; Fri, 18 Apr 2014 06:30:16 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so1413040ykq.0 for ; Fri, 18 Apr 2014 06:30:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oWwoBpVYCdBwmr95yu5cJ0IoP1DJ2hhad7tPT88OVq0=; b=F7bCpCIwj2lRFqBlcq/mk5o+nfVhkRpppSSufORl/DfzN4ZT5u3dlVkhkiryMy55Ji Ssh1q78YKDYcCnpufMnwBs2wEfoQ4gkVLoizeGCOpJMAahaBZivHjIgAKW1iPXFWi5rs iL5Ktn8JA8WpAaSOEIn2H07PFOtqBvMg6eQLMPMVik1aqB0KVobGvS48wkpCqEd3yS3h yF95bCIa5/AL/GZMEejvgvl/Ze1uAnzL1cemNsAzQiuydnMMCaquKWwalO5DX/xLwIRs g8cpONs278sdWpWInUhB+JT4VQgCGXWTu+tRwffInauaRFON8N0w6bkPGEu/7j1NgR0Q iUqw== X-Gm-Message-State: ALoCoQnJ4dW3wF0JxrxLwrqp0/dkYIbgtSCBJ0ChsWuSroBWS85WznzZWfkeiPt1fgdFs04NNR4I MIME-Version: 1.0 X-Received: by 10.236.53.5 with SMTP id f5mr30488660yhc.53.1397827812156; Fri, 18 Apr 2014 06:30:12 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Fri, 18 Apr 2014 06:30:12 -0700 (PDT) In-Reply-To: <026f01cf59b3$498206f0$dc8614d0$@olddog.co.uk> References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> <026f01cf59b3$498206f0$dc8614d0$@olddog.co.uk> Date: Fri, 18 Apr 2014 09:30:12 -0400 Message-ID: From: Eric Osborne To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Rz3rqk3-p3yZJbiK2F1mAuobuFg Cc: "mpls@ietf.org" , "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "Les Ginsberg \(ginsberg\)" Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:30:20 -0000 Thanks! Comments inline as well. I will post later today. On Wed, Apr 16, 2014 at 4:34 PM, Adrian Farrel wrote: > Hi Eric, > > Comments in line with appropriate snipping. > > Update and post when ready. > ... > > But I think it slightly misses my point that the colors have meaning spec= ific to an administrative domain. It is unclear how one administrative doma= in knows the meanings of the colors in another domain. And this is worse th= an an ERO: an ERO can be encoded (perhaps from the CLI) to span multiple do= mains because the addresses/labels/etc only have meaning at the point they = are examined. The color is applied to the whole LSP not embedded in the ERO= with the result that the domain boundary may have to translate the colors = for use in the next domain. > > I would argue that it is not practical for two domains to coordinate thei= r use of colors. EO# All of this is true. But it's a) just as bad with AG as with EAG; EAG is simply a longer version of AG. b) moot. Since we cannot signal EAG in either RSVP or PCEP, it cannot cross domains (intra- or inter-AS) in signaling. If we need to issue a document explaining the hazards of trying to signal affinity across boundaries, we can do so, and it will apply equally to AG and EAG. But that's not what I'm trying to do, and it's not something I've ever seen causing issues in the wild (YMMV, of course). Or I may still be missing the point entirely. ... >> > 2.3.1 ... >> I therefore propose the following for the entirety of section 2.3.1: >> >> ---- NEW ---- >> >> If a node advertises EAG it MAY also advertise AG. >> >> If a node advertises both AG and EAG then the first 32 bits of the >> EAG MUST be identical to the advertised AG. If a receiving node >> notices that the AG differs from the first 32 bits of the EAG, it >> SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> indicate this mismatch to the operator. This allows nodes which do >> not support EAG to obtain some >> link color information from the network, but also allow for an >> eventual migration away from AG. >> --- >> >> all this does is drop the sentence "If the AG and EAG advertised for a >> link differ, the EAG MUST take >> priority." as that clearly contradicted everything else in that secti= on. > > I feel the need to mutter :-) > Why the first SHOULD? EO# I have written and rewritten this comment two or three times. On the one hand, I don't see the need to mandate a headend-only behavior with a MUST. It's not like a different interpretation of an error case will cause an issue for anything other than the headend which disregards the recommended behavior. On the other hand, it *is* an error case. And it makes no sense to say "you MUST not advertise EAG !=3D AG, but if you find that in the wild then you MAY ignore the fact that it's an error and do something special and proprietary with it". After much back-and-forthing, I think the second point wins. > (And actually, why the need to compare the values?) EO# I said 'If a receiving node notices", not "When a receiving node notices"...it could be cleaner than that, of course. > > I'd suggest > > If a node advertises EAG it MAY also advertise AG. > > If a node advertises both AG and EAG then the first 32 bits of the > EAG MUST be identical to the advertised AG. > > If both an AG and EAG are present, a receiving node MUST use the > AG as the first 32 bits (0-31) of administrative color and use the EA= G > for bits 32 and higher if present. > > A receiving node that notices that the AG differs from the first 32 > bits of the EAG, SHOULD report this mismatch to the operator. > > This process allows nodes which do not support EAG to obtain some > link color information from the network, but also allow for an > eventual migration away from AG. EO# This is cleaner than the text I had, so I'll use it. ... >> > I read section 4.7.4 of RFC 3209 to compare it with what you say in >> > section 2.3.2 of this document. >> > >> > I read it to say: >> > - a link can only be excluded if it advertises a specific color >> > - a link can only be included if it advertises a specific color >> > Thus, failure to include AG means a link cannot be excluded according >> > to an exclusion requirement. But it also means that it cannot be >> > included according to an include or include-any requirement. >> >> EO# Right. It's a hole in 3209; that section assumes AG is always >> advertised. In my experience this is generally true in practice, and >> the implementations I know best have some default they assume if AG is >> not advertised. > > Oh, I don't think it is a hole at all! > The text is clear (to me) and works (IMHO) when AG is not advertised. EO# It's easy to conflate 'advertised' and 'defined'. We generally assume that if a node has AG defined that it will advertise it, and if it's not advertising it it's because it's not defined. If a node does not define AG but it receives signaling indicating a desire for a particular AG, it has to do one of three things: 1) assume some system-wide, unadvertised, default AG 2) reject the Path message on the grounds that it's asking for something which does not exist 3) ignore the AG bits entirely, as if what was sent was C-Type 7, not 1. None of these seem particularly pleasant or intuitive. > Recall, 3209 is about signaling not path computation. > We want to avoid: "I want chocolate ice cream." "Here is some ice cream, = I have no idea what flavor it is." > EO# I view C-Type 1 as "I want chocolate ice cream" and an IGP TE LSA with no AG as "here is my menu of things. You will kindly notice that it does not include ice cream of any kind." A mismatch between advertised AG and signaled AG is much closer to the "I have ice cream, but no chocolate / I want chocolate" situation. > However, you are saying that most implementations are saying "If you don'= t tell me, I will assume all ice cream is raspberry." > > But this is a side-track... > EO# Yes. An interesting philosophical discussion in a bar, but not germane to getting EAG out the door. ... > > If you lived in a transit node, you would see "pre-computation" as the pa= th was already computed when I received the signaling message. > > Looking at all of this, I think the hole I fell into is found under the q= uestion "Why is AG present in signaling in RFC 3209?" The answer to that qu= estion, I believe, is to allow transit nodes to expand loose hops, and to a= llow transit nodes to verify that a signaled path conforms to the admin col= ors requested for the LSP (also applies to local repair). > EO# I agree with this answer; that's what I always thought AG was for. > What you are saying (and it is fine to say it, although it would be bette= r to say it in the I-D :-) is that at the moment, all envisaged usage of EA= G is achieved at the headend or in a PCE. That means that there is no perce= ived use of EAG in signaling just as (you presumably contend) AG is not use= d in signaling today. > EO# OK. I feel compelled to at least point out exactly what this means, as "there is no signaling" may not mean much to someone who doesn't already have SESSION_ATTRIBUTE C-Type 1 or LSPA in mind. I will add this to the Intro: " EAG's intended use case is within a single domain. As such, this document provides no support for signaling EAG. It provides no analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in RFC3209, nor the LSPA object of the Path Computation Element Communication Protocol (PCEP) defined in [RFC5440] " and remove Section 3 in its entirety. I debated also adding "Such support can be added in a future document", but this seems unnecessary. I think this clears it up. It's Friday as I write this, I'll let it sit until Monday in case there are any last-minute objections to this approach, and plan to post it Monday. thanks! eric From nobody Fri Apr 18 07:06:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445AE1A0307 for ; Fri, 18 Apr 2014 07:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbfyIqK460ic for ; Fri, 18 Apr 2014 07:06:39 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BA1A0303 for ; Fri, 18 Apr 2014 07:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30844; q=dns/txt; s=iport; t=1397829995; x=1399039595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EybVXIen8zpO6ooY+EAwS5/s2hrVp73O+YeOeNn+CNU=; b=IZ9mBOjHbpJWeXlvhCKvbT6bjJwOrex7wmorr77Y8Rqh06UMyORaoxb4 zZVUufclZjqw/xrvFN+Y2Hr2gRMzOLJv5HYjogjCI1ohY20pvvbr31qD9 o7VfzE+ynkqZ80Nm6QLD9rhhpLPpDbHOJDEfpg0OfiLAELFqg16W+h2rx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAGUwUVOtJA2G/2dsb2JhbABagwaBJoMSwF4ZgQMWdIIlAQEBAwEaCRETJAMEBwwEAgEIEQQBAQECAgYdAwICAjAUAQgIAgQOBQiIMQipV4IKggifEBeBKYgUhEMKBgIBHjEHBoJpNYEUBJUAlj2DMYFpQg X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="36919222" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2014 14:06:34 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3IE6Yah002084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 14:06:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 09:06:34 -0500 From: "Les Ginsberg (ginsberg)" To: Eric Osborne Thread-Topic: AD review of draft-ietf-mpls-extended-admin-group Thread-Index: AQHPWYS49Zd+mwmEgEaj6NTc1415IJsUYTFAgAG4CICAAU7LwA== Date: Fri, 18 Apr 2014 14:06:33 +0000 Message-ID: References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7XWyHWUFOm_2nUWCayEYXEKG_rk Cc: "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:06:44 -0000 RXJpYyAtDQoNClRoYW54IGZvciB0aGUgcmVwbHkgYW5kIGV4cGxhbmF0aW9uLg0KDQpBdCB0aGUg cmlzayBvZiBiZWF0aW5nIGEgZGVhZCBob3JzZSwgaWYgRUFHIHdlcmUgc2ltcGx5IGFuIGFkZGl0 aW9uL2V4dGVuc2lvbiBvZiBBRyBJIGRvbuKAmXQgc2VlIHRoYXQgdGhpcyByZXF1aXJlcyBBRyB0 byBiZSBhZHZlcnRpc2VkIHdoZW4gRUFHIGlzIGFkdmVydGlzZWQuIEhhdmluZyByZWFkIFNlY3Rp b24gMi4zLjIgSSBzZWUgdGhhdCB0aGlzIGlzIGFuIGlzc3VlIHlvdSBhcmUgY29uY2VybmVkIHdp dGggLSB5b3Ugc29tZXdoYXQgcmVsdWN0YW50bHkgc3VnZ2VzdCB1bmFkdmVydGlzZWQgYml0cyBj YW4gYmUgYXNzdW1lZCB0byBiZSAwIC0gYnV0IGRvZXNuJ3QgdGhpcyBpc3N1ZSBnZXQgZXhhY2Vy YmF0ZWQgd2l0aCBFQUc/IFdoYXQgSSBtZWFuIGJ5IHRoYXQgaXMgdGhhdCBpZiBzb21lIHJvdXRl cnMgbmVlZCB0byBhZHZlcnRpc2UgMTI4IGJpdHMgeW91IHNlZW0gdG8gYmUgaW1wbHlpbmcgdGhh dCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgYWxsIHJvdXRlcnMgYWR2ZXJ0aXNlZCAxMjggYml0cyBl dmVuIGlmIHRoZXkgaGF2ZSBubyBsb2NhbCBsaW5rcyB3aGljaCByZXF1aXJlIGJpdHMgMzMgLSAx MjguIEJ1dCBvcGVyYXRpb25hbGx5IHRoaXMgbWVhbnMgdGhhdCBhcyBzb29uIGFzIG9uZSByb3V0 ZXIgaXMgY29uZmlndXJlZCB0byBhZHZlcnRpc2UgMTI4IGJpdHMgYWxsIHJvdXRlcnMgU0hPVUxE IGJlIGFkdmVydGlzZWQgdG8gYWR2ZXJ0aXNlIDEyOCBiaXRzIC0gd2hpY2ggc2VlbXMgdW5uZWNl c3NhcmlseSBvbmVyb3VzIC0gYXMgd2VsbCBhcyBibG9hdGluZyB0aGUgSUdQIExTREIuDQoNCkkg ZGVmZXIgdG8geW91ciBleHBlcnRpc2UgLSBJIG9ubHkgZGFiYmxlIGluIHRoaXMgc3BhY2UgZnJv bSB0aGUgSUdQIHBlcnNwZWN0aXZlIC0gc28gSSBhbSBmaW5lIHdpdGggd2hhdGV2ZXIgeW91IGRl Y2lkZSAtIGluY2x1ZGluZyB0aGUgY3VycmVudCBkZWZpbml0aW9uIC0gYnV0IG5vdyB5b3UgaGF2 ZSAiYWxsIG15IHRob3VnaHRzIiBvbiB0aGUgc3ViamVjdC4NCg0KICAgTGVzDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmljIE9zYm9ybmUgW21haWx0bzplcmlj QG5vdGNvbS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNywgMjAxNCA1OjU1IEFNDQo+ IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiBDYzogQWRyaWFuIEZhcnJlbDsgZHJhZnQt aWV0Zi1tcGxzLWV4dGVuZGVkLWFkbWluLWdyb3VwLmFsbEB0b29scy5pZXRmLm9yZzsNCj4gbXBs c0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEFE IHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtZXh0ZW5kZWQtYWRtaW4tZ3JvdXANCj4gDQo+IEhp IExlcy0NCj4gDQo+ICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LCBnbGFkIHRob3NlIGNoYW5nZXMg d29ya2VkIGZvciB5b3UuDQo+IEFzIGZhciBhcyB0aGUgY29uZmxpY3QsIHdlIHdlbnQgYmFjayBh bmQgZm9ydGggYW5kIHRoaXMgZHVyaW5nIGluaXRpYWwNCj4gZGV2ZWxvcG1lbnQuICBUaGVyZSBh cmUgcHJvYmFibHkgZ29vZCBhcmd1bWVudHMgb24gYm90aCBzaWRlcywgYW5kIGFzDQo+IGxvbmcg YXMgYSBkZXZpY2UgaXMgY29tcGxpYW50IG5vbmUgb2YgdGhpcyBzaG91bGQgbWF0dGVyLiAgVGhl IHJlYXNvbg0KPiB3ZSBkaWQgd2hhdCB3ZSBkaWQgaXMgdGhhdCBBRyBpcyB3aWRlc3ByZWFkIGJ1 dCBvcHRpb25hbCwgYW5kIGlmIHdlDQo+IGRlZmluZSBFQUcgdG8gc3RhcnQgYXQgYml0IDMyIHdl IHRoZW4gaGF2ZSB0byBkZWZpbmUgd2hhdCB5b3UgZG8gaWYgYQ0KPiBub2RlIGFkdmVydGlzZXMg RUFHIGFuZCBub3QgQUcsIGFuZCBhbm90aGVyIG5vZGUgaGFzIGRlc2lyZSBmb3IgYml0cw0KPiBp biB0aGUgQUcgc3BhY2UuIEl0IGdldHMganVzdCBhcyB1Z2x5LCBpZiBub3QgdWdsaWVyOyB3ZSdk IGhhdmUgdG8gc2F5DQo+IHNvbWV0aGluZyBsaWtlICJpZiB0aGVyZSBpcyBFQUcgYW5kIG5vIEFH LCBhc3N1bWUgQUcgPT0gMHgwIiwgYW5kIHRoaXMNCj4gY3JlYXRlcyB0d28gcHJvYmxlbXM6DQo+ ICAgIDEpIHNvbWUgaW1wbGVtZW50YXRpb25zIGhhdmUgZGVmYXVsdCBhc3N1bXB0aW9ucyBpbiB0 aGUgY2FzZSBvZg0KPiBtaXNzaW5nIEFHLCBhbmQgdGhleSBtYXkgbm90IGFsbCBiZSAweDANCj4g ICAgMikgaXQgbWFuZGF0ZXMgdGhhdCAndW5kZWZpbmVkJyA9PSAweDAsIHdoaWNoIG1ha2VzIG1l IGZlZWwgYWxsIHdlaXJkLg0KPiANCj4gSXQgKmlzKiB0cnVlIHRoYXQgYnkgZGVmaW5pbmcgRUFH IHRvIHN0YXJ0IGF0IGJpdCAwIHJhdGhlciB0aGFuIGJpdCAzMg0KPiB3ZSBjYW4gc29tZWRheSBy ZXBsYWNlIEFHLCBidXQgdGhhdCdzIG5vdCB0aGUgbW90aXZhdGlvbi4gIFRoZQ0KPiBtb3RpdmF0 aW9uIGlzIHNpbXBseSB0byBub3QgX3JlcXVpcmVfIEFHIGluIHRoZSBmYWNlIG9mIEVBRyB3aGVu IEFHIGJ5DQo+IGl0c2VsZiBpcyBvcHRpb25hbC4NCj4gDQo+IFRhcmVrLCBwbGVhc2UgY2hpbWUg aW4gaWYgSSBtaXNzZWQgYW55dGhpbmcuDQo+IA0KPiANCj4gDQo+IGVyaWMNCj4gDQo+IA0KPiAN Cj4gT24gV2VkLCBBcHIgMTYsIDIwMTQgYXQgMTE6NDUgQU0sIExlcyBHaW5zYmVyZyAoZ2luc2Jl cmcpDQo+IDxnaW5zYmVyZ0BjaXNjby5jb20+IHdyb3RlOg0KPiA+IEVyaWMgLQ0KPiA+DQo+ID4g VGhlIHJldmlzZWQgdGV4dCBpbiBTZWN0aW9uIDIuMy4xIGFkZHJlc3NlcyBteSBjb25jZXJuIC0g dGhhbnguDQo+ID4NCj4gPiBCdXQgSSBoYWQgYWxzbyBhc2tlZCB3aHkgdGhlIHBvdGVudGlhbCBj b25mbGljdCBiZXR3ZWVuIEFHIGFuZCBFQUcgY291bGQNCj4gbm90IGJlIGF2b2lkZWQgYWx0b2dl dGhlciBieSBkZWZpbmluZyBFQUcgYXMgcmVwcmVzZW50aW5nIHRoZSBncm91cHMgYmV5b25kDQo+ IHRoZSBmaXJzdCAzMiBkZWZpbmVkIGJ5IEFHLiBDb3VsZCB5b3UgcmVzcG9uZCB0byB0aGF0Pw0K PiA+DQo+ID4gSWYgdGhlIGFyZ3VtZW50IGlzIHRoYXQgeW91IHdvdWxkIGxpa2Ugc29tZWRheSB0 byBkZXByZWNhdGUgdGhlIHVzZSBvZiBBRyBJDQo+IGhhdmUgdG8gc2F5IHRoYXQgSSBkb27igJl0 IGZpbmQgdGhhdCB2ZXJ5IGNvbXBlbGxpbmcuDQo+ID4NCj4gPiAgICBMZXMNCj4gPg0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEVyaWMgT3Nib3JuZSBb bWFpbHRvOmVyaWNAbm90Y29tLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNiwg MjAxNCA4OjAxIEFNDQo+ID4+IFRvOiBBZHJpYW4gRmFycmVsDQo+ID4+IENjOiBkcmFmdC1pZXRm LW1wbHMtZXh0ZW5kZWQtYWRtaW4tZ3JvdXAuYWxsQHRvb2xzLmlldGYub3JnOw0KPiBtcGxzQGll dGYub3JnOw0KPiA+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTGVzIEdpbnNiZXJnIChn aW5zYmVyZykNCj4gPj4gU3ViamVjdDogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMt ZXh0ZW5kZWQtYWRtaW4tZ3JvdXANCj4gPj4NCj4gPj4gSEkgQWRyaWFuLQ0KPiA+Pg0KPiA+PiAg IEknbSBjY2luZyBMZXMgYXMgd2VsbDsgaGUgaGFkIHNvbWUgY29tbWVudHMgYXJvdW5kIHNlY3Rp b24gMi4zLjEgKGFzDQo+ID4+IGRpZCBldmVyeW9uZSBlbHNlLCBhbmQgcmlnaHRseSBzbykuDQo+ ID4+IElubGluZSB3aXRoIEVPIy4gIFNpbmNlIHRoZSB0aHJlYWQgaXMgcmF0aGVyIGxhcmdlIGFu ZCBpdCdzIGVhc3kgdG8NCj4gPj4gbG9zZSB0aGUgY2hhbmdlcywgSSBoYXZlIGF0dGFjaGVkIHRo ZSBjYW5kaWRhdGUtMDUgZHJhZnQgdG8gdGhpcw0KPiA+PiBlbWFpbC4gICBJdCBjYW4gYmUgY29t cGFyZWQgdG8gZHJhZnQtMDQsIHdoaWNoIGlzIHRoZSBsYXRlc3QgcG9zdGVkDQo+ID4+IHZlcnNp b24uDQo+ID4+DQo+ID4+IFN1bW1hcnk6IG1vc3Qgb2YgdGhlIGNoYW5nZXMgYXJlIG5vIGJpZyBk ZWFsLCBidXQgSSdtIHdyZXN0bGluZyB3aXRoDQo+ID4+IGhvdyB0byBleGNsdWRlIFBDRSBjbGVh bmx5Lg0KPiA+Pg0KPiA+PiBPbiBUdWUsIEFwciAxLCAyMDE0IGF0IDU6MzkgUE0sIEFkcmlhbiBG YXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KPiA+PiA+IEhlbGxvLA0KPiA+PiA+ DQo+ID4+ID4gSSBoYXZlIGRvbmUgbXkgdXN1YWwgQUQgcmV2aWV3IG9mIHlvdXIgZG9jdW1lbnQg dXBvbiByZWNlaXZpbmcgdGhlDQo+ID4+ID4gcHVibGljYXRpb24gcmVxdWVzdC4gVGhlIHB1cnBv c2UgaXMgdG8gY2F0Y2ggYW55IGlzc3VlcyB0aGF0IG1pZ2h0DQo+ID4+ID4gb3RoZXJ3aXNlIHNo b3cgdXAgZHVyaW5nIElFVEYgbGFzdCBjYWxsIG9yIElFU0cgcmV2aWV3IGFuZCB0byBnZXQgdGhl DQo+ID4+ID4gZG9jdW1lbnQgaW50byBnb29kIHNoYXBlIHNvIHRoYXQgdGhvc2UgbGF0ZXIgcmV2 aWV3cyBoYXZlIGEgY2xlYXJlcg0KPiA+PiA+IHJ1bi4NCj4gPj4gPg0KPiA+PiA+IFRoZXJlIGFy ZSBhIGZldyBjb21tZW50cyBiZWxvdyB0aGF0IEkgd291bGQgbGlrZSB5b3UgdG8gbG9vayBhdC4g VGhlDQo+ID4+ID4gSS1EIGlzIHZlcnkgc2hvcnQgYW5kIHNpbXBsZSwgc28gdGhlcmUgaXMgbm90 IG11Y2ggdG8gY29tbWVudCBvbiwgYnV0DQo+ID4+ID4gSSBoYXZlIGEgZmV3IGNvbmNlcm5zLCBj bGFyaWZpY2F0aW9ucywgYW5kIGVkaXRvcmlhbCBwb2ludHMgdGhhdCBJDQo+ID4+ID4gaG9wZSB5 b3Ugd2lsbCBsb29rIGF0LiBZb3UgYXJlLCBvZiBjb3Vyc2UsIHdlbGNvbWUgdG8gZGlzcHV0ZSBh bnkgb2YNCj4gPj4gPiB0aGVzZSBwb2ludHMgYW5kIGRpc2N1c3MgdGhlbSB3aXRoIG1lIG9uIHRo ZSBXRyBtYWlsaW5nIGxpc3QuDQo+ID4+ID4NCj4gPj4gPiBXaGlsZSB5b3UgYXJlIHdvcmtpbmcg b24gdGhpcyBJIHdpbGwgcHV0IHRoZSBkb2N1bWVudCBpbnRvICJSZXZpc2VkDQo+ID4+ID4gSS1E IE5lZWRlZCIgc3RhdGUgYW5kIEkgd2lsbCBhc2sgdGhlIFdHIGNoYWlycyB0byBzZW5kIGEgbm90 aWNlIGFib3V0DQo+ID4+ID4gdGhpcyBJLUQgdG8gdGhlIE9TUEYsIElTSVMsIGFuZCBDQ0FNUCBt YWlsaW5nIGxpc3RzIHNvIHRoYXQgdGhleSBhcmUNCj4gPj4gPiBhd2FyZSBvZiB0aGUgZHJhZnQg YW5kIGNhbiBjb21tZW50IGltbWVkaWF0ZWx5IG9yIGR1cmluZyBJRVRGIGxhc3QgY2FsbA0KPiA+ PiA+IGlmIHRoZXkgaGF2ZSBhbnkgY29uY2VybnMuDQo+ID4+ID4NCj4gPj4gPiBUaGFua3MgZm9y IHRoZSB3b3JrLA0KPiA+PiA+IEFkcmlhbg0KPiA+PiA+DQo+ID4+ID4gPT09DQo+ID4+ID4NCj4g Pj4gPiBUaGlzIGRvY3VtZW50IGFkZHMgYSBzdWItVExWLiBJIHRoaW5rIGl0IGlzIHlvdXIgaW50 ZW50aW9uIHRoYXQgdGhpcyBpcw0KPiA+PiA+IGEgc3ViLVRMViBvZiB0aGUgTGluayBUTFYgYW5k IG5vdCBvZiB0aGUgQWRtaW5pc3RyYXRpdmUgR3JvdXAgc3ViLVRMViwNCj4gPj4gPiBpdHNlbGYu IFRoYXQgc2VlbXMgcHJldHR5IGltcG9ydGFudCwgc28gaXQgbmVlZHMgdG8gYmUgc3RhdGVkIGNs ZWFybHkuDQo+ID4+ID4NCj4gPj4NCj4gPj4gRU8jICBGaXhlZC4NCj4gPj4NCj4gPj4gT2xkOg0K PiA+PiAtLS0NCj4gPj4NCj4gPj4gMi4gIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBz dWItVExWDQo+ID4+DQo+ID4+ICAgIFRoZSBFeHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBHcm91cHMg c3ViLVRMViBpcyB1c2VkLi4uDQo+ID4+IC0tLQ0KPiA+Pg0KPiA+Pg0KPiA+PiBOZXc6DQo+ID4+ IC0tLS0NCj4gPj4gMi4gIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBzdWItVExWDQo+ ID4+DQo+ID4+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN1Yi1UTFYgb2YgdGhlIExpbmsg VExWIGZvciBib3RoIE9TUEYNCj4gPj4gICAgW1JGQzM2MzBdIGFuZCBJU0lTIFtSRkM1MzA1XSBj YWxsZWQgdGhlIEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlDQo+ID4+ICAgIEdyb3VwcyAoRUFHKSBz dWItVExWLiAgVGhlIEVBRyBzdWItVExWIGlzIHVzZWQuLi4NCj4gPj4gLS0tLQ0KPiA+Pg0KPiA+ PiBPSz8NCj4gPj4NCj4gPj4gPiAtLS0NCj4gPj4gPg0KPiA+PiA+IFRoZSB1c2UgY2FzZSBpbiBw YXJhIDIgb2YgU2VjdGlvbiAxIGlzLCBvZiBjb3Vyc2UsIHByZWRpY2F0ZWQgb24gdXNpbmcNCj4g Pj4gPiBhIHNpbmdsZSBJR1AgZG9tYWluIChhcmVhL2xldmVsKSB0byBjb3ZlciB0aGUgd2hvbGUg bmV0d29yayB0aGF0IGlzDQo+ID4+ID4gYmVpbmcgZGlzY3Vzc2VkLiAgVGhhdCBpcyBPSywgYnV0 IHRoZSB0ZXh0IHNob3VsZCBub3RlIHRoaXMgY2F2ZWF0IGxlc3QNCj4gPj4gPiBwZW9wbGUgdGhp bmsgdGhhdCBhZG1pbiBjb2xvdXJzIGFyZSBzb21laG93IGdsb2JhbGx5IHVuaXF1ZS4NCj4gPj4g Pg0KPiA+Pg0KPiA+PiBFTyMgICBJIGFncmVlIHRoYXQgdGhlIHVzZSBjYXNlIHlvdSBjaXRlIGlz IHByb2JhYmx5IGEgc2luZ2xlLWxldmVsDQo+ID4+IGNhc2UuICBCdXQgdGhhdCBkb2Vzbid0IG1l YW4gRUFHIG11c3QgYmUgY29uc3RyYWluZWQgdG8gb25seSBhIHNpbmdsZQ0KPiA+PiBsZXZlbC4g IEFuIGltcGxlbWVudGF0aW9uIHRoYXQgc2lnbmFscyBBRyBpbiBSU1ZQIGNhbiB1c2UgaXQgYWNy b3NzDQo+ID4+IG11bHRpcGxlIGFyZWFzICh0aGF0J3MgcmVhbGx5IHRoZSBwb2ludCBvZiBzaWdu YWxpbmcgQUcgYXQgYWxsKS4gIEkNCj4gPj4gZG9uJ3Qgd2FudCB0byBwcmVjbHVkZSB0aGF0IGhh cHBlbmluZyB3aXRoIEVBRyBzaG91bGQgc29tZW9uZSBkZWNpZGUNCj4gPj4gdG8gaW1wbGVtZW50 IHNpZ25hbGluZyBvZiBFQUcgaW4gUlNWUC4NCj4gPj4NCj4gPj4gVG8gYWRkcmVzcyB5b3VyIGNv bW1lbnQgSSBoYXZlIGFkZGVkIGEgc2VudGVuY2UgdG8gc2VjdGlvbiAzLiAgSW4gaXRzDQo+ID4+ IGVudGlyZXR5Og0KPiA+Pg0KPiA+PiAtLS0gT0xEIC0tLS0NCj4gPj4gMy4gIFNpZ25hbGluZyBF eHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBHcm91cHMgaW4gUlNWUA0KPiA+Pg0KPiA+PiAgICBSU1ZQ IHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIHNpZ25hbCBsaW5rIGFmZmluaXR5IHZpYSB0aGUNCj4g Pj4gICAgU0VTU0lPTl9BVFRSSUJVVEUgb2JqZWN0IHdpdGggQy1UeXBlIDEgaW4gUkZDIDMyMDkg W1JGQzMyMDldLg0KPiA+PiAgICBTaWduYWxpbmcgRUFHIGluIFJTVlAgaXMgbm90IGFkZHJlc3Nl ZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KPiA+PiAgICBkb2N1bWVudCBkb2VzIG5vdCBwcmVj bHVkZSBhZGRyZXNzaW5nIHRoaXMgaW4gdGhlIGZ1dHVyZSBzaG91bGQgaXQgYmUNCj4gPj4gICAg ZGVlbWVkIG5lY2Vzc2FyeQ0KPiA+PiAtLS0tDQo+ID4+DQo+ID4+IC0tLS0gTkVXIC0tLS0NCj4g Pj4gMy4gIFNpZ25hbGluZyBFeHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBHcm91cHMgaW4gUlNWUA0K PiA+Pg0KPiA+PiAgICBSU1ZQIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIHNpZ25hbCBsaW5rIGFm ZmluaXR5IHZpYSB0aGUNCj4gPj4gICAgU0VTU0lPTl9BVFRSSUJVVEUgb2JqZWN0IHdpdGggQy1U eXBlIDEgaW4gUkZDIDMyMDkgW1JGQzMyMDldLg0KPiA+PiAgICBTaWduYWxpbmcgRUFHIGluIFJT VlAgaXMgbm90IGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KPiA+PiAgICBkb2N1 bWVudCBkb2VzIG5vdCBwcmVjbHVkZSBhZGRyZXNzaW5nIHRoaXMgaW4gdGhlIGZ1dHVyZSBzaG91 bGQgaXQgYmUNCj4gPj4gICAgZGVlbWVkIG5lY2Vzc2FyeS4NCj4gPj4NCj4gPj4gICAgTm90ZSB0 aGF0IHNpZ25hbGluZyBFQUcgaXMgUlNWUCBpcyBsaWtlbHkgdG8gYmUgbmVjZXNzYXJ5IHRvIGV4 cGFuZA0KPiA+PiAgICB0aGUgdXNlIG9mIEVBRyBvdXRzaWRlIGEgc2luZ2xlIGFyZWEvbGV2ZWws IGp1c3QgYXMgaXQgaXMgd2l0aCBBRw0KPiA+PiAtLS0NCj4gPj4NCj4gPj4gYnV0IHBsZWFzZSBz ZWUgbXkgY29tbWVudHMgbGF0ZXIgaW4gdGhpcyBtYWlsIGFib3V0IFBDRVAuDQo+ID4+DQo+ID4+ ID4gLS0tDQo+ID4+ID4NCj4gPj4gPiBTZWN0aW9uIDIuMQ0KPiA+PiA+DQo+ID4+ID4gICBUaGUg RUFHIG1heQ0KPiA+PiA+ICAgIGJlIG9mIGFueSBsZW5ndGgsIGJ1dCBNVVNUIGJlIGEgbXVsdGlw bGUgb2YgNCBieXRlcy4NCj4gPj4gPg0KPiA+PiA+IElzIGEgemVyby1sZW5ndGggVExWIGFsbG93 ZWQ/DQo+ID4+ID4NCj4gPj4NCj4gPj4gRU8jICBJJ20gbm90IHN1cmUgd2hhdCBpdCB3b3VsZCBh Y3R1YWxseSAqZG8qLiAgTWFraW5nIGNsZWFyIHRoYXQgYQ0KPiA+PiBUTFYgbXVzdCBhY3R1YWxs eSBjb250YWluIHNvbWUgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gYmUgdXNlZnVsIGlzDQo+ID4+ IHByb2JhYmx5IG1vcmUgbmVjZXNzYXJ5IHRoYW4gSSdkIGxpa2UgdG8gdGhpbmsuICBJIGxpdmUg aW4gYSBjb3VudHJ5DQo+ID4+IHdoZXJlIHdlIGhhdmUgdG8gc2F5ICJ0aGlzIHBsYXN0aWMgYmFn IGlzIG5vdCBhIHRveSwgZG8gbm90IGdpdmUgdG8NCj4gPj4gaW5mYW50cyIganVzdCBpbiBjYXNl IHNvbWVvbmUgdGhvdWdodCBvdGhlcndpc2UuLi5pdCBpcyBmb3IgdGhvc2UNCj4gPj4gcGVvcGxl IHRoYXQgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4gPj4NCj4gPj4gLS0tIE9MRCAt LS0NCj4gPj4NCj4gPj4gVGhlIEVBRyBtYXkNCj4gPj4gICAgYmUgb2YgYW55IGxlbmd0aCwgYnV0 IE1VU1QgYmUgYSBtdWx0aXBsZSBvZiA0IGJ5dGVzLg0KPiA+PiAtLS0tDQo+ID4+DQo+ID4+DQo+ ID4+IC0tLSBORVcgLS0tLQ0KPiA+Pg0KPiA+PiBUaGUgRUFHIG1heSBiZSBvZiBhbnkgbm9uLXpl cm8gbGVuZ3RoLCBidXQgTVVTVCBiZSBhIG11bHRpcGxlIG9mIDQgYnl0ZXMNCj4gPj4gLS0tLS0N Cj4gPj4NCj4gPj4gT0s/DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ID4gLS0tDQo+ID4+ID4NCj4g Pj4gPiAyLjMuMQ0KPiA+PiA+DQo+ID4+DQo+ID4+IEVPIyAgVGhpcyBzZWN0aW9uIGlzIHJhdGhl ciBjb25mdXNpbmcuLi5tdWx0aXBsZSByZXZpZXdlcnMgY2F1Z2h0IGl0Lg0KPiA+PiBUaGUgY3Vy cmVudCB0ZXh0IGluIGl0cyBlbnRpcmV0eSBpczoNCj4gPj4NCj4gPj4gLS0tLSBPTEQgLS0tLQ0K PiA+PiAyLjMuMS4gIEFHIGFuZCBFQUcgY29leGlzdGVuY2UNCj4gPj4NCj4gPj4gICAgSWYgYSBu b2RlIGFkdmVydGlzZXMgRUFHIGl0IE1BWSBhbHNvIGFkdmVydGlzZSBBRy4NCj4gPj4NCj4gPj4g ICAgSWYgYSBub2RlIGFkdmVydGlzZXMgYm90aCBBRyBhbmQgRUFHIHRoZW4gdGhlIGZpcnN0IDMy IGJpdHMgb2YgdGhlDQo+ID4+ICAgIEVBRyBNVVNUIGJlIGlkZW50aWNhbCB0byB0aGUgYWR2ZXJ0 aXNlZCBBRy4gIElmIGEgcmVjZWl2aW5nIG5vZGUNCj4gPj4gICAgbm90aWNlcyB0aGF0IHRoZSBB RyBkaWZmZXJzIGZyb20gdGhlIGZpcnN0IDMyIGJpdHMgb2YgdGhlIEVBRywgaXQNCj4gPj4gICAg U0hPVUxEIHVzZSB0aGUgQUcgYXMgdGhlIGZpcnN0IDMyIGJpdHMgb2YgdGhlIEVBRywgYW5kIFNI T1VMRA0KPiA+PiAgICBpbmRpY2F0ZSB0aGlzIG1pc21hdGNoIHRvIHRoZSBvcGVyYXRvci4NCj4g Pj4NCj4gPj4gICAgSWYgdGhlIEFHIGFuZCBFQUcgYWR2ZXJ0aXNlZCBmb3IgYSBsaW5rIGRpZmZl ciwgdGhlIEVBRyBNVVNUIHRha2UNCj4gPj4gICAgcHJpb3JpdHkuICBUaGlzIGFsbG93cyBub2Rl cyB3aGljaCBkbyBub3Qgc3VwcG9ydCBFQUcgdG8gb2J0YWluIHNvbWUNCj4gPj4gICAgbGluayBj b2xvciBpbmZvcm1hdGlvbiBmcm9tIHRoZSBuZXR3b3JrLCBidXQgYWxzbyBhbGxvdyBmb3IgYW4N Cj4gPj4gICAgZXZlbnR1YWwgbWlncmF0aW9uIGF3YXkgZnJvbSBBRy4NCj4gPj4gLS0tLQ0KPiA+ Pg0KPiA+PiBhbmQgaXQgd2FzIHdvcmRlZCB0aGF0IHdheSBhZnRlciBhIGRpc2N1c3Npb24gb24g dGhlIGxpc3Qgd2l0aCBBbmR5DQo+ID4+IE1hbGlzIGFuZCBUYXJlayBTYWFkLg0KPiA+PiBUaGUg aW50ZW50IGlzIHN0cmFpZ2h0Zm9yd2FyZDogaW4gdGhlIGV2ZW50IG9mIGEgbWlzbWF0Y2gsIHBy ZWZlciBBRy4NCj4gPj4NCj4gPj4gPiAgICBJZiBhIHJlY2VpdmluZyBub2RlDQo+ID4+ID4gICAg bm90aWNlcyB0aGF0IHRoZSBBRyBkaWZmZXJzIGZyb20gdGhlIGZpcnN0IDMyIGJpdHMgb2YgdGhl IEVBRywgaXQNCj4gPj4gPiAgICBTSE9VTEQgdXNlIHRoZSBBRyBhcyB0aGUgZmlyc3QgMzIgYml0 cyBvZiB0aGUgRUFHLCBhbmQgU0hPVUxEDQo+ID4+ID4gICAgaW5kaWNhdGUgdGhpcyBtaXNtYXRj aCB0byB0aGUgb3BlcmF0b3IuDQo+ID4+ID4NCj4gPj4gPiAgICBJZiB0aGUgQUcgYW5kIEVBRyBh ZHZlcnRpc2VkIGZvciBhIGxpbmsgZGlmZmVyLCB0aGUgRUFHIE1VU1QgdGFrZQ0KPiA+PiA+ICAg IHByaW9yaXR5Lg0KPiA+PiA+DQo+ID4+ID4gQXJlbid0IHRoZXNlIHR3byBzdGF0ZW1lbnRzIGNv bnRyYWRpY3Rvcnk/DQo+ID4+ID4gSSBzdXNwZWN0IHRoZSBmaW5hbCAiRUFHIiBpcyBzdXBwb3Nl ZCB0byByZWFkICJBRyIgdG8gYmUgY29uc2lzdGVudA0KPiA+PiA+IHdpdGggdGhlIGZpcnN0IHBh cmFncmFwaCBhbmQgYWxzbyB0byBtYXRjaCB0aGUgZmlyc3QgbW90aXZhdGlvbiBnaXZlbg0KPiA+ PiA+IGltbWVkaWF0ZWx5IGFmdGVyLg0KPiA+Pg0KPiA+PiBFTyMgIFNvcnQgb2YuICBUaGVyZSBh cmUgYSBmZXcgb3B0aW9ucyBoZXJlIGluIHRoZSBldmVudCBvZiBhIG1pc21hdGNoOg0KPiA+Pg0K PiA+PiAxKSB1c2Ugb25seSBBRw0KPiA+PiAyKSBvdmVyd3JpdGUgdGhlIGZpcnN0IDMyIGJpdHMg b2YgRUFHIHdpdGggQUcsIHRoZW4gdXNlIHRoZSBlbnRpcmUgRUFHLg0KPiA+PiAzKSB1c2Ugb25s eSBFQUcNCj4gPj4NCj4gPj4NCj4gPj4gSW4gdGhlIGRpc2N1c3Npb24gd2l0aCBBbmR5IGFuZCBU YXJlayB3ZSBjYW1lIHRvIGFncmVlbWVudCBvbiAjMi4NCj4gPj4gVGhhdCdzIHdoYXQgdGhlIHRl eHQgaW4gc2VjdGlvbiAyLjMuMSBuZWVkcyB0byBzYXkuDQo+ID4+DQo+ID4+IEkgdGhlcmVmb3Jl IHByb3Bvc2UgdGhlIGZvbGxvd2luZyBmb3IgdGhlIGVudGlyZXR5IG9mIHNlY3Rpb24gMi4zLjE6 DQo+ID4+DQo+ID4+IC0tLS0gTkVXIC0tLS0NCj4gPj4NCj4gPj4gICAgSWYgYSBub2RlIGFkdmVy dGlzZXMgRUFHIGl0IE1BWSBhbHNvIGFkdmVydGlzZSBBRy4NCj4gPj4NCj4gPj4gICBJZiBhIG5v ZGUgYWR2ZXJ0aXNlcyBib3RoIEFHIGFuZCBFQUcgdGhlbiB0aGUgZmlyc3QgMzIgYml0cyBvZiB0 aGUNCj4gPj4gICAgRUFHIE1VU1QgYmUgaWRlbnRpY2FsIHRvIHRoZSBhZHZlcnRpc2VkIEFHLiAg SWYgYSByZWNlaXZpbmcgbm9kZQ0KPiA+PiAgICBub3RpY2VzIHRoYXQgdGhlIEFHIGRpZmZlcnMg ZnJvbSB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgRUFHLCBpdA0KPiA+PiAgICBTSE9VTEQgdXNl IHRoZSBBRyBhcyB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgRUFHLCBhbmQgU0hPVUxEDQo+ID4+ ICAgIGluZGljYXRlIHRoaXMgbWlzbWF0Y2ggdG8gdGhlIG9wZXJhdG9yLiAgVGhpcyBhbGxvd3Mg bm9kZXMgd2hpY2ggZG8NCj4gPj4gbm90IHN1cHBvcnQgRUFHIHRvIG9idGFpbiBzb21lDQo+ID4+ ICAgIGxpbmsgY29sb3IgaW5mb3JtYXRpb24gZnJvbSB0aGUgbmV0d29yaywgYnV0IGFsc28gYWxs b3cgZm9yIGFuDQo+ID4+ICAgIGV2ZW50dWFsIG1pZ3JhdGlvbiBhd2F5IGZyb20gQUcuDQo+ID4+ IC0tLQ0KPiA+Pg0KPiA+PiBhbGwgdGhpcyBkb2VzIGlzIGRyb3AgdGhlIHNlbnRlbmNlICJJZiB0 aGUgQUcgYW5kIEVBRyBhZHZlcnRpc2VkIGZvciBhDQo+ID4+IGxpbmsgZGlmZmVyLCB0aGUgRUFH IE1VU1QgdGFrZQ0KPiA+PiAgICBwcmlvcml0eS4iIGFzIHRoYXQgY2xlYXJseSBjb250cmFkaWN0 ZWQgZXZlcnl0aGluZyBlbHNlIGluIHRoYXQNCj4gc2VjdGlvbi4NCj4gPj4NCj4gPj4NCj4gPj4g Pg0KPiA+PiA+ICAgIFRoaXMgYWxsb3dzIG5vZGVzIHdoaWNoIGRvIG5vdCBzdXBwb3J0IEVBRyB0 byBvYnRhaW4gc29tZQ0KPiA+PiA+ICAgIGxpbmsgY29sb3IgaW5mb3JtYXRpb24gZnJvbSB0aGUg bmV0d29yaywgYnV0IGFsc28gYWxsb3cgZm9yIGFuDQo+ID4+ID4gICAgZXZlbnR1YWwgbWlncmF0 aW9uIGF3YXkgZnJvbSBBRy4NCj4gPj4gPg0KPiA+PiA+IE9UT0guLi4NCj4gPj4gPg0KPiA+PiA+ IDEuIFRoZSBzZWNvbmQgbW90aXZhdGlvbiBzZWVtcyB0byBzdXBwb3J0IEVBRyB0YWtpbmcgcHJp b3JpdHkuDQo+ID4+ID4NCj4gPj4gPiAyLiBUaGUgZmlyc3QgbW90aXZhdGlvbiBzZWVtcyB0byBt aXNzIHNvbWUgcmVhbGx5IGJpZyBpc3N1ZXMgY29uY2VybmluZw0KPiA+PiA+ICAgIG5vbi1zdXBw b3J0IG9mIEVBRy4gWW91IG5lZWQgdG8gZGlzY3VzcyB0aGlzIHByb2Nlc3NpbmcgaW4gcmVsYXRp b24NCj4gPj4gPiAgICB0byBzaWduYWxpbmcuLi4NCj4gPj4gPg0KPiA+PiA+ICAgIFN1cHBvc2Ug YSBsaW5rIGlzIGFkdmVydGlzZWQgd2l0aCBFQUcgYW5kIGEgbm9kZSB0aGF0IGRvZXMgbm90DQo+ ID4+ID4gICAgc3VwcG9ydCBFQUcgc2lnbmFscyBhbiBMU1A/DQo+ID4+DQo+ID4+IEVPIyAgSSBk b24ndCB0aGluayB0aGlzIGFwcGxpZXMsIHNpbmNlIHRoZXJlIGlzIG5vIHN1cHBvcnQgZm9yDQo+ ID4+IHNpZ25hbGVkIEVBRy4gIEl0J3MgcHVyZWx5IGZvciBoZWFkZW5kIGNhbGN1bGF0aW9uLg0K PiA+Pg0KPiA+PiA+DQo+ID4+ID4gICAgU3VwcG9zZSBvbmUgZW5kIG9mIGEgbGluayBzdXBwb3J0 cyBFQUcgYnV0IHRoZSBvdGhlciBkb2VzIG5vdCBhbmQNCj4gPj4gPiAgICBhIHNpZ25hbGluZyBt ZXNzYWdlIGluY2x1ZGVzIEVBRyBhbmQgdGhlIHVwc3RyZWFtIGVuZCBvZiB0aGUgbGluaw0KPiA+ PiA+ICAgIGlnbm9yZXMgaXQ/DQo+ID4+ID4NCj4gPj4NCj4gPj4gRU8jICBUaGUgc2FtZSBpcyB0 cnVlIG9mIG9uZSBlbmQgc2lnbmFsaW5nIEFHIGFuZCB0aGUgb3RoZXIgbm90DQo+ID4+IHNpZ25h bGluZyBhbnl0aGluZzsgZGVzcGl0ZSBpdHMgd2lkZXNwcmVhZCBhZHZlcnRpc2VtZW50LCBBRyBp cw0KPiA+PiBvcHRpb25hbC4NCj4gPj4NCj4gPj4gSSBuZXZlciB0aG91Z2h0IHRoZXJlIHdhcyBh bnkgcmVxdWlyZW1lbnQgZm9yIGEgVEUgbGluayB0byBoYXZlDQo+ID4+IGlkZW50aWNhbCBwcm9w ZXJ0aWVzIGluIGJvdGggZGlyZWN0aW9ucy4gIE5laXRoZXIgcmZjMzYzMCBub3IgcmZjNTMwNQ0K PiA+PiBjb25jZXJuIHRoZW1zZWx2ZXMgd2l0aCBiaWRpcmVjdGlvbmFsaXR5IGluIGFueSBvZiB0 aGUgVEUgVExWcywgbm9yDQo+ID4+IGRvZXMgcmZjNTMwNy4gIFRoZSBpbXBsZW1lbnRhdGlvbnMg SSdtIGZhbWlsaWFyIHdpdGggcGVyZm9ybSBhIGJhc2ljDQo+ID4+IHR3by13YXkgY29ubmVjdGl2 aXR5IGNoZWNrLCBidXQgdGhhdCdzIGl0Lg0KPiA+Pg0KPiA+PiBJIHdvdWxkIHByZWZlciB0byBz dGF5IGF3YXkgZnJvbSBwcmVzY3JpYmluZyBiZWhhdmlvciBoZXJlIHRoYXQgaXMNCj4gPj4gbW9y ZSByZXN0cmljdGl2ZSB0aGFuIHdoYXQncyBzcGVjaWZpZWQgaW4gdGhlIGJhc2UgZG9jdW1lbnRz Lg0KPiA+Pg0KPiA+PiA+ICAgIEkgdGhpbmsgeW91IGhhdmUgc29tZSBlZGdlIGNvbmRpdGlvbnMg dG8gZGVzY3JpYmUgaW4gc2VjdGlvbiAyLjMNCj4gPj4gPg0KPiA+Pg0KPiA+PiBFTyMgIE5vIHN1 Y2ggY29uZGl0aW9ucyBhcmUgZGlzY3Vzc2VkIGluIGFueSBvdGhlciBSRkMgd2hpY2ggc3BlY2lm aWVzDQo+ID4+IFRFIGxpbmsgcHJvcGVydGllcywgYW5kIHdlIHNlZW0gdG8gaGF2ZSBnb3R0ZW4g YWxvbmcganVzdCBmaW5lLiAgSWYNCj4gPj4geW91IGZlZWwgc3Ryb25nbHkgYWJvdXQgdGhpcyB0 aGVuIHdlIGNhbiBzb3J0IHNvbWV0aGluZyBvdXQsIGJ1dCBJJ20NCj4gPj4gcmVsdWN0YW50IHRv IG1ha2UgdGhlIEVBRyBkb2N1bWVudCB0aGUgcGxhY2Ugd2hlcmUgYWxsIHNvcnRzIG9mDQo+ID4+ IGFzc3VtcHRpb25zIGFib3V0IENTUEYgZ2V0IHNwZWxsZWQgb3V0Lg0KPiA+Pg0KPiA+PiA+IC0t LQ0KPiA+PiA+DQo+ID4+ID4gSSByZWFkIHNlY3Rpb24gNC43LjQgb2YgUkZDIDMyMDkgdG8gY29t cGFyZSBpdCB3aXRoIHdoYXQgeW91IHNheSBpbg0KPiA+PiA+IHNlY3Rpb24gMi4zLjIgb2YgdGhp cyBkb2N1bWVudC4NCj4gPj4gPg0KPiA+PiA+IEkgcmVhZCBpdCB0byBzYXk6DQo+ID4+ID4gLSBh IGxpbmsgY2FuIG9ubHkgYmUgZXhjbHVkZWQgaWYgaXQgYWR2ZXJ0aXNlcyBhIHNwZWNpZmljIGNv bG9yDQo+ID4+ID4gLSBhIGxpbmsgY2FuIG9ubHkgYmUgaW5jbHVkZWQgaWYgaXQgYWR2ZXJ0aXNl cyBhIHNwZWNpZmljIGNvbG9yDQo+ID4+ID4gVGh1cywgZmFpbHVyZSB0byBpbmNsdWRlIEFHIG1l YW5zIGEgbGluayBjYW5ub3QgYmUgZXhjbHVkZWQgYWNjb3JkaW5nDQo+ID4+ID4gdG8gYW4gZXhj bHVzaW9uIHJlcXVpcmVtZW50LiBCdXQgaXQgYWxzbyBtZWFucyB0aGF0IGl0IGNhbm5vdCBiZQ0K PiA+PiA+IGluY2x1ZGVkIGFjY29yZGluZyB0byBhbiBpbmNsdWRlIG9yIGluY2x1ZGUtYW55IHJl cXVpcmVtZW50Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBFTyMgIFJpZ2h0LiAgSXQncyBhIGhvbGUgaW4g MzIwOTsgdGhhdCBzZWN0aW9uIGFzc3VtZXMgQUcgaXMgYWx3YXlzDQo+ID4+IGFkdmVydGlzZWQu ICBJbiBteSBleHBlcmllbmNlIHRoaXMgaXMgZ2VuZXJhbGx5IHRydWUgaW4gcHJhY3RpY2UsIGFu ZA0KPiA+PiB0aGUgaW1wbGVtZW50YXRpb25zIEkga25vdyBiZXN0IGhhdmUgc29tZSBkZWZhdWx0 IHRoZXkgYXNzdW1lIGlmIEFHIGlzDQo+ID4+IG5vdCBhZHZlcnRpc2VkLg0KPiA+Pg0KPiA+PiAu Li4uDQo+ID4+DQo+ID4+ID4gSSB0aGluayB0aGlzIGlzIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50 IHRvIFJGQyAzMjA5Lg0KPiA+PiA+IFRoYXQgaXMsIGEgbGluayBjYW5ub3QgYmUgZXhjbHVkZWQg b24gdGhlIGJhc2lzIG9mIGFuIHVuYWR2ZXJ0aXNlZA0KPiA+PiA+IGFmZmluaXR5IGJlY2F1c2Ug aXQgaXMgYXNzdW1lZCB0byBiZSAwLg0KPiA+PiA+IEFuZCBhIGxpbmsgY2Fubm90IGJlIGluY2x1 ZGVkIG9uIHRoZSBiYXNpcyBvZiBhbiB1bmFkdmVydGlzZWQgYWZmaW5pdHkNCj4gPj4gPiBiZWNh dXNlIGl0IGlzIGFzc3VtZWQgdG8gYmUgMC4NCj4gPj4gPg0KPiA+PiA+IFNvIGl0IGFsbCBlbmRz IHVwIHJpZ2h0IGluIHRoZSBlbmQsIGJ1dCBpdCB0b29rIGEgbG90IG9mIHdvcmRzIQ0KPiA+Pg0K PiA+PiBFTyMgIFllYWguLi5JIHdhbnRlZCB0byBtYWtlIGNsZWFyIHdoYXQgNC43LjQgbWVhbnQg d2l0aG91dCBhZGRpbmcNCj4gPj4gc29tZSBiYWNrZG9vciByZXF1aXJlbWVudHMgdG8gaXQuDQo+ ID4+DQo+ID4+ID4NCj4gPj4gPiAtLS0NCj4gPj4gPg0KPiA+PiA+IEluIFNlY3Rpb24gMi4zLjIg eW91IGhhdmUgYW4gImludGVyZXN0aW5nIiBtaXggb2YgYWR2aWNlIGFuZCAyMTE5IHdvcmRzLg0K PiA+PiA+DQo+ID4+DQo+ID4+IC4uLi4NCj4gPj4NCj4gPj4gWWVzLg0KPiA+PiBZZXMgSSBkaWQu DQo+ID4+DQo+ID4+IEkgdGhpbmsgcy9NVVNUL1NIT1VMRC8gZm9yIHRoZSBmaXJzdCBNVVNUIGlu IDIuMy4yLCBhcyB3ZWxsIGFzIHNvbWUNCj4gPj4gdHdlYWtpbmcsIGZpeGVzIGl0LiAgSSBwcm9w b3NlOg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0gIE9MRC0tLS0NCj4gPj4NCj4gPj4gICBFYWNoIGlt cGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gY2hvb3NlIGl0cyBvd24gbWV0aG9kIGZvciBoYW5kbGlu Zw0KPiA+PiAgICB0aGlzIHF1ZXN0aW9uLiAgSG93ZXZlciwgdG8gYWxsb3cgZm9yIG1heGltdW0g aW50ZXJvcGVyYWJpbGl0eSBhbg0KPiA+PiAgICBpbXBsZW1lbnRhdGlvbiBNVVNUIHRyZWF0IGRl c2lyZWQgYnV0IHVuYWR2ZXJ0aXNlZCBFQUcgYml0cyBhcyBpZg0KPiA+PiAgICB0aGV5IGFyZSBz ZXQgdG8gMC4gIENvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIGEgbm9kZSB3YW50cyB0byBvbmx5IHVz ZQ0KPiA+PiAgICBsaW5rcyB3aGVyZSB0aGUgMTI3dGggYml0IG9mIGFuIEVBRyBpcyBzZXQgdG8g MS4gIElmIGEgbGluayBpcyBvbmx5DQo+ID4+ICAgIGFkdmVydGlzaW5nIDY0IEVBRyBiaXRzLCBj bGVhcmx5IHRoZSAxMjd0aCBFQUcgYml0IGlzIG5vdCBkZWZpbmVkIC0NCj4gPj4gICAgdGhhdCBp cywgaXQgaXMgbmVpdGhlciBleHBsaWNpdGx5IDAgbm9yIDEuICBUaGUgbm9kZSB3aGljaCB3YW50 cyB0aGUNCj4gPj4gICAgMTI3dGggRUFHIGJpdCB0byBiZSAxIE1VU1QgTk9UIHVzZSB0aGlzIGxp bmssIGFzIHRoZSBhc3N1bXB0aW9uIGlzDQo+ID4+ICAgIHRoYW4gYW4gdW5hZHZlcnRpc2VkIGJp dCBpcyBzZXQgdG8gMC4NCj4gPj4gLS0tLQ0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0gTkVXIC0tLQ0K PiA+Pg0KPiA+PiAgIEVhY2ggaW1wbGVtZW50YXRpb24gaXMgZnJlZSB0byBjaG9vc2UgaXRzIG93 biBtZXRob2QgZm9yIGhhbmRsaW5nDQo+ID4+ICAgIHRoaXMgcXVlc3Rpb24uICBIb3dldmVyLCB0 byBhbGxvdyBmb3IgbWF4aW11bSBpbnRlcm9wZXJhYmlsaXR5IGFuDQo+ID4+ICAgIGltcGxlbWVu dGF0aW9uIFNIT1VMRCB0cmVhdCBkZXNpcmVkIGJ1dCB1bmFkdmVydGlzZWQgRUFHIGJpdHMgYXMg aWYNCj4gPj4gICAgdGhleSBhcmUgc2V0IHRvIDAuICBDb25zaWRlciB0aGUgY2FzZSB3aGVyZSBh IG5vZGUgd2FudHMgdG8gb25seSB1c2UNCj4gPj4gICAgbGlua3Mgd2hlcmUgdGhlIDEyN3RoIGJp dCBvZiBhbiBFQUcgaXMgc2V0IHRvIDEuICBJZiBhIGxpbmsgaXMgb25seQ0KPiA+PiAgICBhZHZl cnRpc2luZyA2NCBFQUcgYml0cywgY2xlYXJseSB0aGUgMTI3dGggRUFHIGJpdCBpcyBub3QgZGVm aW5lZCAtDQo+ID4+ICAgIHRoYXQgaXMsIGl0IGlzIG5laXRoZXIgZXhwbGljaXRseSAwIG5vciAx LiAgVGhlIG5vZGUgd2hpY2ggd2FudHMgdGhlDQo+ID4+ICAgIDEyN3RoIEVBRyBiaXQgdG8gYmUg MSBNVVNUIE5PVCB1c2UgdGhpcyBsaW5rIHdoZW4gaW1wbGVtZW50aW5nIHRoZQ0KPiA+PiByZWNv bW1lbmRlZCBiZWhhdmlvciwgYXMgdGhlIGFzc3VtcHRpb24gaXMNCj4gPj4gICAgdGhhbiBhbiB1 bmFkdmVydGlzZWQgYml0IGlzIHNldCB0byAwLg0KPiA+PiAtLS0NCj4gPj4NCj4gPj4NCj4gPj4g Li4uDQo+ID4+DQo+ID4+ID4gQnV0LCBvbmUgZmluYWwgcXVlc3Rpb24uLi4NCj4gPj4gPiBXaHkg ZG8geW91IHdhbnQgdG8gYWxsb3cgb3RoZXIgbW9kZXMgb2Ygb3BlcmF0aW9uPw0KPiA+PiA+IFdo YXQgaXMgdGhlIGJlbmVmaXQsIGFuZCB3aHkgZGlkbid0IHlvdSBjYWxsIGl0IG91dD8NCj4gPj4N Cj4gPj4NCj4gPj4gRU8jICBBcyB3aXRoIG90aGVyIHVzZXMgb2YgU0hPVUxEIChlLmcuLCBzZWN0 aW9uIDIuMy4xKSB0aGVyZSBpcw0KPiA+PiBhbHJlYWR5IGF0IGxlYXN0IG9uZSBpbXBsZW1lbnRh dGlvbiBvdXQgdGhlcmUgYW5kIHdoaWxlIGl0IGhld3MgaW4NCj4gPj4gbGFyZ2UgcGFydCB0byB0 aGUgZG9jdW1lbnQgYXMgd3JpdHRlbiwgSSBkaWQgbm90IHdhbnQgdG8gaW5hZHZlcnRlbnRseQ0K PiA+PiBkZXByZWNhdGUgaXQuDQo+ID4+DQo+ID4+ID4NCj4gPj4gPiAtLS0NCj4gPj4gPg0KPiA+ PiA+IFNlY3Rpb24gMyBkZWxpYmVyYXRlbHkgc2lkZXN0ZXBzIHRoZSB1c2Ugb2YgRUFHIGluIHNp Z25hbGluZy4gVGhhdCBpcw0KPiA+PiA+ICJpbnRlcmVzdGluZyINCj4gPj4NCj4gPj4gRU8jICBZ b3UgbWF5IHJlY2FsbCBmcm9tIChCZXJsaW4/ICBPcmxhbmRvPykgdGhhdCBJIGhhZCBhIG11Y2gg bG9uZ2VyDQo+ID4+IHNlY3Rpb24gd2hpY2ggd3Jlc3RsZWQgd2l0aCB0aGlzLiAgSSB0b29rIGl0 IG91dCBhbmQgc3dlcHQgdGhlIHdob2xlDQo+ID4+IHRoaW5nIHVuZGVyIHRoZSBydWcgdW5kZXIg ZGlyZWN0IGFkdmljZSBvZiBhbiBBRCBhdCB0aGUgbWljLiA6KQ0KPiA+Pg0KPiA+PiA+IGFuZCBt YWtlcyBtZSBhc3N1bWUgdGhhdCB0aGUgdXNlIG9mIEVBRyB5b3UgaGF2ZSBpbiBtaW5kDQo+ID4+ ID4gYXBwbGllcyBvbmx5IGF0IHRoZSBwb2ludCBvZiBleHBsaWNpdCBwYXRoIHNlbGVjdGlvbiAo aS5lLiBubyBsb29zZQ0KPiA+PiA+IGhvcCBzZWxlY3Rpb24pLg0KPiA+PiA+DQo+ID4+DQo+ID4+ IEVPIyAgWWVzLCB0aGF0J3MgdGhlIHByb2JsZW0gSSdtIHRyeWluZyB0byBzb2x2ZS4gIEkgZG9u J3Qgc2VlIG11Y2gNCj4gPj4gcmVsZXZhbnQgdG8gUENFIChpZiB0aGUgUENFIGlzIGdvaW5nIHRv IGhhbmQgZG93biBhbiBleHBsaWNpdCBwYXRoDQo+ID4+IHRoZW4gd2h5IGRvZXMgaXQgbmVlZCB0 byBpbmNsdWRlIGFueSBBRy9FQUcgaW5mb3JtYXRpb24gYXQgYWxsPykgYW5kDQo+ID4+IHdoaWxl IEkgZG9uJ3Qgd2FudCB0byBjb21wbGV0ZWx5IHJ1bGUgaXQgb3V0IGl0IHNlZW1zIGxpa2UgbW9y ZSB0aGFuDQo+ID4+IG5lZWRzIHRvIGJlIHNvbHZlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+Pg0K PiA+Pg0KPiA+PiA+IEkgdGhpbmsgdGhhdCwgaW4gb3JkZXIgdG8ganVzdGlmeSB0aGlzIHdvcmsg YmVpbmcgbGltaXRlZCB0byB0aGUgSUdQcw0KPiA+PiA+IHlvdSBuZWVkIHRvIGJlIGEgYml0IG1v cmUgZXhwbGljaXQsIHVwIGZyb250LCB0aGF0ICp5b3VyKiB1c2UgY2FzZQ0KPiA+PiA+IGNvbmNl cm5zIHByZS1jb21wdXRhdGlvbiBvZiBwYXRocy4NCj4gPj4NCj4gPj4gRU8jICB3ZWxsLCBuby4u Lm5vdCBwcmUtY29tcHV0YXRpb24uICBIZWFkZW5kIGNvbXB1dGF0aW9uLg0KPiA+PiBQcmUtY29t cHV0YXRpb24gKGF0IGxlYXN0IHRoZSB3YXkgSSB1bmRlcnN0YW5kIGl0KSBtZWFucw0KPiA+PiBv ZmZsaW5lK2NvbmZpZyBwdXNoIG9yIHNvbWV0aGluZyBQQ0UtaXNoIGxpa2UgdGhhdC4NCj4gPj4N Cj4gPj4gPg0KPiA+PiA+IE5vdywgdGhlcmUgYXJlIHR3byBwbGFjZXMgd2hlcmUgcGF0aCBzZWxl Y3Rpb24gd2lsbCBiZSBkb25lOg0KPiA+PiA+IDEuIFRoZSBoZWFkLWVuZCBMU1INCj4gPj4gPiAy LiBBIFBDRQ0KPiA+PiA+DQo+ID4+ID4gU28sIHlvdSBzaG91bGQgcGljayBvbmUgb3IgYm90aCBv ZiB0aGVzZSBhcyB5b3VyIHVzZSBjYXNlIGFuZCBzdGF0ZSBpdA0KPiA+PiA+IGNsZWFybHkuIElm IHlvdSBpbmNsdWRlIFBDRSwgeW91IHdpbGwgbmVlZCB0byBsb29rIGF0IHRoZSBhcHBsaWNhYmls aXR5DQo+ID4+ID4gdG8gUENFUCAoc2VlIFNlY3Rpb24gNy4xMSBvZiBSRkMgNTQ0MCkuDQo+ID4+ DQo+ID4+IEVPIyAgSWYgSSdtIHNpZGVzdGVwcGluZyBSU1ZQIEkgbWlnaHQgYXMgd2VsbCBzaWRl c3RlcCBQQ0VQIHRvby4gIEl0DQo+ID4+IGlzbid0IG5lY2Vzc2FyeSBmb3IgdGhlIHVzZSBjYXNl IEVBRyB3YXMgZGV2ZWxvcGVkIGZvciwgYW5kIEknbSBub3QNCj4gPj4gc3VyZSBJIHNlZSBpdCBi ZWluZyBhbGwgdGhhdCBiaWcgb2YgYW4gaXNzdWUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIuLi4ucmZj NTQ0MCBzZWN0aW9uIDcuMTEgcHJvdmlkZXMgYW4gTFNQQSB3aGljaCBpcyBhIGNvcHkgb2YNCj4g Pj4gdGhlIFNFU1NJT05fQVRUUklCVVRFIG9mIEMtVHlwZSAxICh0aGF0IGlzLCB0aGUgb25lIHdp dGggdGhlIHRocmVlDQo+ID4+IGxpbmsgYXR0cmlidXRlIHRlc3RzKS4gIEkgZGlkIG5vdCBzZWUg YW55dGhpbmcgaW4gNTQ0MCB3aGljaCBwcm92aWRlZA0KPiA+PiBhIGNvcHkgb2YgU0VTU0lPTl9B VFRSSUJVVEUgb2YgQy1UeXBlIDcgKHdpdGggc2V0dXAvaG9sZGluZyBwcmlvIGJ1dA0KPiA+PiBu byBhdHRyaWJ1dGUgdGVzdHMpLg0KPiA+Pg0KPiA+PiBUaGlzIG1lYW5zIHRoYXQsIGFzIGZhciBh cyBJIGNhbiB0ZWxsLCBpdCdzIG5vdCBwb3NzaWJsZSB0byBlbXVsYXRlDQo+ID4+IEMtVHlwZSA3 IGluIFBDRVAuICBUaGlzIGlzIHJlYWxseSBxdWl0ZSBmYXIgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhlDQo+ID4+IEVBRyBkb2N1bWVudCwgYnV0IHN3ZWVwaW5nIGl0IHVuZGVyIHRoZSBydWcgZ2V0 cyB1Z2x5Lg0KPiA+Pg0KPiA+PiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4gPj4NCj4gPj4g LSByZXRpdGxlIHNlY3Rpb24gdG8gIlNpZ25hbGluZyBFeHRlbmRlZCBBZG1pbmlzdHJhdGl2ZSBH cm91cHMgaW4gUlNWUA0KPiA+PiAgYW5kIFBDRVAiDQo+ID4+IC0gbWFraW5nIHRoZSBlbnRpcmV0 eSBvZiBzZWN0aW9uIDMgaW50bzoNCj4gPj4NCj4gPj4gLS0tLQ0KPiA+PiAzLiAgU2lnbmFsaW5n IEV4dGVuZGVkIEFkbWluaXN0cmF0aXZlIEdyb3VwcyBpbiBSU1ZQIGFuZCBQQ0VQDQo+ID4+DQo+ ID4+ICAgIFJTVlAgcHJvdmlkZXMgdGhlIGFiaWxpdHkgdG8gc2lnbmFsIGxpbmsgYWZmaW5pdHkg dmlhIHRoZQ0KPiA+PiAgICBTRVNTSU9OX0FUVFJJQlVURSBvYmplY3Qgd2l0aCBDLVR5cGUgMSBp biBSRkMgMzIwOSBbUkZDMzIwOV0uDQo+ID4+ICAgIFNpZ25hbGluZyBFQUcgaW4gUlNWUCBpcyBu b3QgYWRkcmVzc2VkIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzDQo+ID4+ICAgIGRvY3VtZW50IGRv ZXMgbm90IHByZWNsdWRlIGFkZHJlc3NpbmcgdGhpcyBpbiB0aGUgZnV0dXJlIHNob3VsZCBpdCBi ZQ0KPiA+PiAgICBkZWVtZWQgbmVjZXNzYXJ5Lk5vdGUgdGhhdCBzaWduYWxpbmcgRUFHIGlzIFJT VlAgaXMgbGlrZWx5IHRvIGJlDQo+ID4+ICAgIG5lY2Vzc2FyeSB0byBleHBhbmQgdGhlIHVzZSBv ZiBFQUcgb3V0c2lkZSBhIHNpbmdsZSBhcmVhL2xldmVsLCBqdXN0DQo+ID4+ICAgIGFzIGl0IGlz IHdpdGggQUcuDQo+ID4+DQo+ID4+ICAgIFRoZSBQQ0UgQ29tbXVuaWNhdGlvbiBQcm90b2NvbCwg b3IgUENFUCAoIFtSRkM1NDQwXSkgc3BlY2lmaWVzIGFuDQo+ID4+ICAgIExTUEEgb2JqZWN0IHdo aWNoIGlzIGVzc2VudGlhbGx5IGEgY29weSBvZiBSRkMzMjA5J3MNCj4gPj4gICAgU0VTU0lPTl9B VFRSSUJVVEUgd2l0aCBDLVR5cGUgMS4gIEl0IGRvZXMgbm90IHByb3ZpZGUgYSBjb3B5IG9mIHRo ZQ0KPiA+PiAgICBTRVNTSU9OX0FUVFJJQlVURSB3aXRoIEMtVHlwZSA3LiAgVGh1cywgdGhlIG9u bHkgd2F5IHRvIGluZGljYXRlDQo+ID4+ICAgIHNldHVwL2hvbGRpbmcgcHJpb3JpdHkgaW4gUENF UCBpcyB0byBhbHNvIHNpZ25hbCAzMi1iaXQgQUcgdmFsdWVzIGZvcg0KPiA+PiAgICBFeGNsdWRl LWFueSwgSW5jbHVkZS1hbnkgYW5kIEluY2x1ZGUtYWxsLg0KPiA+Pg0KPiA+PiAgICBJZiBhIG5v ZGUgd2hpY2ggaW1wbGVtZW50cyBib3RoIEVBRyBhbmQgUENFUCB3aXNoZXMgdG8gc2lnbmFsIHNl dHVwDQo+ID4+ICAgIGFuZCBob2xkaW5nIHByaW9yaXRpZXMgaW4gUENFUCdzIExTUEEsIGl0IGhh cyBubyBjaG9pY2UgYnV0IHRvIHVzZQ0KPiA+PiAgICB0aGUgTFNQQSB3aXRoIGFmZmluaXR5IGNv bnN0cmFpbnRzLiAgQSBub2RlIHdoaWNoIHNlbmRzIGFuIExTUEEgaW4NCj4gPj4gICAgUENFUCBN VVNUIHBvcHVsYXRlIHRoZSBhZmZpbml0eSBjb25zdHJhaW50IGZpZWxkcyAoRXhjbHVkZS1hbnks DQo+ID4+ICAgIEluY2x1ZGUtYW55LCBJbmNsdWRlLWFsbCkgd2l0aCB0aGUgbG93ZXIgMzIgYml0 cyBvZiB0aGUgcmVsZXZhbnQgRUFHLg0KPiA+Pg0KPiA+PiAgICBUaGlzIGRvY3VtZW50IGRvZXMg bm90IHByZWNsdWRlIGFkZHJlc3NpbmcgdGhpcyBpbiB0aGUgZnV0dXJlIHNob3VsZA0KPiA+PiAg ICBpdCBiZSBkZWVtZWQgbmVjZXNzYXJ5LiAgT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIHN0 YW5kYXJkaXplIGENCj4gPj4gICAgUENFUCBvYmplY3Qgd2hpY2ggaXMgYSBtaXJyb3Igb2YgdGhl IFNFU1NJT05fQVRUUklCVVRFIG9mIEMtVHlwZSA3Lg0KPiA+PiAgICBBbm90aGVyIGlzIHRvIHN0 YW5kYXJkaXplIGEgUENFUCBvYmplY3Qgd2hpY2ggZGlyZWN0bHkgY29udGFpbnMNCj4gPj4gICAg c3VwcG9ydCBmb3IgRUFHLiAgVGhlcmUgbWF5IGJlIG90aGVyIGFwcHJvYWNoZXMuICBBbnkgYW5k IGFsbCBzdWNoDQo+ID4+ICAgIGFwcHJvYWNoZXMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQNCj4gPj4NCj4gPj4gLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+PiBJJ20gbm90IHN1 cmUgSSBsaWtlIGl0IGFsbCB0aGF0IG11Y2ggYnV0IEkgY2FuJ3QgdGhpbmsgb2YgYSBiZXR0ZXIN Cj4gPj4gYXBwcm9hY2ggdGhhdCBkb2Vzbid0IGludm9sdmUgd3Jlc3RsaW5nIHdpdGggdGhlIHdo b2xlIHNpZ25hbGluZw0KPiA+PiBxdWVzdGlvbiBhZ2Fpbi4NCj4gPj4NCj4gPj4NCj4gPj4gPg0K PiA+PiA+IC0tLQ0KPiA+PiA+DQo+ID4+ID4gU2VjdGlvbiA1IGNvdWxkIGJlIG1hZGUgY2xlYXJl ciBieSBicmVha2luZyB0aGUgdGV4dCBvdXQgaW50byBzZXBhcmF0ZQ0KPiA+PiA+IHBhcmFncmFw aHMgb3IgZXZlbiBzZXBhcmF0ZSBzZWN0aW9ucy4gSXQgd291bGQgYWxzbyBiZSBoZWxwZnVsIHRv IElBTkENCj4gPj4gPiBpZiB5b3UgbWFkZSBsaXR0bGUgdGFibGVzIHNob3dpbmcgdGhlIGV4YWN0 IGluZm9ybWF0aW9uIHlvdSB3YW50DQo+ID4+ID4gcmVjb3JkZWQgaW4gZWFjaCByZWdpc3RyeS4N Cj4gPj4gPg0KPiA+Pg0KPiA+PiBFTyMNCj4gPj4gSSBwdXQgaW4gc29tZSBwYXJhZ3JhcGggYnJl YWtzIGFuZCBjbGVhbmVkIHRoZSB0ZXh0IHVwIGEgYml0Li4gIElmDQo+ID4+IHRob3NlIGFyZW4n dCBjbGVhciBlbm91Z2ggaXQncyBlYXN5IGVub3VnaCB0byB3b3JrIHdpdGggSUFOQSB3aGVuIHRo ZXkNCj4gPj4gZ2V0IGFyb3VuZCB0byBhbGxvY2F0aW5nIHRoZSBjb2RlcG9pbnQuDQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+IGVyaWMNCg== From nobody Fri Apr 18 10:56:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1DE1A0436 for ; Fri, 18 Apr 2014 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GixnTqWDNVJB for ; Fri, 18 Apr 2014 10:56:50 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 29B751A01BA for ; Fri, 18 Apr 2014 10:56:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3IHuWHm017848; Fri, 18 Apr 2014 18:56:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3IHuUx3017827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Apr 2014 18:56:31 +0100 From: "Adrian Farrel" To: "'Vero Zheng'" , "'Loa Andersson'" , References: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk> <534FB734.2020005@pi.nu> <03d801cf5a3e$4327fcc0$c977f640$@olddog.co.uk> <2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98@SZXEMA504-MBS.china.huawei.com> In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C80DE98@SZXEMA504-MBS.china.huawei.com> Date: Fri, 18 Apr 2014 18:56:30 +0100 Message-ID: <011701cf5b2f$877f2140$967d63c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01CF5B37.E9484430" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGwZu0InfoAc9cYjGAjs7sJWmJQfAHiEHL1AZxSIA8BUhszLZsvDNZQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20642.001 X-TM-AS-Result: No--37.478-10.0-31-10 X-imss-scan-details: No--37.478-10.0-31-10 X-TMASE-MatchedRID: CxmI61mtwh8KPlX4RDjq9Ft3XMydUaMXPxXiWH/cMXV3ZigbiYdosM8S ryzNCMVkhj6UQWbcFk7NbplgZ1YjZhWlpVw7TFQD4mYxmYubDHksCc2iFTIxrYKwF4K/wIz9yfC /+jAZD/JuuBQngKeoeKBXTDoMoZzLIIlDSExaEO+epOo7UqIl+U8ikszWUoVbsQufffqzSCKKRr QproVO65b8jLEV4yJnX+aNg4M0RyYR9y8WJPyXEOmc4/pDEQa2Ud7Bjfo+5jSZ1ke1DYhC7Eioj obt/WhvLBcwU+WmxDXJjJ4A9NsFloEdzT5hCcIK2MZGQuKc8UifU25efFpZMXLLhex0FFibrW41 +BBqq++rbW0Tb3XDoYwjf8at/mYVE2ZRbV2rc3GKBcawShLWviTzSFehhfJrWabPstVV86mLuXp vETnA6Cfohe8nyaIcfAHrISqOiW8KvI7z3l+uPXQIOMndeKgEGGXRndNt79WBTeBKqBRm8lSVtD 3HNHesCMa7O+PhLk7OHyiFumtKQfZsmkESQMsrTQh9A4m9EtH2v20RxLDyN4XzOtjIe3TaTgpzW PQpDCVHeOf0KsmWu/XYR5PPzmsuK4gIv0V7SZlVXhlmZsTdjNqgUkBwIfKYkzE2kM4b6HqxgpAs VRsHu2zjy8+skGB4liXG6TWiBAD7OgBbxHXmXxzwnpmtY/+rZG3SCLP7QtJ0PA/ki2kI7EtU4/p Kr/obDsbtrO33TVeLFgnz+hpr+TJ/MD+wSl/DjtK7dC6UBnkUqWKocoJo6esoDDE6CvPdp4Wcmy qBbFxC3bjvSDu959+suYAg9ZWJMxvA4OPLCf6eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7DfnlbwkEsa0VnRXm1iHN1Yj80Za3RRg8JLEoGJVQKnzaQc/31R5a+rgUEb56OhRq/y7BQzR jhFMlYKAKNRg9q0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XeByOvjSBSgSC-KyTzzPVxvs-CA Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 18 Apr 2014 17:56:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0118_01CF5B37.E9484430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Vero, you're very right. Sorry about that: let's blame my old age, shall we? Anyway, the main point is that 6952 exposes the issue, but does not scope the risk. This I-D plugs the hole, but doesn't say when or why you might need the feature. A From: Vero Zheng [mailto:vero.zheng@huawei.com] Sent: 18 April 2014 04:08 To: adrian@olddog.co.uk; 'Loa Andersson'; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth > RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note that the discussion of LDP Hellos didn't make it into this document until -01 in May2011). Adrian, That is not correct. The discussion of LDP Hellos was in the document from the very beginning. The hello spoofing was discussed in both the discussion on current state/optimal state of the protocols in -00. Obviously, the document authors careJ Cheers, Vero > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, April 17, 2014 9:09 PM > To: 'Loa Andersson'; draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth > > Hello, > > I don't think that is the history at all! > This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October > 2010. > Before that the issue with the Hello was discussed and batted around for a > while. > There is a risk with the Hello and it needs a solution. > No issue with that, and I support this draft. > > RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was > adopted by KARP in June 2011. That derives from > draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note that > the discussion of LDP Hellos didn't make it into this document until -01 in May > 2011). > > But who cares? > > RFC 6952 does not describe the attacks or their mitigations. It just notes that > spoofing a Hello can have some bad effects. > > As a deployer, I need help to explain when I need to insist on having this feature > implemented by my supplier (BTW, it looks like none of the suppliers is > implementing it) and when I need to enable it. It seems to me that this feature > is needed to protect against attacks (which 6952 claims have been seen in the > wild), but that those attacks only arise in specific situations. > > Since the security mechanisms defined in this document are pretty > heavy-weight (compare with simple text passwords so loved for IGP security :-) > it would be great to get some help on this topic. Are all networks always > exposed (if so it looks like a must-have feature)? Are the risks only significant > for targeted LDP? Is the network safe if it applies access controls at the edges > and assumes no subversion of routers? Does applying an access list at the LDP > speakers provide protection against everything except address spoofing? > > Cheers, > Adrian > > > -----Original Message----- > > From: Loa Andersson [ mailto:loa@pi.nu] > > Sent: 17 April 2014 12:13 > > To: adrian@olddog.co.uk; > draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth > > > > Adrian, > > > > Given my limited understanding of the security mechanisms, I > > nevertheless have one question I need to ask. > > > > You say: > > > > On 2014-04-13 20:10, Adrian Farrel wrote: > > > It would help if the document was a > > > little clearer about which attacks it is defending against and why > > > normal protection at the edge of the network is not considered > > > enough for the > former, > > > and why a bad actor within the network would waste its time > > > attacking LDP > > when > > > there is so much else it can do! > > > > My understanding is that this document was written as a response to > > the risk analysis in RFC 6952. If I remember correctly you had a > > number of questions, but also said that you had no objections after > > having these question answered. > > > > Since RFC 6952 says we have a security hole that we need to close, you > > said that you approve of that, we tried to fill the hole; how should I > > understand the comment above? Do you just want another reference to > > RFC 6952? > > > > /Loa > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_0118_01CF5B37.E9484430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vero, = you're very right. Sorry about that: let's blame my old age, shall = we?

 

Anyway, the main point is that 6952 exposes the = issue, but does not scope the risk.

This = I-D plugs the hole, but doesn't say when or why you might need the = feature.

 

A

 

From: Vero Zheng = [mailto:vero.zheng@huawei.com]
Sent: 18 April 2014 = 04:08
To: adrian@olddog.co.uk; 'Loa Andersson'; = draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org
Cc: = mpls@ietf.org
Subject: RE: [mpls] AD review of = draft-ietf-mpls-ldp-hello-crypto-auth

 

> RFC = 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was = adopted by KARP in June 2011. That derives from = draft-mahesh-bgp-ldp-msdp-analysis first posted in February = 2011

(note that = the discussion of LDP Hellos didn't make it into this document until -01 = in May2011).

 <= /o:p>

Adrian,=

That is not = correct. The discussion of LDP Hellos was in the document from the very = beginning. The hello spoofing was discussed in both the discussion on = current state/optimal state of the protocols in = -00.

Obviously, = the document authors careJ<= /span>

 <= /o:p>

Cheers, = Vero

 <= /o:p>

> = -----Original Message-----

> From: = mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian = Farrel

> Sent: = Thursday, April 17, 2014 9:09 PM

> To: = 'Loa Andersson'; = draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org

> Cc: = mpls@ietf.org

> = Subject: Re: [mpls] AD review of = draft-ietf-mpls-ldp-hello-crypto-auth

> =

> = Hello,

> =

> I = don't think that is the history at all!

> This = document started as draft-zheng-mpls-ldp-hello-crypto-auth in = October

> = 2010.

> Before = that the issue with the Hello was discussed and batted around for = a

> = while.

> There = is a risk with the Hello and it needs a = solution.

> No = issue with that, and I support this draft.

> =

> RFC = 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that = was

> = adopted by KARP in June 2011. That derives from

> = draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note = that

> the = discussion of LDP Hellos didn't make it into this document until -01 in = May

> = 2011).

> =

> But = who cares?

> =

> RFC = 6952 does not describe the attacks or their mitigations. It just notes = that

> = spoofing a Hello can have some bad effects.

> =

> As a = deployer, I need help to explain when I need to insist on having this = feature

> = implemented by my supplier (BTW, it looks like none of the suppliers = is

> = implementing it) and when I need to enable it. It seems to me that this = feature

> is = needed to protect against attacks (which 6952 claims have been seen in = the

> wild), = but that those attacks only arise in specific = situations.

> =

> Since = the security mechanisms defined in this document are = pretty

> = heavy-weight (compare with simple text passwords so loved for IGP = security :-)

> it = would be great to get some help on this topic. Are all networks = always

> = exposed (if so it looks like a must-have feature)? Are the risks only = significant

> for = targeted LDP? Is the network safe if it applies access controls at the = edges

> and = assumes no subversion of routers? Does applying an access list at the = LDP

> = speakers provide protection against everything except address = spoofing?

> =

> = Cheers,

> = Adrian

> =

> > = -----Original Message-----

> > = From: Loa Andersson [mailt= o:loa@pi.nu]

> > = Sent: 17 April 2014 12:13

> > = To: adria= n@olddog.co.uk;

> = draft= -ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org=

> > = Cc: mpls@= ietf.org

> > = Subject: Re: AD review of = draft-ietf-mpls-ldp-hello-crypto-auth

> = >

> > = Adrian,

> = >

> > = Given my limited understanding of the security mechanisms, = I

> > = nevertheless have one question I need to ask.

> = >

> > = You say:

> = >

> > = On 2014-04-13 20:10, Adrian Farrel wrote:

> > = > It would help if the document was a

> > = > little clearer about which attacks it is defending against and = why

> > = > normal protection at the edge of the network is not = considered

> > = > enough for the

> = former,

> > = > and why a bad actor within the network would waste its = time

> > = > attacking LDP

> > = when

> > = > there is so much else it can do!

> = >

> > = My understanding is that this document was written as a response = to

> > = the risk analysis in RFC 6952. If I remember correctly you had = a

> > = number of questions, but also said that you had no objections = after

> > = having these question answered.

> = >

> > = Since RFC 6952 says we have a security hole that we need to close, = you

> > = said that you approve of that, we tried to fill the hole; how should = I

> > = understand the comment above? Do you just want another reference = to

> > = RFC 6952?

> = >

> > = /Loa

> =

> = _______________________________________________

> mpls = mailing list

> mpls@= ietf.org

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

------=_NextPart_000_0118_01CF5B37.E9484430-- From nobody Mon Apr 21 11:18:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B780E1A0234 for ; Mon, 21 Apr 2014 11:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR2IIgKewubb for ; Mon, 21 Apr 2014 11:18:08 -0700 (PDT) Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37CB71A01FA for ; Mon, 21 Apr 2014 11:18:08 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so3810602yho.18 for ; Mon, 21 Apr 2014 11:18:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5wm00hz6AxV9cTqXgFzdgevGNvf5C9KN4by/63pWzgE=; b=L+zrxm1+qLLkiQe1qfS60jIFaevnVtIfmuBv4RQrx4fNiDKRRYMD0u/+Y8vLRWQIPE zWevuTo3PTY9wMIjZn1m4u0LpewQCpipy0eWuZpj3Lmnj4Rjc/BOHr0XdWraiu+/WOx7 xNoAFVRBehG/eMJr/ShzOFYSW2q5zMbveGciCJoFEfrRdeYULz/4+oPTefPTw5vv2TX0 0MKFnwn5VpfU9CJBkbOG11ezHbOieQ6KYnFjjHp3CknMOaaf9TyMOrxygpHNv1uzq3uY zh5lOjDGj6Uc33zezaBcgV9X8WKUr+UpVWvVuXEZ0xjfSyPpSfmZ8jsUvyc2+IhkBj1F eL+w== X-Gm-Message-State: ALoCoQlGRna7Xrxpyixpx4HGCluOhJHYpBN2GkWlJvY7255N7CC80PdFP8IEuLy9UKsdVoAlQr+H MIME-Version: 1.0 X-Received: by 10.236.20.194 with SMTP id p42mr54552279yhp.56.1398104283010; Mon, 21 Apr 2014 11:18:03 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Mon, 21 Apr 2014 11:18:02 -0700 (PDT) In-Reply-To: References: <03c401cf4df2$d627ca30$82775e90$@olddog.co.uk> Date: Mon, 21 Apr 2014 14:18:02 -0400 Message-ID: From: Eric Osborne To: "Les Ginsberg (ginsberg)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4tBKAzciNOcAcCLdDG22sub_KV4 Cc: "draft-ietf-mpls-extended-admin-group.all@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-extended-admin-group X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:18:12 -0000 Hi Les- There is no clean way to do any of this. With any approach we have to deal with the face that AG and EAG are rather intertwined, yet both are optional. You say: "if EAG were simply an addition/extension of AG I don=E2=80=99t se= e that this requires AG to be advertised when EAG is advertised." but what happens if I advertise only EAG (bits 31+) and a node wants bit 17 to be set to 1? We have to find some way to handle this - either a recommended default, a mandatory default, or an error condition. It's just about as ugly whether we go with the additive approach (AG 0-31, EAG 32+) or the superset approach that the draft is taking (AG 0-31, EAG 0-31+). I can't find a terribly persuasive argument either way. I like the one the draft is taking because it means that I have complete link attribute information in one place - it feels cleaner, and yes, it allows me to deprecate AG. 'feels clean' is a squishy and subjective thing at best, and deprecating AG is a side effect rather than a design goal, but there's no more compelling reason. eric On Fri, Apr 18, 2014 at 10:06 AM, Les Ginsberg (ginsberg) wrote: > Eric - > > Thanx for the reply and explanation. > > At the risk of beating a dead horse, if EAG were simply an addition/exten= sion of AG I don=E2=80=99t see that this requires AG to be advertised when = EAG is advertised. Having read Section 2.3.2 I see that this is an issue yo= u are concerned with - you somewhat reluctantly suggest unadvertised bits c= an be assumed to be 0 - but doesn't this issue get exacerbated with EAG? Wh= at I mean by that is that if some routers need to advertise 128 bits you se= em to be implying that it would be better if all routers advertised 128 bit= s even if they have no local links which require bits 33 - 128. But operati= onally this means that as soon as one router is configured to advertise 128= bits all routers SHOULD be advertised to advertise 128 bits - which seems = unnecessarily onerous - as well as bloating the IGP LSDB. > > I defer to your expertise - I only dabble in this space from the IGP pers= pective - so I am fine with whatever you decide - including the current def= inition - but now you have "all my thoughts" on the subject. > > Les > > >> -----Original Message----- >> From: Eric Osborne [mailto:eric@notcom.com] >> Sent: Thursday, April 17, 2014 5:55 AM >> To: Les Ginsberg (ginsberg) >> Cc: Adrian Farrel; draft-ietf-mpls-extended-admin-group.all@tools.ietf.o= rg; >> mpls@ietf.org; mpls-chairs@tools.ietf.org >> Subject: Re: AD review of draft-ietf-mpls-extended-admin-group >> >> Hi Les- >> >> Thanks for the review, glad those changes worked for you. >> As far as the conflict, we went back and forth and this during initial >> development. There are probably good arguments on both sides, and as >> long as a device is compliant none of this should matter. The reason >> we did what we did is that AG is widespread but optional, and if we >> define EAG to start at bit 32 we then have to define what you do if a >> node advertises EAG and not AG, and another node has desire for bits >> in the AG space. It gets just as ugly, if not uglier; we'd have to say >> something like "if there is EAG and no AG, assume AG =3D=3D 0x0", and th= is >> creates two problems: >> 1) some implementations have default assumptions in the case of >> missing AG, and they may not all be 0x0 >> 2) it mandates that 'undefined' =3D=3D 0x0, which makes me feel all w= eird. >> >> It *is* true that by defining EAG to start at bit 0 rather than bit 32 >> we can someday replace AG, but that's not the motivation. The >> motivation is simply to not _require_ AG in the face of EAG when AG by >> itself is optional. >> >> Tarek, please chime in if I missed anything. >> >> >> >> eric >> >> >> >> On Wed, Apr 16, 2014 at 11:45 AM, Les Ginsberg (ginsberg) >> wrote: >> > Eric - >> > >> > The revised text in Section 2.3.1 addresses my concern - thanx. >> > >> > But I had also asked why the potential conflict between AG and EAG cou= ld >> not be avoided altogether by defining EAG as representing the groups bey= ond >> the first 32 defined by AG. Could you respond to that? >> > >> > If the argument is that you would like someday to deprecate the use of= AG I >> have to say that I don=E2=80=99t find that very compelling. >> > >> > Les >> > >> > >> >> -----Original Message----- >> >> From: Eric Osborne [mailto:eric@notcom.com] >> >> Sent: Wednesday, April 16, 2014 8:01 AM >> >> To: Adrian Farrel >> >> Cc: draft-ietf-mpls-extended-admin-group.all@tools.ietf.org; >> mpls@ietf.org; >> >> mpls-chairs@tools.ietf.org; Les Ginsberg (ginsberg) >> >> Subject: Re: AD review of draft-ietf-mpls-extended-admin-group >> >> >> >> HI Adrian- >> >> >> >> I'm ccing Les as well; he had some comments around section 2.3.1 (a= s >> >> did everyone else, and rightly so). >> >> Inline with EO#. Since the thread is rather large and it's easy to >> >> lose the changes, I have attached the candidate-05 draft to this >> >> email. It can be compared to draft-04, which is the latest posted >> >> version. >> >> >> >> Summary: most of the changes are no big deal, but I'm wrestling with >> >> how to exclude PCE cleanly. >> >> >> >> On Tue, Apr 1, 2014 at 5:39 PM, Adrian Farrel w= rote: >> >> > Hello, >> >> > >> >> > I have done my usual AD review of your document upon receiving the >> >> > publication request. The purpose is to catch any issues that might >> >> > otherwise show up during IETF last call or IESG review and to get t= he >> >> > document into good shape so that those later reviews have a clearer >> >> > run. >> >> > >> >> > There are a few comments below that I would like you to look at. Th= e >> >> > I-D is very short and simple, so there is not much to comment on, b= ut >> >> > I have a few concerns, clarifications, and editorial points that I >> >> > hope you will look at. You are, of course, welcome to dispute any o= f >> >> > these points and discuss them with me on the WG mailing list. >> >> > >> >> > While you are working on this I will put the document into "Revised >> >> > I-D Needed" state and I will ask the WG chairs to send a notice abo= ut >> >> > this I-D to the OSPF, ISIS, and CCAMP mailing lists so that they ar= e >> >> > aware of the draft and can comment immediately or during IETF last = call >> >> > if they have any concerns. >> >> > >> >> > Thanks for the work, >> >> > Adrian >> >> > >> >> > =3D=3D=3D >> >> > >> >> > This document adds a sub-TLV. I think it is your intention that thi= s is >> >> > a sub-TLV of the Link TLV and not of the Administrative Group sub-T= LV, >> >> > itself. That seems pretty important, so it needs to be stated clear= ly. >> >> > >> >> >> >> EO# Fixed. >> >> >> >> Old: >> >> --- >> >> >> >> 2. Extended Administrative Groups sub-TLV >> >> >> >> The Extended Administrative Groups sub-TLV is used... >> >> --- >> >> >> >> >> >> New: >> >> ---- >> >> 2. Extended Administrative Groups sub-TLV >> >> >> >> This document defines a sub-TLV of the Link TLV for both OSPF >> >> [RFC3630] and ISIS [RFC5305] called the Extended Administrative >> >> Groups (EAG) sub-TLV. The EAG sub-TLV is used... >> >> ---- >> >> >> >> OK? >> >> >> >> > --- >> >> > >> >> > The use case in para 2 of Section 1 is, of course, predicated on us= ing >> >> > a single IGP domain (area/level) to cover the whole network that is >> >> > being discussed. That is OK, but the text should note this caveat = lest >> >> > people think that admin colours are somehow globally unique. >> >> > >> >> >> >> EO# I agree that the use case you cite is probably a single-level >> >> case. But that doesn't mean EAG must be constrained to only a single >> >> level. An implementation that signals AG in RSVP can use it across >> >> multiple areas (that's really the point of signaling AG at all). I >> >> don't want to preclude that happening with EAG should someone decide >> >> to implement signaling of EAG in RSVP. >> >> >> >> To address your comment I have added a sentence to section 3. In its >> >> entirety: >> >> >> >> --- OLD ---- >> >> 3. Signaling Extended Administrative Groups in RSVP >> >> >> >> RSVP provides the ability to signal link affinity via the >> >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> >> Signaling EAG in RSVP is not addressed in this document. This >> >> document does not preclude addressing this in the future should it= be >> >> deemed necessary >> >> ---- >> >> >> >> ---- NEW ---- >> >> 3. Signaling Extended Administrative Groups in RSVP >> >> >> >> RSVP provides the ability to signal link affinity via the >> >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> >> Signaling EAG in RSVP is not addressed in this document. This >> >> document does not preclude addressing this in the future should it= be >> >> deemed necessary. >> >> >> >> Note that signaling EAG is RSVP is likely to be necessary to expan= d >> >> the use of EAG outside a single area/level, just as it is with AG >> >> --- >> >> >> >> but please see my comments later in this mail about PCEP. >> >> >> >> > --- >> >> > >> >> > Section 2.1 >> >> > >> >> > The EAG may >> >> > be of any length, but MUST be a multiple of 4 bytes. >> >> > >> >> > Is a zero-length TLV allowed? >> >> > >> >> >> >> EO# I'm not sure what it would actually *do*. Making clear that a >> >> TLV must actually contain some information in order to be useful is >> >> probably more necessary than I'd like to think. I live in a country >> >> where we have to say "this plastic bag is not a toy, do not give to >> >> infants" just in case someone thought otherwise...it is for those >> >> people that I propose the following text: >> >> >> >> --- OLD --- >> >> >> >> The EAG may >> >> be of any length, but MUST be a multiple of 4 bytes. >> >> ---- >> >> >> >> >> >> --- NEW ---- >> >> >> >> The EAG may be of any non-zero length, but MUST be a multiple of 4 by= tes >> >> ----- >> >> >> >> OK? >> >> >> >> >> >> >> >> > --- >> >> > >> >> > 2.3.1 >> >> > >> >> >> >> EO# This section is rather confusing...multiple reviewers caught it. >> >> The current text in its entirety is: >> >> >> >> ---- OLD ---- >> >> 2.3.1. AG and EAG coexistence >> >> >> >> If a node advertises EAG it MAY also advertise AG. >> >> >> >> If a node advertises both AG and EAG then the first 32 bits of the >> >> EAG MUST be identical to the advertised AG. If a receiving node >> >> notices that the AG differs from the first 32 bits of the EAG, it >> >> SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> >> indicate this mismatch to the operator. >> >> >> >> If the AG and EAG advertised for a link differ, the EAG MUST take >> >> priority. This allows nodes which do not support EAG to obtain so= me >> >> link color information from the network, but also allow for an >> >> eventual migration away from AG. >> >> ---- >> >> >> >> and it was worded that way after a discussion on the list with Andy >> >> Malis and Tarek Saad. >> >> The intent is straightforward: in the event of a mismatch, prefer AG. >> >> >> >> > If a receiving node >> >> > notices that the AG differs from the first 32 bits of the EAG, i= t >> >> > SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> >> > indicate this mismatch to the operator. >> >> > >> >> > If the AG and EAG advertised for a link differ, the EAG MUST tak= e >> >> > priority. >> >> > >> >> > Aren't these two statements contradictory? >> >> > I suspect the final "EAG" is supposed to read "AG" to be consistent >> >> > with the first paragraph and also to match the first motivation giv= en >> >> > immediately after. >> >> >> >> EO# Sort of. There are a few options here in the event of a mismatc= h: >> >> >> >> 1) use only AG >> >> 2) overwrite the first 32 bits of EAG with AG, then use the entire EA= G. >> >> 3) use only EAG >> >> >> >> >> >> In the discussion with Andy and Tarek we came to agreement on #2. >> >> That's what the text in section 2.3.1 needs to say. >> >> >> >> I therefore propose the following for the entirety of section 2.3.1: >> >> >> >> ---- NEW ---- >> >> >> >> If a node advertises EAG it MAY also advertise AG. >> >> >> >> If a node advertises both AG and EAG then the first 32 bits of the >> >> EAG MUST be identical to the advertised AG. If a receiving node >> >> notices that the AG differs from the first 32 bits of the EAG, it >> >> SHOULD use the AG as the first 32 bits of the EAG, and SHOULD >> >> indicate this mismatch to the operator. This allows nodes which d= o >> >> not support EAG to obtain some >> >> link color information from the network, but also allow for an >> >> eventual migration away from AG. >> >> --- >> >> >> >> all this does is drop the sentence "If the AG and EAG advertised for = a >> >> link differ, the EAG MUST take >> >> priority." as that clearly contradicted everything else in that >> section. >> >> >> >> >> >> > >> >> > This allows nodes which do not support EAG to obtain some >> >> > link color information from the network, but also allow for an >> >> > eventual migration away from AG. >> >> > >> >> > OTOH... >> >> > >> >> > 1. The second motivation seems to support EAG taking priority. >> >> > >> >> > 2. The first motivation seems to miss some really big issues concer= ning >> >> > non-support of EAG. You need to discuss this processing in relat= ion >> >> > to signaling... >> >> > >> >> > Suppose a link is advertised with EAG and a node that does not >> >> > support EAG signals an LSP? >> >> >> >> EO# I don't think this applies, since there is no support for >> >> signaled EAG. It's purely for headend calculation. >> >> >> >> > >> >> > Suppose one end of a link supports EAG but the other does not an= d >> >> > a signaling message includes EAG and the upstream end of the lin= k >> >> > ignores it? >> >> > >> >> >> >> EO# The same is true of one end signaling AG and the other not >> >> signaling anything; despite its widespread advertisement, AG is >> >> optional. >> >> >> >> I never thought there was any requirement for a TE link to have >> >> identical properties in both directions. Neither rfc3630 nor rfc5305 >> >> concern themselves with bidirectionality in any of the TE TLVs, nor >> >> does rfc5307. The implementations I'm familiar with perform a basic >> >> two-way connectivity check, but that's it. >> >> >> >> I would prefer to stay away from prescribing behavior here that is >> >> more restrictive than what's specified in the base documents. >> >> >> >> > I think you have some edge conditions to describe in section 2.3 >> >> > >> >> >> >> EO# No such conditions are discussed in any other RFC which specifie= s >> >> TE link properties, and we seem to have gotten along just fine. If >> >> you feel strongly about this then we can sort something out, but I'm >> >> reluctant to make the EAG document the place where all sorts of >> >> assumptions about CSPF get spelled out. >> >> >> >> > --- >> >> > >> >> > I read section 4.7.4 of RFC 3209 to compare it with what you say in >> >> > section 2.3.2 of this document. >> >> > >> >> > I read it to say: >> >> > - a link can only be excluded if it advertises a specific color >> >> > - a link can only be included if it advertises a specific color >> >> > Thus, failure to include AG means a link cannot be excluded accordi= ng >> >> > to an exclusion requirement. But it also means that it cannot be >> >> > included according to an include or include-any requirement. >> >> >> >> >> >> EO# Right. It's a hole in 3209; that section assumes AG is always >> >> advertised. In my experience this is generally true in practice, and >> >> the implementations I know best have some default they assume if AG i= s >> >> not advertised. >> >> >> >> .... >> >> >> >> > I think this is functionally equivalent to RFC 3209. >> >> > That is, a link cannot be excluded on the basis of an unadvertised >> >> > affinity because it is assumed to be 0. >> >> > And a link cannot be included on the basis of an unadvertised affin= ity >> >> > because it is assumed to be 0. >> >> > >> >> > So it all ends up right in the end, but it took a lot of words! >> >> >> >> EO# Yeah...I wanted to make clear what 4.7.4 meant without adding >> >> some backdoor requirements to it. >> >> >> >> > >> >> > --- >> >> > >> >> > In Section 2.3.2 you have an "interesting" mix of advice and 2119 w= ords. >> >> > >> >> >> >> .... >> >> >> >> Yes. >> >> Yes I did. >> >> >> >> I think s/MUST/SHOULD/ for the first MUST in 2.3.2, as well as some >> >> tweaking, fixes it. I propose: >> >> >> >> >> >> --- OLD---- >> >> >> >> Each implementation is free to choose its own method for handling >> >> this question. However, to allow for maximum interoperability an >> >> implementation MUST treat desired but unadvertised EAG bits as if >> >> they are set to 0. Consider the case where a node wants to only u= se >> >> links where the 127th bit of an EAG is set to 1. If a link is onl= y >> >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined = - >> >> that is, it is neither explicitly 0 nor 1. The node which wants t= he >> >> 127th EAG bit to be 1 MUST NOT use this link, as the assumption is >> >> than an unadvertised bit is set to 0. >> >> ---- >> >> >> >> >> >> --- NEW --- >> >> >> >> Each implementation is free to choose its own method for handling >> >> this question. However, to allow for maximum interoperability an >> >> implementation SHOULD treat desired but unadvertised EAG bits as i= f >> >> they are set to 0. Consider the case where a node wants to only u= se >> >> links where the 127th bit of an EAG is set to 1. If a link is onl= y >> >> advertising 64 EAG bits, clearly the 127th EAG bit is not defined = - >> >> that is, it is neither explicitly 0 nor 1. The node which wants t= he >> >> 127th EAG bit to be 1 MUST NOT use this link when implementing the >> >> recommended behavior, as the assumption is >> >> than an unadvertised bit is set to 0. >> >> --- >> >> >> >> >> >> ... >> >> >> >> > But, one final question... >> >> > Why do you want to allow other modes of operation? >> >> > What is the benefit, and why didn't you call it out? >> >> >> >> >> >> EO# As with other uses of SHOULD (e.g., section 2.3.1) there is >> >> already at least one implementation out there and while it hews in >> >> large part to the document as written, I did not want to inadvertentl= y >> >> deprecate it. >> >> >> >> > >> >> > --- >> >> > >> >> > Section 3 deliberately sidesteps the use of EAG in signaling. That = is >> >> > "interesting" >> >> >> >> EO# You may recall from (Berlin? Orlando?) that I had a much longer >> >> section which wrestled with this. I took it out and swept the whole >> >> thing under the rug under direct advice of an AD at the mic. :) >> >> >> >> > and makes me assume that the use of EAG you have in mind >> >> > applies only at the point of explicit path selection (i.e. no loose >> >> > hop selection). >> >> > >> >> >> >> EO# Yes, that's the problem I'm trying to solve. I don't see much >> >> relevant to PCE (if the PCE is going to hand down an explicit path >> >> then why does it need to include any AG/EAG information at all?) and >> >> while I don't want to completely rule it out it seems like more than >> >> needs to be solved in this document. >> >> >> >> >> >> > I think that, in order to justify this work being limited to the IG= Ps >> >> > you need to be a bit more explicit, up front, that *your* use case >> >> > concerns pre-computation of paths. >> >> >> >> EO# well, no...not pre-computation. Headend computation. >> >> Pre-computation (at least the way I understand it) means >> >> offline+config push or something PCE-ish like that. >> >> >> >> > >> >> > Now, there are two places where path selection will be done: >> >> > 1. The head-end LSR >> >> > 2. A PCE >> >> > >> >> > So, you should pick one or both of these as your use case and state= it >> >> > clearly. If you include PCE, you will need to look at the applicabi= lity >> >> > to PCEP (see Section 7.11 of RFC 5440). >> >> >> >> EO# If I'm sidestepping RSVP I might as well sidestep PCEP too. It >> >> isn't necessary for the use case EAG was developed for, and I'm not >> >> sure I see it being all that big of an issue. >> >> >> >> However....rfc5440 section 7.11 provides an LSPA which is a copy of >> >> the SESSION_ATTRIBUTE of C-Type 1 (that is, the one with the three >> >> link attribute tests). I did not see anything in 5440 which provided >> >> a copy of SESSION_ATTRIBUTE of C-Type 7 (with setup/holding prio but >> >> no attribute tests). >> >> >> >> This means that, as far as I can tell, it's not possible to emulate >> >> C-Type 7 in PCEP. This is really quite far outside the scope of the >> >> EAG document, but sweeping it under the rug gets ugly. >> >> >> >> I propose the following: >> >> >> >> - retitle section to "Signaling Extended Administrative Groups in RSV= P >> >> and PCEP" >> >> - making the entirety of section 3 into: >> >> >> >> ---- >> >> 3. Signaling Extended Administrative Groups in RSVP and PCEP >> >> >> >> RSVP provides the ability to signal link affinity via the >> >> SESSION_ATTRIBUTE object with C-Type 1 in RFC 3209 [RFC3209]. >> >> Signaling EAG in RSVP is not addressed in this document. This >> >> document does not preclude addressing this in the future should it= be >> >> deemed necessary.Note that signaling EAG is RSVP is likely to be >> >> necessary to expand the use of EAG outside a single area/level, ju= st >> >> as it is with AG. >> >> >> >> The PCE Communication Protocol, or PCEP ( [RFC5440]) specifies an >> >> LSPA object which is essentially a copy of RFC3209's >> >> SESSION_ATTRIBUTE with C-Type 1. It does not provide a copy of th= e >> >> SESSION_ATTRIBUTE with C-Type 7. Thus, the only way to indicate >> >> setup/holding priority in PCEP is to also signal 32-bit AG values = for >> >> Exclude-any, Include-any and Include-all. >> >> >> >> If a node which implements both EAG and PCEP wishes to signal setu= p >> >> and holding priorities in PCEP's LSPA, it has no choice but to use >> >> the LSPA with affinity constraints. A node which sends an LSPA in >> >> PCEP MUST populate the affinity constraint fields (Exclude-any, >> >> Include-any, Include-all) with the lower 32 bits of the relevant E= AG. >> >> >> >> This document does not preclude addressing this in the future shou= ld >> >> it be deemed necessary. One possible approach is to standardize a >> >> PCEP object which is a mirror of the SESSION_ATTRIBUTE of C-Type 7= . >> >> Another is to standardize a PCEP object which directly contains >> >> support for EAG. There may be other approaches. Any and all such >> >> approaches are outside the scope of this document >> >> >> >> ---------- >> >> >> >> I'm not sure I like it all that much but I can't think of a better >> >> approach that doesn't involve wrestling with the whole signaling >> >> question again. >> >> >> >> >> >> > >> >> > --- >> >> > >> >> > Section 5 could be made clearer by breaking the text out into separ= ate >> >> > paragraphs or even separate sections. It would also be helpful to I= ANA >> >> > if you made little tables showing the exact information you want >> >> > recorded in each registry. >> >> > >> >> >> >> EO# >> >> I put in some paragraph breaks and cleaned the text up a bit.. If >> >> those aren't clear enough it's easy enough to work with IANA when the= y >> >> get around to allocating the codepoint. >> >> >> >> >> >> >> >> eric From nobody Mon Apr 21 11:43:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872DC1A0234 for ; Mon, 21 Apr 2014 11:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al7SfaswQCgW for ; Mon, 21 Apr 2014 11:43:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 103491A022D for ; Mon, 21 Apr 2014 11:43:06 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 21 Apr 2014 18:42:59 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0918.000; Mon, 21 Apr 2014 18:42:59 +0000 From: Ross Callon To: "adrian@olddog.co.uk" , "draft-ietf-mpls-in-udp.all@tools.ietf.org" Thread-Topic: Progressing draft-ietf-mpls-in-udp Thread-Index: Ac858KPw42tL5KdwQcOnayoNmTHpwgjoKvhg Date: Mon, 21 Apr 2014 18:42:59 +0000 Message-ID: <653e22ad5ac949aca5304bd75d8a5600@CO2PR05MB636.namprd05.prod.outlook.com> References: <0f5c01cf39f0$afa53d90$0eefb8b0$@olddog.co.uk> In-Reply-To: <0f5c01cf39f0$afa53d90$0eefb8b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(13464003)(377454003)(189002)(199002)(76482001)(33646001)(80976001)(4396001)(31966008)(81342001)(74316001)(19580405001)(87936001)(83322001)(19580395003)(2656002)(83072002)(85852003)(74662001)(74502001)(46102001)(92566001)(79102001)(76576001)(66066001)(80022001)(99396002)(20776003)(86362001)(76176999)(77982001)(99286001)(54356999)(77096999)(81542001)(50986999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:9EDA7234.AFF2BFC2.71E3530B.4AE8C9BC.202C9; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Rg0NPgiEPbfF0IVkpD1G38nW0MY Cc: "mpls@ietf.org" , "tsvwg-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" Subject: Re: [mpls] Progressing draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:43:09 -0000 Adrian; Have you had a chance to come up with appropriate text to complete the work= on this document? The "week after the IETF" is long past.=20 Thanks, Ross -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, March 07, 2014 5:33 AM To: draft-ietf-mpls-in-udp.all@tools.ietf.org Cc: mpls@ietf.org; 'Alia Atlas'; tsv-ads@tools.ietf.org; tsvwg-chairs@tools= .ietf.org Subject: Progressing draft-ietf-mpls-in-udp Hi, Sorry that I have been sitting on this I-D since IETF last call completed, = but it has proven to be a valuable wait. During this IETF meeting I have met with the TSV ADs and discussed this I-D= , the GRE-in-UDP draft and the broader congestion and checksum issues. The TSV Area and TSVWG have also discussed the topics in some detail. I believe that I now know exactly what additions/changes are necessary. The= se are not necessary to get this past the TSV fanatics and ADs. These *are* necessary to make the document and the protocol valuable and stable. My next action will be to work up some text for inclusion in each of the I-= Ds (I am AD for this document and co-author on the GRE document). I suspect this = will be about a page in each case and will overlap with some text already presen= t (we can handle the editorial process separately). Obviously we will need to review and discuss the new text before we move forward. I am hoping that I can do this within about a week, but the time immediatel= y after an IETF meeting does tend to get filled up with the most extraordinar= y demands on my time (like sleeping). Thanks to the authors for their patience with this work. Adrian From nobody Mon Apr 21 12:17:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28901A0283; Mon, 21 Apr 2014 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9-xgBq9bFet; Mon, 21 Apr 2014 12:17:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2781A0263; Mon, 21 Apr 2014 12:17:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421191720.16157.49856.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 12:17:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Smy8NCrp0PkB0iXU85gw9TVKwu0 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-extended-admin-group-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-ietf-mpls-extended-admin-group-05.txt Pages : 7 Date : 2014-04-21 Abstract: MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-extended-admin-group-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-extended-admin-group-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 21 13:20:51 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647D51A02AA; Mon, 21 Apr 2014 13:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqiHJqzXUreU; Mon, 21 Apr 2014 13:20:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB01A0281; Mon, 21 Apr 2014 13:20:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421202045.8776.58735.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 13:20:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/T0f6PDkdSy6uDSGO2VJo-HAg2aM Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-psc-updates-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:20:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to MPLS Transport Profile Linear Protection Author : Eric Osborne Filename : draft-ietf-mpls-psc-updates-04.txt Pages : 10 Date : 2014-04-21 Abstract: This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaision statement, and clarify The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-psc-updates-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-psc-updates-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 21 13:21:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109691A0281 for ; Mon, 21 Apr 2014 13:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca2xZyFN7Bq7 for ; Mon, 21 Apr 2014 13:20:55 -0700 (PDT) Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by ietfa.amsl.com (Postfix) with ESMTP id CA7321A02AD for ; Mon, 21 Apr 2014 13:20:53 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id b6so3929539yha.5 for ; Mon, 21 Apr 2014 13:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=VOTEPQjZiFiaj+A92QM5sKYZ9gLyayNdY9aPm5OXlv4=; b=MCiUDIY+DNqRJTUFVEQR6UlHPRb4C5cDe2G0gGs5wyOEnFVDVSto6ta1jpgePTI6ud UCIoBtN3Ouu727A0wg3Z3s4cs6xFstWIHeRqjcTY89/qXQNvFvd7YL9E7OGVKVXk/9S3 GaYbO0h1PZszrftK+Jb2YvtzEgVK4XMGMGmiNNDBBewyaD6u3dG6PpnJOQy3CqFxo+0g XOx1CJpmwEXu8PFX/dDu28vTPsewA9OvEvEfa5Jm+Jx7NHERhVScbPaLziu1s+WK25mk 1AGPPP9z0EHo6Yig5IP2cydF1/hoOvM/prmgmmJjOGPfO4SK5bj3qPsepvDQkQO6CPy9 d1og== X-Gm-Message-State: ALoCoQmCrbEB+jeyGq+kbSqYjE0uKA3VSREYUJPhH9H+UPsZYHbzuU38lhsogRSyEsIQVEmXzYX2 MIME-Version: 1.0 X-Received: by 10.236.102.70 with SMTP id c46mr56255379yhg.40.1398111648525; Mon, 21 Apr 2014 13:20:48 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Mon, 21 Apr 2014 13:20:48 -0700 (PDT) Date: Mon, 21 Apr 2014 16:20:48 -0400 Message-ID: From: Eric Osborne To: General Area Review Team , draft-ietf-mpls-psc-updates.all@tools.ietf.org, "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MqYhzB1gAcwVyTqkMw3I3VomIFc Subject: [mpls] Addressing comments on draft-ietf-mpls-psc-updates-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:21:00 -0000 Folks- I have posted draft-ietf-mpls-psc-updates-04. It addresses the gen-art comments as well as other feeback received on this list from the v-03 last call. I also shuffled things around so that the section order made more sense. This draft elicited a comment and a warning from idnits. I believe they are both OK to disregard: 1) -- The draft header indicates that this document updates RFC6378, but the abstract doesn't seem to directly say this. It does mention RFC6378 though, so this could be OK. It's pretty clear that the document updates rfc6378. 2) == Missing Reference: 'RFC-ietf-mpls-psc-updates-04' is mentioned on line 412, but not defined This is a self-reference which needs to be updated with the RFC number for this draft. I expect this to be good to go, but given the amount of reshuffling and new text I'd like to give folks one more shot at tweaking the language. The meat of the work is in section 2.2. Adrian, Elwyn - this contains the majority of the changes based on gen-art feedback and other discussions on the list. Please give this the once-over at your convenience. eric From nobody Tue Apr 22 05:32:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2AF1A0401; Tue, 22 Apr 2014 05:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM24uQ6mhVBx; Tue, 22 Apr 2014 05:31:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C611A0409; Tue, 22 Apr 2014 05:31:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422123157.23383.24017.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 05:31:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hB0uowz9nLib84zulZSHFFD4Sjc Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:32:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Reoptimization of Point-to-Multipoint Traffic Engineering Loosely Routed LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt Pages : 10 Date : 2014-04-22 Abstract: This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions for reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs) in an Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-tsaad-mpls-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-tsaad-mpls-p2mp-loose-path-reopt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-tsaad-mpls-p2mp-loose-path-reopt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 22 05:49:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA11A0401 for ; Tue, 22 Apr 2014 05:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx5QakWaDuZz for ; Tue, 22 Apr 2014 05:49:38 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF521A03EC for ; Tue, 22 Apr 2014 05:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2014; q=dns/txt; s=iport; t=1398170973; x=1399380573; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HTAKOVxfDqTKzQCuIUpTT1T+MW9MdWDb/QMJt52Rwls=; b=AgXQjc1B0dgpNCm4WmIZMOe0NcJCMk0mDBDYKukCghMISp8JENq2Kr2c b0J9HE7ETjlqHKidjHze9Cbna+4QrQp83kCgK+PGBm8iOCH1Y05kwKmrM 3ONnwn39oMd7f2zo74J750JCIBv9oGe9OUFcSZPCYaFylpRJZt4AinZMl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0cAAdlVlOtJV2d/2dsb2JhbABZgWwCAYEXT1EGvFuHO4EXFnSCJwEEAQEBNzQLEgEINjcLJQIEDgUJiDgIBcw8F44jMweEOASYcIE3kRuDMYIr X-IronPort-AV: E=Sophos;i="4.97,904,1389744000"; d="scan'208";a="37738906" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 22 Apr 2014 12:49:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3MCnWRl020597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 12:49:32 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.162]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 07:49:32 -0500 From: "Rakesh Gandhi (rgandhi)" To: "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] I-D Action: draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt Thread-Index: AQHPXibhkvcnBBw7ekW6gbSRsHpqQZsdpw0A Date: Tue, 22 Apr 2014 12:49:19 +0000 Message-ID: In-Reply-To: <20140422123157.23383.24017.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.247.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <039E213603517E4C8DF763EE29ED34A0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OZ6yaSTs7blyoVewu92NFXWtfE4 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:49:42 -0000 Hi MPLS WG, This version contains editorial changes and updated "Security Considerations" section. Thank you in advance for your review comments. Regards, Rakesh On 2014-04-22 8:31 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Multiprotocol Label Switching Working >Group of the IETF. > > Title : Reoptimization of Point-to-Multipoint Traffic >Engineering Loosely Routed LSPs > Authors : Tarek Saad > Rakesh Gandhi > Zafar Ali > Robert H. Venator > Yuji Kamite > Filename : draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt > Pages : 10 > Date : 2014-04-22 > >Abstract: > This document defines Resource Reservation Protocol - Traffic > Engineering (RSVP-TE) signaling extensions for reoptimizing loosely > routed Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label > Switched Paths (LSPs) in an Multi-Protocol Label Switching (MPLS) > and/or Generalized MPLS (GMPLS) networks. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-tsaad-mpls-p2mp-loose-path-reopt/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-tsaad-mpls-p2mp-loose-path-reopt-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-tsaad-mpls-p2mp-loose-path-reopt-= 02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 22 05:55:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9007A1A0410; Tue, 22 Apr 2014 05:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh567GOBky0Z; Tue, 22 Apr 2014 05:55:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0980D1A041B; Tue, 22 Apr 2014 05:55:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422125508.11941.69395.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 05:55:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ABy-y4zBtTyjK652pr8qnO4a70I Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-psc-updates-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:55:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to MPLS Transport Profile Linear Protection Author : Eric Osborne Filename : draft-ietf-mpls-psc-updates-05.txt Pages : 10 Date : 2014-04-22 Abstract: This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC6378. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-psc-updates-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-psc-updates-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 22 06:00:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5A1A042A; Tue, 22 Apr 2014 06:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80l_V-RorabP; Tue, 22 Apr 2014 06:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CB21A03EF; Tue, 22 Apr 2014 06:00:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140422130029.19992.10085.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 06:00:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xIaVlMBPLeOm_1LZ5jn5QGI3p6Y Cc: mpls@ietf.org Subject: [mpls] Last Call: (Extended Administrative Groups in MPLS-TE) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 13:00:31 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Extended Administrative Groups in MPLS-TE' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 22 08:42:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AE01A0682; Tue, 22 Apr 2014 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9df5IJXvxz2P; Tue, 22 Apr 2014 08:40:29 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id DB7E31A068B; Tue, 22 Apr 2014 08:40:18 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wccnh-0005W1-PC; Tue, 22 Apr 2014 16:40:01 +0100 From: Elwyn Davies To: Eric Osborne In-Reply-To: References: Content-Type: text/plain Date: Tue, 22 Apr 2014 16:39:59 +0100 Message-Id: <1398181199.15324.27769.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1ZsZAZGMzMhVzYFp-brTC6rRUJg X-Mailman-Approved-At: Tue, 22 Apr 2014 08:42:51 -0700 Cc: "mpls@ietf.org" , General Area Review Team , draft-ietf-mpls-psc-updates.all@tools.ietf.org Subject: Re: [mpls] [Gen-art] Addressing comments on draft-ietf-mpls-psc-updates-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 15:40:35 -0000 Hi, Eric. I checked over the new version and it addresses my previous comments just fine. Thanks. One trivial nit: s2.3.2: s/processesed/processed/ I noted Adrian's point about draft-ietf-mpls-tp-psc-itu in the tracker and I guess the suggested change is reasonable. If you are updating the text you could also fix: - The style is supposed to be 'RFC 6378' rather than RFC6378 outside of reference anchors. - Sort out the punctuations of 'i.e.,' : Currently there is one with no comma (5, para 1), two with one comma and one with two commas (s6, para 10 - the quote from RFC 6378 where it has one comma); and of 'e.g.,' : Currently one with no comma (s4.3, para 2). I'll send an official telechat review when the review is scheduled. Cheers, Elwyn On Mon, 2014-04-21 at 16:20 -0400, Eric Osborne wrote: > Folks- > > I have posted draft-ietf-mpls-psc-updates-04. It addresses the > gen-art comments as well as other feeback received on this list from > the v-03 last call. I also shuffled things around so that the section > order made more sense. > > This draft elicited a comment and a warning from idnits. I believe > they are both OK to disregard: > > 1) > > -- The draft header indicates that this document updates RFC6378, but the > abstract doesn't seem to directly say this. It does mention RFC6378 > though, so this could be OK. > > > It's pretty clear that the document updates rfc6378. > > > 2) > > == Missing Reference: 'RFC-ietf-mpls-psc-updates-04' is mentioned on line > 412, but not defined > > > This is a self-reference which needs to be updated with the RFC number > for this draft. > > > > I expect this to be good to go, but given the amount of reshuffling > and new text I'd like to give folks one more shot at tweaking the > language. > > The meat of the work is in section 2.2. Adrian, Elwyn - this contains > the majority of the changes based on gen-art feedback and other > discussions on the list. Please give this the once-over at your > convenience. > > > > > eric > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Apr 23 00:01:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81051A0330 for ; Wed, 23 Apr 2014 00:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REZURLKjreX8 for ; Wed, 23 Apr 2014 00:01:19 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2EA1A032E for ; Wed, 23 Apr 2014 00:01:19 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id as1so538578iec.17 for ; Wed, 23 Apr 2014 00:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hyzB8T9KqwsHQOQrJg41dB1wr28Qp+hNvxOAkaQjKTs=; b=eq50YySeJ7hoBZkqd0V6gMfHeelImqLgILPS7c52RrtdVWCXcos8ccZEjl09SDbkDq BHgEjJUrqAfPJ37EUlV7bXSKsMlRwLCi28hLql4dPmn60tyKD4nqoQzn9h1sNO2h01E3 eYDb8xJPaXw4Jmiv3Zki3aEsnaiLI7p1VfY4X7kJrtIDrLzAK4ul3b0lNMPhHoSQtQYg fVhjTDSf8KhDeK8z+9m0eZxgxtTjkl3rmGbh3g9ACt29PRP9ShuQxtxk8/uYkbHuJxyc cauqv4k23Ht+wn48e02ctIVACfSvNeZfGhbrbRg10Mw2HIOrS9+yMlgr9aVicTqL1EGN hyIQ== MIME-Version: 1.0 X-Received: by 10.50.61.142 with SMTP id p14mr616568igr.12.1398236473481; Wed, 23 Apr 2014 00:01:13 -0700 (PDT) Received: by 10.64.226.66 with HTTP; Wed, 23 Apr 2014 00:01:13 -0700 (PDT) In-Reply-To: <534F8B25.80802@pi.nu> References: <534F8B25.80802@pi.nu> Date: Wed, 23 Apr 2014 15:01:13 +0800 Message-ID: From: Ryan Zheng To: "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/e_VKPL_6uoiK91UHTRdWtspfDZQ Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 07:01:25 -0000 Hi, As a contributor, I'm not aware of any other IPRs other than those already disclosed. Thanks, Ryan 2014-04-17 16:04 GMT+08:00 Loa Andersson : > Working Group, > > The authors of draft-ietf-mpls-lsp-ping-relay-reply has informed us > that the draft is ready for working groups last call. > > Before starting the working group last call we want to run an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ietf-mpls-lsp-ping-relay-reply? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are two IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 23 12:27:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2788D1A052E; Wed, 23 Apr 2014 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjo4O9ErRnNY; Wed, 23 Apr 2014 12:26:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF391A049A; Wed, 23 Apr 2014 12:26:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423192651.18597.24053.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 12:26:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Da4Nm1isz4ZeoEDYY_JLY-zz4OA Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-12.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 19:26:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Extensions for Multi Topology Authors : Quintin Zhao Kamran Raza Chao Zhou Luyuan Fang Lianyuan Li Daniel King Filename : draft-ietf-mpls-ldp-multi-topology-12.txt Pages : 19 Date : 2014-04-23 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 23 15:03:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDB81A06DC; Wed, 23 Apr 2014 15:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk5lBpsYjTSU; Wed, 23 Apr 2014 15:02:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB491A06E4; Wed, 23 Apr 2014 15:02:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423220256.4101.1319.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 15:02:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FD8UcjrMwzjmeZsdFJ2f-iDpWLM Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'LDP Extensions for Multi Topology' to Proposed Standard (draft-ietf-mpls-ldp-multi-topology-12.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:03:00 -0000 The IESG has approved the following document: - 'LDP Extensions for Multi Topology' (draft-ietf-mpls-ldp-multi-topology-12.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ Technical Summary Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. Working Group Summary There is a strong support for this document in the working group and it has been has been well reviewed. After IESG last call there were a number of questions and issues that resulted in a significant revision to the document. The document was returned to the WG for an additional last call that showed support for the current revision of the document. Document Quality We know of implementations and intended implementations, further a poll has been sent to the working group mailing list requesting information. ¨ This poll has just resulted in that we know of two more implementations in progress. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the responsible AD. RFC Editor Note Section 1 para 1 OLD support Multiple Topologies (MT) within MPLS environments (MPLS-MT). NEW support an MPLS Multi-Topology (MPLS-MT) environment. END Section 3.7 s/"Reserved"/"Unassigned"/ From nobody Thu Apr 24 05:35:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7B31A01B3 for ; Thu, 24 Apr 2014 05:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUu4c1Cw5g1D for ; Thu, 24 Apr 2014 05:35:08 -0700 (PDT) Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by ietfa.amsl.com (Postfix) with ESMTP id C16CC1A01CD for ; Thu, 24 Apr 2014 05:35:06 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id i57so2137994yha.28 for ; Thu, 24 Apr 2014 05:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d235aReLnZQOGjuPSqjq5TqGV8Y9WjLnNSl0GKtjh7A=; b=S9LwPMRceTsEUonugzcmiqmnK5NdsJhUkvVHxfUaq3CmizipYxrdIh+LpY+iOPrjpa 0QakIjpM2Lu5gLr/i9QPTAm1M4IMDOIQYmS2NZBr1BlqsvFRNms4sXCIaRDbV24GZY8G xU43dES2eJBef8W3vSHwxgHkbfshff7MhdJ3+Iumg1C3OUrmRwQw1rxmFkXnm6ycT/5b SlFHnX07Jm8Tc2Z52G9rVUD4ZIj/ADR95lsOQVW5tW7zTbqa0Zmjbna9AfGYQLzkTbmN y8T5JCRsmLkrSyuodjmWEEtCAWWs10AaBSsnboFbRJQU8BBcqhXHOzWU6COT5lFzU31k WHOA== X-Gm-Message-State: ALoCoQkU+qP6jemj2TAD2Kii5tmAPWk/pSJOD7oZZ4Hfd+OSOvcTHFUB9FNOb+vFmjdketlGknUA MIME-Version: 1.0 X-Received: by 10.236.20.194 with SMTP id p42mr2078668yhp.56.1398342900447; Thu, 24 Apr 2014 05:35:00 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Thu, 24 Apr 2014 05:35:00 -0700 (PDT) In-Reply-To: <1398181199.15324.27769.camel@mightyatom> References: <1398181199.15324.27769.camel@mightyatom> Date: Thu, 24 Apr 2014 08:35:00 -0400 Message-ID: From: Eric Osborne To: Elwyn Davies Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/L7lBhynMZlIKVHZx76qKkwMm5lQ Cc: "mpls@ietf.org" , General Area Review Team , draft-ietf-mpls-psc-updates.all@tools.ietf.org Subject: Re: [mpls] [Gen-art] Addressing comments on draft-ietf-mpls-psc-updates-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:35:11 -0000 Hi Elwyn- Inline. On Tue, Apr 22, 2014 at 11:39 AM, Elwyn Davies wrote: > Hi, Eric. > > I checked over the new version and it addresses my previous comments > just fine. Thanks. > Cool! > One trivial nit: > s2.3.2: s/processesed/processed/ > OK. > I noted Adrian's point about draft-ietf-mpls-tp-psc-itu in the tracker > and I guess the suggested change is reasonable. > I agree. > If you are updating the text you could also fix: > - The style is supposed to be 'RFC 6378' rather than RFC6378 outside of > reference anchors. OK > - Sort out the punctuations of 'i.e.,' : Currently there is one with no > comma (5, para 1), two with one comma and one with two commas (s6, para > 10 - the quote from RFC 6378 where it has one comma); and of 'e.g.,' : > Currently one with no comma (s4.3, para 2). Sorry, I thought I caught all of those. > > I'll send an official telechat review when the review is scheduled. > OK. thanks! eric > Cheers, > Elwyn > > > > On Mon, 2014-04-21 at 16:20 -0400, Eric Osborne wrote: >> Folks- >> >> I have posted draft-ietf-mpls-psc-updates-04. It addresses the >> gen-art comments as well as other feeback received on this list from >> the v-03 last call. I also shuffled things around so that the section >> order made more sense. >> >> This draft elicited a comment and a warning from idnits. I believe >> they are both OK to disregard: >> >> 1) >> >> -- The draft header indicates that this document updates RFC6378, but the >> abstract doesn't seem to directly say this. It does mention RFC6378 >> though, so this could be OK. >> >> >> It's pretty clear that the document updates rfc6378. >> >> >> 2) >> >> == Missing Reference: 'RFC-ietf-mpls-psc-updates-04' is mentioned on line >> 412, but not defined >> >> >> This is a self-reference which needs to be updated with the RFC number >> for this draft. >> >> >> >> I expect this to be good to go, but given the amount of reshuffling >> and new text I'd like to give folks one more shot at tweaking the >> language. >> >> The meat of the work is in section 2.2. Adrian, Elwyn - this contains >> the majority of the changes based on gen-art feedback and other >> discussions on the list. Please give this the once-over at your >> convenience. >> >> >> >> >> eric >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > From nobody Thu Apr 24 14:55:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E4A1A0407; Thu, 24 Apr 2014 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STJv4lV94laG; Thu, 24 Apr 2014 14:55:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id F038D1A03FD; Thu, 24 Apr 2014 14:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 111A11C0A6C; Thu, 24 Apr 2014 14:55:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C7711C0518; Thu, 24 Apr 2014 14:55:37 -0700 (PDT) Message-ID: <53598854.2010201@joelhalpern.com> Date: Thu, 24 Apr 2014 17:55:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "A. Jean Mahoney" , gen-art@ietf.org, "mpls@ietf.org" References: <53597772.6000401@nostrum.com> In-Reply-To: <53597772.6000401@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BkCWG_nzGy_oqYIcGPe4ryOEgqQ Subject: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:55:45 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-extended-admin-group-05 Extended Administrative Groups in MPLS-TE Reviewer: Joel M. Halpern Review Date: 24-April-2014 IETF LC End Date: 06-May-2014 IESG Telechat date: N/A Summary: This document is ready for publication as a Proposed Standards RFC Major issues: N/A Minor issues: I believe that the description of when to use this EAG is slightly misleading. The text says that EAG is to be used "when a node wishes to advertise more than 32 colors for a link." I believe it is more accurate to say that it is to be used "when a node wishes to advertise colors for a link which are not represented in the first 32 bits of the color mask." The node may only wish to advertise colors 7 and 60, but that will require the EAG. Nits/editorial comments: N/A From nobody Thu Apr 24 15:16:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662FE1A03FE; Thu, 24 Apr 2014 15:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46YQKv9cbWik; Thu, 24 Apr 2014 15:16:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD05F1A03EF; Thu, 24 Apr 2014 15:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Loa Andersson , George Swallow , Ross Callon X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424221617.30038.52822.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 15:16:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uVpWWN6f44_GHnA55O622-TQFPU Cc: mpls@ietf.org, tom.huber@coriant.com, lihan@chinamobile.com Subject: [mpls] New Liaison Statement, "LS/r on progress of MPLS Protection State Coordination Work in the IETF (reply to IETF-MPLS-LS087)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:16:19 -0000 Title: LS/r on progress of MPLS Protection State Coordination Work in the IETF (reply to IETF-MPLS-LS087) Submission Date: 2014-04-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1321/ From: ITU-T SG 15 (Greg Jones ) To: Multiprotocol Label Switching (Loa Andersson , George Swallow , Ross Callon ) Cc: Adrian Farrel ,Alia Atlas ,mpls@ietf.org,John Drake ,Scott Mansfield Response Contact: tom.huber@coriant.com, lihan@chinamobile.com Technical Contact: Purpose: For information Body: Thank you for your liaison informing us of the progress of MPLS Protection State Coordination work in the IETF, in particular the approval of draft-ietf-mpls-tp-psc-itu. With the approval of draft-ietf-mpls-tp-psc-itu, we have been able to progress and have initiated the approval process for the revision of ITU-T G.8131 in this plenary meeting (Geneva, 24 March – 4 April 2014). We appreciate your cooperation on MPLS-TP standardization and hope it will continue for the benefit of the global industry. Attached: − Draft revised Recommendation ITU-T G.8131/Y.1382 (TD233/PLEN). Attachments: Draft revised Recommendation ITU-T G.8131/Y.1382 (for Consent, 4 April 2014) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-23-itu-t-sg-15-mpls-lsr-on-progress-of-mpls-protection-state-coordination-work-in-the-ietf-reply-to-ietf-mpls-ls087-attachment-1.pdf From nobody Thu Apr 24 15:21:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1861A0416; Thu, 24 Apr 2014 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8az1mmeV3Gc; Thu, 24 Apr 2014 15:21:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 420A41A0412; Thu, 24 Apr 2014 15:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: The IETF Chair X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424222128.1431.43278.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 15:21:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/I8d2guFGzTdkaIm4_uzE7vPCSD4 Cc: mpls@ietf.org, ccamp@ietf.org, pce@ietf.org, The IESG , ohara.takuya@lab.ntt.co.jp Subject: [mpls] New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:21:30 -0000 Title: LS on ITU-T SG15 OTNT standardization work plan Submission Date: 2014-04-24 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1322/ Please reply by 2014-11-07 From: ITU-T SG 15 (Greg Jones ) To: The IETF (The IETF Chair ) Cc: The IESG ,John Drake ,Scott Mansfield ,ccamp@ietf.org,pce@ietf.org,mpls@ietf.org Response Contact: ohara.takuya@lab.ntt.co.jp Technical Contact: Purpose: For action Body: Thank you for your previous review and comments for “Optical Transport Networks & Technologies Standardization Work Plan”. Attached is the updated version from this SG15 meeting (Geneva, 24 March – 4 April 2014). This version reflects recent development of related standards and your valuable input. We appreciate your review of this latest version and comments. Attach: − Draft revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 18 (TD231R2/PLEN). Attachments: Draft revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 18 https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-24-itu-t-sg-15-the-ietf-ls-on-itu-t-sg15-otnt-standardization-work-plan-attachment-1.pdf From nobody Fri Apr 25 07:07:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D10D1A0515 for ; Fri, 25 Apr 2014 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzPyXPENqmbR for ; Fri, 25 Apr 2014 07:07:03 -0700 (PDT) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id E33B31A04F1 for ; Fri, 25 Apr 2014 07:07:02 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id b6so780398yha.41 for ; Fri, 25 Apr 2014 07:06:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C6UuSJmF37b36gipDz5dbOmpcAsyfjFXoDSCAyuY34I=; b=WkOFhVotFJOeePQchzDK/0+iP0Ify7zz8NOsd9uAPdeeD8doqgPDdLDjezAJJat6ys 4JihR7lcbfVs+SSC/eCh5EpdFWmGI1tpQzA15ACF+BjWqvaMDFkeA4dDfQzkc/ai+nn+ A9gdeqmYlz7b9zoPM0GFZTlXxtLX0yadvQdu/WZ5SS7/VircfiUiqFx6RFAVUrE2XgCI WmTwZA34rVqAGNTqs20DNt0kO6wmVKdXgnM4Kmet5tOV1vZj4kiju941PXo2MMpqK8qw 18IX/asjzOrsUQKTtdSawLkTsU6D5zWfUJWls/qw6w6oJ/JdvNq+fN6vxWOyIG9GB5A3 3i3g== X-Gm-Message-State: ALoCoQmzAutk8JLpfEbFlYRMvIpt1JmQjNUqAWHWUuolXGozp4PA/pbCjvFnB79EQgzsmXC4BlAi MIME-Version: 1.0 X-Received: by 10.236.126.43 with SMTP id a31mr2649504yhi.154.1398434816205; Fri, 25 Apr 2014 07:06:56 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Fri, 25 Apr 2014 07:06:56 -0700 (PDT) In-Reply-To: <53598854.2010201@joelhalpern.com> References: <53597772.6000401@nostrum.com> <53598854.2010201@joelhalpern.com> Date: Fri, 25 Apr 2014 10:06:56 -0400 Message-ID: From: Eric Osborne To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6AdNvZ1fOOMAf6OLD_aK3xhjyY8 Cc: "mpls@ietf.org" , General Area Review Team , "A. Jean Mahoney" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:07:06 -0000 Hi Joel- Thanks for the review. On your minor issue: --- I believe it is more accurate to say that it is to be used "when a node wishes to advertise colors for a link which are not represented in the first 32 bits of the color mask." The node may only wish to advertise colors 7 and 60, but that will require the EAG. --- I see your point, but I'm having trouble coming up with obvious text. Deciding which colors are represented in a color mask is up to the operator, which means it would have to say something like "when a node wishes to advertise colors for a link which the operator has defined to be outside the first 32 bits of the color mask". but this would be the only use of 'color mask' in the document, and it's not one I've seen used in any other docs around link coloring. The whole sentence you refer to is: " The EAG sub-TLV is used in addition to the Administrative Groups when a node wishes to advertise more than 32 colors for a link." If I rephrased it as " The EAG sub-TLV is used in addition to the Administrative Groups when an operator wants to make more than 32 colors available for advertisement on a link" would that do it? s/wishes/wants/ while I'm here. eric On Thu, Apr 24, 2014 at 5:55 PM, Joel M. Halpern wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-mpls-extended-admin-group-05 > Extended Administrative Groups in MPLS-TE > Reviewer: Joel M. Halpern > Review Date: 24-April-2014 > IETF LC End Date: 06-May-2014 > IESG Telechat date: N/A > > Summary: This document is ready for publication as a Proposed Standards RFC > > Major issues: N/A > > Minor issues: > I believe that the description of when to use this EAG is slightly > misleading. The text says that EAG is to be used "when a node wishes to > advertise more than 32 colors for a link." I believe it is more accurate to > say that it is to be used "when a node wishes to advertise colors for a link > which are not represented in the first 32 bits of the color mask." The node > may only wish to advertise colors 7 and 60, but that will require the EAG. > > Nits/editorial comments: N/A > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 25 08:26:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C987F1A0535; Fri, 25 Apr 2014 08:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDn79NWAcuQV; Fri, 25 Apr 2014 08:02:41 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 891FD1A04F6; Fri, 25 Apr 2014 08:02:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3FE9C1C0865; Fri, 25 Apr 2014 08:02:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8CDD71C078F; Fri, 25 Apr 2014 08:02:34 -0700 (PDT) Message-ID: <535A7903.2070704@joelhalpern.com> Date: Fri, 25 Apr 2014 11:02:27 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Osborne References: <53597772.6000401@nostrum.com> <53598854.2010201@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aUMzoySPyJe0LkzW3cyX03Fxc_s X-Mailman-Approved-At: Fri, 25 Apr 2014 08:26:53 -0700 Cc: "mpls@ietf.org" , General Area Review Team Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:02:44 -0000 What if instead of "on the link" it is simoply "in the network". This recommend the use of EAG whenever the operators is using more than 32 colors across the link. It thus actually better aligns with avoiding the under-claiming issue by suggesting that operators should use the EAG if they have more than 32 candidate colors. Yours, Joel PS: substituting wants for wishes is probably reasonable. If we talk about network-wide you might even be able to us "intends". On 4/25/14, 10:06 AM, Eric Osborne wrote: > Hi Joel- > > Thanks for the review. On your minor issue: > --- > I believe it is more accurate to say that it is to be used "when a > node wishes to advertise colors for a link which are not represented > in the first 32 bits of the color mask." The node may only wish to > advertise colors 7 and 60, but that will require the EAG. > --- > > I see your point, but I'm having trouble coming up with obvious text. > Deciding which colors are represented in a color mask is up to the > operator, which means it would have to say something like > > "when a node wishes to advertise colors for a link which the operator > has defined to be outside the first 32 bits of the color mask". > > but this would be the only use of 'color mask' in the document, and > it's not one I've seen used in any other docs around link coloring. > > The whole sentence you refer to is: > > " The EAG sub-TLV is used in addition to the Administrative Groups > when a node wishes to advertise more than 32 colors for a link." > > If I rephrased it as > > " The EAG sub-TLV is used in addition to the Administrative Groups > when an operator wants to make more than 32 colors available for > advertisement on a link" > > would that do it? > s/wishes/wants/ while I'm here. > > > > eric > > > On Thu, Apr 24, 2014 at 5:55 PM, Joel M. Halpern wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-mpls-extended-admin-group-05 >> Extended Administrative Groups in MPLS-TE >> Reviewer: Joel M. Halpern >> Review Date: 24-April-2014 >> IETF LC End Date: 06-May-2014 >> IESG Telechat date: N/A >> >> Summary: This document is ready for publication as a Proposed Standards RFC >> >> Major issues: N/A >> >> Minor issues: >> I believe that the description of when to use this EAG is slightly >> misleading. The text says that EAG is to be used "when a node wishes to >> advertise more than 32 colors for a link." I believe it is more accurate to >> say that it is to be used "when a node wishes to advertise colors for a link >> which are not represented in the first 32 bits of the color mask." The node >> may only wish to advertise colors 7 and 60, but that will require the EAG. >> >> Nits/editorial comments: N/A >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 25 08:28:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EA71A0572 for ; Fri, 25 Apr 2014 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE8n2Rp3yVTC for ; Fri, 25 Apr 2014 08:28:30 -0700 (PDT) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by ietfa.amsl.com (Postfix) with ESMTP id F28101A0636 for ; Fri, 25 Apr 2014 08:28:28 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id v1so175057yhn.7 for ; Fri, 25 Apr 2014 08:28:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4/WSSr0/h/jO/uR3jN02snLwL6jRSw65AxfpYheld0Y=; b=k2F9RJ8rFbDSxwXJEivzrpRb6re+y/AghaqPWXsWscOwH0uLOBTEzrKLEsAJfAwghl SvOh+U0J+5mq9dIfOKSTCzhalSAU3q1tWqZxR/i5m2g1VqTz7dqc7b0fL/W15kwLMQ4Q e6yMu0abDSIGB/hv0IZIR8uADVXfP9ejmYfRTWIk6xcCXkMzb9P7qB5omEnnkVT9yboY 197EIK+EcJXJUzEcbLQml+6A/CBIBgiz+AbYidJYWx/Yi53fjO8N+zAHWW/KmG7S3ri8 ouVWKRKuZ5dWemPerYGEMqDuBaok7rV9FN51ufy25a8afqZLyjrVB4KGcqvDSUNLLMfM IySg== X-Gm-Message-State: ALoCoQkn49UQMazNpl7mebyDK2O/tFrQpGT8J0vYXveLsI0X98GI6eJzqnXHuWumKNEa2+5VvGfl MIME-Version: 1.0 X-Received: by 10.236.20.194 with SMTP id p42mr12617329yhp.56.1398439702388; Fri, 25 Apr 2014 08:28:22 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Fri, 25 Apr 2014 08:28:22 -0700 (PDT) In-Reply-To: <535A7903.2070704@joelhalpern.com> References: <53597772.6000401@nostrum.com> <53598854.2010201@joelhalpern.com> <535A7903.2070704@joelhalpern.com> Date: Fri, 25 Apr 2014 11:28:22 -0400 Message-ID: From: Eric Osborne To: Joel Halpern Direct Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/H9ONd2KR2iRJe_OiWmtJGXOR2Cs Cc: "mpls@ietf.org" , General Area Review Team Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:28:34 -0000 Works for me. So " The EAG sub-TLV is used in addition to the Administrative Groups when an operator wants to make more than 32 colors available for advertisement in a network" I had gone back and forth with Adrian on language to scope this to a single LSDB, so as to avoid the discussion of signaling EAG desire in RSVP or PCEP. I don't want to add that sort of disclaimer here too, as it makes the sentence clunky and unweildy. eric On Fri, Apr 25, 2014 at 11:02 AM, Joel Halpern Direct wrote: > What if instead of "on the link" it is simoply "in the network". This > recommend the use of EAG whenever the operators is using more than 32 colors > across the link. It thus actually better aligns with avoiding the > under-claiming issue by suggesting that operators should use the EAG if they > have more than 32 candidate colors. > > Yours, > Joel > > PS: substituting wants for wishes is probably reasonable. If we talk about > network-wide you might even be able to us "intends". > > > On 4/25/14, 10:06 AM, Eric Osborne wrote: >> >> Hi Joel- >> >> Thanks for the review. On your minor issue: >> --- >> I believe it is more accurate to say that it is to be used "when a >> node wishes to advertise colors for a link which are not represented >> in the first 32 bits of the color mask." The node may only wish to >> advertise colors 7 and 60, but that will require the EAG. >> --- >> >> I see your point, but I'm having trouble coming up with obvious text. >> Deciding which colors are represented in a color mask is up to the >> operator, which means it would have to say something like >> >> "when a node wishes to advertise colors for a link which the operator >> has defined to be outside the first 32 bits of the color mask". >> >> but this would be the only use of 'color mask' in the document, and >> it's not one I've seen used in any other docs around link coloring. >> >> The whole sentence you refer to is: >> >> " The EAG sub-TLV is used in addition to the Administrative Groups >> when a node wishes to advertise more than 32 colors for a link." >> >> If I rephrased it as >> >> " The EAG sub-TLV is used in addition to the Administrative Groups >> when an operator wants to make more than 32 colors available for >> advertisement on a link" >> >> would that do it? >> s/wishes/wants/ while I'm here. >> >> >> >> eric >> >> >> On Thu, Apr 24, 2014 at 5:55 PM, Joel M. Halpern >> wrote: >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-mpls-extended-admin-group-05 >>> Extended Administrative Groups in MPLS-TE >>> Reviewer: Joel M. Halpern >>> Review Date: 24-April-2014 >>> IETF LC End Date: 06-May-2014 >>> IESG Telechat date: N/A >>> >>> Summary: This document is ready for publication as a Proposed Standards >>> RFC >>> >>> Major issues: N/A >>> >>> Minor issues: >>> I believe that the description of when to use this EAG is slightly >>> misleading. The text says that EAG is to be used "when a node wishes to >>> advertise more than 32 colors for a link." I believe it is more accurate >>> to >>> say that it is to be used "when a node wishes to advertise colors for a >>> link >>> which are not represented in the first 32 bits of the color mask." The >>> node >>> may only wish to advertise colors 7 and 60, but that will require the >>> EAG. >>> >>> Nits/editorial comments: N/A >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 25 08:39:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725E51A0342; Fri, 25 Apr 2014 08:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmpUyYCYrI25; Fri, 25 Apr 2014 08:39:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 180FD1A0312; Fri, 25 Apr 2014 08:39:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ED21D1C0A7D; Fri, 25 Apr 2014 08:39:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5D9921C0878; Fri, 25 Apr 2014 08:39:35 -0700 (PDT) Message-ID: <535A81AF.3030500@joelhalpern.com> Date: Fri, 25 Apr 2014 11:39:27 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Osborne References: <53597772.6000401@nostrum.com> <53598854.2010201@joelhalpern.com> <535A7903.2070704@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0Y1KtyWPOTwCeSYP644-SkVH8Pg Cc: "mpls@ietf.org" , General Area Review Team Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:39:44 -0000 That works for me. Thank you Eric. Yours, Joel On 4/25/14, 11:28 AM, Eric Osborne wrote: > Works for me. > So > > " The EAG sub-TLV is used in addition to the Administrative Groups > when an operator wants to make more than 32 colors available for > advertisement in a network" > > I had gone back and forth with Adrian on language to scope this to a > single LSDB, so as to avoid the discussion of signaling EAG desire in > RSVP or PCEP. I don't want to add that sort of disclaimer here too, > as it makes the sentence clunky and unweildy. > > > > eric > > > On Fri, Apr 25, 2014 at 11:02 AM, Joel Halpern Direct > wrote: >> What if instead of "on the link" it is simoply "in the network". This >> recommend the use of EAG whenever the operators is using more than 32 colors >> across the link. It thus actually better aligns with avoiding the >> under-claiming issue by suggesting that operators should use the EAG if they >> have more than 32 candidate colors. >> >> Yours, >> Joel >> >> PS: substituting wants for wishes is probably reasonable. If we talk about >> network-wide you might even be able to us "intends". >> >> >> On 4/25/14, 10:06 AM, Eric Osborne wrote: >>> >>> Hi Joel- >>> >>> Thanks for the review. On your minor issue: >>> --- >>> I believe it is more accurate to say that it is to be used "when a >>> node wishes to advertise colors for a link which are not represented >>> in the first 32 bits of the color mask." The node may only wish to >>> advertise colors 7 and 60, but that will require the EAG. >>> --- >>> >>> I see your point, but I'm having trouble coming up with obvious text. >>> Deciding which colors are represented in a color mask is up to the >>> operator, which means it would have to say something like >>> >>> "when a node wishes to advertise colors for a link which the operator >>> has defined to be outside the first 32 bits of the color mask". >>> >>> but this would be the only use of 'color mask' in the document, and >>> it's not one I've seen used in any other docs around link coloring. >>> >>> The whole sentence you refer to is: >>> >>> " The EAG sub-TLV is used in addition to the Administrative Groups >>> when a node wishes to advertise more than 32 colors for a link." >>> >>> If I rephrased it as >>> >>> " The EAG sub-TLV is used in addition to the Administrative Groups >>> when an operator wants to make more than 32 colors available for >>> advertisement on a link" >>> >>> would that do it? >>> s/wishes/wants/ while I'm here. >>> >>> >>> >>> eric >>> >>> >>> On Thu, Apr 24, 2014 at 5:55 PM, Joel M. Halpern >>> wrote: >>>> >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> . >>>> >>>> Please resolve these comments along with any other Last Call comments >>>> you may receive. >>>> >>>> Document: draft-ietf-mpls-extended-admin-group-05 >>>> Extended Administrative Groups in MPLS-TE >>>> Reviewer: Joel M. Halpern >>>> Review Date: 24-April-2014 >>>> IETF LC End Date: 06-May-2014 >>>> IESG Telechat date: N/A >>>> >>>> Summary: This document is ready for publication as a Proposed Standards >>>> RFC >>>> >>>> Major issues: N/A >>>> >>>> Minor issues: >>>> I believe that the description of when to use this EAG is slightly >>>> misleading. The text says that EAG is to be used "when a node wishes to >>>> advertise more than 32 colors for a link." I believe it is more accurate >>>> to >>>> say that it is to be used "when a node wishes to advertise colors for a >>>> link >>>> which are not represented in the first 32 bits of the color mask." The >>>> node >>>> may only wish to advertise colors 7 and 60, but that will require the >>>> EAG. >>>> >>>> Nits/editorial comments: N/A >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Apr 27 12:58:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC0A1A06BB; Sun, 27 Apr 2014 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuDMF05Xyugj; Sun, 27 Apr 2014 12:58:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 149DC1A03C5; Sun, 27 Apr 2014 12:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140427195814.14969.91164.idtracker@ietfa.amsl.com> Date: Sun, 27 Apr 2014 12:58:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hzB3GWAJxoSIRaK91tjCrY1Dw8o Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 19:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Controlling State Advertisements Of Non-negotiated LDP Applications Authors : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-07.txt Pages : 13 Date : 2014-04-27 Abstract: There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ip-pw-capability-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 09:19:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0B1A6F3F; Mon, 28 Apr 2014 09:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPALw0GZgYo1; Mon, 28 Apr 2014 09:18:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4C1A08C5; Mon, 28 Apr 2014 09:18:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140428161858.5930.82050.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 09:18:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aBKTlAZkat_-_wWfNyBbCwfPCto Cc: mpls@ietf.org Subject: [mpls] Last Call: (Controlling State Advertisements Of Non-negotiated LDP Applications) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:18:59 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Controlling State Advertisements Of Non-negotiated LDP Applications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There is no capability negotiation done for Label Distribution Protocol (LDP) applications that setup Label Switched Paths (LSPs) for IP prefixes or that signal Point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise be advertised over the established LDP session. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 28 10:03:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1AF1A6F9B; Mon, 28 Apr 2014 10:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEVxXR74r7x7; Mon, 28 Apr 2014 10:03:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A3E1A6F9F; Mon, 28 Apr 2014 10:03:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428170319.29699.51227.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 10:03:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/esZh1uJxxMa1CfzbrlwKhoj8prg Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Label Advertisement Discipline for LDP FECs' to Proposed Standard (draft-ietf-mpls-ldp-applicability-label-adv-03.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:03:23 -0000 The IESG has approved the following document: - 'Label Advertisement Discipline for LDP FECs' (draft-ietf-mpls-ldp-applicability-label-adv-03.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ Technical Summary The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, RFC 6388, and RFC 7140 by specifying the label advertisement mode for all currently defined LDP FEC types. Working Group Summary There is a strong support for this document in the working group and it has been has been well reviewed. After AD review, the document was sent back to the WG for a substantial rewrite. A subsequent last call in the WG established support for the new revision. The document also got cleaned up during discussions with IANA in IETF last call (and that uncovered some bugs in the registry which was a whole lot of fun!). Document Quality The document describes what is effectively deployed implementation behaviour. Any disagreements with this would have resulted in loud shouts during WG last call. Any divergence from this presumably led to embarrassed silence during which code was frantically fixed. Personnel Loa Andersson (loa@pi.nu) is the document shepherd. Adrian Farrel (Adrian@olddog.co.uk) is the responsible AD. RFC Editor Note Please use the expansion "Forwarding Equivalence Class" for FEC in the Abstract and on its first use. Section 4 Please remove the following bullet: - For the existing FEC types, populate this column with the values listed under section 2.2. IANA Note IANA, please note the RFC Editor Note applying to the IANA Considerations section. From nobody Tue Apr 29 05:46:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD041A08CB; Tue, 29 Apr 2014 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzEH2V246UAj; Tue, 29 Apr 2014 05:46:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2406B1A0788; Tue, 29 Apr 2014 05:46:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429124635.29275.86241.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 05:46:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9Xhi70b9-wBwqXepBC29Nu-oirU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-extended-admin-group-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:46:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extended Administrative Groups in MPLS-TE Author : Eric Osborne Filename : draft-ietf-mpls-extended-admin-group-06.txt Pages : 7 Date : 2014-04-29 Abstract: MPLS-TE advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV of the Link TLV. This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS (RFC5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-extended-admin-group/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-extended-admin-group-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-extended-admin-group-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 05:47:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8020D1A08D2 for ; Tue, 29 Apr 2014 05:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJljLq_w5mGI for ; Tue, 29 Apr 2014 05:47:28 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF81A0788 for ; Tue, 29 Apr 2014 05:47:28 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so115332ykp.18 for ; Tue, 29 Apr 2014 05:47:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qBxoju/bNqOAad9cRoi2KC5kJQK7PE2HPAWPijmFBAY=; b=nH3xAdC/c1I50MS6m8nsH8+yIMn241c9TTf43UcFTkFBrn9Mk5kcSDlhhDP6EHzuNk fYTfMIvseNpNcKQA3LWDgtn9Jb5p3bW4HWc7t9XRP48iOOumt79J2PeFSHvk/RS08ItS xiaRNX1W92k1a41MY7RAtyKPCUURSF9Ob2sk1fbkSvudDpTmjIElmcvVjax10IC9Uyh+ Y6FvWjySRZA4zuGGy0KJpuGPZ1W9bYeNHEmwxSV13AAM6fcSBzhDoVBscmymb6IXivW1 wFKLLtbk9IZ81LeZD7UrLh2KcWdA72aOlf5KBXq+wnO6HvQKfZfTDPVmYS7Rjopcz6EB nyag== X-Gm-Message-State: ALoCoQlAcCzsFZMTQ3zPlQHXHusrwBwEHM1u4StJZ+RtvAQrhvlP6jigx0g/IaZ9xyQ+nxY3gARf MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr27028734yhc.53.1398775647019; Tue, 29 Apr 2014 05:47:27 -0700 (PDT) Received: by 10.170.60.5 with HTTP; Tue, 29 Apr 2014 05:47:26 -0700 (PDT) In-Reply-To: <535A81AF.3030500@joelhalpern.com> References: <53597772.6000401@nostrum.com> <53598854.2010201@joelhalpern.com> <535A7903.2070704@joelhalpern.com> <535A81AF.3030500@joelhalpern.com> Date: Tue, 29 Apr 2014 08:47:26 -0400 Message-ID: From: Eric Osborne To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/V8Vts67ZX8SkKDObsDpHUKv_4ps Cc: "mpls@ietf.org" , General Area Review Team , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [Gen-art] review: draft-ietf-mpls-extended-admin-group-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:47:30 -0000 Done and posted as -06. Chairs: This latest posting has all of the reviews, nits and other changes that have been requested. It is ready for publication. eric On Fri, Apr 25, 2014 at 11:39 AM, Joel M. Halpern wrote: > That works for me. > Thank you Eric. > Yours, > Joel > > > On 4/25/14, 11:28 AM, Eric Osborne wrote: >> >> Works for me. >> So >> >> " The EAG sub-TLV is used in addition to the Administrative Groups >> when an operator wants to make more than 32 colors available for >> advertisement in a network" >> >> I had gone back and forth with Adrian on language to scope this to a >> single LSDB, so as to avoid the discussion of signaling EAG desire in >> RSVP or PCEP. I don't want to add that sort of disclaimer here too, >> as it makes the sentence clunky and unweildy. >> >> >> >> eric >> >> >> On Fri, Apr 25, 2014 at 11:02 AM, Joel Halpern Direct >> wrote: >>> >>> What if instead of "on the link" it is simoply "in the network". This >>> recommend the use of EAG whenever the operators is using more than 32 >>> colors >>> across the link. It thus actually better aligns with avoiding the >>> under-claiming issue by suggesting that operators should use the EAG if >>> they >>> have more than 32 candidate colors. >>> >>> Yours, >>> Joel >>> >>> PS: substituting wants for wishes is probably reasonable. If we talk >>> about >>> network-wide you might even be able to us "intends". >>> >>> >>> On 4/25/14, 10:06 AM, Eric Osborne wrote: >>>> >>>> >>>> Hi Joel- >>>> >>>> Thanks for the review. On your minor issue: >>>> --- >>>> I believe it is more accurate to say that it is to be used "when a >>>> node wishes to advertise colors for a link which are not represented >>>> in the first 32 bits of the color mask." The node may only wish to >>>> advertise colors 7 and 60, but that will require the EAG. >>>> --- >>>> >>>> I see your point, but I'm having trouble coming up with obvious text. >>>> Deciding which colors are represented in a color mask is up to the >>>> operator, which means it would have to say something like >>>> >>>> "when a node wishes to advertise colors for a link which the operator >>>> has defined to be outside the first 32 bits of the color mask". >>>> >>>> but this would be the only use of 'color mask' in the document, and >>>> it's not one I've seen used in any other docs around link coloring. >>>> >>>> The whole sentence you refer to is: >>>> >>>> " The EAG sub-TLV is used in addition to the Administrative Groups >>>> when a node wishes to advertise more than 32 colors for a link." >>>> >>>> If I rephrased it as >>>> >>>> " The EAG sub-TLV is used in addition to the Administrative Groups >>>> when an operator wants to make more than 32 colors available for >>>> advertisement on a link" >>>> >>>> would that do it? >>>> s/wishes/wants/ while I'm here. >>>> >>>> >>>> >>>> eric >>>> >>>> >>>> On Thu, Apr 24, 2014 at 5:55 PM, Joel M. Halpern >>>> wrote: >>>>> >>>>> >>>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>>> Gen-ART, please see the FAQ at >>>>> >>>>> . >>>>> >>>>> Please resolve these comments along with any other Last Call comments >>>>> you may receive. >>>>> >>>>> Document: draft-ietf-mpls-extended-admin-group-05 >>>>> Extended Administrative Groups in MPLS-TE >>>>> Reviewer: Joel M. Halpern >>>>> Review Date: 24-April-2014 >>>>> IETF LC End Date: 06-May-2014 >>>>> IESG Telechat date: N/A >>>>> >>>>> Summary: This document is ready for publication as a Proposed Standards >>>>> RFC >>>>> >>>>> Major issues: N/A >>>>> >>>>> Minor issues: >>>>> I believe that the description of when to use this EAG is >>>>> slightly >>>>> misleading. The text says that EAG is to be used "when a node wishes >>>>> to >>>>> advertise more than 32 colors for a link." I believe it is more >>>>> accurate >>>>> to >>>>> say that it is to be used "when a node wishes to advertise colors for a >>>>> link >>>>> which are not represented in the first 32 bits of the color mask." The >>>>> node >>>>> may only wish to advertise colors 7 and 60, but that will require the >>>>> EAG. >>>>> >>>>> Nits/editorial comments: N/A >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Apr 30 02:15:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B454B1A0770 for ; Wed, 30 Apr 2014 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VphN3H45RIqc for ; Wed, 30 Apr 2014 02:15:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1C1A08B0 for ; Wed, 30 Apr 2014 02:15:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430091512.2494.4876.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 02:15:12 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YGfIi_od9eAbFI6ypbuvyN4Zh3E Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:15:21 -0000 Deleted milestone "Submit draft-ietf-mpls-ldp-multi-topology for publication". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Wed Apr 30 02:23:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2059E1A0317 for ; Wed, 30 Apr 2014 02:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4PmNsnO7PxI for ; Wed, 30 Apr 2014 02:22:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C488B1A08BD for ; Wed, 30 Apr 2014 02:22:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430092226.32551.47784.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 02:22:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LhkhvGhHU8FwNzhpbJby0LWh7dw Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:22:39 -0000 Changed milestone "Submit draft-ietf-mpls-ldp-applicability-label-adv for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Wed Apr 30 02:25:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521981A6F33 for ; Wed, 30 Apr 2014 02:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI81fFj7MtYZ for ; Wed, 30 Apr 2014 02:24:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B94151A6F3C for ; Wed, 30 Apr 2014 02:24:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430092453.1361.78265.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 02:24:53 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bDYMqA9__41GPFuvaDRfy25gabE Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:25:01 -0000 Changed milestone "Submit draft-ietf-mpls-forwardig for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Wed Apr 30 17:59:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2211A6FC2 for ; Wed, 30 Apr 2014 17:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U19rKdlzVhft for ; Wed, 30 Apr 2014 17:59:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F931A8869 for ; Wed, 30 Apr 2014 17:59:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501005930.1480.70685.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 17:59:30 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/bN-pQaImDDgy-QAo5mezAbfR8XU Subject: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 00:59:32 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Wed Apr 30 18:07:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5BF1A8895 for ; Wed, 30 Apr 2014 18:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSlWQLr_vsOm for ; Wed, 30 Apr 2014 18:07:20 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC15B1A888F for ; Wed, 30 Apr 2014 18:07:19 -0700 (PDT) Received: from [192.168.1.5] (unknown [112.208.110.53]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D750F1802AD6 for ; Thu, 1 May 2014 03:07:16 +0200 (CEST) Message-ID: <53619E41.2090901@pi.nu> Date: Thu, 01 May 2014 03:07:13 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mpls@ietf.org References: <20140501005930.1480.70685.idtracker@ietfa.amsl.com> In-Reply-To: <20140501005930.1480.70685.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7rmR7wFL7pjDSWYOjKEj9j2bQJs Subject: Re: [mpls] Milestones changed for mpls WG X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:07:24 -0000 Working Group, I deleted the milestone on draft-ietf-mpls-ldp-multi-topology by mistake (was going to mark it as "Done"). I put milestone back in, and will mark it "Done" as soon as Adrian has approved it. This regrettable causes some mail traffic to the working mailing list, sorry about that. /Loa On 2014-05-01 02:59, IETF Secretariat wrote: > > > URL: http://datatracker.ietf.org/wg/mpls/charter/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 30 23:09:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DF1A09F8; Wed, 30 Apr 2014 23:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClyiU_4L0904; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 300011A0A03; Wed, 30 Apr 2014 23:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1398924532; x=1400134132; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Vte9Knz0JjhgdbAJ1kp3eKKp3ToonmUBVOihCQgxQ+g=; b=IsqidTfcc30ArMFreNaKt0c6brNj2SKNlCN8ZCo1pAluHEJaWd+Ci9Oe XWlAzAJ92+OiEYY0iziK1OkPdt2jkt/LH503Sr7tai186awJa1AOCPn9i 9ujEe2LHkSUyJrB21kstU1jSwuunyg8Syqu0L7Wg/CzzIL3EkwcN8lYNk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAB3kYVOtJA2L/2dsb2JhbABZgwZPV8RYgRgWdIIsOj8SAT5CJwQBDYhGDcoGF45RhEAEmSqBPJEwgzOCKw X-IronPort-AV: E=Sophos;i="4.97,963,1389744000"; d="scan'208";a="40196646" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 01 May 2014 06:08:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4168qRh016918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 06:08:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 1 May 2014 01:08:52 -0500 From: "Rajiv Asati (rajiva)" To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpHw== Date: Thu, 1 May 2014 06:08:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.218.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <63CAFEE989E18C4398F9ABD33C077125@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kUd-aC42MokaZP8ZrFaWo0DFFZA Cc: "mpls@ietf.org" Subject: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:08:58 -0000 We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 of [RFC4291]).=20 1. Should/Would they appear in IPv6 routing table? 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or treated as a loopback packet, if ever received? The answer to Q#1 will help MPLS WG to decide the proper handling of v4-mapped v6 addresses in LDPv6 draft section 7 1st para. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * The answer to Q2 will help us assess the efficacy of RFC4379. Thanks.=20 --=20 Cheers, Rajiv=20 * // An LSR MUST treat the IPv4-mapped IPv6 address, defined in section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and not mix it with the 'corresponding' IPv4 address. // From nobody Wed Apr 30 23:40:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452411A0A1D; Wed, 30 Apr 2014 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlf-HPyfvtsC; Wed, 30 Apr 2014 23:40:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0948D1A0A17; Wed, 30 Apr 2014 23:40:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41647A6; Thu, 1 May 2014 08:40:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398926401; bh=IUHzY9P5Tzupc+oTZ9Cw00jAZ0R12KITCQd0JZw7mT8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=v9iSrtsKIY6SlqfOHArroPqa2T7ik1NVdcSEWIWkldg0RNfVZmbMtfF+BrgcpmuZq 3VRaVh/8zy+n1Z2s+Ol4Lgn/L/sKA+JWtQVmdhC7S4UYkIh8kOMz91uRIwm2x5ywAo k5asWe7ioeDjuKaX1yw1Y7fZCMl438Vn0IVEWQd4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D8FAA5; Thu, 1 May 2014 08:40:01 +0200 (CEST) Date: Thu, 1 May 2014 08:40:01 +0200 (CEST) From: Mikael Abrahamsson To: "Rajiv Asati (rajiva)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/o7dHgh-_cLHnlfZUrrBwqgIQfm4 Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:40:07 -0000 On Thu, 1 May 2014, Rajiv Asati (rajiva) wrote: > > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]). > > 1. Should/Would they appear in IPv6 routing table? > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or > treated as a loopback packet, if ever received? > > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * > > The answer to Q2 will help us assess the efficacy of RFC4379. http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 I realise this draft seems to have died, but I would never expect to see packets with these addresses on the wire or in the routing table and if they're there, I would want hosts/routers to drop them. Not doing this seems to me it would open to all kinds of unwanted consequences when it comes to filtering etc. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 30 23:59:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472AD1A0A27; Wed, 30 Apr 2014 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k07gSmZUr0tY; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA51A0A17; Wed, 30 Apr 2014 23:59:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B4FCA6; Thu, 1 May 2014 08:59:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398927562; bh=8xqZPIWyBXZqp6CTGwV0Pcox1VFGEELHcpcDyoP4C6o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=y0mdbxSSvD+nRQBAoYSpkaZ6yRxzHjDS5vmaEe/Mhw4WWxMKaBn43953IW2wzLa6h jL1kokdz7ISR24CwYn1LEx3puCia6sYgb8PzLCy0I1MQHa+1hIcyv8WKVxwvwjzDai AsEaanXlo9009qbDj0kfNDEJ+xJgta+lxRRHEucU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7DB4CA5; Thu, 1 May 2014 08:59:22 +0200 (CEST) Date: Thu, 1 May 2014 08:59:22 +0200 (CEST) From: Mikael Abrahamsson To: Hesham Soliman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-478116969-1398927562=:29282" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/oWWvNfhLZllht1Qlw8BzHNC20tE Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [mpls] [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:59:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-478116969-1398927562=:29282 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 1 May 2014, Hesham Soliman wrote: >> or in the routing table > > => Thatıs a different story. I donıt think there is anything banning this, > not least due to the fact that it is an implementation issue. If that > entry points to an IPv4 tunnel it should be fine. So it is possible to > implement a tunnel that way inside the host/router and nothing to stop > someone from doing unless I missed an RFC. Let me qualify my statement that I don't want to see it outside the box, ie in routes it's sending to anyone else. If it's in the internal RIB I have no problem with it, if it starts being announced in IGP and BGP then I think it's a bigger issue. >> and if >> they're there, I would want hosts/routers to drop them. > > => Is that behaviour documented somewhere? Also, youıre mixing them > appearing on the wire with an internal implementation issue. If this is documented somewhere, I am not aware, but I am definitely not the right person to ask about what might be in what RFC. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-478116969-1398927562=:29282--