From nobody Mon Sep 1 00:45:12 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 5F4D01A0163 for ; Mon, 1 Sep 2014 00:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 yb2n9MOMnbJU for ; Mon, 1 Sep 2014 00:45:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3D31A0115 for ; Mon, 1 Sep 2014 00:45:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIX99567; Mon, 01 Sep 2014 07:45:06 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Sep 2014 08:45:05 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 15:45:01 +0800 From: Mach Chen To: Sam Aldrin Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPvOsdwjhGcp6uiEqhBQ5TeCNTy5vbARkAgABOkoCAA/otAIACKNwAgAcIvhD//96TAIAAj/NwgAAPyYCAAt1JMIAAADkggAAAGjA= Date: Mon, 1 Sep 2014 07:45:00 +0000 Message-ID: References: In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XUR4XeRkqHLFQP57La9rWoSfCl8 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 01 Sep 2014 07:45:11 -0000 Hi Sam, Please see inline... =20 >=20 > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Sunday, August 31, 2014 2:05 AM > To: Mach Chen > Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf= .org > Subject: Re: [mpls] Poll for Adoption > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >=20 > Hi Mach, >=20 > See inline. >=20 > On Aug 30, 2014, at 2:40 AM, Mach Chen wrote: >=20 >=20 > Hi Sam, >=20 > Thanks for your prompt response! >=20 > Please see my reply inline... >=20 >=20 > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Saturday, August 30, 2014 4:33 PM > To: Mach Chen > Cc: Nobo Akiya (nobo); Ross Callon;=A0mpls@ietf.org;=A0mpls-chairs@tools.= ietf.org > Subject: Re: [mpls] Poll for Adoption > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >=20 > Hi Mach, >=20 > Inline for my brief comments > On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: >=20 >=20 > Hi Sam, >=20 > Some replies inline... >=20 > Sniped. >=20 >=20 >=20 > Let us take the MPLS TP with IP on every node. > The scenario you are talking about is 'associated bidirectional' tunnel. > Just because a 'vendor' implemented certain default method doesn't > require new TLV support. > For associated bidirectional tunnel with IP on every node, perform > reply mode as IP. > I don't think RFC4379 warrants certain default type to be fixed type > for a given FEC. >=20 > [NOBO] What you say is true only if all operators prefer IP return > path over control channel and reverse LSP. I am aware of operators > who wants to prefer control channel or reverse LSP whenever > available, over IP path. The preference really varies depending on > operators. This is exactly where this extension can benefit. > %sam - We discussed this before but ended up with opposite conclusion > :D. If user want to perform return path via lsp or via IP, nothing > prevents and one could chose either of them. The same goes for bitmap siz= e, > selector size etc. >=20 >=20 > Your assumption is that all nodes along the path support both IP and LSP = return > path, this may not always true. =A0In some mobile backhaul networks that > normally have access and core network parts, the nodes in the access may = only > support pure MPLS-TP and not support IP forwarding; the nodes in the core= part > normally support IP/MPLS. Then takes the picture in A.2 as an example: >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0+----C------D----+ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0/ > =A0=A0=A0=A0=A0=A0\ > A'----A------B =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0G---H---H' > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0\ > =A0=A0=A0=A0=A0/ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0+----E------F----+ >=20 > Where A', A, H and H' only support pure MPLS-TP and do not support IP > forwarding, B and G support both LSP and IP return path, it means that re= ply > mode 2 cannot be used when perform traceroute. But when =A0"Reply via rev= erse > LSP" is used, since =A0C, D, E and F may not have reverse LSP path but ha= ve IP > return path, it still cannot traceroute the whole path. In this case, act= ually, any > single reply mode cannot satisfy the requirement. > Neither does this new TLV will help, nor mandating IP reply mode only tra= ce is > what I am advocating. > Head end do not know which nodes support IP or which don't. > For the same topology, If C,D,E and F do not support IP, this new TLV is = not going > to help you either. >=20 > No, it can help only if C, D, E and F know how to handle the Reply Mode T= LV. For > your case, if C does not support IP, but it should support at least one o= ther reply > mode and then use that mode to send back the echo reply. > Please quote with real LSP example you are talking about and which other = way > and reply mode you are talking about. > Please refer to earlier emails, why I say that. >=20 >=20 >=20 >=20 > Solution cannot be topology specific, where the initiator do not know wha= t the > topology is or will be. > What you have is a solution, trying to find a problem. >=20 > The above scenario is a very typical MBB scenario that deploys pure MPLS-= TP in > access and reuse the IP/MPLS for core network. And even if operators know= (and > normally they do) the topologies, they cannot depend on the existing > mechanisms to trace the path for reason that a single reply mode cannot a= pply to > an LSP that across nodes support different modes. > I have deployed and helped networks operated and troubleshoot them, so I > know what I am talking about. > Provided examples how one could make it work without the need. Also provi= ded > why this TLV cannot help in the so called mixed mode. > In your own example, if C, D, E and F do not support 'IP' (not just new T= LV), > your solution do not work. To make traceroute work, two conditions are required; 1) intermediate nodes must know how to process reply mode; with the Reply m= ode TLV and the mechanisms defined in this document, a node could easily ch= ose proper reply mode when it does not support the reply mode in echo reque= st; simultaneously ping would require the operators or the smart ingress LS= R to guess/compute which reply mode should be used. 2) there MUST be return path(s) from intermediate nodes to ingress LSR; for= whatever mechanisms used, this is a "MUST" condition. According to the above two conditions, a node should at least support one r= eply mode and should have one return path to the ingress LSR. So for the qu= estion, if you ask me it does not support "IP", I can answer it could suppo= rt LSP return path, we may not need to circle the question and answer :-) >=20 >=20 >=20 > As I said in my earlier emails, performing IP and reply via LSP trace sim= ultaneously > could achieve the same result, for mixed mode (some nodes do not support = IP) > topology. >=20 > Given the above example, since A', A, H and H' only support pure MPLS > forwarding and do not support IP forwarding, you cannot perform IP and re= ly via > LSP trace simultaneously. Because when you reply mode 2 (IP path) to perf= orm > trace, the echo request will be dropped at A and will not have chance to = reach to > other nodes. Similarly, if you use reply via LSP, C,D, E and F will not f= ind a reverse > path. > Really? Then what is the purpose of TTL? Could you care to explain how th= e node > drops a packet when TTL do not expire? I revised my saying in another email, my original meaning is that the node = will not reply if it does not support a specific mode, of cause, increasing= the TTL could make the subsequent echo requests reach to the next hop.=20 Thanks, Mach >=20 > -sam >=20 >=20 >=20 > Thanks, > Mach >=20 >=20 > Performance or diagnosing is not an issue as Timeout value, ttl value > etc are all configurable and 4379 does not mandate what those values shou= ld be. >=20 >=20 >=20 >=20 > The essential of the Reply Mode Order TLV is to allow multiple reply mode= s to > be used for a specific LSP, and each responder can select its appropriate= reply > mode to return the echo reply. > You could achieve that without the need for new TLV and upgrade of the > network. >=20 > cheers > -sam >=20 >=20 >=20 > Best regards, > Mach From nobody Mon Sep 1 02:40: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 32B621A02F6 for ; Mon, 1 Sep 2014 02:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 x9xBsPUusqYh for ; Mon, 1 Sep 2014 02:40:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D561A02F7 for ; Mon, 1 Sep 2014 02:40:48 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 743503242C7; Mon, 1 Sep 2014 11:40:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4BEEB238048; Mon, 1 Sep 2014 11:40:47 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.43]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 11:40:47 +0200 From: To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5AJPjt5w Date: Mon, 1 Sep 2014 09:40:46 +0000 Message-ID: <28799_1409564447_54043F1F_28799_3445_1_9E32478DFA9976438E7A22F69B08FF92080D02@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92080D02OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.1.61823 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9J_ymt8rdojijCB69pYWgAx69PQ Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 01 Sep 2014 09:40:51 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92080D02OPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I strongly support this draft which brings simplification in understanding/= managing reply paths. Stephane From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, August 20, 2014 17:21 To: mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92080D02OPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I strongly support this d= raft which brings simplification in understanding/managing reply paths.

 <= /p>

Stephane

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 17:21
To: mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.=

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92080D02OPEXCLILM34corpor_-- From nobody Mon Sep 1 11:57: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 BD7CD1A0697 for ; Mon, 1 Sep 2014 11:57: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 7UVkUgrj7D2q for ; Mon, 1 Sep 2014 11:57:22 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A911A068C for ; Mon, 1 Sep 2014 11:57:22 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so12847002pad.35 for ; Mon, 01 Sep 2014 11:57:22 -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=E/7egQ+lPKjPn/t+I3Lw1bRV5IL/8ifpv+jAD9UIx04=; b=AuLVcTu+coeJ/y6wi/wBcJco9MBhz6AUnl00AGPOLCwEFI7cSHUz+0Haystj6oRiMs L8NVchtQNFKCheA+RVtwR8yWheICAA8uklJIT/sesafg+9c2rJiP7Kji4vRftJdSakpx FSj4A4aPmqwvigD6seK7ekBQdc8yfHUAr5b+NJj7QsE7+bUl4UvorXLSDXKCDK13Lqjw Ux/xkyhh0bvu+g+T4XXpOd/yIg5zlA8VswEOgw4NtaHf16MCdpWaTlNbqeysYzORJ8Iv Ffsu3R9v8/5tNQBQUioQ7l/VvQsDoM/c+qJD4g2e/AH9FIL7rmkJfn2wdd3PfqT/CMe6 L0XA== X-Received: by 10.68.95.196 with SMTP id dm4mr41469210pbb.95.1409597842159; Mon, 01 Sep 2014 11:57:22 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id q13sm2286805pdj.44.2014.09.01.11.57.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 11:57:21 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 1 Sep 2014 11:57:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FE6B654-518E-486D-858F-5B713FEF2CE6@gmail.com> References: To: Mach Chen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kyEcxd-2whC3EUXZ3MWokk8c6bs Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 01 Sep 2014 18:57:25 -0000 Hi Mach, See inline. On Sep 1, 2014, at 12:45 AM, Mach Chen wrote: > Hi Sam, >=20 > Please see inline... >=20 >>=20 >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Sunday, August 31, 2014 2:05 AM >> To: Mach Chen >> Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; = mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] Poll for Adoption >> draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >>=20 >> Hi Mach, >>=20 >> See inline. >>=20 >> On Aug 30, 2014, at 2:40 AM, Mach Chen wrote: >>=20 >>=20 >> Hi Sam, >>=20 >> Thanks for your prompt response! >>=20 >> Please see my reply inline... >>=20 >>=20 >> -----Original Message----- >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Saturday, August 30, 2014 4:33 PM >> To: Mach Chen >> Cc: Nobo Akiya (nobo); Ross Callon; mpls@ietf.org; = mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] Poll for Adoption >> draft-akiya-mpls-lsp-ping-reply-mode-simple-02 >>=20 >> Hi Mach, >>=20 >> Inline for my brief comments >> On Aug 29, 2014, at 8:32 PM, Mach Chen wrote: >>=20 >>=20 >> Hi Sam, >>=20 >> Some replies inline... >>=20 >> Sniped. >>=20 >>=20 >>=20 >> Let us take the MPLS TP with IP on every node. >> The scenario you are talking about is 'associated bidirectional' = tunnel. >> Just because a 'vendor' implemented certain default method doesn't >> require new TLV support. >> For associated bidirectional tunnel with IP on every node, perform >> reply mode as IP. >> I don't think RFC4379 warrants certain default type to be fixed type >> for a given FEC. >>=20 >> [NOBO] What you say is true only if all operators prefer IP return >> path over control channel and reverse LSP. I am aware of operators >> who wants to prefer control channel or reverse LSP whenever >> available, over IP path. The preference really varies depending on >> operators. This is exactly where this extension can benefit. >> %sam - We discussed this before but ended up with opposite conclusion >> :D. If user want to perform return path via lsp or via IP, nothing >> prevents and one could chose either of them. The same goes for bitmap = size, >> selector size etc. >>=20 >>=20 >> Your assumption is that all nodes along the path support both IP and = LSP return >> path, this may not always true. In some mobile backhaul networks = that >> normally have access and core network parts, the nodes in the access = may only >> support pure MPLS-TP and not support IP forwarding; the nodes in the = core part >> normally support IP/MPLS. Then takes the picture in A.2 as an = example: >>=20 >>=20 >> +----C------D----+ >> / >> \ >> A'----A------B G---H---H' >> \ >> / >> +----E------F----+ >>=20 >> Where A', A, H and H' only support pure MPLS-TP and do not support IP >> forwarding, B and G support both LSP and IP return path, it means = that reply >> mode 2 cannot be used when perform traceroute. But when "Reply via = reverse >> LSP" is used, since C, D, E and F may not have reverse LSP path but = have IP >> return path, it still cannot traceroute the whole path. In this case, = actually, any >> single reply mode cannot satisfy the requirement. >> Neither does this new TLV will help, nor mandating IP reply mode only = trace is >> what I am advocating. >> Head end do not know which nodes support IP or which don't. >> For the same topology, If C,D,E and F do not support IP, this new TLV = is not going >> to help you either. >>=20 >> No, it can help only if C, D, E and F know how to handle the Reply = Mode TLV. For >> your case, if C does not support IP, but it should support at least = one other reply >> mode and then use that mode to send back the echo reply. >> Please quote with real LSP example you are talking about and which = other way >> and reply mode you are talking about. >> Please refer to earlier emails, why I say that. >>=20 >>=20 >>=20 >>=20 >> Solution cannot be topology specific, where the initiator do not know = what the >> topology is or will be. >> What you have is a solution, trying to find a problem. >>=20 >> The above scenario is a very typical MBB scenario that deploys pure = MPLS-TP in >> access and reuse the IP/MPLS for core network. And even if operators = know (and >> normally they do) the topologies, they cannot depend on the existing >> mechanisms to trace the path for reason that a single reply mode = cannot apply to >> an LSP that across nodes support different modes. >> I have deployed and helped networks operated and troubleshoot them, = so I >> know what I am talking about. >> Provided examples how one could make it work without the need. Also = provided >> why this TLV cannot help in the so called mixed mode. >> In your own example, if C, D, E and F do not support 'IP' (not just = new TLV), >> your solution do not work. >=20 > To make traceroute work, two conditions are required; > 1) intermediate nodes must know how to process reply mode; with the = Reply mode TLV and the mechanisms defined in this document, a node could = easily chose proper reply mode when it does not support the reply mode = in echo request; simultaneously ping would require the operators or the = smart ingress LSR to guess/compute which reply mode should be used. >=20 > 2) there MUST be return path(s) from intermediate nodes to ingress = LSR; for whatever mechanisms used, this is a "MUST" condition. >=20 > According to the above two conditions, a node should at least support = one reply mode and should have one return path to the ingress LSR. So = for the question, if you ask me it does not support "IP", I can answer = it could support LSP return path, we may not need to circle the question = and answer :-) If you use the logic above to support the case, it will totally fail. You are discounting your own solution by the above logic. In order to make your logic really really work, all nodes MUST support = the new TLV, which will be a non-starter. I have provided explanations for the topologies provided so far and how = to make it work w/o the need for new TLV. You can refer to earlier = emails. Whether a node supports one or two reply modes is dependent on LSP type, = Pick a LSP and we could discuss. >=20 >>=20 >>=20 >>=20 >> As I said in my earlier emails, performing IP and reply via LSP trace = simultaneously >> could achieve the same result, for mixed mode (some nodes do not = support IP) >> topology. >>=20 >> Given the above example, since A', A, H and H' only support pure MPLS >> forwarding and do not support IP forwarding, you cannot perform IP = and rely via >> LSP trace simultaneously. Because when you reply mode 2 (IP path) to = perform >> trace, the echo request will be dropped at A and will not have chance = to reach to >> other nodes. Similarly, if you use reply via LSP, C,D, E and F will = not find a reverse >> path. >> Really? Then what is the purpose of TTL? Could you care to explain = how the node >> drops a packet when TTL do not expire? >=20 > I revised my saying in another email, my original meaning is that the = node will not reply if it does not support a specific mode, of cause, = increasing the TTL could make the subsequent echo requests reach to the = next hop.=20 That is how trace works, be it ICMP or LSP ping, uses ttl to go to next = hop, which is not what you said earlier. It will not reply if the node do not understand the new tlv either. cheers -sam > Thanks, > Mach >=20 >>=20 >> -sam >>=20 >>=20 >>=20 >> Thanks, >> Mach >>=20 >>=20 >> Performance or diagnosing is not an issue as Timeout value, ttl value >> etc are all configurable and 4379 does not mandate what those values = should be. >>=20 >>=20 >>=20 >>=20 >> The essential of the Reply Mode Order TLV is to allow multiple reply = modes to >> be used for a specific LSP, and each responder can select its = appropriate reply >> mode to return the echo reply. >> You could achieve that without the need for new TLV and upgrade of = the >> network. >>=20 >> cheers >> -sam >>=20 >>=20 >>=20 >> Best regards, >> Mach >=20 From nobody Tue Sep 2 11:57: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 D3AB41A0662 for ; Tue, 2 Sep 2014 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 uIHmCoKn82kO for ; Tue, 2 Sep 2014 11:57:04 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618301A065F for ; Tue, 2 Sep 2014 11:57:03 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4CB1CE9C3ADFF; Tue, 2 Sep 2014 18:56:54 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s82IuuoR006493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 14:56:56 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 2 Sep 2014 14:56:56 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkReGJe0hsllSUWt55jdwggY6ZvXguRQgAXkqoCACAl2gIAC82twgAD6kwCABO68kA== Date: Tue, 2 Sep 2014 18:56:55 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D9471DC7F@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> , <4A79394211F1AF4EB57D998426C9340D9471CE50@US70UWXCHMBA01.zam.alcatel-lucent.com> <7A384EF8-93FE-4157-8726-6B0F4DD3D47B@cisco.com> In-Reply-To: <7A384EF8-93FE-4157-8726-6B0F4DD3D47B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DYeZtLR9d6A6i4myy2j9rPqH7C4 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) 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, 02 Sep 2014 18:57:08 -0000 Hi Rajiv, I think the key point I am trying to convey is that we should keep the prot= ocol clean and use features for what they are designed for. LDP has its own= capability advertisement and it is meant to address issues like this one. Overloading the TR field of the initialization message means that a peer wi= ll have to check both the TR and the SAC to decide what to do for the IPv6 = prefix FEC while it is sufficient to check the SAC for all other FEC types.= This is inconsistent and will cause an unnecessary exception in the protoc= ol. Also, using the LDP advertisement capability is not a baggage in the future= . This mechanism is used with mLDP P2P and MP2MP FECs and this is working f= ine today although many implementations now support these types of FECs. As for changing other drafts, we are simply talking about stating in draft-= ietf-mpls-ldp-ip-pw-capability-07 that an LDP peer must set D-bit=3D0 in I= Pv6 prefix FEC SAC in the initialization message.=20 Regards, Mustapha. > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Saturday, August 30, 2014 7:19 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mp= ls-ldp- > ipv6@tools.ietf.org > Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc = closed) >=20 > Hi Mustapha, >=20 > TR field is useful in case of dual-stack environment and using it for det= ermining > whether the peer implementation is compliant (wrt handling v6 address bin= dings and > label bindings) is simple and straight forward. >=20 > When v6-only peer implementations exist (and become a new norm), TR field > usage would become moot. And we wouldn't have to see them. A very good th= ing, > IMO. >=20 > We need to think about how much of this baggage needs to carry over when = single- > stack ipv6 networks become a new norm (like single-stack ipv4 has been). >=20 > Given that this draft already has built-in means to accommodate the RFC50= 36 non- > compliant peer issue and do so in a simple manner, it is not necessary to= require > changing other drafts, IMO. >=20 >=20 > Cheers, > Raj >=20 >=20 > PS; While there are multiple types of FECs, and it would be wise to dicta= te the > default behavior (v6 FECs advertised) in v6-only environment with an opti= on to > change it. This is nothing different from current protocol machinery. >=20 >=20 > > On Aug 29, 2014, at 8:25 PM, "Aissaoui, Mustapha (Mustapha)" > wrote: > > > > Hi Rajiv, > > See inline below for some follow-up. > > > > Regards, > > Mustapha. > > > >> -----Original Message----- > >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > >> Sent: Wednesday, August 27, 2014 7:19 PM > >> To: Ross Callon; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > >> Cc: mpls-chairs@tools.ietf.org; > >> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >> wglc closed) > >> > >> > >> If this draft were to address the interoperability with rfc5036 > >> non-compliant implementations, then it would be easier to rather > >> leverage the =8Ctransport preference=B9 TLV that is already part of th= e version 13. > >> This TLV was defined after the getting Adrian's and George=B9s feedbac= k. > >> > >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.1 > > MA> It is not a good idea to overload this new TLV with a capability ad= vertisement > role. LDP has its own capability advertisement mechanism and there is no = need to > confuse implementations with the handling of two mechanisms. > > > >> The reason for not agreeing to the alternate solution (of using IP > >> Prefix capability > >> etc.) is 2-fold: > >> > >> - not forward compatible (consider a deployment 5 yrs from now - > >> IPv6-only MPLS network - now, the LSR will be expecting an > >> unnecessary IPv6 prefix capability advertisement, and that=B9s not > >> optimal, if not annoying) > > MA> IPv6-only network is not synonymous with a single FEC type network.= It will > support many types of FECs in addition to the IPv6 prefix FEC: mLDP IPv6= FECs, > PW FECs, IPv4 prefix FEC, etc. The LDP capabilities have been designed fo= r the > purpose of explicitly enabling or disabling capabilities including FEC ty= pe support on > a given session. > > > >> - not 100% backward compatible (does not solve the advertisement of > >> v6 address binding to a v4 neighbor (which can also cause an outage > >> to a non-compliant peer)) > > MA> I think it makes sense to tie the exchange of both IPv6 address mes= sages > and IPv6 prefix FECs to the advertisement of the IPv6 capability by both = peers. If > however there is a use case for decoupling the advertising of IPv6 addres= ses from > IPv6 FECs, then a separate capability can be devised for addresses but I = do not > think we need it. > > > > > >> Thanks. > >> > >> > >> -- > >> Cheers, > >> Rajiv Asati > >> Distinguished Engineer, Cisco > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Ross Callon > >> Date: Friday, August 22, 2014 at 4:34 PM > >> To: Mustapha Aissaoui , > >> "mpls@ietf.org" > >> Cc: "mpls-chairs@tools.ietf.org" , > >> "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" > >> > >> Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >> wglc > >> closed) > >> Resent-From: > >> Resent-To: Carlos Pignataro , Rajiv Papneja > >> , Rajiv Asati , Vishwas > >> Manral , , Loa Andersson > >> , Ross Callon , MARTIN VIGOUREUX > >> > >> Resent-Date: Friday, August 22, 2014 at 4:35 PM > >> > >>>> The proposed solution is to have implementations complying to this > >>>> draft advertise the IPv6 prefix state advertisement control > >>>> capability > >>>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization > >>>> message explicitly indicating support for LDP IPv6. Without the > >>>> peer advertising this capability, an LSR must not send IPv6 > >>>> addresses and FECs to that peer. > >>> > >>> Speaking as an individual contributor, this seems IMHO to be the > >>> right solution (noting that, in final text as would be published in > >>> an RFC, the "must not" in the last sentence should be capitalized). > >>> > >>> Thanks, Ross > >>> > >>> -----Original Message----- > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, > >>> Mustapha > >>> (Mustapha) > >>> Sent: Tuesday, August 19, 2014 3:19 AM > >>> To: mpls@ietf.org > >>> Cc: mpls-chairs@tools.ietf.org; > >>> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >>> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >>> wglc > >>> closed) > >>> > >>> Dear all, > >>> The following are the details of the issue we found and the proposed > >>> solution. We shared this first with the authors to get initial feedba= ck. > >>> > >>> When an LSR which supports LDP IPv6 according to this draft is in a > >>> LAN with a broadcast interface, it can peer with LSRs which support > >>> this draft and LSRs which do not. When it peers using IPv4 LDP > >>> control plane with an LSR which does not support this draft, we have > >>> seen during our testing an issue that the advertisement of IPv6 > >>> addresses or IPv6 FECs to that peer will cause it to bring down the I= Pv4 LDP > session. > >>> > >>> In other words, there are deployed LDP implementations which are > >>> compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 > >>> when it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4 > session. > >>> This is making us very concerned that when users enable dual-stack > >>> LDP IPv4/IPv6, they will bring down LDP IPv4 sessions which have > >>> been working in a multi-vendor environments for so many years. > >>> > >>> The proposed solution is to have implementations complying to this > >>> draft advertise the IPv6 prefix state advertisement control > >>> capability > >>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization > >>> message explicitly indicating support for LDP IPv6. Without the peer > >>> advertising this capability, an LSR must not send IPv6 addresses and > >>> FECs to that peer. > >>> > >>> This approach is safer and has been followed when mLDP FEC was > >>> introduced as explained in Section 2.1 of RFC 6388. Also, this does > >>> not introduce any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes > >>> the exchange of LDP IPv6 addresses and FECs conditional to both > >>> peers explicitly indicating support for IPv6 capability during LDP se= ssion > initialization. > >>> > >>> We do not feel such a simple change justifies writing a new draft > >>> and having to deal with backward compatibility of implementations > >>> across two drafts. > >>> > >>> We appreciate your comments on this matter. > >>> > >>> Regards, > >>> Mustapha. > >>> > >>> > >>>> -----Original Message----- > >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > >>>> Andersson > >>>> Sent: Tuesday, August 12, 2014 11:45 AM > >>>> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; > >>>> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >>>> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >>>> wglc > >>>> closed) > >>>> > >>>> Working Group, > >>>> > >>>> During what we thought would be a short wglc on > >>>> draft-ietf-mpls-ldp-ipv6 > >>>> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > >>>> we had a comment that stopped us from continuing progressing the dra= ft. > >>>> > >>>> The short working group last call is now closed! > >>>> > >>>> The comment we refer to was raised in a private mail to the working > >>>> group chairs and the draft authors. > >>>> > >>>> It says that there are a problem with some RFC 5036 non-compliant > >>>> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no > >>>> detailed description of the exact problems. > >>>> > >>>> We strongly encourage the people that made the comment(s) to > >>>> write-up the problem, either as > >>>> > >>>> - a new draft (preferred); or > >>>> - in a mail to the working group mailing list > >>>> > >>>> Once we an agreement to write a new draft or the write-up to the > >>>> mailing, we will continue to ask the working group to see if we can > >>>> agree to a way to progress. We like to see this write-up before > >>>> September 1. Failing this we will continue to progress the > >>>> draft-ietf-mpls-ldp-ipv6 as is. > >>>> > >>>> /Loa > >>>> for the working group chairs > >>>> -- > >>>> > >>>> > >>>> 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 > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > From nobody Tue Sep 2 14:32: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 65F371A0649 for ; Tue, 2 Sep 2014 14:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 Z1SAYPhHEnNZ for ; Tue, 2 Sep 2014 14:32:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710FB1A063F for ; Tue, 2 Sep 2014 14:32:46 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A4F2E76C7EF16; Tue, 2 Sep 2014 21:32:41 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s82LWiBk029171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 17:32:44 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 2 Sep 2014 17:32:44 -0400 Received: from SG70YWXCHMBA08.zap.alcatel-lucent.com ([169.254.8.30]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Wed, 3 Sep 2014 05:32:39 +0800 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , "Rajiv Asati (rajiva)" Thread-Topic: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) Thread-Index: AQHPtkReW5ZYZDudTUC1XfMcEOSFO5vXguRQgAXkqoCACAl2gIAC82twgAD6kwCABO68kIAAJfpg Date: Tue, 2 Sep 2014 21:32:38 +0000 Message-ID: References: <53EA3666.2040004@pi.nu> <4A79394211F1AF4EB57D998426C9340D94717BBC@US70UWXCHMBA01.zam.alcatel-lucent.com> <9ace61def77942938bc577e4b6782680@CO2PR05MB636.namprd05.prod.outlook.com> , <4A79394211F1AF4EB57D998426C9340D9471CE50@US70UWXCHMBA01.zam.alcatel-lucent.com> <7A384EF8-93FE-4157-8726-6B0F4DD3D47B@cisco.com> <4A79394211F1AF4EB57D998426C9340D9471DC7F@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D9471DC7F@US70UWXCHMBA01.zam.alcatel-lucent.com> 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: multipart/alternative; boundary="_000_ABD110CD5D879A4BB51C269846E4CA3117F912SG70YWXCHMBA08zap_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/D2At3iwkg2vB8hx1hazcnnDeLeA Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed) 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, 02 Sep 2014 21:32:50 -0000 --_000_ABD110CD5D879A4BB51C269846E4CA3117F912SG70YWXCHMBA08zap_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I second to Mustapha. We should use features for what they are designed for= . It is the SAC capability (draft-ietf-mpls-ldp-ip-pw-capability-07) that d= efines the negotiation of IPV4/IPV6 Prefix FEC Capabilities in LDP session,= which fits into the required inter-op solution organically. I do not consider explicit advertisement of IPv6 Prefix FEC SAC (D =3D 0) i= n Initialization message can be seen as baggage. An implementation that doe= s not want to receive IPv6 Prefix FECs will send D=3D1 in Initialization me= ssage anyways. Cheers, Pranjal -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (= Mustapha) Sent: Tuesday, September 02, 2014 11:57 AM To: Rajiv Asati (rajiva) Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls= -ldp-ipv6@tools.ietf.org Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc cl= osed) Hi Rajiv, I think the key point I am trying to convey is that we should keep the prot= ocol clean and use features for what they are designed for. LDP has its own= capability advertisement and it is meant to address issues like this one. Overloading the TR field of the initialization message means that a peer wi= ll have to check both the TR and the SAC to decide what to do for the IPv6 = prefix FEC while it is sufficient to check the SAC for all other FEC types.= This is inconsistent and will cause an unnecessary exception in the protoc= ol. Also, using the LDP advertisement capability is not a baggage in the future= . This mechanism is used with mLDP P2P and MP2MP FECs and this is working f= ine today although many implementations now support these types of FECs. As for changing other drafts, we are simply talking about stating in draft-= ietf-mpls-ldp-ip-pw-capability-07 that an LDP peer must set D-bit=3D0 in I= Pv6 prefix FEC SAC in the initialization message. Regards, Mustapha. > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Saturday, August 30, 2014 7:19 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.i= etf.org; > draft-ietf-mpls-ldp- ipv6@tools.ietf.org > Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > wglc closed) > > Hi Mustapha, > > TR field is useful in case of dual-stack environment and using it for > determining whether the peer implementation is compliant (wrt handling > v6 address bindings and label bindings) is simple and straight forward. > > When v6-only peer implementations exist (and become a new norm), TR > field usage would become moot. And we wouldn't have to see them. A > very good thing, IMO. > > We need to think about how much of this baggage needs to carry over > when single- stack ipv6 networks become a new norm (like single-stack ipv= 4 has been). > > Given that this draft already has built-in means to accommodate the > RFC5036 non- compliant peer issue and do so in a simple manner, it is > not necessary to require changing other drafts, IMO. > > > Cheers, > Raj > > > PS; While there are multiple types of FECs, and it would be wise to > dictate the default behavior (v6 FECs advertised) in v6-only > environment with an option to change it. This is nothing different from c= urrent protocol machinery. > > > > On Aug 29, 2014, at 8:25 PM, "Aissaoui, Mustapha (Mustapha)" > > wrote: > > > > Hi Rajiv, > > See inline below for some follow-up. > > > > Regards, > > Mustapha. > > > >> -----Original Message----- > >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > >> Sent: Wednesday, August 27, 2014 7:19 PM > >> To: Ross Callon; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > >> Cc: mpls-chairs@tools.ietf.org; > >> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >> wglc closed) > >> > >> > >> If this draft were to address the interoperability with rfc5036 > >> non-compliant implementations, then it would be easier to rather > >> leverage the =8Ctransport preference=B9 TLV that is already part of th= e version 13. > >> This TLV was defined after the getting Adrian's and George=B9s feedbac= k. > >> > >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1. > >> 1 > > MA> It is not a good idea to overload this new TLV with a capability > > MA> advertisement > role. LDP has its own capability advertisement mechanism and there is > no need to confuse implementations with the handling of two mechanisms. > > > >> The reason for not agreeing to the alternate solution (of using IP > >> Prefix capability > >> etc.) is 2-fold: > >> > >> - not forward compatible (consider a deployment 5 yrs from now - > >> IPv6-only MPLS network - now, the LSR will be expecting an > >> unnecessary IPv6 prefix capability advertisement, and that=B9s not > >> optimal, if not annoying) > > MA> IPv6-only network is not synonymous with a single FEC type > > MA> network. It will > support many types of FECs in addition to the IPv6 prefix FEC: mLDP > IPv6 FECs, PW FECs, IPv4 prefix FEC, etc. The LDP capabilities have > been designed for the purpose of explicitly enabling or disabling > capabilities including FEC type support on a given session. > > > >> - not 100% backward compatible (does not solve the advertisement of > >> v6 address binding to a v4 neighbor (which can also cause an outage > >> to a non-compliant peer)) > > MA> I think it makes sense to tie the exchange of both IPv6 address > > MA> messages > and IPv6 prefix FECs to the advertisement of the IPv6 capability by > both peers. If however there is a use case for decoupling the > advertising of IPv6 addresses from > IPv6 FECs, then a separate capability can be devised for addresses but > I do not think we need it. > > > > > >> Thanks. > >> > >> > >> -- > >> Cheers, > >> Rajiv Asati > >> Distinguished Engineer, Cisco > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Ross Callon > > >> Date: Friday, August 22, 2014 at 4:34 PM > >> To: Mustapha Aissaoui >, > >> "mpls@ietf.org" > > >> Cc: "mpls-chairs@tools.ietf.org" >, > >> "draft-ietf-mpls-ldp-ipv6@tools.ietf.org" > >> > > >> Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >> wglc > >> closed) > >> Resent-From: > > >> Resent-To: Carlos Pignataro >, Rajiv Papneja > >> >, Rajiv Asa= ti >, Vishwas > >> Manral >, >, Loa Andersson > >> >, Ross Callon >, MARTIN VIGOUREUX > >> > > >> Resent-Date: Friday, August 22, 2014 at 4:35 PM > >> > >>>> The proposed solution is to have implementations complying to > >>>> this draft advertise the IPv6 prefix state advertisement control > >>>> capability > >>>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization > >>>> message explicitly indicating support for LDP IPv6. Without the > >>>> peer advertising this capability, an LSR must not send IPv6 > >>>> addresses and FECs to that peer. > >>> > >>> Speaking as an individual contributor, this seems IMHO to be the > >>> right solution (noting that, in final text as would be published > >>> in an RFC, the "must not" in the last sentence should be capitalized)= . > >>> > >>> Thanks, Ross > >>> > >>> -----Original Message----- > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, > >>> Mustapha > >>> (Mustapha) > >>> Sent: Tuesday, August 19, 2014 3:19 AM > >>> To: mpls@ietf.org > >>> Cc: mpls-chairs@tools.ietf.org; > >>> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >>> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 > >>> (short wglc > >>> closed) > >>> > >>> Dear all, > >>> The following are the details of the issue we found and the > >>> proposed solution. We shared this first with the authors to get initi= al feedback. > >>> > >>> When an LSR which supports LDP IPv6 according to this draft is in > >>> a LAN with a broadcast interface, it can peer with LSRs which > >>> support this draft and LSRs which do not. When it peers using IPv4 > >>> LDP control plane with an LSR which does not support this draft, > >>> we have seen during our testing an issue that the advertisement of > >>> IPv6 addresses or IPv6 FECs to that peer will cause it to bring > >>> down the IPv4 LDP > session. > >>> > >>> In other words, there are deployed LDP implementations which are > >>> compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC > >>> 5036 when it comes to handling IPv6 address or IPv6 FECs over an > >>> LDP IPv4 > session. > >>> This is making us very concerned that when users enable dual-stack > >>> LDP IPv4/IPv6, they will bring down LDP IPv4 sessions which have > >>> been working in a multi-vendor environments for so many years. > >>> > >>> The proposed solution is to have implementations complying to this > >>> draft advertise the IPv6 prefix state advertisement control > >>> capability > >>> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization > >>> message explicitly indicating support for LDP IPv6. Without the > >>> peer advertising this capability, an LSR must not send IPv6 > >>> addresses and FECs to that peer. > >>> > >>> This approach is safer and has been followed when mLDP FEC was > >>> introduced as explained in Section 2.1 of RFC 6388. Also, this > >>> does not introduce any new TLV to draft-ietf-mpls-ldp-ipv6. It > >>> just makes the exchange of LDP IPv6 addresses and FECs conditional > >>> to both peers explicitly indicating support for IPv6 capability > >>> during LDP session > initialization. > >>> > >>> We do not feel such a simple change justifies writing a new draft > >>> and having to deal with backward compatibility of implementations > >>> across two drafts. > >>> > >>> We appreciate your comments on this matter. > >>> > >>> Regards, > >>> Mustapha. > >>> > >>> > >>>> -----Original Message----- > >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > >>>> Andersson > >>>> Sent: Tuesday, August 12, 2014 11:45 AM > >>>> To: mpls@ietf.org; mpls-chairs@tools.ietf.org<= mailto:mpls-chairs@tools.ietf.org>; > >>>> draft-ietf-mpls-ldp-ipv6@tools.ietf.org > >>>> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short > >>>> wglc > >>>> closed) > >>>> > >>>> Working Group, > >>>> > >>>> During what we thought would be a short wglc on > >>>> draft-ietf-mpls-ldp-ipv6 > >>>> http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html > >>>> we had a comment that stopped us from continuing progressing the dra= ft. > >>>> > >>>> The short working group last call is now closed! > >>>> > >>>> The comment we refer to was raised in a private mail to the > >>>> working group chairs and the draft authors. > >>>> > >>>> It says that there are a problem with some RFC 5036 non-compliant > >>>> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is > >>>> no detailed description of the exact problems. > >>>> > >>>> We strongly encourage the people that made the comment(s) to > >>>> write-up the problem, either as > >>>> > >>>> - a new draft (preferred); or > >>>> - in a mail to the working group mailing list > >>>> > >>>> Once we an agreement to write a new draft or the write-up to the > >>>> mailing, we will continue to ask the working group to see if we > >>>> can agree to a way to progress. We like to see this write-up > >>>> before September 1. Failing this we will continue to progress the > >>>> draft-ietf-mpls-ldp-ipv6 as is. > >>>> > >>>> /Loa > >>>> for the working group chairs > >>>> -- > >>>> > >>>> > >>>> 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 > >>> > >>> _______________________________________________ > >>> 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 --_000_ABD110CD5D879A4BB51C269846E4CA3117F912SG70YWXCHMBA08zap_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

I second to Mustaph= a. We should use features for what they are designed for. It is the SAC cap= ability (draft-ietf-mpls-ldp-ip-pw-capability-07) that defines the negotiation of IPV4/IPV6 Prefix FEC Capabilities in LDP session, which= fits into the required inter-op solution organically.

 

I do not consider e= xplicit advertisement of IPv6 Prefix FEC SAC (D =3D 0) in Initialization me= ssage can be seen as baggage. An implementation that does not want to receive IPv6 Prefix FECs will send D=3D1 in Initialization mes= sage anyways.

 

Cheers,<= /span>

Pranjal<= /span>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (= Mustapha)
Sent: Tuesday, September 02, 2014 11:57 AM
To: Rajiv Asati (rajiva)
Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls= -ldp-ipv6@tools.ietf.org
Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc cl= osed)

 

Hi Rajiv,

I think the key point I am trying to convey is th= at we should keep the protocol clean and use features for what they are des= igned for. LDP has its own capability advertisement and it is meant to addr= ess issues like this one.

 

Overloading the TR field of the initialization me= ssage means that a peer will have to check both the TR and the SAC to decid= e what to do for the IPv6 prefix FEC while it is sufficient to check the SA= C for all other FEC types. This is inconsistent and will cause an unnecessary exception in the protocol.=

 

Also, using the LDP advertisement capability is n= ot a baggage in the future. This mechanism is used with mLDP P2P and MP2MP = FECs and this is working fine today although many implementations now suppo= rt these types of FECs.

 

As for changing other drafts, we are simply talki= ng about stating in draft-ietf-mpls-ldp-ip-pw-capability-07 that an LDP pee= r must set D-bit=3D0  in IPv6 prefix FEC SAC in the initialization mes= sage.

 

Regards,

Mustapha.

 

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

> From: Rajiv Asati (rajiva) [m= ailto:rajiva@cisco.com]

> Sent: Saturday, August 30, 2014 7:19 AM=

> To: Aissaoui, Mustapha (Mustapha)=

> Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org;

> draft-ietf-mpls-ldp- ipv6@tools.ietf.org

> Subject: Re: [mpls] Way to progress draft-ie= tf-mpls-ldp-ipv6 (short

> wglc closed)

>

> Hi Mustapha,

>

> TR field is useful in case of dual-stack env= ironment and using it for

> determining whether the peer implementation = is compliant (wrt handling

> v6 address bindings and label bindings) is s= imple and straight forward.

>

> When v6-only peer implementations exist (and= become a new norm), TR

> field usage would become moot. And we wouldn= 't have to see them. A

> very good thing, IMO.

>

> We need to think about how much of this bagg= age needs to carry over

> when single- stack ipv6 networks become a ne= w norm (like single-stack ipv4 has been).

>

> Given that this draft already has built-in m= eans to accommodate the

> RFC5036 non- compliant peer issue and do so = in a simple manner, it is

> not necessary to require changing other draf= ts, IMO.

>

>

> Cheers,

> Raj

>

>

> PS; While there are multiple types of FECs, = and it would be wise to

> dictate the default behavior (v6 FECs advert= ised) in v6-only

> environment with an option to change it. Thi= s is nothing different from current protocol machinery.

>

>

> > On Aug 29, 2014, at 8:25 PM, "Aiss= aoui, Mustapha (Mustapha)"

> <mu= stapha.aissaoui@alcatel-lucent .com> wrote:

> >

> > Hi Rajiv,

> > See inline below for some follow-up.

> >

> > Regards,

> > Mustapha.

> >

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

> >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]

> >> Sent: Wednesday, August 27, 2014 7:= 19 PM

> >> To: Ross Callon; Aissaoui, Mustapha= (Mustapha); mpls@ietf.org<= /a>

> >> Cc: mpls-c= hairs@tools.ietf.org;

> >> draft-ietf-mpls-ldp-i= pv6@tools.ietf.org

> >> Subject: Re: [mpls] Way to progress= draft-ietf-mpls-ldp-ipv6 (short

> >> wglc closed)

> >>

> >>

> >> If this draft were to address the i= nteroperability with rfc5036

> >> non-compliant implementations, then= it would be easier to rather

> >> leverage the =8Ctransport preferenc= e=B9 TLV that is already part of the version 13.

> >> This TLV was defined after the gett= ing Adrian's and George=B9s feedback.

> >>

> >> http://tools.ietf.org= /html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.

> >> 1

> > MA> It is not a good idea to overloa= d this new TLV with a capability

> > MA> advertisement

> role. LDP has its own capability advertiseme= nt mechanism and there is

> no need to confuse implementations with the = handling of two mechanisms.

> >

> >> The reason for not agreeing to the = alternate solution (of using IP

> >> Prefix capability

> >> etc.) is 2-fold:

> >>

> >> - not forward compatible (consider = a deployment 5 yrs from now -

> >> IPv6-only MPLS network - now, the L= SR will be expecting an

> >> unnecessary IPv6 prefix capability = advertisement, and that=B9s not

> >> optimal, if not annoying)

> > MA> IPv6-only network is not synonym= ous with a single FEC type

> > MA> network. It will

> support many types of FECs  in addition= to the IPv6 prefix FEC: mLDP

> IPv6 FECs, PW FECs, IPv4 prefix FEC, etc. Th= e LDP capabilities have

> been designed for the purpose of explicitly = enabling or disabling

> capabilities including FEC type support on a= given session.

> >

> >> - not 100% backward compatible (doe= s not solve the advertisement of

> >> v6 address binding to a v4 neighbor= (which can also cause an outage

> >> to a non-compliant peer))

> > MA> I think it makes sense to tie th= e exchange of both IPv6 address

> > MA> messages

> and IPv6 prefix FECs to the advertisement of= the IPv6 capability by

> both peers. If however there is a use case f= or decoupling the

> advertising of IPv6 addresses from

> IPv6 FECs, then a separate capability can be= devised for addresses but

> I do not think we need it.

> >

> >

> >> Thanks.

> >>

> >>

> >> --

> >> Cheers,

> >> Rajiv Asati

> >> Distinguished Engineer, Cisco<= /o:p>

> >>

> >>

> >>

> >>

> >>

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

> >> From: Ross Callon <rcallon@juniper.net>

> >> Date: Friday, August 22, 2014 at 4:= 34 PM

> >> To: Mustapha Aissaoui <mustapha.aissaoui@alcatel-lucent.com= >,

> >> "mpls@ietf.org" <mpls@ietf.org>

> >> Cc: "= mpls-chairs@tools.ietf.org" <mp= ls-chairs@tools.ietf.org>,

> >> "draft-ietf-mpls-ldp-ipv6@tools.ietf.org"

> >> <draft-ietf-mpls-ldp-ipv6@tools.ietf.org>

> >> Subject: RE: [mpls] Way to progress= draft-ietf-mpls-ldp-ipv6 (short

> >> wglc

> >> closed)

> >> Resent-From: <draft-alias-bounces@tools.ietf.org>=

> >> Resent-To: Carlos Pignataro <cpignata@cisco.com>, Rajiv Papneja

> >> <rajiv.pa= pneja@huawei.com>, Rajiv Asati <rajiva@cisc= o.com>, Vishwas

> >> Manral <vish= was.manral@hp.com>, <= swallow@cisco.com>, Loa Andersson

> >> <loa@pi.nu>= ;, Ross Callon <rcallon@juniper.net>, MARTIN VIGOUREUX

> >> <martin.vigoureux@alcatel-lucent.com>

> >> Resent-Date: Friday, August 22, 201= 4 at 4:35 PM

> >>

> >>>> The proposed solution is to= have implementations complying to

> >>>> this draft advertise the IP= v6 prefix state advertisement control

> >>>> capability

> >>>> (draft-ietf-mpls-ldp-ip-pw-= capability-07) in the initialization

> >>>> message explicitly indicati= ng support for LDP IPv6. Without the

> >>>> peer advertising this capab= ility, an LSR must not send IPv6

> >>>> addresses and FECs to that = peer.

> >>>

> >>> Speaking as an individual contr= ibutor, this seems IMHO to be the

> >>> right solution (noting that, in= final text as would be published

> >>> in an RFC, the "must not&q= uot; in the last sentence should be capitalized).

> >>>

> >>> Thanks, Ross

> >>>

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

> >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui,

> >>> Mustapha

> >>> (Mustapha)

> >>> Sent: Tuesday, August 19, 2014 = 3:19 AM

> >>> To: mpls@ietf.org

> >>> Cc: mp= ls-chairs@tools.ietf.org;

> >>> draft-ietf-mpls-ldp-i= pv6@tools.ietf.org

> >>> Subject: Re: [mpls] Way to prog= ress draft-ietf-mpls-ldp-ipv6

> >>> (short wglc

> >>> closed)

> >>>

> >>> Dear all,

> >>> The following are the details o= f the issue we found and the

> >>> proposed solution. We shared th= is first with the authors to get initial feedback.

> >>>

> >>> When an LSR which supports LDP = IPv6 according to this draft is in

> >>> a LAN with a broadcast interfac= e, it can peer with LSRs which

> >>> support this draft and LSRs whi= ch do not. When it peers using IPv4

> >>> LDP control plane with an LSR w= hich does not support this draft,

> >>> we have seen during our testing= an issue that the advertisement of

> >>> IPv6 addresses or IPv6 FECs to = that peer will cause it to bring

> >>> down the IPv4 LDP

> session.

> >>>

> >>> In other words, there are deplo= yed LDP implementations which are

> >>> compliant to RFC 5036 for LDP I= Pv4 but are not compliant to RFC

> >>> 5036 when it comes to handling = IPv6 address or IPv6 FECs over an

> >>> LDP IPv4

> session.

> >>> This is making us very concerne= d that when users enable dual-stack

> >>> LDP IPv4/IPv6, they will bring = down LDP IPv4 sessions which have

> >>> been working in a multi-vendor = environments for so many years.

> >>>

> >>> The proposed solution is to hav= e implementations complying to this

> >>> draft advertise the IPv6 prefix= state advertisement control

> >>> capability

> >>> (draft-ietf-mpls-ldp-ip-pw-capa= bility-07) in the initialization

> >>> message explicitly indicating s= upport for LDP IPv6. Without the

> >>> peer advertising this capabilit= y, an LSR must not send IPv6

> >>> addresses and FECs to that peer= .

> >>>

> >>> This approach is safer and has = been followed when mLDP FEC was

> >>> introduced as explained in Sect= ion 2.1 of RFC 6388. Also, this

> >>> does not introduce any new TLV = to draft-ietf-mpls-ldp-ipv6. It

> >>> just makes the exchange of LDP = IPv6 addresses and FECs conditional

> >>> to both peers explicitly indica= ting support for IPv6 capability

> >>> during LDP session

> initialization.

> >>>

> >>> We do not feel such a simple ch= ange justifies writing a new draft

> >>> and having to deal with backwar= d compatibility of implementations

> >>> across two drafts.

> >>>

> >>> We appreciate your comments on = this matter.

> >>>

> >>> Regards,

> >>> Mustapha.

> >>>

> >>>

> >>>> -----Original Message-----<= o:p>

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

> >>>> Andersson

> >>>> Sent: Tuesday, August 12, 2= 014 11:45 AM

> >>>> To: mpls@ietf.o= rg; mpls-chairs@tools.ietf.org;

> >>>> draft-ietf-mpls-ldp-i= pv6@tools.ietf.org

> >>>> Subject: [mpls] Way to prog= ress draft-ietf-mpls-ldp-ipv6 (short

> >>>> wglc

> >>>> closed)

> >>>>

> >>>> Working Group,

> >>>>

> >>>> During what we thought woul= d be a short wglc on

> >>>> draft-ietf-mpls-ldp-ipv6

> >>>> http://www.ietf.org/m= ail-archive/web/mpls/current/msg12464.html

> >>>> we had a comment that stopp= ed us from continuing progressing the draft.

> >>>>

> >>>> The short working group las= t call is now closed!

> >>>>

> >>>> The comment we refer to was= raised in a private mail to the

> >>>> working group chairs and th= e draft authors.

> >>>>

> >>>> It says that there are a pr= oblem with some RFC 5036 non-compliant

> >>>> implementations deployed an= d draft-ietf-mpls-ldp-ipv6. There is

> >>>> no detailed description of = the exact problems.

> >>>>

> >>>> We strongly encourage the p= eople that made the comment(s) to

> >>>> write-up the problem, eithe= r as

> >>>>

> >>>> - a new draft (preferred); = or

> >>>> - in a mail to the working = group mailing list

> >>>>

> >>>> Once we an agreement to wri= te a new draft or the write-up to the

> >>>> mailing, we will continue t= o ask the working group to see if we

> >>>> can agree to a way to progr= ess. We like to see this write-up

> >>>> before September 1. Failing= this we will continue to progress the

> >>>> draft-ietf-mpls-ldp-ipv6 as= is.

> >>>>

> >>>> /Loa

> >>>> for the working group chair= s

> >>>> --

> >>>>

> >>>>

> >>>> Loa Andersson  &n= bsp;            = ;         email: loa@mail01.huawei.com=

> >>>> Senior MPLS Expert &nb= sp;            =             loa@pi.nu<= o:p>

> >>>> Huawei Technologies (consul= tant)     phone: +46 739 81 21 64

> >>>>

> >>>> ___________________________= ____________________

> >>>> mpls mailing list

> >>>> mpls@ietf.org

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

> >>>

> >>> _______________________________= ________________

> >>> mpls mailing list

> >>> mpls@ietf.org

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

> >

 

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.iet= f.org/mailman/listinfo/mpls

--_000_ABD110CD5D879A4BB51C269846E4CA3117F912SG70YWXCHMBA08zap_-- From nobody Wed Sep 3 17:00: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 17EAD1A6F70 for ; Wed, 3 Sep 2014 17:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 LZK29h8AIOCN for ; Wed, 3 Sep 2014 17:00:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518F41A6F10 for ; Wed, 3 Sep 2014 17:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4596; q=dns/txt; s=iport; t=1409788842; x=1410998442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vA6TK2ssoIvk1aZHACcf9xCJ87g/9iPaHn6DWKuP2wM=; b=I8JUEFnlJwHkxiEarwKYmiQaJv9PtBYzhNC+kg2gs8xIV/A4Wk89749e fgDQnCk13pOVI891poBCJnGdI1LSmu72tky6FxDbvyWxP66zrUJDCCCXK Qyr1uBWNZw3OtkaPw8NVciBmCzTkwTmdQgd+ykN8d7+/LmfOGwePBKkiD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAJuqB1StJA2G/2dsb2JhbABZgkdGgS7QIQGBDBZ3hAMBAQEEJwZBCxACAQgECgMDAQIoBzIUCQgCBAENBYhCvi4BF488EQeETAWPHoIUiyuVHoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,461,1406592000"; d="scan'208,217";a="352418652" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 04 Sep 2014 00:00:41 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8400fTs027783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 00:00:41 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 19:00:41 -0500 From: "Tarek Saad (tsaad)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPx9NE9t8SC8sHsE2irSizJfKcPg== Date: Thu, 4 Sep 2014 00:00:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [161.44.212.239] Content-Type: multipart/alternative; boundary="_000_D02D1CE912FF17tsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/i2VU0izbdqjktwOedvFEE2qhQMA Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 04 Sep 2014 00:00:44 -0000 --_000_D02D1CE912FF17tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support this draft. The proposed new LSP ping/trace reply mode is useful for the initiator to i= ndicate the response to come back on the reverse LSP path (without addition= al path TLV). The ordered list of reply modes is also useful as a flexible (per request) = list of reply modes to be visited when otherwise the response may fail if t= he only requested reply mode becomes invalid=97 hence this extension decrea= ses chance of false failures. Minor comment in section 1: to minimizes -> to minimize Regards, Tarek From: Ross Callon > Date: Wednesday, August 20, 2014 at 11:20 AM To: "mpls@ietf.org" > Cc: "'mpls-chairs@tools.ietf.org'" > Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_D02D1CE912FF17tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I support this draft.

The proposed new LSP ping/trace reply mode is useful for the initiator= to indicate the response to come back on the reverse LSP path (without add= itional path TLV).
The ordered list of reply modes is also useful as a flexible (per requ= est) list of reply modes to be visited when otherwise the response may fail= if the only requested reply mode becomes invalid=97 hence this extension d= ecreases chance of false failures.

Minor comment in section 1:
to minimizes -> to minimize

Regards,
Tarek

From: Ross Callon <rcallon@juniper.net>
Date: Wednesday, August 20, 2014 at= 11:20 AM
To: "mpls@ietf.org" <mpls@i= etf.org>
Cc: "'mpls-chairs@tools.ietf.org'" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Poll for Adoption d= raft-akiya-mpls-lsp-ping-reply-mode-simple-02

This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping= -reply-mode-simple-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working gr= oup
mailing list (mpls@ietf.org).
 
This poll will end Thursday September 4, 2014.
 
Thanks, Ross
 
--_000_D02D1CE912FF17tsaadciscocom_-- From nobody Wed Sep 3 17:02: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 0B3581A8771; Wed, 3 Sep 2014 17:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 BExp1s7PStnd; Wed, 3 Sep 2014 17:00:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDD31A8774; Wed, 3 Sep 2014 17:00:51 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d6-54075420e4cd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.4A.25146.02457045; Wed, 3 Sep 2014 19:47:12 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 3 Sep 2014 20:00:48 -0400 From: Gregory Mirsky To: "Tissa Senevirathne (tsenevir)" , "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1wAT/fSeA= Date: Thu, 4 Sep 2014 00:00:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82A71B@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPiK5CCHuIwZnPphZ7t71ktXj87RC7 xa2lK1kt5l9sZLV4Ol/S4vOfbYwWxy/8ZrSYt+sDk0X3j6dsDpweU35vZPVYsuQnk8eXy5/Z ApijuGxSUnMyy1KL9O0SuDI2N35iLFg9k6ni+6JNTA2MbZ8Yuxg5OSQETCT+v5rFBGGLSVy4 t56ti5GLQ0jgKKPE5kvrWCCcZYwSB3bMYAOpYhMwknixsYcdJCEi0M8o8X7eHbAqZoFGJonv 19+zglQJC6hIPD9wFqxDREBVYn/jf2YI20ri69K1YPtYgGpe/rkIVs8r4CuxZM9OJoh1Exgl Pk3pBDuQEyjR3PuKBcRmBDrw+6k1YM3MAuISt57MhzpcAKj5PDOELSrx8vE/VghbSWLS0nOs EPX5Et/mr2GGWCYocXLmE5YJjKKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIW X8DIvoqRo7Q4tSw33chwEyMwXo9JsDnuYFzwyfIQowAHoxIP7wJWthAh1sSy4srcQ4zSHCxK 4rya1fOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCqXGqU6FRI+tmWLxsSXHN667dHG45/ 9eFZlH50qa/4yZkP54qqVa1yWmghkj9rxn+xvszlHfcuJ9oeqDyjtWIyJ7uI2gKXAxz35i46 d3zD9CfTtqukPRT43fr/ytGwAIFHljZcDd+8BYVur89YnGbL5cO/vuJKiM/hikdePHdsnygz eDX/+q6kxFKckWioxVxUnAgAY9KYUbgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VWY8aMHz3UDFZy7wwThhbYGmMjY Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] draft-tissa-netmod-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: Thu, 04 Sep 2014 00:01:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tissa, thank you for detailed and informative response. Information about OAM work= at TRILL WG is very interesting as I haven't been following it in much det= ails. I'd note that applicability of the model developed at TRILL WG to MPL= S OAM is not clear to me. I think that it would be helpful to discuss relev= ance of the TRILL's OAM model at MPLS and MPLS technology related WGs befor= e presenting it as the model that encompasses MPLS. Similarly, I think, for= the IP. Perhaps, for the time, we can refer to the model as TRILL OAM. Mor= e notes in-lined and tagged GIM>>. Regards, Greg From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] Sent: Thursday, August 28, 2014 8:24 AM To: Gregory Mirsky; 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: RE: draft-tissa-netmod-oam Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@iet= f.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. GIM>> I don't have "favorite tool" but would point that in connectionless n= etwork one cannot define Mis-connection defect and thus OAM models for con= nectionless and connection-oriented networks would be different. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. GIM>> LSP Ping does more that ICMP or CFM's Loopback and Linktrace as it ve= rifies correlation between control and data planes. Had that functionality = been removed by TRILL OAM from "extended CFM model"? o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " GIM>> Had other WGs agreed that the proposed by TRILL WG OAM model is repre= sentative of their technologies? If not, then what "Generic" is there? * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. GIM>> Is IP MEP being defined as being in control plane/CPU? What if it is = in NPU, i.e. data plane? If on CPU, then what differentiates Up MEP from Do= wn MEP from POV of packets it transmits and receives? And how MIP functions= in IP based on TRILL OAM model? Is it, as in Ethernet OAM, constructed of = two MHFs? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tissa,

thank you for detailed= and informative response. Information about OAM work at TRILL WG is very i= nteresting as I haven’t been following it in much details. I’d = note that applicability of the model developed at TRILL WG to MPLS OAM is not clear to me. I think that it would be helpful = to discuss relevance of the TRILL’s OAM model at MPLS and MPLS techno= logy related WGs before presenting it as the model that encompasses MPLS. S= imilarly, I think, for the IP. Perhaps, for the time, we can refer to the model as TRILL OAM. More notes in-lined = and tagged GIM>>.

 

   &nbs= p;            Regard= s,

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

 

From: Tissa Se= nevirathne (tsenevir) [mailto:tsenevir@cisco.com]
Sent: Thursday, August 28, 2014 8:24 AM
To: Gregory Mirsky; 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: RE: draft-tissa-netmod-oam

 

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; = time@ietf.org; 'netmod@ietf.org'; nvo3= @ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

GIM>> I don̵= 7;t have “favorite tool” but would point that in connectionless= network one cannot define Mis-connection defect and thus OAM models for &n= bsp;connectionless and connection-oriented networks would be different.

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

 

GIM>> LSP Ping d= oes more that ICMP or CFM’s Loopback and Linktrace as it verifies cor= relation between control and data planes. Had that functionality been remov= ed by TRILL OAM from “extended CFM model”?

 

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

GIM>> Had other = WGs agreed that the proposed by TRILL WG OAM model is representative of the= ir technologies? If not, then what “Generic” is there?

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

GIM>> Is IP MEP = being defined as being in control plane/CPU? What if it is in NPU, i.e. dat= a plane? If on CPU, then what differentiates Up MEP from Down MEP from POV = of packets it transmits and receives? And how MIP functions in IP based on TRILL OAM model? Is it, as in Ethernet OA= M, constructed of two MHFs?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_-- From nobody Wed Sep 3 17:18: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 DB9B91A6EFE for ; Wed, 3 Sep 2014 17:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NJNsJVoeyhhu for ; Wed, 3 Sep 2014 17:18:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078981A0AE4 for ; Wed, 3 Sep 2014 17:18:32 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-68-54075ab1297a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 96.B8.05330.1BA57045; Wed, 3 Sep 2014 20:15:13 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Wed, 3 Sep 2014 20:18:30 -0400 From: Gregory Mirsky To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPx9NN5ejHL/oufU61MLxwUVdDO5vwGtzg Date: Thu, 4 Sep 2014 00:18:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82A77B@eusaamb103.ericsson.se> References: In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1121B82A77Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonXHdjFHuIwYI1JhbfLy1hsbi1dCWr xd8VV1gcmD2WLPnJ5HG96Sq7x5fLn9kCmKO4bFJSczLLUov07RK4MrpfTmcu2O5UsahxK3MD 42frLkZODgkBE4mlMx4xQ9hiEhfurWfrYuTiEBI4yijx/eJ8RghnGaPEm66HjCBVbAJGEi82 9rCD2CICbhJz+k8wgdjMAvYSp7rvsoDYwgJhEttvPWKFqAmXWL5lEiOEbSTxa+VTsG0sAioS d3YtZQOxeQV8JS7tfQvWKyRQKXHv9mOgGg4OTgE9ieuHuEHCjEDHfT+1BmqVuMStJ/OZII4W kFiy5zzUA6ISLx//Y4WwlSQmLT3HCjKGWSBf4tUnM4hNghInZz5hmcAoOgvJpFkIVbOQVEGU 6Egs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAqPsmASb7g7GPS8tDzEK cDAq8fAuYGULEWJNLCuuzD3EKM3BoiTOO6t2XrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xviz1xR11uQqsi1q6f40/fsJvv7Jy2oX/975cfWiKebB9xRKJIJOZ4RzvUm0a3pZPcPB08xJ kqdcaavMkdaJhj0zjB4Yzvq8WqbEuSeZ8/PUO8pb7WVub51whY+9KvRy0ZVXgk5uRz60Wn07 91Nvl7jiHwOWhr5A8ST+6BTBtaxTFq/MD+nnUGIpzkg01GIuKk4EAAToiwuTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/U2jfzY8Of5j90jDXulo4S1kX3uM Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 04 Sep 2014 00:18:35 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82A77Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I support WG adoption of this work. In my view it proposes useful tool for an operator to expedite meaningful m= onitoring and/or troubleshooting by reducing probability of possible false = negative result. Regards, Greg From: Ross Callon > Date: Wednesday, August 20, 2014 at 11:20 AM To: "mpls@ietf.org" > Cc: "'mpls-chairs@tools.ietf.org'" > Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_7347100B5761DC41A166AC17F22DF1121B82A77Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

I support WG adoption of = this work.

In my view it proposes us= eful tool for an operator to expedite meaningful monitoring and/or troubles= hooting by reducing probability of possible false negative result.

 <= /p>

    &= nbsp;           Regards,<= o:p>

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

 

From: Ross Callon <rcallon@juniper.net>
Date: Wednesday, August 20, 2014 at 11:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: "'mpls-chair= s@tools.ietf.org'" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week= poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simple-02=

as an MPLS working group do= cument.

 

Please send your comments (= support/not support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday= September 4, 2014.

 

Thanks, Ross

 

--_000_7347100B5761DC41A166AC17F22DF1121B82A77Beusaamb103erics_-- From nobody Thu Sep 4 02:54: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 C9FBE1A0203 for ; Thu, 4 Sep 2014 02:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 NLGO4nkwPYvk for ; Thu, 4 Sep 2014 02:54:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E031A0117 for ; Thu, 4 Sep 2014 02:54:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BME17400; Thu, 04 Sep 2014 09:54:31 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 10:54:31 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 17:54:25 +0800 From: "Dongjie (Jimmy)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5ALmw1oA Date: Thu, 4 Sep 2014 09:54:24 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273370F2A9@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273370F2A9nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NINHaCEOanHKf8b_zhb_v9pkMrg Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 04 Sep 2014 09:54:36 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273370F2A9nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've read this draft and think it provides a useful tool for better monitor= ing and troubleshooting in MPLS networks. Best regards, Jie From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, August 20, 2014 11:21 PM To: mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_76CD132C3ADEF848BD84D028D243C9273370F2A9nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I’ve= read this draft and think it provides a useful tool for better monitoring = and troubleshooting in MPLS networks.

 = ;

Best regar= ds,

Jie

 = ;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 PM
To: mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two w= eek poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group= document.

 =

Please send your comment= s (support/not support) to the mpls working group

mailing list (mpls@ietf.org).

 =

This poll will end Thurs= day September 4, 2014.

 =

Thanks, Ross<= /span>

 =

--_000_76CD132C3ADEF848BD84D028D243C9273370F2A9nkgeml512mbxchi_-- From nobody Thu Sep 4 06:07: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 50AD31A8893 for ; Thu, 4 Sep 2014 06:06:56 -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, HTML_MESSAGE=0.001, 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 GYo1ogwD_Kfe for ; Thu, 4 Sep 2014 06:06:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050A91A88A6 for ; Thu, 4 Sep 2014 06:06:53 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB627.namprd05.prod.outlook.com (10.141.204.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 13:06:50 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.1019.015; Thu, 4 Sep 2014 13:06:50 +0000 From: John E Drake To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+8ilRUv/hpET0IRlGIeWYgr95o5ALtpi8A Date: Thu, 4 Sep 2014 13:06:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199003)(164054003)(377454003)(4396001)(87936001)(77982001)(105586002)(74502001)(230783001)(2656002)(19580395003)(19300405004)(74662001)(86362001)(19625215002)(46102001)(79102001)(92566001)(99396002)(76482001)(83322001)(20776003)(33646002)(99286002)(81542001)(76576001)(19580405001)(1941001)(83072002)(106356001)(108616004)(76176999)(95666004)(54356999)(80022001)(101416001)(15202345003)(90102001)(64706001)(81342001)(50986999)(16236675004)(31966008)(85852003)(85306004)(21056001)(74316001)(2501002)(66066001)(107046002)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB627; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_c6e33e6dee374131929892817ccda22fBLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZLgx3nZFtLaR3q9oFIeKlDvB5Co Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 04 Sep 2014 13:06:56 -0000 --_000_c6e33e6dee374131929892817ccda22fBLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of the 03 version of the subject draft. It provides= useful operational flexibility. Yours Irrespectively, John From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, August 20, 2014 8:21 AM To: mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_c6e33e6dee374131929892817ccda22fBLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption of= the 03 version of the subject draft.  It provides useful operational = flexibility.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: mpls [= mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 8:21 AM
To: mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.=

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

--_000_c6e33e6dee374131929892817ccda22fBLUPR05MB562namprd05pro_-- From nobody Thu Sep 4 08:08: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 C81131A8796 for ; Thu, 4 Sep 2014 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8pC-hvmmXTa9 for ; Thu, 4 Sep 2014 08:08:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416811A88FB for ; Thu, 4 Sep 2014 08:08:14 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4D1CA2AC7EA; Thu, 4 Sep 2014 17:08:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 105C7158082; Thu, 4 Sep 2014 17:08:12 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 17:08:11 +0200 From: To: Ross Callon , "'mpls-chairs@tools.ietf.org'" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPx9NN5ejHL/oufU61MLxwUVdDO5vwGtzggADzfaA= Date: Thu, 4 Sep 2014 15:08:11 +0000 Message-ID: <12729_1409843292_5408805C_12729_6345_1_53C29892C857584299CBF5D05346208A071EE16E@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <7347100B5761DC41A166AC17F22DF1121B82A77B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82A77B@eusaamb103.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A071EE16EPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.4.103924 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SsRVq7vwFjtzSWDI5oo_ec8z4gc Cc: "mpls@ietf.org" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 04 Sep 2014 15:08:24 -0000 --_000_53C29892C857584299CBF5D05346208A071EE16EPEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I support this draft. It's benefit increase as the number of reply mode increase (which is a typi= cal trend). Thanks, Regards, Bruno From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, September 04, 2014 2:19 AM To: Ross Callon; mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 Dear All, I support WG adoption of this work. In my view it proposes useful tool for an operator to expedite meaningful m= onitoring and/or troubleshooting by reducing probability of possible false = negative result. Regards, Greg From: Ross Callon > Date: Wednesday, August 20, 2014 at 11:20 AM To: "mpls@ietf.org" > Cc: "'mpls-chairs@tools.ietf.org'" > Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A071EE16EPEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 <= /p>

I support = this draft.

It’s= benefit increase as the number of reply mode increase (which is a typical = trend).

 = ;

Thanks,

Regards,

Bruno=

 = ;

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, September 04, 2014 2:19 AM
To: Ross Callon; mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

Dear All,<= o:p>

I support = WG adoption of this work.

In my view= it proposes useful tool for an operator to expedite meaningful monitoring = and/or troubleshooting by reducing probability of possible false negative result.

 = ;

 &nbs= p;            &= nbsp; Regards,

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

 <= /o:p>

From: Ross Callon <rcallon@juniper.net>
Date: Wednesday, August 20, 2014 at 11:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: "'mpls-chair= s@tools.ietf.org'" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 <= /o:p>

This is to s= tart a two week poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simpl= e-02

as an MPLS w= orking group document.

 <= /o:p>

Please send = your comments (support/not support) to the mpls working group

mailing list= (mpls@ietf.org).

 <= /o:p>

This poll wi= ll end Thursday September 4, 2014.

 <= /o:p>

Thanks, Ross=

 <= /o:p>

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A071EE16EPEXCVZYM11corpo_-- From nobody Thu Sep 4 08:26: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 2B6441A88CC; Thu, 4 Sep 2014 08:26:17 -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 T1ExD7cQXsJZ; Thu, 4 Sep 2014 08:26:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095F1A033E; Thu, 4 Sep 2014 08:26:15 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904152615.5753.22234.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 08:26:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xe895TcPQhaVaKis82tvyBHAA1Y Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-01.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, 04 Sep 2014 15:26:17 -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 : RFC6374 UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-ietf-mpls-rfc6374-udp-return-path-01.txt Pages : 8 Date : 2014-09-04 Abstract: This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc6374-udp-return-path-01 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 Fri Sep 5 06:03:16 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 6B3821A016A for ; Fri, 5 Sep 2014 06:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 A1pbbEgPxvuw for ; Fri, 5 Sep 2014 06:03:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC3D1A0111 for ; Fri, 5 Sep 2014 06:03:03 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 566811900B8; Fri, 5 Sep 2014 15:03:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 3A007C8084; Fri, 5 Sep 2014 15:03:01 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 15:03:00 +0200 From: To: "mpls@ietf.org" , "Nobo Akiya (nobo)" Thread-Topic: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: Ac/I3NBe/9xEsa0FTUaOUQSDRUmfig== Date: Fri, 5 Sep 2014 13:02:59 +0000 Message-ID: <22701_1409922181_5409B485_22701_1961_1_53C29892C857584299CBF5D05346208A071EF2E8@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A071EF2E8PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.16.70918 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qAYrbdzSI7jxVEbMNOldtbW0MB8 Subject: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 05 Sep 2014 13:03:10 -0000 --_000_53C29892C857584299CBF5D05346208A071EF2E8PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs a= nd TP LSPs". I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC = stack TLV (e.g. L1, L2 ... Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3... Ln) c. Get the ingress to local segment list/path by subtracting both sta= cks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For nod= e segments, keep them unchanged, for adjacency segment, use the reverse adj= acency. This is computationally very simple and but requires the IGP metric= to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that's already the cas= e for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/"pre POP" the initial adjacency label). To address = this, the ingres router could indicate this initial adjacency label in the = Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A071EF2E8PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

*) Short version (use case):

draft-akiya-mpls-lsp-ping-reply= -mode-simple defines a new Reply mode for MPLS LSP Ping: “Reply via r= everse LSP”, with an applicability to “RSVP LSPs and TP LSPs= 221;.

I have the rough impression tha= t this mode would also be very applicable in SPRING networks/LSPs since the= responder would be able send the reply along the same (reverse)/co-routed = path than the requester.

Could this be investigated? (on= the mailing list or in either of the above 2 drafts).

 

*) Long version (proposed solut= ion):

a) &nbs= p;    The responder is/should= be able to get/infer the incoming path

a= .   &= nbsp;   Get the end to end segm= ent list/path a priori from the Target FEC stack TLV (e.g. L1, L2 … L= n)

b= .   &= nbsp;  Get the local to end se= gment list/path from the label stack in the received packet (e.g. L3…= Ln)

c= .   &= nbsp;   Get the ingress to loca= l segment list/path by subtracting both stacks (e.g. L1, L2)

b) &nbs= p;    Using SR, the responder= is able to enforce any explicit path, so in particular the reverse path fr= om local to ingress. 2 options for this:

a= .   &= nbsp;   Simple one: reverse the= order of the segments in the path. For node segments, keep them unchanged,= for adjacency segment, use the reverse adjacency. This is computationally = very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse direction.<= o:p>

b= .   &= nbsp;  Exact one: compute the = exact forward path (SPF rooted on the sender then follow the segments stack= ).Then reverse the path and compute the list of segments required to enforc= e this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segment). This is com= putationally more expensive but enforces the same path in all cases. (seems= a bit scary from a DOS perspective, to use significant control plane resou= rces in response to a forwarding plane packet, but in essence, that’s already the case for ping/traceroute)=

I = guess that the choice could be a local choice on the responder, configured = by the SP (e.g. depending on its use of asymmetric IGP costs)

 

A priori this would be applicab= le to both MPLS ping and traceroute.

 

Caveats:

1) restricted to a single IGP a= rea. But this is a usual limitation of TE in a multi-area network. (and typ= ical solution may also apply e.g. PCE)

2) The spring ingress router ma= y have pushed the packet on a non shortest path interface (i.e. PHP/”= pre POP” the initial adjacency label). To address this, the ingres ro= uter could indicate this initial adjacency label in the Target FEC stack of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A071EF2E8PEXCVZYM11corpo_-- From nobody Fri Sep 5 09:14: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 B267A1A071D for ; Fri, 5 Sep 2014 09:14:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EU63S_gj1yjA for ; Fri, 5 Sep 2014 09:14:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCA91A0375 for ; Fri, 5 Sep 2014 09:14:20 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 5 Sep 2014 16:14:17 +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.1015.018; Fri, 5 Sep 2014 16:14:17 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPySRx4o8bUYRo/U6p0JsAYJHXXg== Date: Fri, 5 Sep 2014 16:14:17 +0000 Message-ID: <3e3137b6ccc44996bf53c9e25152b492@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(189002)(199003)(164054003)(18717965001)(87936001)(77982001)(66066001)(19609705001)(15975445006)(64706001)(81342001)(86362001)(92566001)(80022001)(83072002)(85852003)(76482001)(79102001)(2656002)(81542001)(15202345003)(19300405004)(19625215002)(83322001)(4396001)(21056001)(76576001)(19580395003)(19580405001)(46102001)(99396002)(105586002)(99286002)(95666004)(74316001)(90102001)(2501002)(106116001)(106356001)(101416001)(85306004)(76176999)(50986999)(230783001)(108616004)(33646002)(20776003)(74662001)(74502001)(16236675004)(54356999)(110136001)(31966008)(107046002)(2351001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3e3137b6ccc44996bf53c9e25152b492CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/L-KO00v0IgDy52sX3fqPavL9YMQ Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 05 Sep 2014 16:14:26 -0000 --_000_3e3137b6ccc44996bf53c9e25152b492CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This poll for adoption has been closed - and we have a new working group document. Can the author please re-post the document (the most recent -03 version) as draft-ietf-mpls-lsp-ping-reply-mode-simple-00 without any other changes than file name, version and dates. After this is posted, the authors should deal with the various comments rec= eived following normal WG processes. The authors might also want to note (f= or example, in deciding when to post an update) that we have requested a ro= uting area QA team review of the document, and we are expecting a review to= appear relatively shortly. However, posting the -00 version of the working= group document can be done immediately and should not wait for the QA revi= ew. Thanks, Ross (as mpls wg co-chair) From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, August 20, 2014 11:21 AM To: mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_3e3137b6ccc44996bf53c9e25152b492CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group,=

 <= /p>

This poll for adoption ha= s been closed - and we have a new working group

document.

 <= /p>

Can the author please re-= post the document (the most recent -03 version) as

 <= /p>

     = draft-ietf-mpls-lsp-ping-reply-mode-simple-00

 <= /p>

without any other changes= than file name, version and dates.

 <= /p>

After this is posted, the= authors should deal with the various comments received following normal WG= processes. The authors might also want to note (for example, in deciding when to post an update) that we have requested a routing area = QA team review of the document, and we are expecting a review to appear rel= atively shortly. However, posting the -00 version of the working group docu= ment can be done immediately and should not wait for the QA review.

 <= /p>

Thanks, Ross

(as mpls wg co-chair)

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, August 20, 2014 11:21 AM
To: mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week poll on ado= pting draft-akiya-mpls-lsp-ping-reply-mode-simple-02

as an MPLS working group document.=

 

Please send your comments (support/not = support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday September 4= , 2014.

 

Thanks, Ross

 

--_000_3e3137b6ccc44996bf53c9e25152b492CO2PR05MB636namprd05pro_-- From nobody Fri Sep 5 13:21: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 11A551A010D for ; Fri, 5 Sep 2014 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] 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 kGIUUbu9uxtZ for ; Fri, 5 Sep 2014 13:21:30 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 053FC1A010A for ; Fri, 5 Sep 2014 13:21:29 -0700 (PDT) Received: (qmail 5205 invoked by uid 0); 5 Sep 2014 20:21:24 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 5 Sep 2014 20:21:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id neMF1o00d2SSUrH01eMJLT; Fri, 05 Sep 2014 20:21:23 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=4kc_xtrGfg0A:10 a=HFCU6gKsb0MA:10 a=jZ44FGKI4aMA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=GRd5rHI3PBnbKcUc_ncA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=L8IAqmEDyZCU2YtML/tEO9n1fvoi+hmEhFGesO20DJU=; b=Zo/x+VOIGjRqQdId2LjAP3xOs01rlb1QKp3dztKQBOJOJ8Xk8Nv+ScjVX5Jox754lAc785a+MaxcQulXA2jB7zjzJzYttfSKAHVHH8SQnXnc7p3yq+PdAlRslESWa8+K; Received: from box313.bluehost.com ([69.89.31.113]:54830 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XQ00S-0005o6-QN; Fri, 05 Sep 2014 14:21:16 -0600 Message-ID: <540A1B48.7020504@labn.net> Date: Fri, 05 Sep 2014 16:21:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rNf___aOdFVHLKSvcsTh2x_nyBc Cc: mpls@ietf.org Subject: [mpls] QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 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, 05 Sep 2014 20:21:31 -0000 Hello, I've been asked to do a QA review of this draft. Overall it looks like a solid, well written document, and more than reasonable -00 WG document. I have some technical nits/comments/questions that I think can be addressed as part of normal WG process: Section 3.1 - "Reverse LSP is in relation to the last FEC specified in the Target FEC Stack TLV." I think I understand this statement for the egress, but what about at transit nodes? Perhaps just drop the sentence? - Missing "in the range of" in the last sentence of the section. Section 3.2 - The phrasing of 4 is a bit stricter than I think you mean with respect to use of Reply Mode field. One could read it as saying that a value carried in the field can't be used even when it is in the Order TLV, as well as precluding its use described in the subsequent requirement (5). Perhaps just rephrase to say that it is only used after any mode included in the ordered TLV is excluded/invalid/unavailable. -I think the document should be explicit about ordering relationship of the reply modes listed in the Order TLV and to the order of paths included in other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV. (Yes it should obvious, but it is a potential interop issue) - Section 4.1.1 o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner, particularly when considering non-draft supporting implementations, to use multiple Reply Path TLVs (one per possible reply path)? That's it, Lou From nobody Fri Sep 5 17:14: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 7135F1A0694 for ; Fri, 5 Sep 2014 17:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 jjxkMPCOUbdy for ; Fri, 5 Sep 2014 17:14:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558251A06A3 for ; Fri, 5 Sep 2014 17:14:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 512E5C5454FEA for ; Sat, 6 Sep 2014 00:14:46 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s860EnNd026481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Sep 2014 02:14:50 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 6 Sep 2014 02:14:49 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "mpls@ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPyTTwmHwq2PONZ0CRrFtcWs5uIJvzBwRA Date: Sat, 6 Sep 2014 00:14:48 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832344C52F@FR711WXCHMBA07.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF832344C52FFR711WXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wpq3PtOwnVwPQboPSFooCPWoKUY Subject: [mpls] FW: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 06 Sep 2014 00:14:55 -0000 --_000_84675BAA8C49154AB81E2587BE8BDF832344C52FFR711WXCHMBA07z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIGFza2VkIHRvIGRvIGEgcHJlbGltaW5hcnkgcmV2aWV3IG9m IHRoaXMgZHJhZnQuIEhlcmUgYmVsb3cgbXkgY29tbWVudHMgZm9yIGRpc2N1c3Npb246DQoNCkZy b206IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwg U2VwdGVtYmVyIDA1LCAyMDE0IDg6MTIgUE0NClRvOiBQYXBhZGltaXRyaW91LCBEaW1pdHJpIChE aW1pdHJpKQ0KQ2M6IEJSVU5HQVJELCBERUJPUkFIIEE7IExvYSBBbmRlcnNzb247IHJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBWSUdPVVJFVVgsIE1B UlRJTiAoTUFSVElOKTsgZHJhZnQtdHNhYWQtbXBscy1wMm1wLWxvb3NlLXBhdGgtcmVvcHRAdG9v bHMuaWV0Zi5vcmc7IEpvbmF0aGFuIEhhcmR3aWNrIChKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dp dGNoLmNvbSkNClN1YmplY3Q6IFJlOiBSVEctRElSIHJldmlldyByZXF1ZXN0ZWQgLSBGd2Q6IHBv bGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXRzYWFkLW1wbHMtcDJt cC1sb29zZS1wYXRoLXJlb3B0IGFuIG1wbHMgd2cgZG9jDQoNCkRtaXRyaSwNCg0KVGhhbmtzIGZv ciBkb2luZyB0aGUgcmV2aWV3ISAgIENvdWxkIHlvdSBwbGVhc2Ugc2VuZCBpdCB0byB0aGUgTVBM UyBtYWlsaW5nIGxpc3QgZm9yIGRpc2N1c3Npb24/DQoNClJlZ2FyZHMsDQpBbGlhDQoNCk9uIE1v biwgQXVnIDI1LCAyMDE0IGF0IDg6NDUgQU0sIFBhcGFkaW1pdHJpb3UsIERpbWl0cmkgKERpbWl0 cmkpIDxkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpkaW1p dHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQpIZWxsbywNCg0K SGVyZSBpcyBteSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudDoNCg0KVGhlIHN0YXRlbWVudCAibm90 aWZpY2F0aW9uIG9mIHByZWZlcnJlZCBwYXRoIGV4aXN0cyBmb3IgYSBzaW5nbGUgUzJMIHN1Yi1M U1Agb25seS4iIGFuZCB3aGF0IGNvbWVzIGluIFNlY3Rpb24gMyBvZiB0aGlzIGRvY3VtZW50IGlz IHF1ZXN0aW9uYWJsZQ0KDQppKSB0aGVyZSBpcyBhIG1vZGUgb2Ygb3BlcmF0aW9uIGFscmVhZHkg aW5jbHVkZWQgaW4gUkZDIDQ4NzUgd2hpY2ggYWxsb3dzIHN1Y2ggcmVvcmdhbml6YXRpb24gYnkg c3ViLWdyb3VwIElEIGNmLiBTZWN0aW9uIDE0LjIuICJTdWItR3JvdXAtQmFzZWQgUmUtT3B0aW1p emF0aW9uLiIgSXQgbG9va3MgYXMgYW4gb3Zlci1yZWFkaW5nIHRvIHN0YXRlIHRoaXMgbWV0aG9k IGlzIGxpbWl0ZWQgb24gcGVyLXN1Yi1MU1AgYmFzaXMsIHRoYXQgc2VjdGlvbiBzdGF0ZXMgY2xl YXJseQ0KDQoiMTQuMi4gIFN1Yi1Hcm91cC1CYXNlZCBSZS1PcHRpbWl6YXRpb24NCg0KICAgQW55 IG5vZGUgbWF5IGluaXRpYXRlIHJlLW9wdGltaXphdGlvbiBvZiBhIHNldCBvZiBTMkwgc3ViLUxT UHMgYnkgdXNpbmcgaW5jcmVtZW50YWwgc3RhdGUgdXBkYXRlIGFuZCB0aGVuLCBvcHRpb25hbGx5 LCBjb21iaW5pbmcNCiAgIG11bHRpcGxlIHBhdGggbWVzc2FnZXMuIg0KDQpUaGUgcHJvdG9jb2wg Zm9ybWF0IGNoYWluIGNhbiBiZSBmb3VuZCBoZXJlIGJlbG93IHRvIHNlZSBwb3NzaWJpbGl0eSBm b3IgZ2VuZXJhdGluZyBzdWNoIHJlcXVlc3QgdmlhIG5vdGlmaWNhdGlvbjoNCg0KICAgPG5vdGlm eSBzZXNzaW9uIGxpc3Q+ICAgICAgIDo6PSBbIDxub3RpZnkgc2Vzc2lvbiBsaXN0PiBdDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx1cHN0cmVhbSBub3RpZnkgc2Vzc2lvbj4g fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZG93bnN0cmVhbSBub3RpZnkg c2Vzc2lvbj4NCg0KICAgPHVwc3RyZWFtIG5vdGlmeSBzZXNzaW9uPiAgIDo6PSA8U0VTU0lPTj4g WyA8QURNSU5fU1RBVFVTPiBdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFs8 UE9MSUNZX0RBVEE+Li4uXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c2Vu ZGVyIGRlc2NyaXB0b3I+DQoNCg0KICAgPHNlbmRlciBkZXNjcmlwdG9yPiA6Oj0gPFNFTkRFUl9U RU1QTEFURT4gPFNFTkRFUl9UU1BFQz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFsgPEFEU1BFQz4gXQ0KDQogICBXaXRoOg0KDQogICAgICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgSVB2NCB0dW5uZWwg c2VuZGVyIGFkZHJlc3MgICAgICAgICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAg fCAgICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgTFNQIElEICAgICAg ICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgIFN1Yi1H cm91cCBPcmlnaW5hdG9yIElEICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgIHwgICAgICAgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIFN1Yi1H cm91cCBJRCAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpJIHJlYWQgYmVoaW5kIHRoaXMgZHJh ZnQgdGhhdCB0aGlzIG5ldyBtb2RlIG9mIG9wZXJhdGlvbiAodGhlIGZhY3Qgc3VicGF0aHMgImFy ZSBsb29zZSBvciBhYnN0cmFjdCBob3AgZXhwYW5kZWQiIGRvZXNuJ3QgY2hhbmdlIHRoZSBnZW5l cmFsIGNvbW1lbnQpIG1lYW5zIHNvbWUgd291bGQgcHJlZmVyIGFsaWdubWVudCB3aXRoIFAyUCBy ZS1vcHRpbWl6YXRpb24gYW5kIG9wZXJhdGUgb3V0c2lkZSBpbmNyZW1lbnRhbCBzdGF0ZSB1cGRh dGUgLS1pbnRyb2R1Y2VkIGZvciBzY2FsaW5nIHJlYXNvbnMuIEluIGFueSBjYXNlLCB0aGUganVz dGlmaWNhdGlvbi9tb3RpdmF0aW9uIGZvciB0aGlzIG1vZGUgb2Ygb3BlcmF0aW9uIGlzIG1pc3Np bmcgaW4gdGhlIGRvY3VtZW50Lg0KDQppaSkgd2l0aCBQYXRoRXJyIGFzIGRlZmluZWQgaW4gUkZD IDQ4NzUgaXQgaW5jbHVkZXMgYSBbIDxTMkwgc3ViLUxTUCBkZXNjcmlwdG9yIGxpc3Q+IF0gdGh1 cywgaXQgaXMgZXZlbiBsZXNzIGNsZWFyIHdoeSBvbmUgd291bGQgbGlrZSB0byBtb3ZlIHdpdGgg b3IgbW9yZSBnZW5lcmFsbHkgc2lnbmFsaW5nIGl0IGRpZmZlcmVudGx5ICgiUmVxdWVzdCBmbGFn cyIgaW5zdGVhZCBvZiBhICJjb2RlIikgd291bGQgcHJldmVudCBhcyBtZW50aW9uZWQgaW4gW1JG QzQ4NzVdIFNlY3Rpb24gMTQuMiwgdGhhdCDigJxzdWItR3JvdXAtYmFzZWQgcmUtb3B0aW1pemF0 aW9uIG1heSByZXN1bHQgaW4gdHJhbnNpZW50IGRhdGEgZHVwbGljYXRpb24gYXMgdGhlIG5ldyBQ YXRoIG1lc3NhZ2VzIGZvciBhIHNldCBvZiBTMkwgc3ViLUxTUHMgbWF5IHRyYW5zaXQgb25lIG9y IG1vcmUgbm9kZXMgd2l0aCB0aGUgb2xkIFBhdGggc3RhdGUgZm9yIHRoZSBzYW1lIHNldCBvZiBT Mkwgc3ViLUxTUHMu4oCdDQoNClRoZSBwcm9wb3NlZCBkcmFmdCBkb2VzbuKAmXQgc29sdmUgY2Fz ZXMgd2hlcmUgdGhpcyB3b3VsZCBvY2N1ciwgYW5kIG9uIHRoZSBvdGhlciwgdGhlIGNhc2VzIGl0 IGNvdmVycyBhcmUgYWxyZWFkeSBieSBSRkMgNDg3NSAocmUtb3B0aW1pemUgYSBsb29zZSBzZXQg ZnJvbSBhIHNpbmdsZSBicmFuY2hpbmcgcG9pbnQgaXMgYWxyZWFkeSBjb3ZlcmVkKS4NCg0KTWFu eSB0aGFua3MsDQotZGltaXRyaS4NCg0KDQo= --_000_84675BAA8C49154AB81E2587BE8BDF832344C52FFR711WXCHMBA07z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyIsInNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBo YXZlIGJlZW4gYXNrZWQgdG8gZG8gYSBwcmVsaW1pbmFyeSByZXZpZXcgb2YgdGhpcyBkcmFmdC4g SGVyZSBiZWxvdyBteSBjb21tZW50cyBmb3IgZGlzY3Vzc2lvbjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWEgQXRsYXMgW21haWx0bzph a2F0bGFzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAw NSwgMjAxNCA4OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBQYXBhZGltaXRyaW91LCBEaW1pdHJpIChE aW1pdHJpKTxicj4NCjxiPkNjOjwvYj4gQlJVTkdBUkQsIERFQk9SQUggQTsgTG9hIEFuZGVyc3Nv bjsgcnRnLWFkc0B0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IFZJ R09VUkVVWCwgTUFSVElOIChNQVJUSU4pOyBkcmFmdC10c2FhZC1tcGxzLXAybXAtbG9vc2UtcGF0 aC1yZW9wdEB0b29scy5pZXRmLm9yZzsgSm9uYXRoYW4gSGFyZHdpY2sgKEpvbmF0aGFuLkhhcmR3 aWNrQG1ldGFzd2l0Y2guY29tKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUlRHLURJUiByZXZp ZXcgcmVxdWVzdGVkIC0gRndkOiBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFr ZSBkcmFmdC10c2FhZC1tcGxzLXAybXAtbG9vc2UtcGF0aC1yZW9wdCBhbiBtcGxzIHdnIGRvYzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG1pdHJpLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBkb2lu ZyB0aGUgcmV2aWV3ISAmbmJzcDsgQ291bGQgeW91IHBsZWFzZSBzZW5kIGl0IHRvIHRoZSBNUExT IG1haWxpbmcgbGlzdCBmb3IgZGlzY3Vzc2lvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsaWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIEF1ZyAyNSwgMjAxNCBhdCA4OjQ1IEFNLCBQYXBhZGltaXRyaW91LCBEaW1p dHJpIChEaW1pdHJpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpbWl0cmkucGFwYWRpbWl0cmlvdUBh bGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaW1pdHJpLnBhcGFkaW1pdHJpb3VA YWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5I ZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkhlcmUgaXMgbXkgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQ6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5UaGUgc3RhdGVtZW50ICZxdW90O25vdGlmaWNhdGlvbiBvZiBwcmVmZXJyZWQgcGF0aCBl eGlzdHMgZm9yIGEgc2luZ2xlIFMyTCBzdWItTFNQIG9ubHkuJnF1b3Q7IGFuZCB3aGF0IGNvbWVz IGluIFNlY3Rpb24gMyBvZiB0aGlzIGRvY3VtZW50IGlzIHF1ZXN0aW9uYWJsZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ aSkgdGhlcmUgaXMgYSBtb2RlIG9mIG9wZXJhdGlvbiBhbHJlYWR5IGluY2x1ZGVkIGluIFJGQyA0 ODc1IHdoaWNoIGFsbG93cyBzdWNoIHJlb3JnYW5pemF0aW9uIGJ5IHN1Yi1ncm91cCBJRCBjZi4g U2VjdGlvbiAxNC4yLiAmcXVvdDtTdWItR3JvdXAtQmFzZWQgUmUtT3B0aW1pemF0aW9uLiZxdW90 OyBJdCBsb29rcw0KIGFzIGFuIG92ZXItcmVhZGluZyB0byBzdGF0ZSB0aGlzIG1ldGhvZCBpcyBs aW1pdGVkIG9uIHBlci1zdWItTFNQIGJhc2lzLCB0aGF0IHNlY3Rpb24gc3RhdGVzIGNsZWFybHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZxdW90OzE0LjIuJm5ic3A7IFN1Yi1Hcm91cC1CYXNlZCBSZS1PcHRpbWl6YXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbnkgbm9kZSBtYXkgaW5pdGlhdGUgcmUtb3B0aW1p emF0aW9uIG9mDQo8Yj48dT5hIHNldCBvZiBTMkwgc3ViLUxTUHMgPC91PjwvYj5ieSB1c2luZyBp bmNyZW1lbnRhbCBzdGF0ZSB1cGRhdGUgYW5kIHRoZW4sIG9wdGlvbmFsbHksIGNvbWJpbmluZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbXVsdGlwbGUgcGF0aCBt ZXNzYWdlcy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBwcm90b2NvbCBmb3JtYXQgY2hhaW4gY2FuIGJl IGZvdW5kIGhlcmUgYmVsb3cgdG8gc2VlIHBvc3NpYmlsaXR5IGZvciBnZW5lcmF0aW5nIHN1Y2gg cmVxdWVzdCB2aWEgbm90aWZpY2F0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7ICZsdDtub3Rp Znkgc2Vzc2lvbiBsaXN0Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6 Oj0gWyAmbHQ7bm90aWZ5IHNlc3Npb24gbGlzdCZndDsgXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3Vwc3RyZWFtIG5v dGlmeSBzZXNzaW9uJmd0OyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZG93bnN0cmVhbSBub3RpZnkgc2Vzc2lvbiZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyAmbHQ7dXBzdHJlYW0gbm90aWZ5IHNlc3Npb24mZ3Q7 Jm5ic3A7Jm5ic3A7IDo6PSAmbHQ7U0VTU0lPTiZndDsgWyAmbHQ7QURNSU5fU1RBVFVTJmd0OyBd PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBbJmx0O1BPTElDWV9EQVRBJmd0Oy4uLl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtzZW5kZXIgZGVzY3Jp cHRvciZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsgJmx0O3NlbmRlciBkZXNjcmlwdG9yJmd0OyA6Oj0gJmx0O1NFTkRFUl9URU1Q TEFURSZndDsgJmx0O1NFTkRFUl9UU1BFQyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsgJmx0O0FEU1BFQyZn dDsgXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdpdGg6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJUHY0IHR1bm5lbCBzZW5kZXIgYWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExTUCBJRCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdWItR3JvdXAgT3JpZ2luYXRvciBJRCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1Yi1Hcm91cCBJRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBy ZWFkIGJlaGluZCB0aGlzIGRyYWZ0IHRoYXQgdGhpcyBuZXcgbW9kZSBvZiBvcGVyYXRpb24gKHRo ZSBmYWN0IHN1YnBhdGhzICZxdW90O2FyZSBsb29zZSBvciBhYnN0cmFjdCBob3AgZXhwYW5kZWQm cXVvdDsgZG9lc24ndCBjaGFuZ2UgdGhlIGdlbmVyYWwgY29tbWVudCkgbWVhbnMgc29tZSB3b3Vs ZCBwcmVmZXINCiBhbGlnbm1lbnQgd2l0aCBQMlAgcmUtb3B0aW1pemF0aW9uIGFuZCBvcGVyYXRl IG91dHNpZGUgaW5jcmVtZW50YWwgc3RhdGUgdXBkYXRlIC0taW50cm9kdWNlZCBmb3Igc2NhbGlu ZyByZWFzb25zLiBJbiBhbnkgY2FzZSwgdGhlIGp1c3RpZmljYXRpb24vbW90aXZhdGlvbiBmb3Ig dGhpcyBtb2RlIG9mIG9wZXJhdGlvbiBpcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPmlpKSB3aXRoIFBhdGhFcnIgYXMgZGVmaW5lZCBpbiBSRkMgNDg3NSBpdCBpbmNsdWRlcyBh IFsgJmx0O1MyTCBzdWItTFNQIGRlc2NyaXB0b3IgbGlzdCZndDsgXSB0aHVzLCBpdCBpcyBldmVu IGxlc3MgY2xlYXIgd2h5IG9uZSB3b3VsZCBsaWtlIHRvIG1vdmUgd2l0aCBvciBtb3JlIGdlbmVy YWxseSBzaWduYWxpbmcNCiBpdCBkaWZmZXJlbnRseSAoJnF1b3Q7UmVxdWVzdCBmbGFncyZxdW90 OyBpbnN0ZWFkIG9mIGEgJnF1b3Q7Y29kZSZxdW90Oykgd291bGQgcHJldmVudCBhcyBtZW50aW9u ZWQgaW4gW1JGQzQ4NzVdIFNlY3Rpb24gMTQuMiwgdGhhdCDigJxzdWItR3JvdXAtYmFzZWQgcmUt b3B0aW1pemF0aW9uIG1heSByZXN1bHQgaW4gdHJhbnNpZW50IGRhdGEgZHVwbGljYXRpb24gYXMg dGhlIG5ldyBQYXRoIG1lc3NhZ2VzIGZvciBhIHNldCBvZiBTMkwgc3ViLUxTUHMgbWF5IHRyYW5z aXQgb25lIG9yDQogbW9yZSBub2RlcyB3aXRoIHRoZSBvbGQgUGF0aCBzdGF0ZSBmb3IgdGhlIHNh bWUgc2V0IG9mIFMyTCBzdWItTFNQcy7igJ0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUgcHJvcG9zZWQgZHJhZnQg ZG9lc27igJl0IHNvbHZlIGNhc2VzIHdoZXJlIHRoaXMgd291bGQgb2NjdXIsIGFuZCBvbiB0aGUg b3RoZXIsIHRoZSBjYXNlcyBpdCBjb3ZlcnMgYXJlIGFscmVhZHkgYnkgUkZDIDQ4NzUgKHJlLW9w dGltaXplIGEgbG9vc2Ugc2V0IGZyb20gYSBzaW5nbGUgYnJhbmNoaW5nDQogcG9pbnQgaXMgYWxy ZWFkeSBjb3ZlcmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk1hbnkgdGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4tZGltaXRyaS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_84675BAA8C49154AB81E2587BE8BDF832344C52FFR711WXCHMBA07z_-- From nobody Fri Sep 5 17:39: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 141461A06CF for ; Fri, 5 Sep 2014 17:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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.668, 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 hEEXF1zI2Zdp for ; Fri, 5 Sep 2014 17:38:58 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CE51A06CB for ; Fri, 5 Sep 2014 17:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25919; q=dns/txt; s=iport; t=1409963939; x=1411173539; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=rplZEPTkzkLObXC1UaOwskkb9hchXCUgWztKYiUMRxk=; b=F+vFN3PKuhT83o6FCqg51RxRr11tXMC6Mheo/Y/FHacXQEXu71zAxDaA bILJbtmNzlfSX56zI3ZXGgLWnkFMQjjlY5OVhQDI8RulLqe8ch1V8FwoK Jd1k3xCla1UyiijnXm6Pr1TzzthfVWO5QW2H0gymtnx2SnWO6TxIz5pog M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGZWClStJV2b/2dsb2JhbABagkdGgSoE0GgBgQQWd4QDAQIELUELEgEIEQMBAiEDBDkUCQgCBAENBYhCv0UBF451LQcTEQYBBoRGBY8pghWLLpUmghuBRmyBBkKBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,477,1406592000"; d="scan'208,217"; a="75457976" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 06 Sep 2014 00:38:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s860cvpb029898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 00:38:57 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 19:38:57 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Tarek Saad (tsaad)" , "Papadimitriou, Dimitri (Dimitri)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAA== Date: Sat, 6 Sep 2014 00:38:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.240.29] Content-Type: multipart/alternative; boundary="_000_D02FCEBF39889rgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NchWhVeC-RZgGxJLkkz131HAw_I Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 06 Sep 2014 00:39:02 -0000 --_000_D02FCEBF39889rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D02FCEBF39889rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <74D9DA7F99FECE46B68C5FD25105FD25@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi WG,

Forwarding following reply from Tarek to the MPLS mailing list.

Thanks Tarek and Dimitri.

Regards,
Rakesh


From: "Tarek Saad (tsaad)"= ; <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:4= 2 PM
To: "Papadimitriou, Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>, DEBORAH BRUNGARD <<= a href=3D"mailto:db3546@att.com">db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, &qu= ot;mpls-chairs@tools.ietf.org= " <mpls-chairs@tools.ietf.o= rg>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-m= pls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.= com)" <Jona= than.Hardwick@metaswitch.com>
Subject: Re: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc


Hi Dimitri,

Thanks much for reviewing the draft and for your feedback. Please see inlin= e..

From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:= 45 AM
To: "BRUNGARD, DEBORAH A"= <db3546@att.com>, Loa Andersso= n <loa@pi.nu>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.= com)" <Jona= than.Hardwick@metaswitch.com>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc
Hello,
 
Here is my review of this document:
 
The statement "notification of preferred path exists for a single= S2L sub-LSP only." and what comes in Section 3 of this document is qu= estionable
 
i) there is a mode of operation already included in RFC 4875 which all= ows such reorganization by sub-group ID cf. Section 14.2. "Sub-Group-B= ased Re-Optimization." It looks as an over-reading to state this metho= d is limited on per-sub-LSP basis, that section states clearly
 
"14.2.  Sub-Group-Based Re-Optimization
 
   Any node may initiate re-optimization of a set of S= 2L sub-LSPs by
   using incremental state update and then, optionally, comb= ining
   multiple path messages."

[TS]: the draft is in agreement of t= he above statement from rfc4875 and this is called out in the draft (below)= with the shortcoming mentioned in section 14.2 for duplication of traffic = in certain cases.
"The ingress LSR that receives = (un)solicited PathErr notification(s)
   for individual S2L sub-= LSP(s), may prematurely start re-optimizing
   the sub-set of S2= L sub-LSPs.  However, as mentioned in [RFC4875]
   Section 14.2, such re-o= ptimization procedure may result in data duplication
" 
The make-before-break reoptimization= method as described in rfc4875 section 14.1 avoids the former duplication = problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Curren= tly, there=92s no explicit way for a mid-LSR to notify the ingress to trigger this specific mode of reoptimizat= ion-- short of possibly re-using the PERR code/subcode for =93preferable pa= th exists=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PER= R sent back to the ingress. However, as mentioned in rfc4875, an LSR may fr= agment such signalled messages (e.g. when a single message may not be large= enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 
We also believe having a sub-set of = S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR is useful= to explicitly trigger the sub-group based reoptimization mode described in= section 14.2.

In other cases, a PATH message that = is intended to carry the =93path re-evaluation=94 flag =97 as defined defin= ed in rfc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor= list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over same next-hop w= ill be propagated in the descriptor list of the PATH message propagated to = downstream mid-LSRs.. Consequently, when a preferable path exists at such m= id-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case c= an unambiguously use it to distinguish which LSP mode of reoptimization to = invoke.

 
The protocol format chain can be found here below to see possibility f= or generating such request via notification:
 
   <notify session list>     =   ::=3D [ <notify session list> ]
           &nbs= p;            &= nbsp;          <upstream no= tify session> |
           &nbs= p;            &= nbsp;          <downstream = notify session>
 
   <upstream notify session>   ::=3D <SES= SION> [ <ADMIN_STATUS> ]
           &nbs= p;            &= nbsp;          [<POLICY_DAT= A>...]
           &nbs= p;            &= nbsp;          <sender desc= riptor>
 
 
   <sender descriptor> ::=3D <SENDER_TEMPLATE> &= lt;SENDER_TSPEC>
           &nbs= p;            &= nbsp;           [ <ADS= PEC> ]
 
   With:
 
       0     &n= bsp;            = ; 1            =        2      &= nbsp;            3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+
      |      &n= bsp;            IPv4= tunnel sender address         = ;         |
      +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+
      |       R= eserved           &n= bsp;    |        &nb= sp;   LSP ID         = ;    |
      +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+
      |      &n= bsp;            Sub-= Group Originator ID         &n= bsp;           |
      +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+
      |       R= eserved           &n= bsp;    |        &nb= sp;   Sub-Group ID       |
      +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+
 
I read behind this draft that this new mode of operation (the fact sub= paths "are loose or abstract hop expanded" doesn't change the gen= eral comment) means some would prefer alignment with P2P re-optimization an= d operate outside incremental state update --introduced for scaling reasons. In any case, the justification/motivatio= n for this mode of operation is missing in the document.
 
ii) with PathErr as defined in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]
thus, it is even less clear why one would like to move with or more ge= nerally signaling it differently ("Request flags" instead of an &= quot;code") would prevent as mentioned in [RFC4875] Section 14.2, that= sub-Group-based re-optimization may result in transient data
duplication as the new Path messages for a set of S2L sub-LSPs may
transit one or more nodes with the old Path state for the same set of<= /div>
S2L sub-LSPs.=94
[TS]: Please see reply above for the first one.

Regards,
Tarek
 
The proposed draft doesn=92t solve cases where this would occur, and o= n the other, the cases it covers are already by RFC 4875 (re-optimize a loo= se set from a single branching point is already covered).
 
Many thanks,
-dimitri.
 

--_000_D02FCEBF39889rgandhiciscocom_-- From nobody Fri Sep 5 18:26: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 A82C31A0709 for ; Fri, 5 Sep 2014 18:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.168 X-Spam-Level: X-Spam-Status: No, score=-115.168 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.668, 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 3zfvATR5eQQ0 for ; Fri, 5 Sep 2014 18:26:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3911A0706 for ; Fri, 5 Sep 2014 18:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28632; q=dns/txt; s=iport; t=1409966767; x=1411176367; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QAVlEtaXu9uVxFHBFHGPww/ksDDhYWzljk63WYhA0xw=; b=fg5N42ILbpyqE4+ERGeUTq9+Nh/IvshJLmIQK5srY4WEywrkW5i686/d YWH4UkbRS5WgknDu2MAkrib0Z5hatth6E2kureC+D+N0GyYdUEd7gX9SM ysaG1EAEPiDMIa0TeCiMjOYMdCin5d+phymMRmBLca4Bu9yKmSNaULolm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIRhClStJA2I/2dsb2JhbABagkcjI1NXBNBpAYEEFneEAwEBAQQtPgMbAgEIEQQBAQsWAQYHMhQJCAEBBAESCBOIJwG/QwEXjmsRAR83AQaDKYEdBYp4hDGCFYZrmWmCG4FGbIEPOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,477,1406592000"; d="scan'208,217"; a="75462524" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 06 Sep 2014 01:26:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s861Q6an020597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 01:26:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 20:26:05 -0500 From: "Nobo Akiya (nobo)" To: "bruno.decraene@orange.com" , "mpls@ietf.org" Thread-Topic: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: Ac/I3NBe/9xEsa0FTUaOUQSDRUmfigAjuShQ Date: Sat, 6 Sep 2014 01:26:05 +0000 Message-ID: References: <22701_1409922181_5409B485_22701_1961_1_53C29892C857584299CBF5D05346208A071EF2E8@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <22701_1409922181_5409B485_22701_1961_1_53C29892C857584299CBF5D05346208A071EF2E8@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.70] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3C55E4xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GTuEZ5EFNr6A59vB1BpR8UdaYcg Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 06 Sep 2014 01:26:11 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C55E4xmbalnx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, I very much agree that the use case that you raised is useful for LSP Ping/= Trace on SPRING. In terms of how, there are few aspects that I'd like to highlight. 1. To accomplish MPLS Echo Reply messages taking a return path that mi= rrors the forward path, generally there are two approaches. a. Sender of MPLS Echo Request messages (initiator) to compute the mir= roring return path and include the information in the MPLS Echo Request. Th= is can be done via extending RFC7110. b. Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path (this is the logic you described in your email). 2. With the approach (1a), return path computation requires that the i= nitiator try to determine where the packet will terminate (thus incoming la= bel stack on that node). That will be ok in a stable state but can get prob= lematic when there are changes happening in the network (convergence, FRR).= Instead, I tend to think (and agree) the approach (1b) of the responder co= mputing the mirroring return path is superior. 3. I've heard some stories about folks wanting to do path association = on end-points in SPRING to create bi-directional "tunnels". These "tunnels"= will have a real reverse LSP. So the Reply Mode "reverse LSP" should apply= to such bi-directional "tunnels". 4. Thus to address this use case, I think we need a new Reply Mode def= ined instead of using Reply Mode "reverse LSP". 5. How do we preserve the forward segment stack in the MPLS Echo Reque= st? a. One way is for the entire segment stack to be described in the Targ= et FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is e= xpected normally is that Target FEC Stack shrinks as initiator receives "FE= C Stack Change with POP" from downstream LSRs. It's worth keeping this beha= vior. b. Another way is to introduce a new TLV that describes the entire seg= ment stack pushed by the initiator, and that can get used by the responder = along with the logic you described. In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a goo= d way to address the use case you raised. Logistically, these extensions (if we agree to extend) should be described = in draft-kumarkini-mpls-spring-lsp-ping. I would certainly like to hear from other experts on this matter as well. Thanks! -Nobo From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Friday, September 05, 2014 9:03 AM To: mpls@ietf.org; Nobo Akiya (nobo) Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls= -spring-lsp-ping Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs a= nd TP LSPs". I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC s= tack TLV (e.g. L1, L2 ... Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3... Ln) c. Get the ingress to local segment list/path by subtracting both stac= ks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For node= segments, keep them unchanged, for adjacency segment, use the reverse adja= cency. This is computationally very simple and but requires the IGP metric = to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that's already the cas= e for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/"pre POP" the initial adjacency label). To address = this, the ingres router could indicate this initial adjacency label in the = Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C55E4xmbalnx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

I very much agree that= the use case that you raised is useful for LSP Ping/Trace on SPRING.<= /o:p>

 

In terms of how, there= are few aspects that I’d like to highlight.

 

1.&n= bsp;     To accomplish = MPLS Echo Reply messages taking a return path that mirrors the forward path= , generally there are two approaches.

a. &nbs= p;    Sender of MPLS= Echo Request messages (initiator) to compute the mirroring return path and= include the information in the MPLS Echo Request. This can be done via ext= ending RFC7110.

b. &nbs= p;    Sender of MPLS= Echo Reply messages (responder) to compute the mirroring return path (this= is the logic you described in your email).

2.&n= bsp;     With the appro= ach (1a), return path computation requires that the initiator try to determ= ine where the packet will terminate (thus incoming label stack on that node= ). That will be ok in a stable state but can get problematic when there are changes happening in the network (c= onvergence, FRR). Instead, I tend to think (and agree) the approach (1b) of= the responder computing the mirroring return path is superior.<= /span>

3.&n= bsp;     I’ve hea= rd some stories about folks wanting to do path association on end-points in= SPRING to create bi-directional “tunnels”. These “tunnel= s” will have a real reverse LSP. So the Reply Mode “reverse LSP” should apply to such bi-directional “tunnels”.=

4.&n= bsp;     Thus to addres= s this use case, I think we need a new Reply Mode defined instead of using = Reply Mode “reverse LSP”.

5.&n= bsp;     How do we pres= erve the forward segment stack in the MPLS Echo Request?<= /p>

a. &nbs= p;    One way is for= the entire segment stack to be described in the Target FEC Stack TLV. Alth= ough when LSP Traceroute is done on SRPING, what is expected normally is th= at Target FEC Stack shrinks as initiator receives “FEC Stack Change with POP” from downstream LSRs. It&= #8217;s worth keeping this behavior.

b. &nbs= p;    Another way is= to introduce a new TLV that describes the entire segment stack pushed by t= he initiator, and that can get used by the responder along with the logic y= ou described.

 

In summary, my persona= l opinion will be (1b), new Reply Mode, (5b) is a good way to address the u= se case you raised.

 

Logistically, these ex= tensions (if we agree to extend) should be described in draft-kumarkini-mpl= s-spring-lsp-ping.

 

I would certainly like= to hear from other experts on this matter as well.

 

Thanks!

 

-Nobo

 

bruno= .decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Friday, September 05, 2014 9:03 AM
To: mpls@ietf.org; Nobo Akiya (nobo)
Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping

 

Hi all,

 

*) Short version (use case):

draft-akiya-mpls-lsp-ping-reply= -mode-simple defines a new Reply mode for MPLS LSP Ping: “Reply via r= everse LSP”, with an applicability to “RSVP LSPs and TP LSPs= 221;.

I have the rough impression tha= t this mode would also be very applicable in SPRING networks/LSPs since the= responder would be able send the reply along the same (reverse)/co-routed = path than the requester.

Could this be investigated? (on= the mailing list or in either of the above 2 drafts).

 

*) Long version (proposed solut= ion):

a)  = ;    The responder is/should= be able to get/infer the incoming path

a= .   &= nbsp;  Get the end to end segm= ent list/path a priori from the Target FEC stack TLV (e.g. L1, L2 … L= n)

b= .   &= nbsp;  Get the local to end se= gment list/path from the label stack in the received packet (e.g. L3…= Ln)

c= .   &= nbsp;  Get the ingress to loca= l segment list/path by subtracting both stacks (e.g. L1, L2)

b)  = ;    Using SR, the responder= is able to enforce any explicit path, so in particular the reverse path fr= om local to ingress. 2 options for this:

a= .   &= nbsp;  Simple one: reverse the= order of the segments in the path. For node segments, keep them unchanged,= for adjacency segment, use the reverse adjacency. This is computationally = very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse direction.<= o:p>

b= .   &= nbsp;  Exact one: compute the = exact forward path (SPF rooted on the sender then follow the segments stack= ).Then reverse the path and compute the list of segments required to enforc= e this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segment). This is com= putationally more expensive but enforces the same path in all cases. (seems= a bit scary from a DOS perspective, to use significant control plane resou= rces in response to a forwarding plane packet, but in essence, that’s already the case for ping/traceroute)=

I g= uess that the choice could be a local choice on the responder, configured b= y the SP (e.g. depending on its use of asymmetric IGP costs)

 

A priori this would be applicab= le to both MPLS ping and traceroute.

 

Caveats:

1) restricted to a single IGP a= rea. But this is a usual limitation of TE in a multi-area network. (and typ= ical solution may also apply e.g. PCE)

2) The spring ingress router ma= y have pushed the packet on a non shortest path interface (i.e. PHP/”= pre POP” the initial adjacency label). To address this, the ingres ro= uter could indicate this initial adjacency label in the Target FEC stack of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_CECE764681BE964CBE1DFF78F3CDD3943A3C55E4xmbalnx01ciscoc_-- From nobody Sat Sep 6 00:41: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 B3DAF1A0029; Sat, 6 Sep 2014 00:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 AQ4YoqN-RF32; Sat, 6 Sep 2014 00:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBE21A0013; Sat, 6 Sep 2014 00:41:18 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> Date: Sat, 06 Sep 2014 00:41:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S3gaRHbhzkovlsAaCAX0Tifp00Q Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-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: Sat, 06 Sep 2014 07:41:19 -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 Switched Path (LSP) Ping/Traceroute Reply Mode Simplification Authors : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Pages : 11 Date : 2014-09-05 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document adds one value to the Reply Mode field to indicate reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-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 Sat Sep 6 02:04: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 4F9621A017F for ; Sat, 6 Sep 2014 02:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.652] 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 p5zQD3_exm6J for ; Sat, 6 Sep 2014 02:04:38 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8E81A0178 for ; Sat, 6 Sep 2014 02:04:37 -0700 (PDT) Received: from [192.168.0.100] (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 CEF14180137F; Sat, 6 Sep 2014 11:04:35 +0200 (CEST) Message-ID: <540ACE28.2070201@pi.nu> Date: Sat, 06 Sep 2014 11:04:40 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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/Owfz3di8HQWfEN0l7vck4Nrzivk Cc: "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] The RTG area QA process in the 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: Sat, 06 Sep 2014 09:04:40 -0000 Working Group, We have started to see mails on the working group mailing list that originates from the document Quality Assurance (QA) process that the Routing ADs has started. Examples of such are: http://www.ietf.org/mail-archive/web/mpls/current/msg12782.html and http://www.ietf.org/mail-archive/web/mpls/current/msg12783.html The QA process involve a review from a member of the routing area directorate twice during the life time of a document, first at about the time a document is polled to become a working group document and a second time at working group last call. The routing area directorate member is also supposed to follow the document during it life time. We hope that this process will will contribute to improve the quality of the documents across the area. What we see with the two reviews above, if done in parallel to the wg adoption poll is that we may receive the reviews after the document has been adopted as a wg document. This is in itself not a real problem, we can address these comments as part of the normal working group process. However, we anticipate that the comments we get from the QA review is closer to what we get from the MPLS-RT reviews, i.e. first of all a recommendation if we should take the document to wg adoption poll + a set of comments that the authors very often want to address before starting the poll. We will therefore try to run the QA review at the same time as we run the MPLS-RT review. /Loa for the mpls wg 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 Sat Sep 6 06:58: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 401EC1A03C2 for ; Sat, 6 Sep 2014 06:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, 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 Zcx2yq2l8l35 for ; Sat, 6 Sep 2014 06:58:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD871A0306 for ; Sat, 6 Sep 2014 06:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3218; q=dns/txt; s=iport; t=1410011931; x=1411221531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gVCViUgorAH5mOzeRCzxSiQC0dKs4rQqpDSfxSPUVpg=; b=Jwrw66/+ITJBCBXvBKJDjsNsui66HJEuWP0wAywFcsaBKCdwl17Q2woZ QaMwx0TSJhl3OvK+V+HQlOUQoG8A9w7hXN+cxAoo6TbP7NpA5f2x9iW7u l8zcLUj4i92MmomLWv7b4yQkhI2gkiOSCjr/7Jrm1e7z/6AnV+hlU7ugV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAQSC1StJA2F/2dsb2JhbABZgmojU1cEyTIMh0oBgQAWd4QDAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEDgUIAYg5AQy+GAEXjxwxBwaDKYEdBY8pghWEMIhak0qDYWwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,479,1406592000"; d="scan'208";a="75551834" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 06 Sep 2014 13:58:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s86DwofG030011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 13:58:50 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.0195.001; Sat, 6 Sep 2014 08:58:50 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt Thread-Index: AQHPyaX7qUs104RkB0qetEn/yhEdopv0Iaww Date: Sat, 6 Sep 2014 13:58:49 +0000 Message-ID: References: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> In-Reply-To: <20140906074118.14965.93339.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.70] 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/AedIuae2iFEEmi-NqG7wEk8f9a0 Cc: "Ross Callon \(rcallon@juniper.net\)" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-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: Sat, 06 Sep 2014 13:58:53 -0000 Thank you Ross and the WG. We have posted draft-akiya-mpls-lsp-ping-reply-mode-simple-03 as draft-ietf= -mpls-lsp-ping-reply-mode-simple-00. Authors would like the WG help to discuss and close off on these two aspect= s: - From Bruno Decraene: Reply Mode for SPRING and applicability of this docu= ment. o There's already a thread for this. - From Mustapha Aissaoui: Relaxing of Reply Mode 5 introduced by RFC7110 in= stead of defining a new Reply Mode for Reverse LSP. o Mustapha or myself will start a thread on this topic later. Once above are close off, then we will roll out -01 that includes: - Conclusion from the two aspects above. - A comment received from Tarek Saad. - Comments received from Lou Berger (will reply to the review comments from= Lou soon) URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-pin= g-reply-mode-simple-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-r= eply-mode-simple/ Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-m= ode-simple-00 Thanks! -Nobo, on behalf of authors > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, September 06, 2014 3:41 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple- > 00.txt >=20 >=20 > 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. >=20 > Title : Label Switched Path (LSP) Ping/Traceroute Reply= Mode > Simplification > Authors : Nobo Akiya > George Swallow > Carlos Pignataro > Loa Andersson > Mach(Guoyi) Chen > Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-00.txt > Pages : 11 > Date : 2014-09-05 >=20 > Abstract: > The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) > Ping and Traceroute use the Reply Mode field to signal the method to > be used in the MPLS echo reply. This document adds one value to the > Reply Mode field to indicate reverse LSP. This document also adds an > optional TLV which can carry ordered list of Reply Mode values. >=20 > This document updates RFC4379. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode- > simple/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-00 >=20 >=20 > 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.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Sep 6 11:41: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 6513C1A00C2 for ; Sat, 6 Sep 2014 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.453 X-Spam-Level: X-Spam-Status: No, score=-113.453 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 s6geOdR7ky0E for ; Sat, 6 Sep 2014 11:41:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F931A0028 for ; Sat, 6 Sep 2014 11:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5539; q=dns/txt; s=iport; t=1410028875; x=1411238475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nFEsjTI6TjVmbR6jT0CXajLGAoUminSUqkTXQ6l0TPE=; b=Xkg4Sqz6PlAhXLXYcXuF4ly1g3/SNqWalzzUHY3ozmPDRmh20cv8ke7s 4/dJ/Vhn6N0EdXKq0rwLGeM7K8MqIUi3cwTEiv1F4lAzV/Uz/kEfEMnNH 3w2th8ZGinVzI7xYXKaXUa7npwWo07IeqBSuO09cQJwZ+Tjs4pNuLZg8O 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAONUC1StJA2N/2dsb2JhbABZgmojgSoE0RoBgQAWd4QDAQEBAwE6LQsHDAQCAQgOAwQBAQsUCQcyFAkIAgQBDQUIiDIIAb10ARePHDEHBoMpgR0BBI8rghWGbJlyg2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,479,1406592000"; d="scan'208";a="350033697" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 06 Sep 2014 18:41:13 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s86IfCGZ021918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Sep 2014 18:41:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sat, 6 Sep 2014 13:41:12 -0500 From: "Nobo Akiya (nobo)" To: Lou Berger , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 Thread-Index: AQHPyUb/PzDawroPiUu7n84aJkZ0rpv0Ixdw Date: Sat, 6 Sep 2014 18:41:11 +0000 Message-ID: References: <540A1B48.7020504@labn.net> In-Reply-To: <540A1B48.7020504@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.70] 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/DWdbBsJdKJaAp2lqZROBqB1Vs34 Cc: "mpls@ietf.org" Subject: Re: [mpls] QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 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, 06 Sep 2014 18:41:15 -0000 Hi Lou, Many thanks for your time for reviewing and providing constructive and posi= tive comments. Please see in-line with [NOBO]. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, September 05, 2014 4:21 PM > To: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > Cc: mpls@ietf.org > Subject: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 >=20 >=20 > Hello, > I've been asked to do a QA review of this draft. Overall it looks lik= e a solid, > well written document, and more than reasonable -00 WG document. [NOBO] :) >=20 > I have some technical nits/comments/questions that I think can be > addressed as part of normal WG process: >=20 > Section 3.1 > - "Reverse LSP is in relation to the last FEC specified in the Target FE= C Stack > TLV." > I think I understand this statement for the egress, but what about at tra= nsit > nodes? Perhaps just drop the sentence? [NOBO] The text pointed out was added as result of comments received on the= list, so I believe it is worth keeping some form of this text in the docum= ent. Although this is something I've been meaning to revisit, so thanks for= highlighting it! I believe the text is mostly correct, even for transit LS= Rs. When FOO is going over a bi-directional LSP, then the transit LSR withi= n the bi-directional LSR: (1) has a reverse LSP in relation to the first FEC (top label). (2) does not have a reverse LSP in relation to the second (last) FEC (botto= m label). In this case, the transit LSR shouldn't be using the reverse LSP for (1) si= nce that may not reach the ingress of the LSP being tested. What is missing from this particular text is that the reverse LSP is not al= ways in relation to the last FEC described. A label stack having special pu= rpose label as bottom of the stack (ex: Explicit NULL) will result in the T= arget FEC Stack to have a Nil FEC as the last FEC. So what the text should = say is that reverse LSP is in relation to the last "transport" FEC specifie= d in the Target FEC Stack TLV. If you are ok with this, I'd like the change the text to: [OLD] Reverse LSP is in relation to the last FEC specified in the Target FEC Stack TLV. [NEW] Reverse LSP is in relation to the last "transport" FEC specified in the Target FEC Stack TLV. A FEC such as Nil FEC (Target FEC Stack TLV Sub-Type 16) is not considered a "transport" FEC. What do you think? >=20 > - Missing "in the range of" in the last sentence of the section. [NOBO] Yes, thanks for catching this. >=20 > Section 3.2 > - The phrasing of 4 is a bit stricter than I think you mean with respect = to use > of Reply Mode field. One could read it as saying that a value carried in= the > field can't be used even when it is in the Order TLV, as well as precludi= ng its > use described in the subsequent requirement (5). > Perhaps just rephrase to say that it is only used after any mode included= in > the ordered TLV is excluded/invalid/unavailable. [NOBO] Good point. Let me change (4): [OLD] 4. If a responder node understands the Reply Mode Order TLV and the TLV is valid, then the responder MUST consider Reply Mode values described in the TLV and MUST NOT use the value described in the Reply Mode field of received MPLS echo request. [NEW] 4. If a responder node understands the Reply Mode Order TLV and the TLV is valid, then the responder MUST consider Reply Mode values described in the TLV. >=20 > -I think the document should be explicit about ordering relationship of t= he > reply modes listed in the Order TLV and to the order of paths included in > other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV. (Yes it should ob= vious, > but it is a potential interop issue) [NOBO] Reply Path TLV is the only one that lists paths for the purpose of r= eplies. Section 4.1.1 intends to clarify this. Can you take a look and let = me know if this is sufficient, or you think more texts will be helpful. >=20 > - Section 4.1.1 > o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner, > particularly when considering non-draft supporting implementations, to us= e > multiple Reply Path TLVs (one per possible reply path)? [NOBO] I believe authors of RFC7110 (which defines the Reply Path TLV) can = clarify its usage, but here's the way I understand that document. - Number of Reply Path TLVs that can appear in the MPLS Echo Request/Reply = messages is not strictly enforced in the document. - The document defines and describes scenarios where one Reply Path TLV is = in the MPLS Echo Request/Reply (that can carry multiple return FECs). - The document does not spell out what happens when there are more than one= Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e. which takes = precedence). Hence I assumed that author intended that MPLS Echo Request/Reply can carry= only one Reply Path TLV. And hence, I descried the 4.1.1 example as one Re= ply Path TLV carrying {FEC X, FEC Y} instead of having multiple Reply Path = TLVs. After scanning through RFC7110, I still think my understanding of the= document is probably what the author intended. I suppose the last two comments are sort of related. Do let me know your th= oughts after reading my repose to you. > > That's it, > Lou Again, many thanks for thorough review! Thanks! -Nobo From nobody Sat Sep 6 17:27: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 6793F1A02CB for ; Sat, 6 Sep 2014 17:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.152 X-Spam-Level: X-Spam-Status: No, score=-116.152 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=-1.652, 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 Y9D2tvXhCvuD for ; Sat, 6 Sep 2014 17:27:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536541A02BD for ; Sat, 6 Sep 2014 17:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12337; q=dns/txt; s=iport; t=1410049626; x=1411259226; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dNfTlfzOMpBv4KnzL+penXCcCwELFsF00D4ox8Zhd2E=; b=EizinW8vs5N+9EoyGvQ4uNB2P5EjTlPPFTQvW++1COwVtQdWwPMldSbM xzrtVtZCHTkYQ5vZdCgGM0qCcut0G6pvgFsulqkOeDJy0kXY4bpK1t6+N C9gxjVSSyPN6N8scdvq1eL1Q7HUKhvKEmmhJK7iVd50xCUxx/MZ91lyA/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAKqlC1StJA2I/2dsb2JhbABZgkcjI1NXBNEyAYECFneEAwEBAQQnBkELEAIBCBEDAQEBCx0HMhQJCAIEAQ0FCIg6Abw9ARePHCARBgGDL4EdBY8rghWgXoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,480,1406592000"; d="scan'208,217"; a="75618235" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 07 Sep 2014 00:27:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s870R1ZA028340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Sep 2014 00:27:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sat, 6 Sep 2014 19:27:01 -0500 From: "Nobo Akiya (nobo)" To: "Tarek Saad (tsaad)" , Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPx9NVK3ACNmTt3kiJimXidGctj5v01Q4Q Date: Sun, 7 Sep 2014 00:27:00 +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.86.245.70] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3C6FABxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/iAS6vjjBPUMYL-s53ZRJgH-af_s Cc: "'mpls-chairs@tools.ietf.org'" Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02 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, 07 Sep 2014 00:27:08 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C6FABxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tarek, Thanks for catching the error. We will correct it in the next revision. Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad) Sent: Wednesday, September 03, 2014 8:01 PM To: Ross Callon; mpls@ietf.org Cc: 'mpls-chairs@tools.ietf.org' Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-= simple-02 I support this draft. The proposed new LSP ping/trace reply mode is useful for the initiator to i= ndicate the response to come back on the reverse LSP path (without addition= al path TLV). The ordered list of reply modes is also useful as a flexible (per request) = list of reply modes to be visited when otherwise the response may fail if t= he only requested reply mode becomes invalid- hence this extension decrease= s chance of false failures. Minor comment in section 1: to minimizes -> to minimize Regards, Tarek From: Ross Callon > Date: Wednesday, August 20, 2014 at 11:20 AM To: "mpls@ietf.org" > Cc: "'mpls-chairs@tools.ietf.org'" > Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02 This is to start a two week poll on adopting draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end Thursday September 4, 2014. Thanks, Ross --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C6FABxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tarek,

 <= /p>

Thanks for catching the e= rror. We will correct it in the next revision.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Tarek Saad (tsaad)
Sent: Wednesday, September 03, 2014 8:01 PM
To: Ross Callon; mpls@ietf.org
Cc: 'mpls-chairs@tools.ietf.org'
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-repl= y-mode-simple-02

 

I support this draft.<= /o:p>

 

The proposed new LSP ping/t= race reply mode is useful for the initiator to indicate the response to com= e back on the reverse LSP path (without additional path TLV).

The ordered list of reply m= odes is also useful as a flexible (per request) list of reply modes to be v= isited when otherwise the response may fail if the only requested reply mode becomes invalid— hence this extension decreases= chance of false failures.

 

Minor comment in section 1:=

to minimizes -> to minim= ize

 

Regards,<= /p>

Tarek

 

From: Ross Callon <rcallon@juniper.net>
Date: Wednesday, August 20, 2014 at 11:20 AM
To: "mpls@ietf.org" &= lt;mpls@ietf.org>
Cc: "'mpls-chair= s@tools.ietf.org'" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mo= de-simple-02

 

This is to start a two week= poll on adopting draft-akiya-mpls-lsp-ping-reply-mode-simple-02=

as an MPLS working group do= cument.

 

Please send your comments (= support/not support) to the mpls working group

mailing list (mpls@ietf.org).

 

This poll will end Thursday= September 4, 2014.

 

Thanks, Ross

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A3C6FABxmbalnx01ciscoc_-- From nobody Mon Sep 8 00:48: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 6F1111A6F6D for ; Mon, 8 Sep 2014 00:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 oYqiZ9pGMFuv for ; Mon, 8 Sep 2014 00:48:11 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A8A1A6F44 for ; Mon, 8 Sep 2014 00:48:10 -0700 (PDT) Received: from [192.168.0.102] (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 536791801487; Mon, 8 Sep 2014 09:48:09 +0200 (CEST) Message-ID: <540D5F3F.4030308@pi.nu> Date: Mon, 08 Sep 2014 09:48:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <53F598B7.7060205@pi.nu> In-Reply-To: <53F598B7.7060205@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/sTtmqJts8dWjwmtAtBuTFJ8Q5ks Cc: "draft-ietf-mpls-pim-sm-over-mldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-pim-sm-over-mldp 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, 08 Sep 2014 07:48:12 -0000 Working Group, This wglc is closed. There has been a very small set of commens, can the authors please address those and re-post a new version of the document. /Loa On 2014-08-21 08:59, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-pim-sm-over-mldp. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There is one IPR disclosures against this document. All the authors > and contributors have stated on the working group mailing list that > they are not aware of any other IPRs that relates to this draft. > > This working group last call ends September 5, 2014. > > /Loa > for the MPLS wg 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 Mon Sep 8 06:21: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 DE32C1A87D1; Mon, 8 Sep 2014 06:21: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=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 naBe7mWfwzRC; Mon, 8 Sep 2014 06:21:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951A1A87CE; Mon, 8 Sep 2014 06:21:38 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908132138.28745.19165.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 06:21:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cOyBMCGvgPF5HM1rLWZIwa2a8R8 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-pim-sm-over-mldp-01.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, 08 Sep 2014 13:21:40 -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 : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Authors : Yakov Rekhter Rahul Aggarwal Nicolai Leymann Wim Henderickx Quintin Zhao Richard Li Filename : draft-ietf-mpls-pim-sm-over-mldp-01.txt Pages : 12 Date : 2014-09-08 Abstract: When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switched Paths are established using mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-pim-sm-over-mldp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-pim-sm-over-mldp-01 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 Sep 8 06:22:06 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 6F08E1A87E2 for ; Mon, 8 Sep 2014 06:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] 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 CQgXmUddlgkg for ; Mon, 8 Sep 2014 06:22:01 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 311481A87D2 for ; Mon, 8 Sep 2014 06:21:59 -0700 (PDT) Received: (qmail 5618 invoked by uid 0); 8 Sep 2014 13:21:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Sep 2014 13:21:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id odMj1o0032SSUrH01dMmNQ; Mon, 08 Sep 2014 07:21:55 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=ZSdzdHkL1-cA:10 a=D_UVkK3T8E8A:10 a=C0WSyExUKrQA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=L0TUcx3Rk3KRpY05e3MA:9 a=wPNLvfGTeEIA:10 a=GMSbCyEWakQA:10 a=33rK67OTR_gA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9U0mCVQwwox8w1bIgDoQkTWShOp7PYxY8Akhy6BfpIU=; b=JEAgZggewQMmwqz9fpXalI2iexabC4gwT9mHGaWg/lwAACXWC7d50xQ5d3ZVyTTAooa9Q11J2Bvy1wxM+2WQFAMtAgyYLdOdU692kj2WhoQ2MWlZJfTeGk7DEUN+yl5r; Received: from box313.bluehost.com ([69.89.31.113]:37023 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XQyt5-00082b-Px; Mon, 08 Sep 2014 07:21:43 -0600 Message-ID: <540DAD64.4040803@labn.net> Date: Mon, 08 Sep 2014 09:21:40 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" References: <540A1B48.7020504@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IbyioRsCF8KYFHsJP2SdNmbl6PY Cc: "mpls@ietf.org" Subject: Re: [mpls] QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 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, 08 Sep 2014 13:22:02 -0000 On 09/06/2014 02:41 PM, Nobo Akiya (nobo) wrote: > Hi Lou, > > Many thanks for your time for reviewing and providing constructive and positive comments. > > Please see in-line with [NOBO]. > Nobo, responses in-line. >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, September 05, 2014 4:21 PM >> To: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 >> >> >> Hello, >> I've been asked to do a QA review of this draft. Overall it looks like a solid, >> well written document, and more than reasonable -00 WG document. > > [NOBO] :) > >> >> I have some technical nits/comments/questions that I think can be >> addressed as part of normal WG process: >> >> Section 3.1 >> - "Reverse LSP is in relation to the last FEC specified in the Target FEC Stack >> TLV." >> I think I understand this statement for the egress, but what about at transit >> nodes? Perhaps just drop the sentence? > > [NOBO] The text pointed out was added as result of comments received > on the list, so I believe it is worth keeping some form of this text > in the document. Although this is something I've been meaning to > revisit, so thanks for highlighting it! I believe the text is mostly > correct, even for transit LSRs. When FOO is going over a > bi-directional LSP, then the transit LSR within the bi-directional > LSR: > > (1) has a reverse LSP in relation to the first FEC (top label). > (2) does not have a reverse LSP in relation to the second (last) FEC (bottom label). > > In this case, the transit LSR shouldn't be using the reverse LSP for > (1) since that may not reach the ingress of the LSP being tested. > > What is missing from this particular text is that the reverse LSP is > not always in relation to the last FEC described. A label stack > having special purpose label as bottom of the stack (ex: Explicit > NULL) will result in the Target FEC Stack to have a Nil FEC as the > last FEC. So what the text should say is that reverse LSP is in > relation to the last "transport" FEC specified in the Target FEC > Stack TLV. > > If you are ok with this, I'd like the change the text to: > > [OLD] > Reverse LSP is in relation to the last FEC > specified in the Target FEC Stack TLV. > > [NEW] > Reverse LSP is in relation to the last "transport" > FEC specified in the Target FEC Stack TLV. A FEC such as Nil FEC > (Target FEC Stack TLV Sub-Type 16) is not considered a "transport" > FEC. > > What do you think? Isn't the reverse LSP based on the received LSP? If not, a ping can be (perhaps miss) delivered on one LSP and have a response on a different reverse LSP. What am I missing? > >> >> - Missing "in the range of" in the last sentence of the section. > > [NOBO] Yes, thanks for catching this. > >> >> Section 3.2 >> - The phrasing of 4 is a bit stricter than I think you mean with respect to use >> of Reply Mode field. One could read it as saying that a value carried in the >> field can't be used even when it is in the Order TLV, as well as precluding its >> use described in the subsequent requirement (5). >> Perhaps just rephrase to say that it is only used after any mode included in >> the ordered TLV is excluded/invalid/unavailable. > > [NOBO] Good point. Let me change (4): > > [OLD] > 4. If a responder node understands the Reply Mode Order TLV and the > TLV is valid, then the responder MUST consider Reply Mode values > described in the TLV and MUST NOT use the value described in the > Reply Mode field of received MPLS echo request. > > [NEW] > 4. If a responder node understands the Reply Mode Order TLV and the > TLV is valid, then the responder MUST consider Reply Mode values > described in the TLV. sure, although "consider" is a bit ambiguous. Perhaps ... "MUST select the first available return path as identified by the ordered list of Reply Mode values contained in the TLV." also change the start of 5 to be "If no valid return path can be identified based on the TLV or if the responder..." > >> >> -I think the document should be explicit about ordering relationship of the >> reply modes listed in the Order TLV and to the order of paths included in >> other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV. (Yes it should obvious, >> but it is a potential interop issue) > > [NOBO] Reply Path TLV is the only one that lists paths for the > purpose of replies. Section 4.1.1 intends to clarify this. Can you > take a look and let me know if this is sufficient, or you think more > texts will be helpful. > How about something along the lines of (if you can make this simpler, please do so!): (section 3.2) 9. When the same Reply Mode value appears more than once in a Reply Mode Order TLV and the indicated reply mode uses information contained in the MPLS echo request, the ordering of Reply Mode values will correspond to the order the information appears in the MPLS echo request. >> >> - Section 4.1.1 >> o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner, >> particularly when considering non-draft supporting implementations, to use >> multiple Reply Path TLVs (one per possible reply path)? > > [NOBO] I believe authors of RFC7110 (which defines the Reply Path > TLV) can clarify its usage, but here's the way I understand that > document. At this point, it's the document that matters most ;-) > > - Number of Reply Path TLVs that can appear in the MPLS Echo > Request/Reply messages is not strictly enforced in the document. > If this means that it is under defined/open to interpretation, I agree. > - The document defines and describes scenarios where one Reply Path > TLV is in the MPLS Echo Request/Reply (that can carry multiple return > FECs). > Yeah, but it also mentioned encoding multiple return path(s). > - The document does not spell out what happens when there are more > than one Reply Path TLVs in the MPLS Echo Request/Reply messages > (i.e. which takes precedence). > Fair point. That said, rfc7110 doesn't also doesn't spell out when there are more than one fecs/paths in the Reply Path TLVs. > Hence I assumed that author intended that MPLS Echo Request/Reply can > carry only one Reply Path TLV. And hence, I descried the 4.1.1 > example as one Reply Path TLV carrying {FEC X, FEC Y} instead of > having multiple Reply Path TLVs. After scanning through RFC7110, I > still think my understanding of the document is probably what the > author intended. > Again, once it's what is actually said in the RFC(s) that matter most at this point. To me your last point is fairly convincing, although as said above, there's still ambiguity. Either way, it probably means that (a) the expected Reply Path TLV processing needs to be spelled out and (b) this document will be an update to rfc7110. This is something that can be worked out by the WG as the document progresses. > I suppose the last two comments are sort of related. Do let me know > your thoughts after reading my repose to you. > Yup. Thanks, Lou >> >> That's it, >> Lou > > Again, many thanks for thorough review! > > Thanks! > > -Nobo > > > From nobody Mon Sep 8 06:23: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 745E41A87CE for ; Mon, 8 Sep 2014 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HCxlPv1xaAFy for ; Mon, 8 Sep 2014 06:23:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982DD1A87DE for ; Mon, 8 Sep 2014 06:23:40 -0700 (PDT) Received: from BL2PR05CA0040.namprd05.prod.outlook.com (10.255.226.40) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 8 Sep 2014 13:23:39 +0000 Received: from BY2FFO11FD047.protection.gbl (2a01:111:f400:7c0c::100) by BL2PR05CA0040.outlook.office365.com (2a01:111:e400:c04::40) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Mon, 8 Sep 2014 13:23:38 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BY2FFO11FD047.mail.protection.outlook.com (10.1.15.175) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Mon, 8 Sep 2014 13:23:38 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 8 Sep 2014 06:23:37 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s88DNZn25700; Mon, 8 Sep 2014 06:23:35 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201409081323.s88DNZn25700@magenta.juniper.net> To: Loa Andersson In-Reply-To: <540D5F3F.4030308@pi.nu> References: <53F598B7.7060205@pi.nu> <540D5F3F.4030308@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Mon, 08 Sep 2014 09:48:15 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28887.1410182614.1@juniper.net> Date: Mon, 8 Sep 2014 06:23:34 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(51704005)(199003)(252514010)(189002)(377424004)(24454002)(83072002)(85852003)(16796002)(31966008)(77982001)(74502001)(74662001)(76176999)(81342001)(46102001)(97736003)(107046002)(79102001)(86362001)(110136001)(64706001)(46406003)(47776003)(80022001)(20776003)(84676001)(54356999)(81542001)(95666004)(50466002)(90102001)(230783001)(102836001)(68736004)(81156004)(106466001)(105596002)(44976005)(23726002)(6806004)(21056001)(76482001)(92566001)(92726001)(4396001)(97756001)(69596002)(87936001)(99396002)(50986999)(19580395003)(83322001)(85306004)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03283976A6 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/b1MBJTmCF4PMwd8xUS1YfpOWvaI Cc: "mpls@ietf.org" , "draft-ietf-mpls-pim-sm-over-mldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-pim-sm-over-mldp 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, 08 Sep 2014 13:23:52 -0000 Loa, > Working Group, > > This wglc is closed. There has been a very small set of commens, can the > authors please address those and re-post a new version of the document. Done (I just posted -01 version). Yakov. > > /Loa > > On 2014-08-21 08:59, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a two week working group last call on > > draft-ietf-mpls-pim-sm-over-mldp. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > There is one IPR disclosures against this document. All the authors > > and contributors have stated on the working group mailing list that > > they are not aware of any other IPRs that relates to this draft. > > > > This working group last call ends September 5, 2014. > > > > /Loa > > for the MPLS wg 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 Mon Sep 8 06:35: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 2D0BA1A87D0 for ; Mon, 8 Sep 2014 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 9aXO4XUEVLkW for ; Mon, 8 Sep 2014 06:34:59 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CD01A87D1 for ; Mon, 8 Sep 2014 06:34:59 -0700 (PDT) Received: from [192.168.0.102] (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 AED7F1801487; Mon, 8 Sep 2014 15:34:57 +0200 (CEST) Message-ID: <540DB087.9040503@pi.nu> Date: Mon, 08 Sep 2014 15:35:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yakov Rekhter References: <53F598B7.7060205@pi.nu> <540D5F3F.4030308@pi.nu> <201409081323.s88DNZn25700@magenta.juniper.net> In-Reply-To: <201409081323.s88DNZn25700@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GRlJu-rbeHWR-wqvU0xhC-X3lMk Cc: "mpls@ietf.org" , "draft-ietf-mpls-pim-sm-over-mldp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-pim-sm-over-mldp 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, 08 Sep 2014 13:35:01 -0000 Yakov, the nits-tool is pick (more pick than I am, so I will go ahead anyway) it requires that the date format is: September 8, 2014 September 8 2014 won't pass the tool. Since this extremely nitty I will put the document in "WG Consensus: Waiting for Write-Up". I normally write the shepherd write-up within the week. I hope to have it ready for review on Wednesday, but I will be on leave Thu and Fri, so if I'm not ready you'll have it fro review early next week. /Loa On 2014-09-08 15:23, Yakov Rekhter wrote: > Loa, > >> Working Group, >> >> This wglc is closed. There has been a very small set of commens, can the >> authors please address those and re-post a new version of the document. > > Done (I just posted -01 version). > > Yakov. > >> >> /Loa >> >> On 2014-08-21 08:59, Loa Andersson wrote: >>> Working Group, >>> >>> This is to initiate a two week working group last call on >>> draft-ietf-mpls-pim-sm-over-mldp. >>> >>> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >>> >>> There is one IPR disclosures against this document. All the authors >>> and contributors have stated on the working group mailing list that >>> they are not aware of any other IPRs that relates to this draft. >>> >>> This working group last call ends September 5, 2014. >>> >>> /Loa >>> for the MPLS wg chairs >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 -- 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 Sep 8 17:10: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 9346F1A0303 for ; Mon, 8 Sep 2014 17:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 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=-1.652, 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 W6VS_lqZnSYv for ; Mon, 8 Sep 2014 17:10:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739CD1A030F for ; Mon, 8 Sep 2014 17:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9881; q=dns/txt; s=iport; t=1410221409; x=1411431009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WDTUSW0HtpJhSuJEYSlu44iVViJU77XQcD0qqM6sGrw=; b=GMDqFBKm/tWO+j+V6Nt62mOSeks6KjieHUjhQaRcshMCGYAcbt73DMkY 7zUKSyI679XPrqBBLJ+nE9B2x2tYYmLYSJJCfQxbxjsZb/V29cXHbTN3N NeTOLLgIv0FtDq+cLQ5HBDVdLHBr2rJwmx1om2P9rIY6/KHXBOREdATk0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOtEDlStJA2K/2dsb2JhbABZgmojgSoE0UsBgRYWeIQDAQEBAwE6LQsHDAQCAQgOAwQBAQEKFAkHMhQJCAIEAQ0FCIgyCAG9GwEXjxwxBwaDKYEdAQSPK4IVhmyZcoNhbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,489,1406592000"; d="scan'208";a="76059661" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 09 Sep 2014 00:10:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s890A8Rq008222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 00:10:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 19:10:08 -0500 From: "Nobo Akiya (nobo)" To: Lou Berger , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 Thread-Index: AQHPyUb/PzDawroPiUu7n84aJkZ0rpv0IxdwgANt0gCAAFcWIA== Date: Tue, 9 Sep 2014 00:10:07 +0000 Message-ID: References: <540A1B48.7020504@labn.net> <540DAD64.4040803@labn.net> In-Reply-To: <540DAD64.4040803@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.156] 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/SFnwKAeOwoP1_wRw87FsgPlAtXk Cc: "mpls@ietf.org" Subject: Re: [mpls] QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 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, 09 Sep 2014 00:10:11 -0000 Hi Lou, Thanks for providing follow up comments and suggested texts! Please see in-line with [NOBO2]. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Monday, September 08, 2014 9:22 AM > To: Nobo Akiya (nobo); draft-akiya-mpls-lsp-ping-reply-mode- > simple@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 >=20 > On 09/06/2014 02:41 PM, Nobo Akiya (nobo) wrote: > > Hi Lou, > > > > Many thanks for your time for reviewing and providing constructive and > positive comments. > > > > Please see in-line with [NOBO]. > > >=20 > Nobo, > responses in-line. >=20 > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, September 05, 2014 4:21 PM > >> To: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > >> Cc: mpls@ietf.org > >> Subject: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 > >> > >> > >> Hello, > >> I've been asked to do a QA review of this draft. Overall it looks > >> like a solid, well written document, and more than reasonable -00 WG > document. > > > > [NOBO] :) > > > >> > >> I have some technical nits/comments/questions that I think can be > >> addressed as part of normal WG process: > >> > >> Section 3.1 > >> - "Reverse LSP is in relation to the last FEC specified in the > >> Target FEC Stack TLV." > >> I think I understand this statement for the egress, but what about at > >> transit nodes? Perhaps just drop the sentence? > > > > [NOBO] The text pointed out was added as result of comments received > > on the list, so I believe it is worth keeping some form of this text > > in the document. Although this is something I've been meaning to > > revisit, so thanks for highlighting it! I believe the text is mostly > > correct, even for transit LSRs. When FOO is going over a > > bi-directional LSP, then the transit LSR within the bi-directional > > LSR: > > > > (1) has a reverse LSP in relation to the first FEC (top label). > > (2) does not have a reverse LSP in relation to the second (last) FEC (b= ottom > label). > > > > In this case, the transit LSR shouldn't be using the reverse LSP for > > (1) since that may not reach the ingress of the LSP being tested. > > > > What is missing from this particular text is that the reverse LSP is > > not always in relation to the last FEC described. A label stack having > > special purpose label as bottom of the stack (ex: Explicit > > NULL) will result in the Target FEC Stack to have a Nil FEC as the > > last FEC. So what the text should say is that reverse LSP is in > > relation to the last "transport" FEC specified in the Target FEC Stack > > TLV. > > >=20 > > If you are ok with this, I'd like the change the text to: > > > > [OLD] > > Reverse LSP is in relation to the last FEC > > specified in the Target FEC Stack TLV. > > > > [NEW] > > Reverse LSP is in relation to the last "transport" > > FEC specified in the Target FEC Stack TLV. A FEC such as Nil FEC > > (Target FEC Stack TLV Sub-Type 16) is not considered a "transport" > > FEC. > > > > What do you think? >=20 > Isn't the reverse LSP based on the received LSP? If not, a ping can be > (perhaps miss) delivered on one LSP and have a response on a different > reverse LSP. What am I missing? [NOBO2] If one is testing a flat LSP (i.e. non-hierarchical), then yes the = reverse LSP is in relation to the received LSP. However, we probably should= n't exclude some hierarchical LSP cases. Say, one is testing an LSP which h= appens to go over another LSP, where the outer LSP is starting from a trans= it LSR of the inner LSP. In such case, if one is performing a traceroute wi= th Reply Mode "reverse LSP", then what the user really mean is that the "re= verse LSP" is in relation to the inner LSP. It would be wrong for a transi= t LSR of the outer LSP to use its own reverse LSP to send the MPLS Echo Rep= ly back, as that may not reach the initiating node. To accommodate this hie= rarchical case, I believe text above is required. >=20 > > > >> > >> - Missing "in the range of" in the last sentence of the section. > > > > [NOBO] Yes, thanks for catching this. > > > >> > >> Section 3.2 > >> - The phrasing of 4 is a bit stricter than I think you mean with > >> respect to use of Reply Mode field. One could read it as saying that > >> a value carried in the field can't be used even when it is in the > >> Order TLV, as well as precluding its use described in the subsequent > requirement (5). > >> Perhaps just rephrase to say that it is only used after any mode > >> included in the ordered TLV is excluded/invalid/unavailable. > > > > [NOBO] Good point. Let me change (4): > > > > [OLD] > > 4. If a responder node understands the Reply Mode Order TLV and the > > TLV is valid, then the responder MUST consider Reply Mode values > > described in the TLV and MUST NOT use the value described in the > > Reply Mode field of received MPLS echo request. > > > > [NEW] > > 4. If a responder node understands the Reply Mode Order TLV and the > > TLV is valid, then the responder MUST consider Reply Mode values > > described in the TLV. >=20 > sure, although "consider" is a bit ambiguous. Perhaps ... "MUST > select the first available return path as identified by the ordered list = of > Reply Mode values contained in the TLV." [NOBO2] Nice text, I'll take it! >=20 > also change the start of 5 to be "If no valid return path can be identifi= ed > based on the TLV or if the responder..." [NOBO2] Good point, and thanks for providing this text as well! >=20 > > > >> > >> -I think the document should be explicit about ordering relationship > >> of the reply modes listed in the Order TLV and to the order of paths > >> included in other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV. > >> (Yes it should obvious, but it is a potential interop issue) > > > > [NOBO] Reply Path TLV is the only one that lists paths for the purpose > > of replies. Section 4.1.1 intends to clarify this. Can you take a look > > and let me know if this is sufficient, or you think more texts will be > > helpful. > > >=20 > How about something along the lines of (if you can make this simpler, > please do so!): > (section 3.2) 9. When the same Reply Mode value appears more than once > in a Reply Mode Order TLV and the indicated reply mode uses information > contained in the MPLS echo request, the ordering of Reply Mode values wil= l > correspond to the order the information appears in the MPLS echo request. [NOBO2] Right, the suggested text does allow the multiple Reply Path TLV ca= se w/o ambiguity (or any other future extension cases). I like it. Let me d= rop down the MUST to SHOULD in (7), and add your suggested as (9). >=20 >=20 > >> > >> - Section 4.1.1 > >> o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner, > >> particularly when considering non-draft supporting implementations, > >> to use multiple Reply Path TLVs (one per possible reply path)? > > > > [NOBO] I believe authors of RFC7110 (which defines the Reply Path > > TLV) can clarify its usage, but here's the way I understand that > > document. >=20 > At this point, it's the document that matters most ;-) >=20 > > > > - Number of Reply Path TLVs that can appear in the MPLS Echo > > Request/Reply messages is not strictly enforced in the document. > > > If this means that it is under defined/open to interpretation, I agree. >=20 > > - The document defines and describes scenarios where one Reply Path > > TLV is in the MPLS Echo Request/Reply (that can carry multiple return > > FECs). > > > Yeah, but it also mentioned encoding multiple return path(s). >=20 > > - The document does not spell out what happens when there are more > > than one Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e. > > which takes precedence). > > > Fair point. That said, rfc7110 doesn't also doesn't spell out when there = are > more than one fecs/paths in the Reply Path TLVs. >=20 > > Hence I assumed that author intended that MPLS Echo Request/Reply can > > carry only one Reply Path TLV. And hence, I descried the 4.1.1 example > > as one Reply Path TLV carrying {FEC X, FEC Y} instead of having > > multiple Reply Path TLVs. After scanning through RFC7110, I still > > think my understanding of the document is probably what the author > > intended. > > >=20 > Again, once it's what is actually said in the RFC(s) that matter most at = this > point. >=20 > To me your last point is fairly convincing, although as said above, there= 's still > ambiguity. Either way, it probably means that (a) the expected Reply Path > TLV processing needs to be spelled out and (b) this document will be an > update to rfc7110. This is something that can be worked out by the WG as > the document progresses. [NOBO2] That sounds reasonable and beneficial thing to do. Let me reach out= to Mach Chen who may already be monitoring this thread (he's the primary a= uthors of RFC7110 and co-author of draft-akiya-mpls-lsp-ping-reply-mode-sim= ple, and get his thoughts on this). We have couple of other topics to close off on the list. Once those are clo= sed off, we will roll out a revision which will have your comments/texts in= corporated. Thanks again Lou! -Nobo >=20 > > I suppose the last two comments are sort of related. Do let me know > > your thoughts after reading my repose to you. > > >=20 > Yup. >=20 > Thanks, > Lou >=20 > >> > >> That's it, > >> Lou > > > > Again, many thanks for thorough review! > > > > Thanks! > > > > -Nobo > > > > > > From nobody Tue Sep 9 00:36: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 A839D1A6EE1 for ; Tue, 9 Sep 2014 00:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 4uxhNUsQCdZ4 for ; Tue, 9 Sep 2014 00:36:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BDA1A1F73 for ; Tue, 9 Sep 2014 00:36:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMI83698; Tue, 09 Sep 2014 07:36:05 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Sep 2014 08:36:04 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 9 Sep 2014 15:35:57 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , Lou Berger , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Thread-Topic: QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 Thread-Index: AQHPygIrb0Ls3VKHR0+ztLDdKxVo+5v4X/UQ Date: Tue, 9 Sep 2014 07:35:57 +0000 Message-ID: References: <540A1B48.7020504@labn.net> In-Reply-To: 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/3a_MHhZ3-UJDEOlaoy4APAd9LVQ Cc: "mpls@ietf.org" Subject: Re: [mpls] QA Review draft-akiya-mpls-lsp-ping-reply-mode-simple-03 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, 09 Sep 2014 07:36:09 -0000 Hi Nobo and Lou, To chime in regarding the Reply Path TLV, please see inline... Snipped. =20 > > - Section 4.1.1 > > o The Reply Path TLV carrying {FEC X, FEC Y} Wouldn't it be cleaner, > > particularly when considering non-draft supporting implementations, to > > use multiple Reply Path TLVs (one per possible reply path)? >=20 > [NOBO] I believe authors of RFC7110 (which defines the Reply Path TLV) ca= n > clarify its usage, but here's the way I understand that document. >=20 > - Number of Reply Path TLVs that can appear in the MPLS Echo Request/Repl= y > messages is not strictly enforced in the document. > - The document defines and describes scenarios where one Reply Path TLV i= s in > the MPLS Echo Request/Reply (that can carry multiple return FECs). > - The document does not spell out what happens when there are more than o= ne > Reply Path TLVs in the MPLS Echo Request/Reply messages (i.e. which takes > precedence). >=20 > Hence I assumed that author intended that MPLS Echo Request/Reply can car= ry > only one Reply Path TLV. And hence, I descried the 4.1.1 example as one R= eply > Path TLV carrying {FEC X, FEC Y} instead of having multiple Reply Path TL= Vs. After > scanning through RFC7110, I still think my understanding of the document = is > probably what the author intended. Yes, your understanding is align with the original intention of RFC7110, th= ere is an implicit assumption that there will be only one Reply TLV that ca= n appear in the MPLS Echo Request/Reply. But the assumption was based on th= at there will be only one return path specified or chosen.=20 For multiple return paths case, IMHO, either single Reply Path TLV with mul= tiple sub-TLVs or multiple Reply Path TLVs is technically workable. Best regards, Mach >=20 > I suppose the last two comments are sort of related. Do let me know your > thoughts after reading my repose to you. >=20 > > > > That's it, > > Lou >=20 > Again, many thanks for thorough review! >=20 > Thanks! >=20 > -Nobo >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Sep 9 18:38: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 572381A0366 for ; Tue, 9 Sep 2014 18:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 yrv9450B7tQQ for ; Tue, 9 Sep 2014 18:38:07 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A651A0332 for ; Tue, 9 Sep 2014 18:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33394; q=dns/txt; s=iport; t=1410313086; x=1411522686; h=from:to:subject:date:message-id:mime-version; bh=XzKSUiZxAMKSq9v4rXSvNcHwc0A4zlEJbx06Vsj3GwM=; b=Q0KQvHwWHU8L6bJ4DrYiMRVjeqXB1qVo5bmx3cvXk409VPfqLoZ8KSR3 h178vwpvMX9adijvMV7rN5Xcu8NHwqpv/BYkuXDXu2kSFcuLmWxhndIFZ MYR2eQZduMYkw56EbLg69gZ6K5nolpNhJ7O5hlDUilaFW8aOulq6InUTH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAGSqD1StJV2U/2dsb2JhbABZgkdGU1cE0gQBgQgWeIQDAQEBBC0+Ax0BCBEDAQEBIQEGORQJCgQBEhuIJ70WAReOaxEBPxcHhEYFjyyCFYZshEaVLoIbgUZsgQ85gQcBAQE X-IronPort-AV: E=Sophos; i="5.04,494,1406592000"; d="scan'208,217"; a="76494030" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 10 Sep 2014 01:38:04 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8A1c3TM022767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 01:38:04 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.166]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 20:38:03 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Nobo Akiya (nobo)" , "bruno.decraene@orange.com" , "mpls@ietf.org" Thread-Topic: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHPzJfcXUCBw4NpKEua7u05+MtHRw== Date: Wed, 10 Sep 2014 01:38:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.82.228.15] Content-Type: multipart/alternative; boundary="_000_D0351A48586A1naikumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QGqgt1LSclzmrTPmQRYE6rSt4D0 Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 10 Sep 2014 01:38:18 -0000 --_000_D0351A48586A1naikumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno/Nobo, I agree with you both that this use case is useful. Per my understanding, e= xtending RFC7110 and let Initiator to pre-calculate the reverse segment sta= ck and populating the same is also possible. While I understand the concern= raised b Nobo, I think the FRR will be in place for reverse path as well a= nd so should be able to reach the Initiator. The other approach of having the responder calculate the return path is als= o reasonable. In either case, I think the extension should be included in d= raft-kumarkini-mpls-spring-lsp-ping. Thanks, Nagendra From: "Nobo Akiya (nobo)" > Date: Friday, September 5, 2014 at 9:26 PM To: "bruno.decraene@orange.com" >, "mpls@ietf.org" > Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping Hi Bruno, I very much agree that the use case that you raised is useful for LSP Ping/= Trace on SPRING. In terms of how, there are few aspects that I=92d like to highlight. 1. To accomplish MPLS Echo Reply messages taking a return path that mi= rrors the forward path, generally there are two approaches. a. Sender of MPLS Echo Request messages (initiator) to compute the mir= roring return path and include the information in the MPLS Echo Request. Th= is can be done via extending RFC7110. b. Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path (this is the logic you described in your email). 2. With the approach (1a), return path computation requires that the i= nitiator try to determine where the packet will terminate (thus incoming la= bel stack on that node). That will be ok in a stable state but can get prob= lematic when there are changes happening in the network (convergence, FRR).= Instead, I tend to think (and agree) the approach (1b) of the responder co= mputing the mirroring return path is superior. 3. I=92ve heard some stories about folks wanting to do path associatio= n on end-points in SPRING to create bi-directional =93tunnels=94. These =93= tunnels=94 will have a real reverse LSP. So the Reply Mode =93reverse LSP= =94 should apply to such bi-directional =93tunnels=94. 4. Thus to address this use case, I think we need a new Reply Mode def= ined instead of using Reply Mode =93reverse LSP=94. 5. How do we preserve the forward segment stack in the MPLS Echo Reque= st? a. One way is for the entire segment stack to be described in the Targ= et FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is e= xpected normally is that Target FEC Stack shrinks as initiator receives =93= FEC Stack Change with POP=94 from downstream LSRs. It=92s worth keeping thi= s behavior. b. Another way is to introduce a new TLV that describes the entire seg= ment stack pushed by the initiator, and that can get used by the responder = along with the logic you described. In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a goo= d way to address the use case you raised. Logistically, these extensions (if we agree to extend) should be described = in draft-kumarkini-mpls-spring-lsp-ping. I would certainly like to hear from other experts on this matter as well. Thanks! -Nobo From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, September 05, 2014 9:03 AM To: mpls@ietf.org; Nobo Akiya (nobo) Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls= -spring-lsp-ping Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: =93Reply via reverse LSP=94, with an applicability to =93RSVP = LSPs and TP LSPs=94. I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC s= tack TLV (e.g. L1, L2 =85 Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3=85 Ln) c. Get the ingress to local segment list/path by subtracting both stac= ks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For node= segments, keep them unchanged, for adjacency segment, use the reverse adja= cency. This is computationally very simple and but requires the IGP metric = to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that=92s already the c= ase for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/=94pre POP=94 the initial adjacency label). To addr= ess this, the ingres router could indicate this initial adjacency label in = the Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D0351A48586A1naikumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <417E82FF9217DA44BB0D13D84C8D6C13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bruno/Nobo,

I agree with you both that this use case is useful. Per my understandi= ng, extending RFC7110 and let Initiator to pre-calculate the reverse segmen= t stack and populating the same is also possible. While I understand the co= ncern raised b Nobo, I think the FRR will be in place for reverse path as well and so should be able to rea= ch the Initiator.

The other approach of having the responder calculate the return path i= s also reasonable. In either case, I think the extension should be included= in draft-kumarkini-mpls-spring-lsp-ping.

Thanks,
Nagendra

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Friday, September 5, 2014 at = 9:26 PM
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] draft-akiya-mpl= s-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

Hi Bruno,

 

I very much agree that= the use case that you raised is useful for LSP Ping/Trace on SPRING.<= /o:p>

 

In terms of how, there= are few aspects that I=92d like to highlight.

 

1.      To accompl= ish MPLS Echo Reply messages taking a return path that mirrors the forward = path, generally there are two approaches.

a.      Sender of = MPLS Echo Request messages (initiator) to compute the mirroring return path= and include the information in the MPLS Echo Request. This can be done via= extending RFC7110.

b.      Sender of = MPLS Echo Reply messages (responder) to compute the mirroring return path (= this is the logic you described in your email).

2.      With the a= pproach (1a), return path computation requires that the initiator try to de= termine where the packet will terminate (thus incoming label stack on that = node). That will be ok in a stable state but can get problematic when there are changes happening in the netw= ork (convergence, FRR). Instead, I tend to think (and agree) the approach (= 1b) of the responder computing the mirroring return path is superior.<= /o:p>

3.      I=92ve hea= rd some stories about folks wanting to do path association on end-points in= SPRING to create bi-directional =93tunnels=94. These =93tunnels=94 will ha= ve a real reverse LSP. So the Reply Mode =93reverse LSP=94 should apply to such bi-directional =93tunnels=94.

4.      Thus to ad= dress this use case, I think we need a new Reply Mode defined instead of us= ing Reply Mode =93reverse LSP=94.

5.      How do we = preserve the forward segment stack in the MPLS Echo Request?

a.      One way is= for the entire segment stack to be described in the Target FEC Stack TLV. = Although when LSP Traceroute is done on SRPING, what is expected normally i= s that Target FEC Stack shrinks as initiator receives =93FEC Stack Change with POP=94 from downstream LSRs. I= t=92s worth keeping this behavior.

b.      Another wa= y is to introduce a new TLV that describes the entire segment stack pushed = by the initiator, and that can get used by the responder along with the log= ic you described.

 

In summary, my persona= l opinion will be (1b), new Reply Mode, (5b) is a good way to address the u= se case you raised.

 

Logistically, these ex= tensions (if we agree to extend) should be described in draft-kumarkini-mpl= s-spring-lsp-ping.

 

I would certainly like= to hear from other experts on this matter as well.

 

Thanks!

 

-Nobo

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, September 05, 2014 9:03 AM
To: mpls@ietf.org; Nobo Akiya (= nobo)
Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping

 

Hi all,

 

*) Short version (use case):

draft-akiya-mpls-lsp-ping-reply= -mode-simple defines a new Reply mode for MPLS LSP Ping: =93Reply via rever= se LSP=94, with an applicability to =93RSVP LSPs and TP LSPs=94.=

I have the rough impression tha= t this mode would also be very applicable in SPRING networks/LSPs since the= responder would be able send the reply along the same (reverse)/co-routed = path than the requester.

Could this be investigated? (on= the mailing list or in either of the above 2 drafts).

 

*) Long version (proposed solut= ion):

a)      The responder is/sh= ould be able to get/infer the incoming path

a.      Get the end to end = segment list/path a priori from the Target FEC stack TLV (e.g. L1, L2 =85 L= n)

b.      Get the local to en= d segment list/path from the label stack in the received packet (e.g. L3=85= Ln)

c.      Get the ingress to = local segment list/path by subtracting both stacks (e.g. L1, L2)=

b)      Using SR, the respo= nder is able to enforce any explicit path, so in particular the reverse pat= h from local to ingress. 2 options for this:

a.      Simple one: reverse= the order of the segments in the path. For node segments, keep them unchan= ged, for adjacency segment, use the reverse adjacency. This is computationa= lly very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse directi= on.

b.      Exact one: compute = the exact forward path (SPF rooted on the sender then follow the segments s= tack).Then reverse the path and compute the list of segments required to en= force this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segment). This is com= putationally more expensive but enforces the same path in all cases. (seems= a bit scary from a DOS perspective, to use significant control plane resou= rces in response to a forwarding plane packet, but in essence, that=92s already the case for ping/traceroute)

I g= uess that the choice could be a local choice on the responder, configured b= y the SP (e.g. depending on its use of asymmetric IGP costs)

 

A priori this would be applicab= le to both MPLS ping and traceroute.

 

Caveats:

1) restricted to a single IGP a= rea. But this is a usual limitation of TE in a multi-area network. (and typ= ical solution may also apply e.g. PCE)

2) The spring ingress router ma= y have pushed the packet on a non shortest path interface (i.e. PHP/=94pre = POP=94 the initial adjacency label). To address this, the ingres router cou= ld indicate this initial adjacency label in the Target FEC stack of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_D0351A48586A1naikumarciscocom_-- From nobody Tue Sep 9 18:53: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 58A4E1A02F7 for ; Tue, 9 Sep 2014 18:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ecHI9n0FEGjL for ; Tue, 9 Sep 2014 18:53:33 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA551A02EC for ; Tue, 9 Sep 2014 18:53:31 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-82-540f5730941e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.82.25146.0375F045; Tue, 9 Sep 2014 21:38:24 +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, 9 Sep 2014 21:53:19 -0400 From: Gregory Mirsky To: "Nagendra Kumar Nainar (naikumar)" , "Nobo Akiya (nobo)" , "bruno.decraene@orange.com" , "mpls@ietf.org" Thread-Topic: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHPzJfcXUCBw4NpKEua7u05+MtHR5v5mZ4A Date: Wed, 10 Sep 2014 01:53:19 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82E233@eusaamb103.ericsson.se> References: In-Reply-To: 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_7347100B5761DC41A166AC17F22DF1121B82E233eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXSPt65BOH+Iwa92VYsfO+YwW9xaupLV 4vXEqWwWszviHVg8pvzeyOqxZMlPJo+WZyfZApijuGxSUnMyy1KL9O0SuDLWN+xiK5i/nani wPx9zA2MxyYydTFyckgImEg8b57LCmGLSVy4t56ti5GLQ0jgKKPE0fWr2CGcZYwSyxfdBKti EzCSeLGxBywhIrCfUWLDprVgCWGBDIn2D/uBEhxAiUyJ6V/ANogA1V//uYIRJMwioCpxqEMI JMwr4CvRs2MWI4gtJKAvcWPXDnYQm1PAQKL5+HKwVkagg76fWgNmMwuIS9x6Mh/qaAGJJXvO M0PYohIvH/+DekBRYl//dHaI+nyJrscrWSF2CUqcnPmEZQKjyCwko2YhKZuFpAwiridxY+oU NghbW2LZwtfMELauxIx/h1iQxRcwsq9i5CgtTi3LTTcy3MQIjK5jEmyOOxgXfLI8xCjAwajE w6vgwB8ixJpYVlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGLfl/ tSperz8WC3G84cuqb9sgZCRuWznxuMpf/lPCTU/qG+8l1dlOdUsS+uuzWDaOpypV+HTUg5/T xdTk1eI+RhqvqBecKrIseLf6XYuOvk/Brwq+Oa/9zzHJ9R5Pra30w4m7Gy/MnNVkFPBG6/fM wptej9843LxbdV7uWeessvtPmzzidr5WYinOSDTUYi4qTgQAg8K8ZY8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hfjnlPFiaFfgbe1DRe9trnj3x3k Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 10 Sep 2014 01:53:39 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82E233eusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, sorry I've missed the initial question by Bruno. I'd like to refer to the Bidirectional Forwarding Detection (BFD) Directed = Return Path draft that was presented and discussed at BFD, MPLS, and SPRING= WGs in Toronto. Sections 3.1.2 and 3.2 introduce new sub-TLVs for MPLS and= IPv6 data plane of Segment Routing domain that can be used in combination = with RFC 7110. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nagendra Kumar Naina= r (naikumar) Sent: Tuesday, September 09, 2014 6:38 PM To: Nobo Akiya (nobo); bruno.decraene@orange.com; mpls@ietf.org Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping Hi Bruno/Nobo, I agree with you both that this use case is useful. Per my understanding, e= xtending RFC7110 and let Initiator to pre-calculate the reverse segment sta= ck and populating the same is also possible. While I understand the concern= raised b Nobo, I think the FRR will be in place for reverse path as well a= nd so should be able to reach the Initiator. The other approach of having the responder calculate the return path is als= o reasonable. In either case, I think the extension should be included in d= raft-kumarkini-mpls-spring-lsp-ping. Thanks, Nagendra From: "Nobo Akiya (nobo)" > Date: Friday, September 5, 2014 at 9:26 PM To: "bruno.decraene@orange.com" >, "mpls@ietf.org" > Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping Hi Bruno, I very much agree that the use case that you raised is useful for LSP Ping/= Trace on SPRING. In terms of how, there are few aspects that I'd like to highlight. 1. To accomplish MPLS Echo Reply messages taking a return path that m= irrors the forward path, generally there are two approaches. a. Sender of MPLS Echo Request messages (initiator) to compute the mi= rroring return path and include the information in the MPLS Echo Request. T= his can be done via extending RFC7110. b. Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path (this is the logic you described in your email). 2. With the approach (1a), return path computation requires that the = initiator try to determine where the packet will terminate (thus incoming l= abel stack on that node). That will be ok in a stable state but can get pro= blematic when there are changes happening in the network (convergence, FRR)= . Instead, I tend to think (and agree) the approach (1b) of the responder c= omputing the mirroring return path is superior. 3. I've heard some stories about folks wanting to do path association= on end-points in SPRING to create bi-directional "tunnels". These "tunnels= " will have a real reverse LSP. So the Reply Mode "reverse LSP" should appl= y to such bi-directional "tunnels". 4. Thus to address this use case, I think we need a new Reply Mode de= fined instead of using Reply Mode "reverse LSP". 5. How do we preserve the forward segment stack in the MPLS Echo Requ= est? a. One way is for the entire segment stack to be described in the Tar= get FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is = expected normally is that Target FEC Stack shrinks as initiator receives "F= EC Stack Change with POP" from downstream LSRs. It's worth keeping this beh= avior. b. Another way is to introduce a new TLV that describes the entire seg= ment stack pushed by the initiator, and that can get used by the responder = along with the logic you described. In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a goo= d way to address the use case you raised. Logistically, these extensions (if we agree to extend) should be described = in draft-kumarkini-mpls-spring-lsp-ping. I would certainly like to hear from other experts on this matter as well. Thanks! -Nobo From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, September 05, 2014 9:03 AM To: mpls@ietf.org; Nobo Akiya (nobo) Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls= -spring-lsp-ping Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs a= nd TP LSPs". I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC = stack TLV (e.g. L1, L2 ... Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3... Ln) c. Get the ingress to local segment list/path by subtracting both sta= cks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For nod= e segments, keep them unchanged, for adjacency segment, use the reverse adj= acency. This is computationally very simple and but requires the IGP metric= to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that's already the cas= e for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/"pre POP" the initial adjacency label). To address = this, the ingres router could indicate this initial adjacency label in the = Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_7347100B5761DC41A166AC17F22DF1121B82E233eusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

sorry I’ve misse= d the initial question by Bruno.

I’d like to refe= r to the Bidirectional Forwarding Detection (BFD) Directed Return Path draf= t that was presented and discussed at BFD, MPLS, and SPRING WGs in Toronto.= Sections 3.1.2 and 3.2 introduce new sub-TLVs for MPLS and IPv6 data plane of Segment Routing domain that can be used in= combination with RFC 7110.

 

   &nbs= p;            Regard= s,

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

 

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Nagendra Kumar Nainar (naikumar)
Sent: Tuesday, September 09, 2014 6:38 PM
To: Nobo Akiya (nobo); bruno.decraene@orange.com; mpls@ietf.org
Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple &= ; draft-kumarkini-mpls-spring-lsp-ping

 

Hi Brun= o/Nobo,

&n= bsp;

I agree= with you both that this use case is useful. Per my understanding, extendin= g RFC7110 and let Initiator to pre-calculate the reverse segment stack and = populating the same is also possible. While I understand the concern raised b Nobo, I think the FRR will be in p= lace for reverse path as well and so should be able to reach the Initiator.=

&n= bsp;

The oth= er approach of having the responder calculate the return path is also reaso= nable. In either case, I think the extension should be included in draft-ku= markini-mpls-spring-lsp-ping.

&n= bsp;

Thanks,=

Nagendr= a

&n= bsp;

From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Friday, September 5, 2014 at 9:26 PM
To: "bruno.decraen= e@orange.com" <bru= no.decraene@orange.com>, "mpls= @ietf.org" <mpls@ietf.org&= gt;
Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple &= ; draft-kumarkini-mpls-spring-lsp-ping

&n= bsp;

Hi Brun= o,

 <= /span>

I very = much agree that the use case that you raised is useful for LSP Ping/Trace o= n SPRING.

 <= /span>

In term= s of how, there are few aspects that I’d like to highlight.

 <= /span>

1.       To accomplish MPLS Echo Reply messages taking a return path that mirrors t= he forward path, generally there are two approaches.

a.       Sender of MPLS Echo Request messages (initiator) to compute the mirroring = return path and include the information in the MPLS Echo Request. This can = be done via extending RFC7110.

b.      Sender of MPLS Echo Reply messages (responder) to compute the mirroring re= turn path (this is the logic you described in your email).

2.       With the approach (1a), return path computation requires that the initiato= r try to determine where the packet will terminate (thus incoming label sta= ck on that node). That will be ok in a stable state but can get problematic when there are changes happening in= the network (convergence, FRR). Instead, I tend to think (and agree) the a= pproach (1b) of the responder computing the mirroring return path is superi= or.

3.       I’ve heard some stories about folks wanting to do path association o= n end-points in SPRING to create bi-directional “tunnels”. Thes= e “tunnels” will have a real reverse LSP. So the Reply Mode “reverse LSP” should apply to such bi-directional “= tunnels”.

4.       Thus to address this use case, I think we need a new Reply Mode defined in= stead of using Reply Mode “reverse LSP”.

5.       How do we preserve the forward segment stack in the MPLS Echo Request?

a.       One way is for the entire segment stack to be described in the Target FEC = Stack TLV. Although when LSP Traceroute is done on SRPING, what is expected= normally is that Target FEC Stack shrinks as initiator receives “FEC Stack Change with POP” from downstr= eam LSRs. It’s worth keeping this behavior.

b.      Another way is to introduce a new TLV that describes the entire segment st= ack pushed by the initiator, and that can get used by the responder along w= ith the logic you described.

 <= /span>

In summ= ary, my personal opinion will be (1b), new Reply Mode, (5b) is a good way t= o address the use case you raised.

 <= /span>

Logisti= cally, these extensions (if we agree to extend) should be described in draf= t-kumarkini-mpls-spring-lsp-ping.

 <= /span>

I would= certainly like to hear from other experts on this matter as well.

 <= /span>

Thanks!=

 <= /span>

-Nobo

 <= /span>

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, September 05, 2014 9:03 AM
To: mpls@ietf.org; Nobo Akiya (= nobo)
Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping

 

Hi all,

 

*) Short version (use ca= se):

draft-akiya-mpls-lsp-pin= g-reply-mode-simple defines a new Reply mode for MPLS LSP Ping: “Repl= y via reverse LSP”, with an applicability to “RSVP LSPs and TP = LSPs”.

I have the rough impress= ion that this mode would also be very applicable in SPRING networks/LSPs si= nce the responder would be able send the reply along the same (reverse)/co-= routed path than the requester.

Could this be investigat= ed? (on the mailing list or in either of the above 2 drafts).

 

*) Long version (propose= d solution):

a)      The responder is= /should be able to get/infer the incoming path

a.       Get the end to e= nd segment list/path a priori from the Target FEC stack TLV (e.g. L1, L2 &#= 8230; Ln)

b.      Get the local to= end segment list/path from the label stack in the received packet (e.g. L3= … Ln)

c.       Get the ingress = to local segment list/path by subtracting both stacks (e.g. L1, L2)<= span lang=3D"EN-CA" style=3D"color:black">

b)      Using SR, the re= sponder is able to enforce any explicit path, so in particular the reverse = path from local to ingress. 2 options for this:

a.       Simple one: reve= rse the order of the segments in the path. For node segments, keep them unc= hanged, for adjacency segment, use the reverse adjacency. This is computati= onally very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse dir= ection.=

b.      Exact one: compu= te the exact forward path (SPF rooted on the sender then follow the segment= s stack).Then reverse the path and compute the list of segments required to= enforce this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segment). This is com= putationally more expensive but enforces the same path in all cases. (seems= a bit scary from a DOS perspective, to use significant control plane resou= rces in response to a forwarding plane packet, but in essence, that’s already the case for ping/traceroute)=

I guess that the choice could be a local choice on the responder, confi= gured by the SP (e.g. depending on its use of asymmetric IGP costs)<= span lang=3D"EN-CA" style=3D"color:black">

 

A priori this would be a= pplicable to both MPLS ping and traceroute.

 

Caveats:

1) restricted to a singl= e IGP area. But this is a usual limitation of TE in a multi-area network. (= and typical solution may also apply e.g. PCE)

2) The spring ingress ro= uter may have pushed the packet on a non shortest path interface (i.e. PHP/= ”pre POP” the initial adjacency label). To address this, the in= gres router could indicate this initial adjacency label in the Target FEC stack of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

______________________________=
___________________________________________________________________________=
________________
 
Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler=

a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant susceptibles=
 d'alteration,=

Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law;
they should not be distributed=
, used or copied without authorisation.
If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.<=
/pre>

As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.


Thank you.
--_000_7347100B5761DC41A166AC17F22DF1121B82E233eusaamb103erics_-- From nobody Tue Sep 9 19:52: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 C8A331A017C for ; Tue, 9 Sep 2014 19:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 NAEeOmUTx0th for ; Tue, 9 Sep 2014 19:52:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C841A0389 for ; Tue, 9 Sep 2014 19:52:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJG16223; Wed, 10 Sep 2014 02:52:06 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Sep 2014 03:52:04 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 10 Sep 2014 10:52:01 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "bruno.decraene@orange.com" , "mpls@ietf.org" Thread-Topic: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: Ac/I3NBe/9xEsa0FTUaOUQSDRUmfigAjuShQAM0Js/A= Date: Wed, 10 Sep 2014 02:52:01 +0000 Message-ID: References: <22701_1409922181_5409B485_22701_1961_1_53C29892C857584299CBF5D05346208A071EF2E8@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: 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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA95BACSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/25DQka2t_RkstrSwfr4D_vCrdc0 Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 10 Sep 2014 02:52:15 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA95BACSZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nobo and Bruno I think both 1a) and 1b) may have their usage. As you said, 1b) is suitable= for the cases where there are more network changes. There is also the case= that the ingress or the centralized controller (PCE) wants to control both= the forward and reverse paths computation. Technically, both 1a) and 1b) can be achieved by introducing new sub-TLVs t= o Reply Path TLV (RFC7110). And I agree that draft-kumarkini-mpls-spring-ls= p-ping should be the right place. Best regards, Mach From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) Sent: Saturday, September 06, 2014 9:26 AM To: bruno.decraene@orange.com; mpls@ietf.org Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping Hi Bruno, I very much agree that the use case that you raised is useful for LSP Ping/= Trace on SPRING. In terms of how, there are few aspects that I'd like to highlight. 1. To accomplish MPLS Echo Reply messages taking a return path that m= irrors the forward path, generally there are two approaches. a. Sender of MPLS Echo Request messages (initiator) to compute the mi= rroring return path and include the information in the MPLS Echo Request. T= his can be done via extending RFC7110. b. Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path (this is the logic you described in your email). 2. With the approach (1a), return path computation requires that the = initiator try to determine where the packet will terminate (thus incoming l= abel stack on that node). That will be ok in a stable state but can get pro= blematic when there are changes happening in the network (convergence, FRR)= . Instead, I tend to think (and agree) the approach (1b) of the responder c= omputing the mirroring return path is superior. 3. I've heard some stories about folks wanting to do path association= on end-points in SPRING to create bi-directional "tunnels". These "tunnels= " will have a real reverse LSP. So the Reply Mode "reverse LSP" should appl= y to such bi-directional "tunnels". 4. Thus to address this use case, I think we need a new Reply Mode de= fined instead of using Reply Mode "reverse LSP". 5. How do we preserve the forward segment stack in the MPLS Echo Requ= est? a. One way is for the entire segment stack to be described in the Tar= get FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is = expected normally is that Target FEC Stack shrinks as initiator receives "F= EC Stack Change with POP" from downstream LSRs. It's worth keeping this beh= avior. b. Another way is to introduce a new TLV that describes the entire seg= ment stack pushed by the initiator, and that can get used by the responder = along with the logic you described. In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a goo= d way to address the use case you raised. Logistically, these extensions (if we agree to extend) should be described = in draft-kumarkini-mpls-spring-lsp-ping. I would certainly like to hear from other experts on this matter as well. Thanks! -Nobo From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, September 05, 2014 9:03 AM To: mpls@ietf.org; Nobo Akiya (nobo) Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls= -spring-lsp-ping Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs a= nd TP LSPs". I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC = stack TLV (e.g. L1, L2 ... Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3... Ln) c. Get the ingress to local segment list/path by subtracting both sta= cks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For nod= e segments, keep them unchanged, for adjacency segment, use the reverse adj= acency. This is computationally very simple and but requires the IGP metric= to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that's already the cas= e for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/"pre POP" the initial adjacency label). To address = this, the ingres router could indicate this initial adjacency label in the = Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA95BACSZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= H= i Nobo and Bruno

= <= o:p> 

= I think both 1a) and 1b) may have their usage. As you said, 1b) is suitable = for the cases where there are more network changes. There is also the case = that the ingress or the centralized controller (PCE) wants to control both = the forward  and reverse paths computation= .  

= <= o:p> 

= T= echnically, both 1a) and 1b) can be achieved by introducing new sub-TLVs to Reply Path= TLV (RFC7110). And I agree that draft-kumarkini-mpls-spring-lsp-ping should be the right place.=

= <= o:p> 

= B= est regards,

= M= ach

=  

From: mpls [mailto:mpls-bounces@ietf.org] On= Behalf Of Nobo Akiya (nobo)
Sent: Saturday, September 06= , 2014 9:26 AM
To: bruno.decraene@orange.co= m; mpls@ietf.org
Subject: Re: [mpls] draft-ak= iya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-p= ing

 

= Hi Bruno,

=  

= I very much agree that the use case that you raised is useful fo= r LSP Ping/Trace on SPRING.

=  

= In terms of how, there are few aspects that I’d like to hi= ghlight.

=  

1.       To accomplis= h MPLS Echo Reply messages taking a return path that mirrors the forward pa= th, generally there are two approaches.

a.=        Sender of MP= LS Echo Request messages (initiator) to compute the mirroring return path a= nd include the information in the MPLS Echo Request. This can be done via extending RFC7110.

b.=       Sender of MP= LS Echo Reply messages (responder) to compute the mirroring return path (th= is is the logic you described in your email).

2.       With the app= roach (1a), return path computation requires that the initiator try to dete= rmine where the packet will terminate (thus incoming label stack on that node). That will be ok in a stable stat= e but can get problematic when there are changes happening in the network (= convergence, FRR). Instead, I tend to think (and agree) the approach (1b) o= f the responder computing the mirroring return path is superior.

3.       I’ve h= eard some stories about folks wanting to do path association on end-points = in SPRING to create bi-directional “tunnels”. These “tunnels” will have a real reverse LSP. So the Reply Mod= e “reverse LSP” should apply to such bi-directional “tunn= els”.

4.       Thus to addr= ess this use case, I think we need a new Reply Mode defined instead of usin= g Reply Mode “reverse LSP”.

5.       How do we pr= eserve the forward segment stack in the MPLS Echo Request?

a.=        One way is f= or the entire segment stack to be described in the Target FEC Stack TLV. Al= though when LSP Traceroute is done on SRPING, what is expected normally is that Target FEC Stack shrinks as init= iator receives “FEC Stack Change with POP” from downstream LSRs= . It’s worth keeping this behavior.

b.=       Another way = is to introduce a new TLV that describes the entire segment stack pushed by= the initiator, and that can get used by the responder along with the logic you described.

=  

= In summary, my personal opinion will be (1b), new Reply Mode, (5= b) is a good way to address the use case you raised.

=  

= Logistically, these extensions (if we agree to extend) should be= described in draft-kumarkini-mpls-spring-lsp-ping.

=  

= I would certainly like to hear from other experts on this matter= as well.

=  

= Thanks!

=  

= -Nobo

=  

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, September 05, = 2014 9:03 AM
To: mpls@ietf.org; Nobo Akiya (nobo)
Subject: draft-akiya-mpls-ls= p-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping

 

Hi all,

 

*) Short version (use case):

draft-akiya-mpls-lsp-ping-reply-mode-simple d= efines a new Reply mode for MPLS LSP Ping: “Reply via reverse LSPR= 21;, with an applicability to “RSVP LSPs and TP LSPs”.

I have the rough impression that this mode wo= uld also be very applicable in SPRING networks/LSPs since the responder wou= ld be able send the reply along the same (reverse)/co-routed path than the requester.

Could this be investigated? (on the mailing l= ist or in either of the above 2 drafts).

 

*) Long version (proposed solution):

a)    =   The respo= nder is/should be able to get/infer the incoming path

a.     &nbs= p; Get the e= nd to end segment list/path a priori from the Target FEC stack TLV (e.g. L1= , L2 … Ln)

b.      Get the l= ocal to end segment list/path from the label stack in the received packet (= e.g. L3… Ln)

c.     &nbs= p; Get the i= ngress to local segment list/path by subtracting both stacks (e.g. L1, L2)<= o:p>

b)    =   Using SR,= the responder is able to enforce any explicit path, so in particular the r= everse path from local to ingress. 2 options for this:

a.     &nbs= p; Simple on= e: reverse the order of the segments in the path. For node segments, keep t= hem unchanged, for adjacency segment, use the reverse adjacency. This is co= mputationally very simple and but requires the IGP metric to be symmetric to enforce the same path in the re= verse direction.

b.      Exact one= : compute the exact forward path (SPF rooted on the sender then follow the = segments stack).Then reverse the path and compute the list of segments requ= ired to enforce this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segmen= t). This is computationally more expensive but enforces the same path in al= l cases. (seems a bit scary from a DOS perspective, to use significant cont= rol plane resources in response to a forwarding plane packet, but in essence, that’s already the case f= or ping/traceroute)

I guess that t= he choice could be a local choice on the responder, configured by the SP (e= .g. depending on its use of asymmetric IGP costs)<= /p>

 

A priori this would be applicable to both MPL= S ping and traceroute.

 

Caveats:

1) restricted to a single IGP area. But this = is a usual limitation of TE in a multi-area network. (and typical solution = may also apply e.g. PCE)

2) The spring ingress router may have pushed = the packet on a non shortest path interface (i.e. PHP/”pre POP”= the initial adjacency label). To address this, the ingres router could indicate this initial adjacency label in the Target FEC stack= of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

_________________________________________=
___________________________________________________________________________=
_____
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent don=
c
pas etre diffuses, exploites ou copies sa=
ns autorisation. Si vous avez recu ce message par erreur, veuillez le signa=
ler
a l'expediteur et le detruire ainsi que l=
es pieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce=
 message a ete altere, deforme ou falsifie. Merci.=

 
This message and its attachments may cont=
ain confidential or privileged information that may be protected by law;
they should not be distributed, used or c=
opied without authorisation.
If you have received this email in error,=
 please notify the sender and delete this message and its attachments.=

As emails may be altered, Orange is not l=
iable for messages that have been modified, changed or falsified.
Thank you.
--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA95BACSZXEMA510MBXchi_-- From nobody Wed Sep 10 01:05: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 044831A0680 for ; Wed, 10 Sep 2014 01:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 UXHv9y9cuuvP for ; Wed, 10 Sep 2014 01:05:56 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7F01A067C for ; Wed, 10 Sep 2014 01:05:56 -0700 (PDT) Received: from [192.168.0.101] (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 5774A180131A; Wed, 10 Sep 2014 10:05:54 +0200 (CEST) Message-ID: <54100668.3040503@pi.nu> Date: Wed, 10 Sep 2014 10:06:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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/2oMdw31lmcnNkDHZ6gLTCiyZQEc Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-pim-sm-over-mldp@tools.ietf.org" Subject: [mpls] Implementation poll for draft-ietf-mpls-pim-sm-over-mldp 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, 10 Sep 2014 08:05:58 -0000 Working Group, We are preparing the Publication Request for draft-ietf-mpls-pim-sm- over-mldp. One question we have to answer in the Shepherd Write Up is about existing implementations. This is to start the Implementation Poll. If you have or are aware of existing implementations of draft-ietf -mpls-pim-sm-over-mldp please send this information to the working group mailing list or directly to the working group chairs. /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 Wed Sep 10 03:05: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 E1C7D1A06E8 for ; Wed, 10 Sep 2014 03:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 a2YHJnciBsA4 for ; Wed, 10 Sep 2014 03:05:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82991A06EB for ; Wed, 10 Sep 2014 03:05:12 -0700 (PDT) Received: from [192.168.0.101] (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 75D55180131A; Wed, 10 Sep 2014 12:05:11 +0200 (CEST) Message-ID: <5410225D.60105@pi.nu> Date: Wed, 10 Sep 2014 12:05:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mcast@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/4BrJ5ETS1n0TurtrZuUnocdcJkE Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast 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, 10 Sep 2014 10:05:15 -0000 Working Group, draft-ietf-mpls-seamless-mcast have been through wglc and been updated after the wglc. We are ready to request publication. However we have made a procedural mistake that needs to be corrected. In the mail that started the wglc I wrote: "There are one IPR disclosure against this document. The authors has stated that he is unaware of any other IPRs that relate to this document." It is correct that there are one IPR disclosure, but we had never done an IPR poll and we did not have any responses. This was my mistake - I'm sorry for that - this mail is intended to correct this mistake and start the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mcast? 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 one 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 Sep 10 06:44: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 ED8281A00D5 for ; Wed, 10 Sep 2014 06:44:35 -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 AcudyCmFPsJb for ; Wed, 10 Sep 2014 06:44:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AB01A00E7 for ; Wed, 10 Sep 2014 06:44:34 -0700 (PDT) Received: from BL2PR05CA0044.namprd05.prod.outlook.com (10.255.226.44) by DM2PR05MB735.namprd05.prod.outlook.com (10.141.178.24) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 10 Sep 2014 13:44:31 +0000 Received: from BL2FFO11FD022.protection.gbl (2a01:111:f400:7c09::152) by BL2PR05CA0044.outlook.office365.com (2a01:111:e400:c04::44) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Wed, 10 Sep 2014 13:44:30 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Wed, 10 Sep 2014 13:44:30 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 10 Sep 2014 06:44:25 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s8ADiKn98815; Wed, 10 Sep 2014 06:44:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201409101344.s8ADiKn98815@magenta.juniper.net> To: Loa Andersson In-Reply-To: <5410225D.60105@pi.nu> References: <5410225D.60105@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 10 Sep 2014 12:05:17 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2606.1410356660.1@juniper.net> Date: Wed, 10 Sep 2014 06:44:20 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019019)(6009001)(24454002)(199003)(189002)(51704005)(50466002)(90102001)(97756001)(102836001)(69596002)(74502001)(31966008)(64706001)(4396001)(74662001)(21056001)(54356999)(230783001)(46406003)(23726002)(16796002)(85306004)(92726001)(68736004)(110136001)(105596002)(81342001)(6806004)(76482001)(81156004)(77982001)(76176999)(92566001)(85852003)(95666004)(80022001)(47776003)(99396002)(79102001)(83072002)(20776003)(44976005)(46102001)(86362001)(83322001)(81542001)(87936001)(97736003)(84676001)(50986999)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB735; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 033054F29A Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Kn2P6FfyacXtS9Sw8VQ5iJhAJ4A Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Subject: Re: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast 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, 10 Sep 2014 13:44:36 -0000 Loa, > Working Group, > > draft-ietf-mpls-seamless-mcast have been through wglc and been updated > after the wglc. We are ready to request publication. > > However we have made a procedural mistake that needs to be corrected. > In the mail that started the wglc I wrote: > "There are one IPR disclosure against this document. The authors has > stated that he is unaware of any other IPRs that relate to this > document." > > It is correct that there are one IPR disclosure, but we had never done > an IPR poll and we did not have any responses. This was my mistake - I'm > sorry for that - this mail is intended to correct this mistake and > start the IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mcast? > > 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 one 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. I am aware of only the IPR discloser you mentioned above. Yakov. From nobody Wed Sep 10 08:50: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 CA7071A8742 for ; Wed, 10 Sep 2014 08:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.502 X-Spam-Level: X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 yLJ5AUeUiN3c for ; Wed, 10 Sep 2014 08:50:01 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577821A872F for ; Wed, 10 Sep 2014 08:50:01 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail31.telekom.de with ESMTP; 10 Sep 2014 17:49:59 +0200 X-IronPort-AV: E=Sophos;i="5.04,499,1406584800"; d="scan'208";a="528870594" Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 10 Sep 2014 17:49:58 +0200 Received: from HE100024.emea1.cds.t-internal.com (10.125.65.200) by HE111527.EMEA1.CDS.T-INTERNAL.COM (10.125.90.86) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 10 Sep 2014 17:49:58 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE100024.emea1.cds.t-internal.com ([2002:769:410c::769:410c]) with mapi; Wed, 10 Sep 2014 17:49:57 +0200 From: To: , Date: Wed, 10 Sep 2014 17:49:56 +0200 Thread-Topic: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast Thread-Index: Ac/M/Wa9gHfsTrofRr2g6bV68h0fwAAEWJTw Message-ID: <9762ACF04FA26B4388476841256BDE02012FE9D173FA@HE111543.emea1.cds.t-internal.com> References: <5410225D.60105@pi.nu> <201409101344.s8ADiKn98815@magenta.juniper.net> In-Reply-To: <201409101344.s8ADiKn98815@magenta.juniper.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VhHsSOCGRV1v-c8I92KdFB-IL4Q Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast 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, 10 Sep 2014 15:50:04 -0000 Hi, same here. I am aware of only the IPR discloser you mentioned below. Regards Nic -----Urspr=FCngliche Nachricht----- Von: mpls [mailto:mpls-bounces@ietf.org] Im Auftrag von Yakov Rekhter Gesendet: Mittwoch, 10. September 2014 15:44 An: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-seamless-mca= st@tools.ietf.org Betreff: Re: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast Loa, > Working Group, >=20 > draft-ietf-mpls-seamless-mcast have been through wglc and been updated=20 > after the wglc. We are ready to request publication. >=20 > However we have made a procedural mistake that needs to be corrected. > In the mail that started the wglc I wrote: > "There are one IPR disclosure against this document. The authors has > stated that he is unaware of any other IPRs that relate to this > document." >=20 > It is correct that there are one IPR disclosure, but we had never done=20 > an IPR poll and we did not have any responses. This was my mistake -=20 > I'm sorry for that - this mail is intended to correct this mistake and=20 > start the IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mcast? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are one IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. *The response needs to be sent to the MPLS wg mailing=20 > list.* The document will not advance to the next stage until a=20 > response has been received from each author and contributor. I am aware of only the IPR discloser you mentioned above. Yakov. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Sep 10 10:27: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 35EA01A7017 for ; Wed, 10 Sep 2014 10:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.152 X-Spam-Level: X-Spam-Status: No, score=-116.152 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=-1.652, 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 4Sknw-78fG13 for ; Wed, 10 Sep 2014 10:27:20 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9E01A7016 for ; Wed, 10 Sep 2014 10:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50275; q=dns/txt; s=iport; t=1410370037; x=1411579637; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pJmtOlJFwGomBRrqrJbKJk2M5jECHUu/kO8SqZ5WplQ=; b=Upx8gxIxhGyviZq/o0W9QYqX+7PK/pmDGAL8fylP49cHlcKkbEa5B3JP /a/roh4yKjWJoS1wgK45zIX1NiTTdmq0RXSB9JUvshPCEflmpiqSQqAus yUr9NgGImpuZshiqm32gR9XKPlwoLCbmtQx0YrKZFW9rAv+AVvIlW+Irv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAFqJEFStJV2a/2dsb2JhbABfgkcjI1NbtEuUDIFph00BgRIWeIQDAQEBBC0+AxsCAQgRBAEBCxYBBgcyFAkIAQEEARIIE4gnAQy+dwEXigCEaxEBHzcBBoMpgR0FiwCEM4IWhDCCPYYlk1qCG4FGbIEPOYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,500,1406592000"; d="scan'208,217"; a="76725664" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 10 Sep 2014 17:27:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8AHRF6o011021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 17:27:15 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 12:27:14 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , "bruno.decraene@orange.com" , "mpls@ietf.org" , "Gregory Mirsky (gregory.mirsky@ericsson.com)" , "Nagendra Kumar Nainar (naikumar)" Thread-Topic: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping Thread-Index: Ac/I3NBe/9xEsa0FTUaOUQSDRUmfigAjuShQAM0Js/AAGkSW0A== Date: Wed, 10 Sep 2014 17:27:13 +0000 Message-ID: References: <22701_1409922181_5409B485_22701_1961_1_53C29892C857584299CBF5D05346208A071EF2E8@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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.105] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A3C9F84xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9ZIOnMJBs0ZAQ3bK8-arCd37lLQ Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls-spring-lsp-ping 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, 10 Sep 2014 17:27:26 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C9F84xmbalnx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [replying on the latest of this thread] Hi Bruno, Mach, Greg, Nagendra, et al, Allow me to take a stab at summarizing this email. - Use cases for both initiator computing and responder computing the= return path are valid. - [initiator computing] Sender of MPLS Echo Request messages (initia= tor) to compute the mirroring return path and include the information in th= e MPLS Echo Request. o Return path to be used for MPLS Echo Reply and BFD. o draft-mirsky-mpls-bfd-directed-00 focuses on BFD. o RFC 7110 extension can allow = MPLS Echo Reply and BFD, and one potential home for the extension is draft-= kumarkini-mpls-spring-lsp-ping-01. o Authors of draft-kumarkini-mpls-spring-lsp-ping-01 and draft-mirsky-mpls-bf= d-directed-00 should discuss. - [responder computing] Sender of MPLS Echo Reply messages (responde= r) to compute the mirroring return path. o Return path to be used for MPLS Echo Reply. o Need a TLV or Sub-TLV to describe the forward segment stack, and one po= tential is to create a Sub-TLV under Reply Path TLV (RFC 7110). o Right home for this extension is draft-kumarkini-mpls-spring-lsp-ping-0= 1. o Authors of draft-kumarkini-mpls-spring-lsp-ping-01 should define and includ= e the solution. In both approaches above, one small concern with extending RFC 7110 is the applicability to LSP Traceroute, = since LSP Traceroute is outside the scope of RFC 7110. This should be considered when defining the solutions= . Please chime in if I missed anything, miss-interpreted anything or you have= comments/questions. Thanks! -Nobo From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Tuesday, September 09, 2014 10:52 PM To: Nobo Akiya (nobo); bruno.decraene@orange.com; mpls@ietf.org Subject: RE: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-= mpls-spring-lsp-ping Hi Nobo and Bruno I think both 1a) and 1b) may have their usage. As you said, 1b) is suitable= for the cases where there are more network changes. There is also the case= that the ingress or the centralized controller (PCE) wants to control both= the forward and reverse paths computation. Technically, both 1a) and 1b) can be achieved by introducing new sub-TLVs t= o Reply Path TLV (RFC7110). And I agree that draft-kumarkini-mpls-spring-ls= p-ping should be the right place. Best regards, Mach From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) Sent: Saturday, September 06, 2014 9:26 AM To: bruno.decraene@orange.com; mpls@ietf.= org Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping Hi Bruno, I very much agree that the use case that you raised is useful for LSP Ping/= Trace on SPRING. In terms of how, there are few aspects that I'd like to highlight. 1. To accomplish MPLS Echo Reply messages taking a return path that mi= rrors the forward path, generally there are two approaches. a. Sender of MPLS Echo Request messages (initiator) to compute the mir= roring return path and include the information in the MPLS Echo Request. Th= is can be done via extending RFC7110. b. Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path (this is the logic you described in your email). 2. With the approach (1a), return path computation requires that the i= nitiator try to determine where the packet will terminate (thus incoming la= bel stack on that node). That will be ok in a stable state but can get prob= lematic when there are changes happening in the network (convergence, FRR).= Instead, I tend to think (and agree) the approach (1b) of the responder co= mputing the mirroring return path is superior. 3. I've heard some stories about folks wanting to do path association = on end-points in SPRING to create bi-directional "tunnels". These "tunnels"= will have a real reverse LSP. So the Reply Mode "reverse LSP" should apply= to such bi-directional "tunnels". 4. Thus to address this use case, I think we need a new Reply Mode def= ined instead of using Reply Mode "reverse LSP". 5. How do we preserve the forward segment stack in the MPLS Echo Reque= st? a. One way is for the entire segment stack to be described in the Targ= et FEC Stack TLV. Although when LSP Traceroute is done on SRPING, what is e= xpected normally is that Target FEC Stack shrinks as initiator receives "FE= C Stack Change with POP" from downstream LSRs. It's worth keeping this beha= vior. b. Another way is to introduce a new TLV that describes the entire seg= ment stack pushed by the initiator, and that can get used by the responder = along with the logic you described. In summary, my personal opinion will be (1b), new Reply Mode, (5b) is a goo= d way to address the use case you raised. Logistically, these extensions (if we agree to extend) should be described = in draft-kumarkini-mpls-spring-lsp-ping. I would certainly like to hear from other experts on this matter as well. Thanks! -Nobo From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, September 05, 2014 9:03 AM To: mpls@ietf.org; Nobo Akiya (nobo) Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kumarkini-mpls= -spring-lsp-ping Hi all, *) Short version (use case): draft-akiya-mpls-lsp-ping-reply-mode-simple defines a new Reply mode for MP= LS LSP Ping: "Reply via reverse LSP", with an applicability to "RSVP LSPs a= nd TP LSPs". I have the rough impression that this mode would also be very applicable in= SPRING networks/LSPs since the responder would be able send the reply alon= g the same (reverse)/co-routed path than the requester. Could this be investigated? (on the mailing list or in either of the above = 2 drafts). *) Long version (proposed solution): a) The responder is/should be able to get/infer the incoming path a. Get the end to end segment list/path a priori from the Target FEC s= tack TLV (e.g. L1, L2 ... Ln) b. Get the local to end segment list/path from the label stack in the = received packet (e.g. L3... Ln) c. Get the ingress to local segment list/path by subtracting both stac= ks (e.g. L1, L2) b) Using SR, the responder is able to enforce any explicit path, so in= particular the reverse path from local to ingress. 2 options for this: a. Simple one: reverse the order of the segments in the path. For node= segments, keep them unchanged, for adjacency segment, use the reverse adja= cency. This is computationally very simple and but requires the IGP metric = to be symmetric to enforce the same path in the reverse direction. b. Exact one: compute the exact forward path (SPF rooted on the sender= then follow the segments stack).Then reverse the path and compute the list= of segments required to enforce this path as with any explicitly rooted pa= th. (a na=EFve algo would require 1 SPF per segment). This is computational= ly more expensive but enforces the same path in all cases. (seems a bit sca= ry from a DOS perspective, to use significant control plane resources in re= sponse to a forwarding plane packet, but in essence, that's already the cas= e for ping/traceroute) I guess that the choice could be a local choice on the responder, configure= d by the SP (e.g. depending on its use of asymmetric IGP costs) A priori this would be applicable to both MPLS ping and traceroute. Caveats: 1) restricted to a single IGP area. But this is a usual limitation of TE in= a multi-area network. (and typical solution may also apply e.g. PCE) 2) The spring ingress router may have pushed the packet on a non shortest p= ath interface (i.e. PHP/"pre POP" the initial adjacency label). To address = this, the ingres router could indicate this initial adjacency label in the = Target FEC stack of the LSP request. Comments welcomed. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CECE764681BE964CBE1DFF78F3CDD3943A3C9F84xmbalnx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[replying on the lates= t of this thread]

 

Hi Bruno, Mach, Greg, = Nagendra, et al,

 

Allow me to take a sta= b at summarizing this email.

 

-&nb= sp;       Use cases for = both initiator computing and responder computing the return path are valid.=

-&nb= sp;       [initiator com= puting] Sender of MPLS Echo Request messages (initiator) to compute the mir= roring return path and include the information in the MPLS Echo Request.

o   Return path to= be used for MPLS Echo Reply and BFD.<= o:p>

o   draft-mirsky-mpls-bfd-directed-0= 0 focuses on BFD.

o   RFC 7110 extension can allow MPLS Echo Reply an= d BFD, and one potential home for the extension is draft-kumarkini-mpls-spring-lsp-ping-01.

o   Authors of draft-kumarkini-mpls-spring-lsp-ping-01 and draft-mirsky-mpls-bfd-directed-00 should discuss.

-&nb= sp;       [responder com= puting] Sender of MPLS Echo Reply messages (responder) to compute the mirro= ring return path.

o   Return path to= be used for MPLS Echo Reply.

o   Need a TLV or = Sub-TLV to describe the forward segment stack, and one potential is to crea= te a Sub-TLV under Reply Path TLV (RFC 7110).

o   Right home for= this extension is draft-kumarkini-mpls-spring-lsp-ping-01.

o   Authors of draft-kumarkini-mpls-spring-lsp-ping-01 should define and include the solution= .

 

In both approaches abo= ve, one small concern with extending RFC = 7110 is the applicability to LSP Traceroute= , since LSP Traceroute is outside the scope of RFC = 7110. This should be considered wh= en defining the solutions.

 

Please chime in if I m= issed anything, miss-interpreted anything or you have comments/questions.

 

Thanks!

 

-Nobo

 

Mach = Chen [mailto:mach.chen@huawei.com]
Sent: Tuesday, September 09, 2014 10:52 PM
To: Nobo Akiya (nobo); bruno.decraene@orange.com; mpls@ietf.org
Subject: RE: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft= -kumarkini-mpls-spring-lsp-ping

 

Hi Nobo and Bruno

 

I think both 1a) and 1b) may have thei= r usage. As you said, 1b) is suitable for the cases where there are more ne= twork changes. There is also the case that the ingress or the centralized controller (PCE) wants to control both= the forward  and reverse paths computation. 

 

Technically, both 1a) and 1b) can be a= chieved by introducing new sub-TLVs to Reply Path TLV (RFC7110). And I agre= e that draft-kumarkini-mpls-spring-lsp-ping should be th= e right place.

 

Best regards,

Mach

 

From:= mpls [mailto:mpls-bounces@ietf.or= g] On Behalf Of Nobo Akiya (nobo)
Sent: Saturday, September 06, 2014 9:26 AM
To: bruno.decraene@oran= ge.com; mpls@ietf.org
Subject: Re: [mpls] draft-akiya-mpls-lsp-ping-reply-mode-simple &= ; draft-kumarkini-mpls-spring-lsp-ping

 

Hi Bruno,

 

I very much agree that= the use case that you raised is useful for LSP Ping/Trace on SPRING.<= /o:p>

 

In terms of how, there= are few aspects that I’d like to highlight.

 

1.&n= bsp;     To accomplish = MPLS Echo Reply messages taking a return path that mirrors the forward path= , generally there are two approaches.

a. &nbs= p;    Sender of MPLS= Echo Request messages (initiator) to compute the mirroring return path and= include the information in the MPLS Echo Request. This can be done via ext= ending RFC7110.

b. &nbs= p;    Sender of MPLS= Echo Reply messages (responder) to compute the mirroring return path (this= is the logic you described in your email).

2.&n= bsp;     With the appro= ach (1a), return path computation requires that the initiator try to determ= ine where the packet will terminate (thus incoming label stack on that node= ). That will be ok in a stable state but can get problematic when there are changes happening in the network (c= onvergence, FRR). Instead, I tend to think (and agree) the approach (1b) of= the responder computing the mirroring return path is superior.<= /span>

3.&n= bsp;     I’ve hea= rd some stories about folks wanting to do path association on end-points in= SPRING to create bi-directional “tunnels”. These “tunnel= s” will have a real reverse LSP. So the Reply Mode “reverse LSP” should apply to such bi-directional “tunnels”.=

4.&n= bsp;     Thus to addres= s this use case, I think we need a new Reply Mode defined instead of using = Reply Mode “reverse LSP”.

5.&n= bsp;     How do we pres= erve the forward segment stack in the MPLS Echo Request?<= /p>

a. &nbs= p;    One way is for= the entire segment stack to be described in the Target FEC Stack TLV. Alth= ough when LSP Traceroute is done on SRPING, what is expected normally is th= at Target FEC Stack shrinks as initiator receives “FEC Stack Change with POP” from downstream LSRs. It&= #8217;s worth keeping this behavior.

b. &nbs= p;    Another way is= to introduce a new TLV that describes the entire segment stack pushed by t= he initiator, and that can get used by the responder along with the logic y= ou described.

 

In summary, my persona= l opinion will be (1b), new Reply Mode, (5b) is a good way to address the u= se case you raised.

 

Logistically, these ex= tensions (if we agree to extend) should be described in draft-kumarkini-mpl= s-spring-lsp-ping.

 

I would certainly like= to hear from other experts on this matter as well.

 

Thanks!

 

-Nobo

 

bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, September 05, 2014 9:03 AM
To: mpls@ietf.org; Nobo Akiya (= nobo)
Subject: draft-akiya-mpls-lsp-ping-reply-mode-simple & draft-kum= arkini-mpls-spring-lsp-ping

 

Hi all,

 

*) Short version (use case):

draft-akiya-mpls-lsp-ping-reply= -mode-simple defines a new Reply mode for MPLS LSP Ping: “Reply via r= everse LSP”, with an applicability to “RSVP LSPs and TP LSPs= 221;.

I have the rough impression tha= t this mode would also be very applicable in SPRING networks/LSPs since the= responder would be able send the reply along the same (reverse)/co-routed = path than the requester.

Could this be investigated? (on= the mailing list or in either of the above 2 drafts).

 

*) Long version (proposed solut= ion):

a)  = ;    The responder is/should= be able to get/infer the incoming path

a= .   &= nbsp;  Get the end to end segm= ent list/path a priori from the Target FEC stack TLV (e.g. L1, L2 … L= n)

b= .   &= nbsp;  Get the local to end se= gment list/path from the label stack in the received packet (e.g. L3…= Ln)

c= .   &= nbsp;  Get the ingress to loca= l segment list/path by subtracting both stacks (e.g. L1, L2)

b)  = ;    Using SR, the responder= is able to enforce any explicit path, so in particular the reverse path fr= om local to ingress. 2 options for this:

a= .   &= nbsp;  Simple one: reverse the= order of the segments in the path. For node segments, keep them unchanged,= for adjacency segment, use the reverse adjacency. This is computationally = very simple and but requires the IGP metric to be symmetric to enforce the same path in the reverse direction.<= o:p>

b= .   &= nbsp;  Exact one: compute the = exact forward path (SPF rooted on the sender then follow the segments stack= ).Then reverse the path and compute the list of segments required to enforc= e this path as with any explicitly rooted path. (a na=EFve algo would require 1 SPF per segment). This is com= putationally more expensive but enforces the same path in all cases. (seems= a bit scary from a DOS perspective, to use significant control plane resou= rces in response to a forwarding plane packet, but in essence, that’s already the case for ping/traceroute)=

I g= uess that the choice could be a local choice on the responder, configured b= y the SP (e.g. depending on its use of asymmetric IGP costs)

 

A priori this would be applicab= le to both MPLS ping and traceroute.

 

Caveats:

1) restricted to a single IGP a= rea. But this is a usual limitation of TE in a multi-area network. (and typ= ical solution may also apply e.g. PCE)

2) The spring ingress router ma= y have pushed the packet on a non shortest path interface (i.e. PHP/”= pre POP” the initial adjacency label). To address this, the ingres ro= uter could indicate this initial adjacency label in the Target FEC stack of the LSP request.

 

 

Comments welcomed.

Thanks,

Regards,

Bruno

 

_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;


they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
o:p>


As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.<=
/o:p>


Thank you.
--_000_CECE764681BE964CBE1DFF78F3CDD3943A3C9F84xmbalnx01ciscoc_-- From nobody Wed Sep 10 12:05: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 8083A1A0028 for ; Wed, 10 Sep 2014 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 w08-m9DADX1V for ; Wed, 10 Sep 2014 12:05:12 -0700 (PDT) Received: from server.isocore.com (server.isocore.com [192.163.204.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698671A86EB for ; Wed, 10 Sep 2014 12:05:12 -0700 (PDT) Received: from [65.213.193.24] (port=49456 helo=adminPCR) by server.isocore.com with esmtpa (Exim 4.82) (envelope-from ) id 1XRnCZ-0001a2-6d for mpls@ietf.org; Wed, 10 Sep 2014 19:05:11 +0000 From: "Shamjhana" To: Date: Wed, 10 Sep 2014 15:05:01 -0400 Message-ID: <002401cfcd2a$1f9ff190$5edfd4b0$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01CFCD08.988FB120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/NKNBVaFrn1XKEQ0W29dZZWLHarg== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.isocore.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Get-Message-Sender-Via: server.isocore.com: authenticated_id: spokharel@isocore.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3_ZS6z1tI3SGno1zIOLyzmish6w Subject: [mpls] SDN/MPLS 2014 Conference 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, 10 Sep 2014 19:05:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01CFCD08.988FB120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SDN/MPLS 2014 Conference will take place November 2-5 in Washington DC and will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Virtualization, SDN, Cloud and Data Centers, NFV, PCE, Mobility, Traffic Engineering, Transport SDN, Orchestration, multi-play applications across common infrastructure and other emerging technologies. The SDN/MPLS 2014 Conference program is available at http://www.isocore.com/sdn-mpls/ Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm Please make sure to register for the SDN/MPLS 2014 by September 15 for reduced rate registration. Please do so at: http://www.isocore.com/sdn-mpls/attendees.php Lastly, the conference hotel is the Marriott Wardman Park in Washington DC. Please note discounted rates are available for a limited time only. Please book your reservations at: https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new &groupID=25088120 ------=_NextPart_000_0025_01CFCD08.988FB120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = SDN/MPLS 2014 Conference will take place November 2-5 in Washington DC = and will
include an extensive four day program consisting of = tutorials, technical
sessions, panels, and exhibits. The key topics = to be discussed at this
year's conference include: Virtualization, = SDN, Cloud and Data Centers, NFV,
PCE, Mobility, Traffic Engineering, = Transport SDN, Orchestration,
multi-play applications across common = infrastructure and other emerging technologies.

 

The SDN/MPLS = 2014 Conference program is = available at http://www.isocore.com/sdn-mpls= /
Tutorials (Sunday): http://www.isocore= .com/sdn-mpls/tutorials.htm
Technical sessions (Mon- = Wed): http://ww= w.isocore.com/sdn-mpls/technical_sessions.htm

Please make = sure to register for the SDN/MPLS 2014 by September 15 for = reduced rate registration. Please do so at:

http://www.isocore.com/sdn-mpls/attendees.php

Lastly, the conference hotel is the Marriott Wardman Park = in Washington DC. Please
note discounted rates are available for a = limited time only. Please book your

reservations at:

https://resweb.passkey.com/Resweb.do?mode=3Dwelcome_gi_= new&groupID=3D25088120

 

------=_NextPart_000_0025_01CFCD08.988FB120-- From nobody Wed Sep 10 12:23:06 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 205D91A86EB; Wed, 10 Sep 2014 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NTyzLDBWDaX8; Wed, 10 Sep 2014 12:23:03 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA251A0659; Wed, 10 Sep 2014 12:23:02 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-55-54104d25e967 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.16.25146.52D40145; Wed, 10 Sep 2014 15:07:50 +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; Wed, 10 Sep 2014 15:22:51 -0400 From: Gregory Mirsky To: "ipfix@ietf.org" Thread-Topic: MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: Ac/NKwbd4PEEn4EDQnes99jLrEnN8A== Date: Wed, 10 Sep 2014 19:22:51 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82E898@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_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPt66ar0CIwZuT7BbHrr5mt7i1dCWr A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy9q//xlowObDi38LfTA2MJz26GDk5JARMJHY+fcIK YYtJXLi3nq2LkYtDSOAoo8S6zf2MEM5yRokDkzrZQKrYBIwkXmzsYQexRQRUJWZ2nmTpYuTg YBZQljh1VwYkLCwQJHH+2RqoknCJ3R+WsUHYehIfdi8FW8YC1NqwZg5YDa+Ar8Sps5cZQWxG oCO+n1rDBGIzC4hL3HoynwniOAGJJXvOM0PYohIvH/+DOlpJYtLSc6wQJ+RLbFkUDTFSUOLk zCcsExiFZyGZNAuhahaSKogSHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR 4SZGYFwck2Bz3MG44JPlIUYBDkYlHl4FB/4QIdbEsuLK3EOM0hwsSuK8mtXzgoUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwMgrmlYf/0eS9Ghg+TetUfyOPnU75qqmLziovLVzGsWR6+Jv5 qW6qieWuv1N4FfLXK0YEJGpX9y8/ZVTJrCJ98fmkPH8r3pzZG9gEXX028DK7+vC5lR/Rsryl 0xrtqHp1wqov3dxZtfKugbLzq19d/njzr+j7n5KMVbZrTb87NN6/vqHO4I4SS3FGoqEWc1Fx IgDe/iBLbAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1bm2e9TcZ7ITOztjWR1actUyILc Cc: "mpls@ietf.org" Subject: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 10 Sep 2014 19:23:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in several places of describing MPLS Label element IEs the registry still r= efers to the EXP field even though the RFC 5462 updated RFC 3032 and rename= d it "Traffic Class" (TC). Below is the list of IEs that may benefit from u= pdating Description and Reference information: * mplsTopLabelStackSection * mplsTopLabelStackSection2 * mplsTopLabelStackSection3 * mplsTopLabelStackSection4 * mplsTopLabelStackSection5 * mplsTopLabelStackSection6 * mplsTopLabelStackSection7 * mplsTopLabelStackSection8 * mplsTopLabelStackSection9 * mplsTopLabelStackSection10 * mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be = created instead?) * postMplsTopLabelExp (should this be deprecated and postMplsTopLab= elTc be created instead?) Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

in several places of describing MPLS Label element I= Es the registry still refers to the EXP field even though the RFC 5462 upda= ted RFC 3032 and renamed it “Traffic Class” (TC). Below is the = list of IEs that may benefit from updating Description and Reference information:

·         mplsTopLabelStackSection

·         mplsTopLabelStackSection2

·         mplsTopLabelStackSection3

·         mplsTopLabelStackSection4

·         mplsTopLabelStackSection5

·         mplsTopLabelStackSection6

·         mplsTopLabelStackSection7

·         mplsTopLabelStackSection8

·         mplsTopLabelStackSection9

·         mplsTopLabelStackSection10

·         mplsTopLabelExp (should this be deprecated a= nd mplsTopLabelTc be created instead?)

·         postMplsTopLabelExp (should this be deprecat= ed and postMplsTopLabelTc be created instead?)

 

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82E898eusaamb103erics_-- From nobody Wed Sep 10 15:39: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 ABB381A8917 for ; Wed, 10 Sep 2014 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 M4wRUWNsUKmz for ; Wed, 10 Sep 2014 15:39:35 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E301A020B for ; Wed, 10 Sep 2014 15:39:34 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so1839538lab.19 for ; Wed, 10 Sep 2014 15:39:33 -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=kFpvcZ2o4JjEryMENN3wbq8Id8LhUeBRkSvOQlkqj08=; b=QMa1AnRchKpsa4AYOgTg5U2fJyFnM8YROqinI2znirOcaGzmWuZ2Qd4L0pcULJMt9w 7xqFJtwLNY70KpgPWXg04pxd+OVOJn+MEk19bUh+siJrtvctgF73nh5QdxCZr7NcRMrj poYO5dKVTc3MD2nBMfQ7VP/eCr6egvU8+j+8fBId3F8v3G26har+pITJ+qtMinOu4UWo bEJ8GuNb7FX5YFYAWvv5bTYYyqm5UVqcu4o2Qd9MdEq17/zZ9/HVpvSTmsGla6Eb82mN VjX17fA02phXmgOBOnVAqK2OoHkMMTZyK+8K5DEY6bOMWJ7eZMXLdZLJ0ZQx5OTfY2Wj nDYA== MIME-Version: 1.0 X-Received: by 10.112.138.39 with SMTP id qn7mr41794057lbb.25.1410388773220; Wed, 10 Sep 2014 15:39:33 -0700 (PDT) Received: by 10.25.141.7 with HTTP; Wed, 10 Sep 2014 15:39:33 -0700 (PDT) In-Reply-To: References: <53F5CA67.9070500@pi.nu> Date: Wed, 10 Sep 2014 15:39:33 -0700 Message-ID: From: Venkatesan Mahalingam To: Mach Chen Content-Type: multipart/alternative; boundary=089e011614ecd2b5b90502bdb993 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1k5uvXPTeoFx9SNThd2HfvzjnpQ Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules 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, 10 Sep 2014 22:39:38 -0000 --089e011614ecd2b5b90502bdb993 Content-Type: text/plain; charset=UTF-8 Hi Mach, Thanks for your thorough review. Please find below our responses in-lined. -MPLS OAM MIB team On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen wrote: > Hi Authors/Editors, > > I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG chairs > and Shepherd are working on the publication of > draft-ietf-mpls-tp-oam-id-mib. > > I have reviewed version 05 of the draft, here are my comments and some > questions, please consider. > > 1. > Extract the acronym when first use, for example, LSP in the Introduction, > and it's not necessary to extract an acronym when each uses, for example, > MPLS in section 1 and section 3.2 . > > *Thanks, will change it in the next version.* > 2. > In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPLS-TP > co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP > Pseudowires Identifiers and Section Identifiers. And in Section 5 of > RFC6370, there are some text that describes the difference between "MPLS > tunnel" and "MPLS LSP". In this draft, there are many usages of "tunnel" in > section 4, 5 and 6, and actually it should be "LSP". I know that sometimes > people alternatively use tunnel and LSP, but it's better to use the term in > an accurate way hence to reduce the confusion. > > *Yes, will state that explicitly in the next version.* > In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw and > section listed), it implies that the MPLS-TP point-to-point Tunnels > identifiers are actually precluded in this document. Is my understanding > right? If so, it needs look through the document and refine the text to > state it clearly. > > * mplsOamIdMegServicePointerType object is defined generically to handle any kind of service pointer (Tunnel, LSP, PW) these service pointers can be used for MPLS/MPLS-TP path.* Here are some example that may need updates: > > Section 4. > > OLD: > " > The MIB module supports configuration of OAM identifiers for > point-to-point, co-routed bidirectional, associated > bidirectional MPLS tunnels and MPLS Pseudowires. > " > NEW: > " > The MIB module supports configuration of OAM identifiers for > MPLS-TP co-routed bidirectional LSPs, associated > bidirectional LSPs, Sections and Pseudowires. > " > > *As mentioned above. we dont need to change the text (MPLS to MPLS-TP), will enhance the existing text to make the intention of this MIB clear.* > Section 5. > > s/...configurations for MPLS Tunnels and Pseudowires/...configurations for > MPLS-TP LSPs, Sections and Pseudowires > > Section 5.1 > > s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and > Pseudowires. > > Section 6 > > s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed > bidirectional LSP > > s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed > bidirectional LSP are illustrated here > > *Same as above.* > 3. > > For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe > following items? > mplsOamIdMeProactiveOamPhbTCValue = 0, > mplsOamIdMeOnDemandOamPhbTCValue = 0, > > It seems that they should not belong to this MIB, maybe better in other > MIB. > > *PHB TC values are defined in this MIB to basically use these values in Proactive(BFD)/OnDemand(LSP Ping) sessions. * 4. > > mplsOamIdMegPathFlow OBJECT-TYPE > SYNTAX INTEGER { > unidirectionalPointToPoint (1), > coRoutedBidirectionalPointToPoint (2), > associatedBidirectionalPointToPoint (3), > unidirectionalPointToMultiPoint (4) > > Seems RFC6370 does not define how to identify a > unidirectionalPointToMultiPoint path, and from the Introduction of this > document, the P2MP seems not be included. > *We will add more information for P2MP in the next version after the internal discussion. * > > 5. > > mplsOamIdMegSubOperStatus OBJECT-TYPE > SYNTAX BITS { > megDown (0), > meDown (1), > oamAppDown (2), > pathDown (3) > } > The bit 0 (megDown) indicates the MEG is down. > The bit 1 (meDown) indicates the ME table is > down. > The bit 2 (oamAppDown) indicates that the > OAM application has notified that the entity (LSP or PW) > monitored by this MEG is down. Currently, BFD is the > only supported OAM application. > The bit 3 (pathDown) indicates that the underlying > LSP or PW is down." > > I am not sure what's the mean of "down" here, especially the mean of "MEG > is down", "ME table is down" and "LSP and PW is down"? > > *We defined this object to notify the operational status of MEG, ME, OAM app and the MPLS/MPLS-TP path, will add more information in the next version.* > 6. > > mplsOamIdMeServicePointer OBJECT-TYPE > > SYNTAX RowPointer > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This variable represents a pointer to the MPLS-TP > transport path. This value MUST point at an entry in the > mplsTunnelEntry if mplsOamIdMegServicePointerType > is configured as lsp (1) or at an entry in the pwEntry if > mplsOamIdMegServicePointerType is configured > as pseudowire (2). > > How about mplsOamIdMegServicePointerTypesection is configured as section > (3)? > > *Section is not yet taken care in this MIB. Will add missing information after internal discussion.* And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP > tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry > and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry? > > *No,Tunnel & PW entries are augmented to have the extra fields in the new tables for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP path to OAM config association.* 7. > mplsOamIdMegServicePointerType OBJECT-TYPE > > SYNTAX INTEGER { > lsp (1), > pseudowire (2), > section (3) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates the service type for the MEG. > If the service type indicates lsp, the service pointer > in mplsOamIdMeTable points to an entry in > the mplsTunnelTable [RFC3812]. > > Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP > Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable and > reference be draft-ietf-mpls-tp-te-mib-08? > > *No, as stated above, this MIB is mainly defined to provide OAM configs for MPLS & MPLS-TP paths. * > > Best regards, > Mach > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Thursday, August 21, 2014 6:31 PM > > To: mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan > Cucchiara; > > Mach Chen; > > Subject: Shepherds for MPLS MIB modules > > > > Working Group, > > > > We have for some time been looking for someone to help us shepherding our > > MIB modules. I'm happy to announce that Mach Chen and Young Lee has > agreed > > to help us. > > > > Please help Mach and Young as they start working with the documents. > > > > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib. > > > > Further shepherd assignments will be done as soon as the details are > sorted out. > > > > > > /Loa > > for the mpls wg chairs > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --089e011614ecd2b5b90502bdb993 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mach,

Thanks for your thorough revie= w. Please find below our responses in-lined.

-MPLS= OAM MIB team

= On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen <mach.chen@huawei.com>= ; wrote:
Hi Authors/Editors,

I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG chairs = and Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-mi= b.

I have reviewed version 05 of the draft, here are my comments and some ques= tions, please consider.

1.
Extract the acronym when first use, for example, LSP in the Introduction, a= nd it's not necessary to extract an acronym when each uses, for example= , MPLS in section 1 and section 3.2 .

Thanks, will change it in the next version.
=C2=A0
2.
In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPLS-TP = co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP Pseud= owires Identifiers and Section Identifiers. And in Section 5 of RFC6370, th= ere are some text that describes the difference between "MPLS tunnel&q= uot; and "MPLS LSP". In this draft, there are many usages of &quo= t;tunnel" in section 4, 5 and 6, and actually it should be "LSP&q= uot;. I know that sometimes people alternatively use tunnel and LSP, but it= 's better to use the term in an accurate way hence to reduce the confus= ion.

Yes, will state that explicitly in the next versio= n.
=C2=A0
In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw and = section listed), it implies that the MPLS-TP point-to-point Tunnels identif= iers are actually precluded in this document. Is my understanding right? If= so, it needs look through the document and refine the text to state it cle= arly.

=C2=A0mplsOamIdMegServicePointerType object is def= ined generically to handle any kind of service pointer (Tunnel, LSP, PW) th= ese service pointers can be used for MPLS/MPLS-TP path.

<= /div>
Here are some example that may need updates:

Section 4.

OLD:
"
The MIB module supports configuration of OAM identifiers for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0point-to-point, co-routed bidirectional, = associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bidirectional MPLS tunnels and MPLS Pseud= owires.
"
NEW:
"
The MIB module supports configuration of OAM identifiers for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS-TP co-routed bidirectional LSPs, ass= ociated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bidirectional LSPs, Sections and Pseudowi= res.
"

As mentioned above. we dont need to change the tex= t (MPLS to MPLS-TP), will enhance the existing text to make the intention o= f this MIB clear.
=C2=A0
Section 5.

s/...configurations for MPLS Tunnels and Pseudowires/...configurations for = MPLS-TP LSPs, Sections and Pseudowires

Section 5.1

s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and Ps= eudowires.

Section 6

s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirectional= LSP

s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed bidire= ctional LSP are illustrated here

Same as above.
=C2=A0
3.

For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe f= ollowing items?
=C2=A0 =C2=A0 =C2=A0 =C2=A0mplsOamIdMeProactiveOamPhbTCValue =3D 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0mplsOamIdMeOnDemandOamPhbTCValue=C2=A0 =3D 0,
It seems that they should not belong to this MIB, maybe better in other MIB= .

PHB TC values are defined in this MIB to basically= use these values in Proactive(BFD)/OnDemand(LSP Ping) sessions.=C2=A0<= /div>

4.

mplsOamIdMegPathFlow OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 INTEGE= R {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 unidirectionalPointToPoint (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 coRoutedBidirectionalPointToPoint (2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 associatedBidirectionalPointToPoint (3),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 unidirectionalPointToMultiPoint (4)

Seems RFC6370 does not define how to identify a unidirectionalPointToMultiP= oint path, and from the Introduction of this document, the P2MP seems not b= e included.
=C2=A0
We will add more infor= mation for P2MP in the next version after the internal discussion.=C2=A0

5.

mplsOamIdMegSubOperStatus OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0BITS {<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 megDown (0),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 meDown (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 oamAppDown (2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 pathDown (3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The bit 0 (megDown) = indicates the MEG is down.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The bit 1 (meDown) i= ndicates the ME table is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0down.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The bit 2 (oamAppDow= n) indicates that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAM application has = notified that the entity (LSP or PW)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0monitored by this ME= G is down. Currently, BFD is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only supported OAM a= pplication.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The bit 3 (pathDown)= indicates that the underlying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSP or PW is down.&q= uot;

I am not sure what's the mean of "down" here, especially the = mean of "MEG is down", "ME table is down" and "LSP= and PW is down"?

We defined this object to notify the operational s= tatus of MEG, ME, OAM app and the MPLS/MPLS-TP path, will add more informat= ion in the next version.
=C2=A0
6.

mplsOamIdMeServicePointer OBJECT-TYPE

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 RowPoi= nter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS=C2=A0 =C2=A0 read-create
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS=C2=A0 =C2=A0 =C2=A0 =C2=A0 curren= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This variable represents a = pointer to the MPLS-TP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transport path. This value = MUST point at an entry in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mplsTunnelEntry if mplsOamI= dMegServicePointerType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is configured as lsp (1) or= at an entry in the pwEntry if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mplsOamIdMegServicePointerT= ype is configured
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as pseudowire (2).

How about mplsOamIdMegServicePointerTypesection is configured as section (3= )?

Section is not yet taken care in this MIB. Will ad= d missing information after internal discussion.

And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP tun= nels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry and p= wEntry be changed to mplsTunnelExtEntry and pwExtEntry?

No,Tunnel & PW entries are augmented to have t= he extra fields in the new tables for MPLS-TP. The base table should be suf= ficient for the MPLS/MPLS-TP path to OAM config association.
=
7.
mplsOamIdMegServicePointerType OBJECT-TYPE

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 INTEGE= R {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 lsp (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 pseudowire (2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 section (3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAX-ACCESS=C2=A0 =C2=A0 read-create
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 STATUS=C2=A0 =C2=A0 =C2=A0 =C2=A0 curren= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates the service type = for the MEG.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the service type indicat= es lsp, the service pointer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in mplsOamIdMeTable points = to an entry in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mplsTunnelTable [RFC381= 2].

Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP T= unnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable and = reference be draft-ietf-mpls-tp-te-mib-08?

No, as stated above, this MIB is mainly defined to= provide OAM configs for MPLS & MPLS-TP paths.=C2=A0

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu= ]
> Sent: Thursday, August 21, 2014 6:31 PM
> To: mpls@ietf.org
> Cc: mpls-chairs@tools.ie= tf.org; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara;
> Mach Chen; <mpls-ads@too= ls.ietf.org>
> Subject: Shepherds for MPLS MIB modules
>
> Working Group,
>
> We have for some time been looking for someone to help us shepherding = our
> MIB modules. I'm happy to announce that Mach Chen and Young Lee ha= s agreed
> to help us.
>
> Please help Mach and Young as they start working with the documents. >
> We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib.=
>
> Further shepherd assignments will be done as soon as the details are s= orted out.
>
>
> /Loa
> for the mpls wg chairs
> --
>
>
> Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

--089e011614ecd2b5b90502bdb993-- From nobody Wed Sep 10 18:36: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 0D0C81A01AA for ; Wed, 10 Sep 2014 18:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 WXKyBMuD6D5t for ; Wed, 10 Sep 2014 18:36:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16F11A013B for ; Wed, 10 Sep 2014 18:36:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMK71948; Thu, 11 Sep 2014 01:36:50 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Sep 2014 02:36:49 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 11 Sep 2014 09:36:44 +0800 From: Mach Chen To: Venkatesan Mahalingam Thread-Topic: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules Thread-Index: AQHPvSsIjXcmgWC890WmwTUyRwbbOJvnTCuwgBNDkYCAAKs+UA== Date: Thu, 11 Sep 2014 01:36:43 +0000 Message-ID: References: <53F5CA67.9070500@pi.nu> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w_DOvU0PrtsJkj8wJ4OA-4ccgI4 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules 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, 11 Sep 2014 01:36:55 -0000 SGkgVmVua2F0ZXNhbiwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIQ0KDQpQbGVhc2Ugc2Vl IG15IHJlcGxpZXMgaW5saW5lLi4uDQoNCj4gRnJvbTogVmVua2F0ZXNhbiBNYWhhbGluZ2FtIFtt YWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNl cHRlbWJlciAxMSwgMjAxNCA2OjQwIEFNDQo+IFRvOiBNYWNoIENoZW4NCj4gQ2M6IGRyYWZ0LWll dGYtbXBscy10cC1vYW0taWQtbWliQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsNCj4gVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTik7IEpvYW4gQ3VjY2hpYXJhOyA8 bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIvL1JFOiBT aGVwaGVyZHMNCj4gZm9yIE1QTFMgTUlCIG1vZHVsZXMNCj4gDQo+IEhpIE1hY2gsDQo+IA0KPiBU aGFua3MgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3LiBQbGVhc2UgZmluZCBiZWxvdyBvdXIgcmVz cG9uc2VzIGluLWxpbmVkLg0KPiANCj4gLU1QTFMgT0FNIE1JQiB0ZWFtDQo+IA0KPiBPbiBGcmks IEF1ZyAyOSwgMjAxNCBhdCAyOjE4IEFNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29t PiB3cm90ZToNCj4gSGkgQXV0aG9ycy9FZGl0b3JzLA0KPiANCj4gSSBhbSBhc3NpZ25lZCBhcyBT aGVwaGVyZCBmb3IgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIsIHRoZSBXRyBjaGFpcnMg YW5kDQo+IFNoZXBoZXJkIGFyZSB3b3JraW5nIG9uIHRoZSBwdWJsaWNhdGlvbiBvZiBkcmFmdC1p ZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi4NCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB2ZXJzaW9uIDA1 IG9mIHRoZSBkcmFmdCwgaGVyZSBhcmUgbXkgY29tbWVudHMgYW5kIHNvbWUNCj4gcXVlc3Rpb25z LCBwbGVhc2UgY29uc2lkZXIuDQo+IA0KPiAxLg0KPiBFeHRyYWN0IHRoZSBhY3JvbnltIHdoZW4g Zmlyc3QgdXNlLCBmb3IgZXhhbXBsZSwgTFNQIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGFuZCBpdCdz DQo+IG5vdCBuZWNlc3NhcnkgdG8gZXh0cmFjdCBhbiBhY3JvbnltIHdoZW4gZWFjaCB1c2VzLCBm b3IgZXhhbXBsZSwgTVBMUyBpbg0KPiBzZWN0aW9uIDEgYW5kIHNlY3Rpb24gMy4yIC4NCj4gVGhh bmtzLCB3aWxsIGNoYW5nZSBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPiANCj4gMi4NCj4gSW4g UkZDNjM3MCwgaXQgZGVmaW5lcyBNUExTLVRQIHBvaW50LXRvLXBvaW50IFR1bm5lbHMgaWRlbnRp ZmllcnMsIE1QTFMtVFANCj4gY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TVBMUyBMU1BzIGlkZW50aWZpZXJzLCBNUExTLVRQDQo+IFBzZXVkb3dpcmVzIElkZW50aWZpZXJz IGFuZCBTZWN0aW9uIElkZW50aWZpZXJzLiBBbmQgaW4gU2VjdGlvbiA1IG9mIFJGQzYzNzAsDQo+ IHRoZXJlIGFyZSBzb21lIHRleHQgdGhhdCBkZXNjcmliZXMgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biAiTVBMUyB0dW5uZWwiIGFuZA0KPiAiTVBMUyBMU1AiLiBJbiB0aGlzIGRyYWZ0LCB0aGVyZSBh cmUgbWFueSB1c2FnZXMgb2YgInR1bm5lbCIgaW4gc2VjdGlvbiA0LCA1IGFuZCA2LA0KPiBhbmQg YWN0dWFsbHkgaXQgc2hvdWxkIGJlICJMU1AiLiBJIGtub3cgdGhhdCBzb21ldGltZXMgcGVvcGxl IGFsdGVybmF0aXZlbHkgdXNlDQo+IHR1bm5lbCBhbmQgTFNQLCBidXQgaXQncyBiZXR0ZXIgdG8g dXNlIHRoZSB0ZXJtIGluIGFuIGFjY3VyYXRlIHdheSBoZW5jZSB0byByZWR1Y2UNCj4gdGhlIGNv bmZ1c2lvbi4NCj4gWWVzLCB3aWxsIHN0YXRlIHRoYXQgZXhwbGljaXRseSBpbiB0aGUgbmV4dCB2 ZXJzaW9uLg0KPiANCj4gSW4gYWRkaXRpb24sIGJhc2VkIG9uIHRoZSBtcGxzT2FtSWRNZWdTZXJ2 aWNlUG9pbnRlclR5cGUgKG9ubHkgbHNwLCBwdyBhbmQNCj4gc2VjdGlvbiBsaXN0ZWQpLCBpdCBp bXBsaWVzIHRoYXQgdGhlIE1QTFMtVFAgcG9pbnQtdG8tcG9pbnQgVHVubmVscyBpZGVudGlmaWVy cyBhcmUNCj4gYWN0dWFsbHkgcHJlY2x1ZGVkIGluIHRoaXMgZG9jdW1lbnQuIElzIG15IHVuZGVy c3RhbmRpbmcgcmlnaHQ/IElmIHNvLCBpdCBuZWVkcw0KPiBsb29rIHRocm91Z2ggdGhlIGRvY3Vt ZW50IGFuZCByZWZpbmUgdGhlIHRleHQgdG8gc3RhdGUgaXQgY2xlYXJseS4NCj4gIG1wbHNPYW1J ZE1lZ1NlcnZpY2VQb2ludGVyVHlwZSBvYmplY3QgaXMgZGVmaW5lZCBnZW5lcmljYWxseSB0byBo YW5kbGUgYW55DQo+IGtpbmQgb2Ygc2VydmljZSBwb2ludGVyIChUdW5uZWwsIExTUCwgUFcpIHRo ZXNlIHNlcnZpY2UgcG9pbnRlcnMgY2FuIGJlIHVzZWQgZm9yDQo+IE1QTFMvTVBMUy1UUCBwYXRo Lg0KDQpIZXJlLCBJIGFtIG5vdCBwcmVmZXIgdG8gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBNUExT IGFuZCBNUExTLVRQLiANCg0KT2YgY2F1c2UsIGlmIHRoZSBpbnRlbnRpb24gaXMgdG8gYXBwbHkg dGhpcyBNSUIgdG8gYm90aCBNUExTIGFuZCBNUExTLVRQIHBhdGgsIGl0J3MgYmV0dGVyIHRvIGFk ZCBzb21lIHRleHQgdG8gZXhwbGljaXRseSBzdGF0ZSB0aGlzIChlLmcuLCBpbiB0aGUgQWJzdHJh Y3QgYW5kL29yIEludHJvZHVjdGlvbiBzZWN0aW9uKS4NCg0KQWN0dWFsbHksIHRoZSBhYm92ZSBx dWVzdGlvbiByZWxhdGVkIHRvIHRoZSBkZWZpbml0aW9uIG9mIG1wbHNPYW1JZE1lZ1NlcnZpY2VQ b2ludGVyVHlwZSwgaXQncyBkZWZpbmVkIGFzIGJlbG93Og0KICAgICAgIG1wbHNPYW1JZE1lZ1Nl cnZpY2VQb2ludGVyVHlwZSBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgICAgSU5U RUdFUiB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgbHNwICgxKSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwc2V1ZG93aXJlICgyKSwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzZWN0aW9uICgzKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KSGVyZSwgb25seSBs c3AsIHB3IGFuZCBzZWN0aW9uIGxpc3RlZCwgYmFzZWQgb24gdGhlIGZhY3QgdGhhdCBUdW5uZWwg aXMgbm90IHRoZSBzYW1lIHRoaW5nIGFzIExTUC4gSWYgTVBMUyBUdW5uZWwgaXMgaW5jbHVkZWQs IHRoZW4gdGhlcmUgbWF5IG5lZWQgdGhlIGZvdXJ0aCBpdGVtOiB0dW5uZWwgKDQpLCByaWdodD8g DQoNCg0KPiANCj4gSGVyZSBhcmUgc29tZSBleGFtcGxlIHRoYXQgbWF5IG5lZWQgdXBkYXRlczoN Cj4gDQo+IFNlY3Rpb24gNC4NCj4gDQo+IE9MRDoNCj4gIg0KPiBUaGUgTUlCIG1vZHVsZSBzdXBw b3J0cyBjb25maWd1cmF0aW9uIG9mIE9BTSBpZGVudGlmaWVycyBmb3INCj4gICAgICAgICAgcG9p bnQtdG8tcG9pbnQsIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsLCBhc3NvY2lhdGVkDQo+ICAgICAg ICAgIGJpZGlyZWN0aW9uYWwgTVBMUyB0dW5uZWxzIGFuZCBNUExTIFBzZXVkb3dpcmVzLg0KPiAi DQo+IE5FVzoNCj4gIg0KPiBUaGUgTUlCIG1vZHVsZSBzdXBwb3J0cyBjb25maWd1cmF0aW9uIG9m IE9BTSBpZGVudGlmaWVycyBmb3INCj4gICAgICAgICAgTVBMUy1UUCBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzLCBhc3NvY2lhdGVkDQo+ICAgICAgICAgIGJpZGlyZWN0aW9uYWwgTFNQcywg U2VjdGlvbnMgYW5kIFBzZXVkb3dpcmVzLg0KPiAiDQo+IEFzIG1lbnRpb25lZCBhYm92ZS4gd2Ug ZG9udCBuZWVkIHRvIGNoYW5nZSB0aGUgdGV4dCAoTVBMUyB0byBNUExTLVRQKSwgd2lsbA0KPiBl bmhhbmNlIHRoZSBleGlzdGluZyB0ZXh0IHRvIG1ha2UgdGhlIGludGVudGlvbiBvZiB0aGlzIE1J QiBjbGVhci4NCg0KT0ssIEkgYW0gZmluZSB3aXRoIHRoZSBpZGVhIHRvIG1ha2UgdGhpcyBNSUIg Z2VuZXJhbGx5IGFwcGx5IHRvIE1QTFMgYW5kIE1QTFMtVFAsIGJ1dCBhcyBzYWlkIGFib3ZlLCBz b21lIGludGVudGlvbiB0ZXh0IG1heSBuZWVkZWQuDQoNCkluIGFkZGl0aW9uLCB3aGVuIHlvdSBi ZWdpbiB0byBlbmhhbmNlIHRoZSB0ZXh0LCBwbGVhc2UgY29uc2lkZXIgd2hpY2ggcGF0aHMoZS5n LiwgVHVubmVsLCBMU1AsIFBXIGFuZCBTZWN0aW9uKSB5b3UgaW50ZW5kIHRvIGluY2x1ZGUgYW5k IG1ha2UgYWxsIHJlbGV2YW50IHRleHQgY29uc2lzdGVudC4gDQoNCj4gDQo+IFNlY3Rpb24gNS4N Cj4gDQo+IHMvLi4uY29uZmlndXJhdGlvbnMgZm9yIE1QTFMgVHVubmVscyBhbmQgUHNldWRvd2ly ZXMvLi4uY29uZmlndXJhdGlvbnMgZm9yDQo+IE1QTFMtVFAgTFNQcywgU2VjdGlvbnMgYW5kIFBz ZXVkb3dpcmVzDQo+IA0KPiBTZWN0aW9uIDUuMQ0KPiANCj4gcy8uLi5mb3IgTVBMUyB0dW5uZWxz IGFuZCBwc2V1ZG93aXJlcy4vLi4uZm9yIE1QTFMtVFAgTFNQcywgU2VjdGlvbnMgYW5kDQo+IFBz ZXVkb3dpcmVzLg0KPiANCj4gU2VjdGlvbiA2DQo+IA0KPiBzLy4uLk1QTFMgY28tcm91dGVkIGJp ZGlyZWN0aW9uYWwgdHVubmVsLy4uLk1QTFMtVFAgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQ DQo+IA0KPiBzLy4uLmNvLXJvdXRlZCBNUExTIHR1bm5lbCBhcmUgaWxsdXN0cmF0ZWQgaGVyZS8u Li5NUExTLVRQIGNvLXJvdXRlZA0KPiBiaWRpcmVjdGlvbmFsIExTUCBhcmUgaWxsdXN0cmF0ZWQg aGVyZSBTYW1lIGFzIGFib3ZlLg0KDQpPSywgc2FtZSBhcyBhYm92ZSwgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBUdW5uZWwgYW5kIExTUC4NCg0KPiANCj4gMy4NCj4gDQo+IEZvciBtcGxzT2FtSWRN ZVRhYmxlLCBzaW5jZSB0aGlzIGlzIHRoZSBpZGVudGlmaWVyIE1JQiwgd2h5IGRvIHdlIG5lZWR0 aGUNCj4gZm9sbG93aW5nIGl0ZW1zPw0KPiAgICAgICAgbXBsc09hbUlkTWVQcm9hY3RpdmVPYW1Q aGJUQ1ZhbHVlID0gMCwNCj4gICAgICAgIG1wbHNPYW1JZE1lT25EZW1hbmRPYW1QaGJUQ1ZhbHVl ICA9IDAsDQo+IA0KPiBJdCBzZWVtcyB0aGF0IHRoZXkgc2hvdWxkIG5vdCBiZWxvbmcgdG8gdGhp cyBNSUIsIG1heWJlIGJldHRlciBpbiBvdGhlciBNSUIuDQo+IFBIQiBUQyB2YWx1ZXMgYXJlIGRl ZmluZWQgaW4gdGhpcyBNSUIgdG8gYmFzaWNhbGx5IHVzZSB0aGVzZSB2YWx1ZXMgaW4NCj4gUHJv YWN0aXZlKEJGRCkvT25EZW1hbmQoTFNQIFBpbmcpIHNlc3Npb25zLg0KDQpJIGtub3cgdGhleSBh cmUgdXNlZnVsLCBJIGFtIGp1c3Qgbm90IHN1cmUgd2hldGhlciB0aGV5IHNob3VsZCBiZWxvbmcg dG8gdGhpcyBNSUIsIHNpbmNlIHRoaXMgTUlCIGlzIGp1c3QgYW4gT0FNIGlkZW50aWZpZXIgTUlC Lg0KDQo+IA0KPiA0Lg0KPiANCj4gbXBsc09hbUlkTWVnUGF0aEZsb3cgT0JKRUNULVRZUEUNCj4g ICAgICAgICAgIFNZTlRBWCAgICAgICAgSU5URUdFUiB7DQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgdW5pZGlyZWN0aW9uYWxQb2ludFRvUG9pbnQgKDEpLA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvUm91dGVkQmlkaXJlY3Rpb25hbFBvaW50VG9Qb2ludCAoMiksDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgYXNzb2NpYXRlZEJpZGlyZWN0aW9uYWxQb2ludFRvUG9pbnQg KDMpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuaWRpcmVjdGlvbmFsUG9pbnRUb011 bHRpUG9pbnQgKDQpDQo+IA0KPiBTZWVtcyBSRkM2MzcwIGRvZXMgbm90IGRlZmluZSBob3cgdG8g aWRlbnRpZnkgYQ0KPiB1bmlkaXJlY3Rpb25hbFBvaW50VG9NdWx0aVBvaW50IHBhdGgsIGFuZCBm cm9tIHRoZSBJbnRyb2R1Y3Rpb24gb2YgdGhpcw0KPiBkb2N1bWVudCwgdGhlIFAyTVAgc2VlbXMg bm90IGJlIGluY2x1ZGVkLg0KPiANCj4gV2Ugd2lsbCBhZGQgbW9yZSBpbmZvcm1hdGlvbiBmb3Ig UDJNUCBpbiB0aGUgbmV4dCB2ZXJzaW9uIGFmdGVyIHRoZSBpbnRlcm5hbA0KPiBkaXNjdXNzaW9u Lg0KDQpPSywgcGxlYXNlIGRvLg0KDQo+IA0KPiA1Lg0KPiANCj4gbXBsc09hbUlkTWVnU3ViT3Bl clN0YXR1cyBPQkpFQ1QtVFlQRQ0KPiAgICAgICAgICAgU1lOVEFYICAgICAgIEJJVFMgew0KPiAg ICAgICAgICAgICAgICAgICAgICAgICBtZWdEb3duICgwKSwNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgbWVEb3duICgxKSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgb2FtQXBwRG93biAo MiksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGhEb3duICgzKQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgIH0NCj4gICAgICAgICAgICAgICAgVGhlIGJpdCAwIChtZWdEb3duKSBpbmRp Y2F0ZXMgdGhlIE1FRyBpcyBkb3duLg0KPiAgICAgICAgICAgICAgICBUaGUgYml0IDEgKG1lRG93 bikgaW5kaWNhdGVzIHRoZSBNRSB0YWJsZSBpcw0KPiAgICAgICAgICAgICAgICBkb3duLg0KPiAg ICAgICAgICAgICAgICBUaGUgYml0IDIgKG9hbUFwcERvd24pIGluZGljYXRlcyB0aGF0IHRoZQ0K PiAgICAgICAgICAgICAgICBPQU0gYXBwbGljYXRpb24gaGFzIG5vdGlmaWVkIHRoYXQgdGhlIGVu dGl0eSAoTFNQIG9yIFBXKQ0KPiAgICAgICAgICAgICAgICBtb25pdG9yZWQgYnkgdGhpcyBNRUcg aXMgZG93bi4gQ3VycmVudGx5LCBCRkQgaXMgdGhlDQo+ICAgICAgICAgICAgICAgIG9ubHkgc3Vw cG9ydGVkIE9BTSBhcHBsaWNhdGlvbi4NCj4gICAgICAgICAgICAgICAgVGhlIGJpdCAzIChwYXRo RG93bikgaW5kaWNhdGVzIHRoYXQgdGhlIHVuZGVybHlpbmcNCj4gICAgICAgICAgICAgICAgTFNQ IG9yIFBXIGlzIGRvd24uIg0KPiANCj4gSSBhbSBub3Qgc3VyZSB3aGF0J3MgdGhlIG1lYW4gb2Yg ImRvd24iIGhlcmUsIGVzcGVjaWFsbHkgdGhlIG1lYW4gb2YgIk1FRyBpcw0KPiBkb3duIiwgIk1F IHRhYmxlIGlzIGRvd24iIGFuZCAiTFNQIGFuZCBQVyBpcyBkb3duIj8NCj4gV2UgZGVmaW5lZCB0 aGlzIG9iamVjdCB0byBub3RpZnkgdGhlIG9wZXJhdGlvbmFsIHN0YXR1cyBvZiBNRUcsIE1FLCBP QU0gYXBwDQo+IGFuZCB0aGUgTVBMUy9NUExTLVRQIHBhdGgsIHdpbGwgYWRkIG1vcmUgaW5mb3Jt YXRpb24gaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KT0ssIHBsZWFzZSBkby4NCg0KPiANCj4gNi4N Cj4gDQo+IG1wbHNPYW1JZE1lU2VydmljZVBvaW50ZXIgT0JKRUNULVRZUEUNCj4gDQo+ICAgICAg ICAgICBTWU5UQVggICAgICAgIFJvd1BvaW50ZXINCj4gICAgICAgICAgIE1BWC1BQ0NFU1MgICAg cmVhZC1jcmVhdGUNCj4gICAgICAgICAgIFNUQVRVUyAgICAgICAgY3VycmVudA0KPiAgICAgICAg ICAgREVTQ1JJUFRJT04NCj4gICAgICAgICAgICAgIlRoaXMgdmFyaWFibGUgcmVwcmVzZW50cyBh IHBvaW50ZXIgdG8gdGhlIE1QTFMtVFANCj4gICAgICAgICAgICAgIHRyYW5zcG9ydCBwYXRoLiBU aGlzIHZhbHVlIE1VU1QgcG9pbnQgYXQgYW4gZW50cnkgaW4gdGhlDQo+ICAgICAgICAgICAgICBt cGxzVHVubmVsRW50cnkgaWYgbXBsc09hbUlkTWVnU2VydmljZVBvaW50ZXJUeXBlDQo+ICAgICAg ICAgICAgICBpcyBjb25maWd1cmVkIGFzIGxzcCAoMSkgb3IgYXQgYW4gZW50cnkgaW4gdGhlIHB3 RW50cnkgaWYNCj4gICAgICAgICAgICAgIG1wbHNPYW1JZE1lZ1NlcnZpY2VQb2ludGVyVHlwZSBp cyBjb25maWd1cmVkDQo+ICAgICAgICAgICAgICBhcyBwc2V1ZG93aXJlICgyKS4NCj4gDQo+IEhv dyBhYm91dCBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGVzZWN0aW9uIGlzIGNvbmZpZ3Vy ZWQgYXMgc2VjdGlvbg0KPiAoMyk/DQo+IFNlY3Rpb24gaXMgbm90IHlldCB0YWtlbiBjYXJlIGlu IHRoaXMgTUlCLiBXaWxsIGFkZCBtaXNzaW5nIGluZm9ybWF0aW9uIGFmdGVyDQo+IGludGVybmFs IGRpc2N1c3Npb24uDQoNCk9LLCBwbGVhc2UgZG8uDQoNCg0KPiANCj4gQW5kIGRyYWZ0LWlldGYt bXBscy10cC10ZS1taWItMDggZGVmaW5lcyBtcGxzVHVubmVsRXh0RW50cnkgZm9yIE1QTFMtVFAN Cj4gdHVubmVscyBhbmQgcHdFeHRFbnRyeSBmb3IgTVBMUy1UUCBQV3MsIHNob3VsZCB0aGUgYWJv dmUgbXBsc1R1bm5lbEVudHJ5DQo+IGFuZCBwd0VudHJ5IGJlIGNoYW5nZWQgdG8gbXBsc1R1bm5l bEV4dEVudHJ5IGFuZCBwd0V4dEVudHJ5Pw0KPiBObyxUdW5uZWwgJiBQVyBlbnRyaWVzIGFyZSBh dWdtZW50ZWQgdG8gaGF2ZSB0aGUgZXh0cmEgZmllbGRzIGluIHRoZSBuZXcgdGFibGVzDQo+IGZv ciBNUExTLVRQLiBUaGUgYmFzZSB0YWJsZSBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlIE1Q TFMvTVBMUy1UUCBwYXRoIHRvDQo+IE9BTSBjb25maWcgYXNzb2NpYXRpb24uDQoNCk9LLg0KDQoN Cj4gDQo+IDcuDQo+IG1wbHNPYW1JZE1lZ1NlcnZpY2VQb2ludGVyVHlwZSBPQkpFQ1QtVFlQRQ0K PiANCj4gICAgICAgICAgIFNZTlRBWCAgICAgICAgSU5URUdFUiB7DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBsc3AgKDEpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHNl dWRvd2lyZSAoMiksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZWN0aW9uICgzKQ0K PiAgICAgICAgICAgICAgICAgICAgICAgICB9DQo+ICAgICAgICAgICBNQVgtQUNDRVNTICAgIHJl YWQtY3JlYXRlDQo+ICAgICAgICAgICBTVEFUVVMgICAgICAgIGN1cnJlbnQNCj4gICAgICAgICAg IERFU0NSSVBUSU9ODQo+ICAgICAgICAgICAgICJJbmRpY2F0ZXMgdGhlIHNlcnZpY2UgdHlwZSBm b3IgdGhlIE1FRy4NCj4gICAgICAgICAgICAgIElmIHRoZSBzZXJ2aWNlIHR5cGUgaW5kaWNhdGVz IGxzcCwgdGhlIHNlcnZpY2UgcG9pbnRlcg0KPiAgICAgICAgICAgICAgaW4gbXBsc09hbUlkTWVU YWJsZSBwb2ludHMgdG8gYW4gZW50cnkgaW4NCj4gICAgICAgICAgICAgIHRoZSBtcGxzVHVubmVs VGFibGUgW1JGQzM4MTJdLg0KPiANCj4gU2luY2UgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlLW1pYi0w OCBkZWZpbmVzIG1wbHNUdW5uZWxFeHRUYWJsZSBmb3IgTVBMUy1UUA0KPiBUdW5uZWxzIGFuZCBQ d3MsIHNob3VsZCB0aGUgYWJvdmUgbXBsc1R1bm5lbFRhYmxlIGJlIG1wbHNUdW5uZWxFeHRUYWJs ZSBhbmQNCj4gcmVmZXJlbmNlIGJlIGRyYWZ0LWlldGYtbXBscy10cC10ZS1taWItMDg/DQo+IE5v LCBhcyBzdGF0ZWQgYWJvdmUsIHRoaXMgTUlCIGlzIG1haW5seSBkZWZpbmVkIHRvIHByb3ZpZGUg T0FNIGNvbmZpZ3MgZm9yIE1QTFMNCj4gJiBNUExTLVRQIHBhdGhzLg0KDQpPSy4NCg0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gTWFjaA0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0 bzpsb2FAcGkubnVdDQo+ID4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCA2OjMxIFBN DQo+ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gPiBDYzogbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc7IFZJR09VUkVVWCwgTUFSVElOIChNQVJUSU4pOyBKb2FuDQo+ID4gQ3VjY2hpYXJhOyBNYWNo IENoZW47IDxtcGxzLWFkc0B0b29scy5pZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBTaGVwaGVyZHMg Zm9yIE1QTFMgTUlCIG1vZHVsZXMNCj4gPg0KPiA+IFdvcmtpbmcgR3JvdXAsDQo+ID4NCj4gPiBX ZSBoYXZlIGZvciBzb21lIHRpbWUgYmVlbiBsb29raW5nIGZvciBzb21lb25lIHRvIGhlbHAgdXMg c2hlcGhlcmRpbmcNCj4gPiBvdXIgTUlCIG1vZHVsZXMuIEknbSBoYXBweSB0byBhbm5vdW5jZSB0 aGF0IE1hY2ggQ2hlbiBhbmQgWW91bmcgTGVlDQo+ID4gaGFzIGFncmVlZCB0byBoZWxwIHVzLg0K PiA+DQo+ID4gUGxlYXNlIGhlbHAgTWFjaCBhbmQgWW91bmcgYXMgdGhleSBzdGFydCB3b3JraW5n IHdpdGggdGhlIGRvY3VtZW50cy4NCj4gPg0KPiA+IFdlJ3ZlIGFzc2lnbmVkIE1hY2ggYXMgU2hl cGhlcmQgZm9yIGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLg0KPiA+DQo+ID4gRnVydGhl ciBzaGVwaGVyZCBhc3NpZ25tZW50cyB3aWxsIGJlIGRvbmUgYXMgc29vbiBhcyB0aGUgZGV0YWls cyBhcmUgc29ydGVkDQo+IG91dC4NCj4gPg0KPiA+DQo+ID4gL0xvYQ0KPiA+IGZvciB0aGUgbXBs cyB3ZyBjaGFpcnMNCj4gPiAtLQ0KPiA+DQo+ID4NCj4gPiBMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiA+IFNlbmlvciBN UExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51IEh1YXdlaQ0KPiA+ IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoN Cg== From nobody Wed Sep 10 18:45: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 986351A01C5 for ; Wed, 10 Sep 2014 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] 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 D-yyOE3B3Tyj for ; Wed, 10 Sep 2014 18:45:20 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF851A01AA for ; Wed, 10 Sep 2014 18:45:19 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so9062875lbv.10 for ; Wed, 10 Sep 2014 18:45:18 -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=xu8G2fwJbAm4lnMjRFJCC7mrWXrAnGIgzOlxx0nGp1M=; b=lRVaCkMUmEW7Y6uuQbKcXrTsJOmjXesspYL8Pa9cEK5aOWbdP/ic/dOWdLOWg5+EnI G+oYhYF+TRvP54C64kbRZBjuQy464QNp1VS97b1NWHrmjVcpTMDeCpf+BiMs+0YghKdT gjeGLZkl/A03JrhO2bHaIe6m4grDbb4Ught6oy0iWfRFMHuBrcPcbXbQO6ERsz8X4MvA +ypDT1+UEhAJP2y6dmYXPQ0ydCsaxxdMVofrTjin4LRZrl2F0KYrOtoCxL6yq9y/gljU VoosY1OWjbt+EJ6Z3XgNcpHiUy9BXH9yVnN76BbAmthWoCKxFksEyBOK8Uu5SbNDk8Gz 6EvA== MIME-Version: 1.0 X-Received: by 10.152.116.80 with SMTP id ju16mr19402053lab.73.1410399918285; Wed, 10 Sep 2014 18:45:18 -0700 (PDT) Received: by 10.25.141.7 with HTTP; Wed, 10 Sep 2014 18:45:18 -0700 (PDT) In-Reply-To: References: <53F5CA67.9070500@pi.nu> Date: Wed, 10 Sep 2014 18:45:18 -0700 Message-ID: From: Venkatesan Mahalingam To: Mach Chen Content-Type: multipart/alternative; boundary=001a11c33b7c1ee8060502c052a6 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zqyuRtpg2w--Zi4_EOU6ybjMQbM Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules 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, 11 Sep 2014 01:45:23 -0000 --001a11c33b7c1ee8060502c052a6 Content-Type: text/plain; charset=UTF-8 Mach, Thanks for the prompt response. Please see inline. -Venkat. On Wed, Sep 10, 2014 at 6:36 PM, Mach Chen wrote: > Hi Venkatesan, > > Thanks for your response! > > Please see my replies inline... > > > From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com] > > Sent: Thursday, September 11, 2014 6:40 AM > > To: Mach Chen > > Cc: draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; > mpls-chairs@tools.ietf.org; > > VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; ; > > mpls@ietf.org > > Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: > Shepherds > > for MPLS MIB modules > > > > Hi Mach, > > > > Thanks for your thorough review. Please find below our responses > in-lined. > > > > -MPLS OAM MIB team > > > > On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen wrote: > > Hi Authors/Editors, > > > > I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG > chairs and > > Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-mib. > > > > I have reviewed version 05 of the draft, here are my comments and some > > questions, please consider. > > > > 1. > > Extract the acronym when first use, for example, LSP in the > Introduction, and it's > > not necessary to extract an acronym when each uses, for example, MPLS in > > section 1 and section 3.2 . > > Thanks, will change it in the next version. > > > > 2. > > In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, > MPLS-TP > > co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP > > Pseudowires Identifiers and Section Identifiers. And in Section 5 of > RFC6370, > > there are some text that describes the difference between "MPLS tunnel" > and > > "MPLS LSP". In this draft, there are many usages of "tunnel" in section > 4, 5 and 6, > > and actually it should be "LSP". I know that sometimes people > alternatively use > > tunnel and LSP, but it's better to use the term in an accurate way hence > to reduce > > the confusion. > > Yes, will state that explicitly in the next version. > > > > In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw > and > > section listed), it implies that the MPLS-TP point-to-point Tunnels > identifiers are > > actually precluded in this document. Is my understanding right? If so, > it needs > > look through the document and refine the text to state it clearly. > > mplsOamIdMegServicePointerType object is defined generically to handle > any > > kind of service pointer (Tunnel, LSP, PW) these service pointers can be > used for > > MPLS/MPLS-TP path. > > Here, I am not prefer to the difference between MPLS and MPLS-TP. > > Of cause, if the intention is to apply this MIB to both MPLS and MPLS-TP > path, it's better to add some text to explicitly state this (e.g., in the > Abstract and/or Introduction section). > > Actually, the above question related to the definition of > mplsOamIdMegServicePointerType, it's defined as below: > mplsOamIdMegServicePointerType OBJECT-TYPE > SYNTAX INTEGER { > lsp (1), > pseudowire (2), > section (3) > } > Here, only lsp, pw and section listed, based on the fact that Tunnel is > not the same thing as LSP. If MPLS Tunnel is included, then there may need > the fourth item: tunnel (4), right? > > Got it. Yes, Thanks. > > > > > Here are some example that may need updates: > > > > Section 4. > > > > OLD: > > " > > The MIB module supports configuration of OAM identifiers for > > point-to-point, co-routed bidirectional, associated > > bidirectional MPLS tunnels and MPLS Pseudowires. > > " > > NEW: > > " > > The MIB module supports configuration of OAM identifiers for > > MPLS-TP co-routed bidirectional LSPs, associated > > bidirectional LSPs, Sections and Pseudowires. > > " > > As mentioned above. we dont need to change the text (MPLS to MPLS-TP), > will > > enhance the existing text to make the intention of this MIB clear. > > OK, I am fine with the idea to make this MIB generally apply to MPLS and > MPLS-TP, but as said above, some intention text may needed. > > In addition, when you begin to enhance the text, please consider which > paths(e.g., Tunnel, LSP, PW and Section) you intend to include and make all > relevant text consistent. > Sure. will update in the next version. > > > > > Section 5. > > > > s/...configurations for MPLS Tunnels and Pseudowires/...configurations > for > > MPLS-TP LSPs, Sections and Pseudowires > > > > Section 5.1 > > > > s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and > > Pseudowires. > > > > Section 6 > > > > s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed > bidirectional LSP > > > > s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed > > bidirectional LSP are illustrated here Same as above. > > OK, same as above, the difference between Tunnel and LSP. > ACK. > > > > > 3. > > > > For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe > > following items? > > mplsOamIdMeProactiveOamPhbTCValue = 0, > > mplsOamIdMeOnDemandOamPhbTCValue = 0, > > > > It seems that they should not belong to this MIB, maybe better in other > MIB. > > PHB TC values are defined in this MIB to basically use these values in > > Proactive(BFD)/OnDemand(LSP Ping) sessions. > > I know they are useful, I am just not sure whether they should belong to > this MIB, since this MIB is just an OAM identifier MIB. > > Will discuss internally and decide on this. > > > > 4. > > > > mplsOamIdMegPathFlow OBJECT-TYPE > > SYNTAX INTEGER { > > unidirectionalPointToPoint (1), > > coRoutedBidirectionalPointToPoint (2), > > associatedBidirectionalPointToPoint (3), > > unidirectionalPointToMultiPoint (4) > > > > Seems RFC6370 does not define how to identify a > > unidirectionalPointToMultiPoint path, and from the Introduction of this > > document, the P2MP seems not be included. > > > > We will add more information for P2MP in the next version after the > internal > > discussion. > > OK, please do. > > ACK > > > > 5. > > > > mplsOamIdMegSubOperStatus OBJECT-TYPE > > SYNTAX BITS { > > megDown (0), > > meDown (1), > > oamAppDown (2), > > pathDown (3) > > } > > The bit 0 (megDown) indicates the MEG is down. > > The bit 1 (meDown) indicates the ME table is > > down. > > The bit 2 (oamAppDown) indicates that the > > OAM application has notified that the entity (LSP or PW) > > monitored by this MEG is down. Currently, BFD is the > > only supported OAM application. > > The bit 3 (pathDown) indicates that the underlying > > LSP or PW is down." > > > > I am not sure what's the mean of "down" here, especially the mean of > "MEG is > > down", "ME table is down" and "LSP and PW is down"? > > We defined this object to notify the operational status of MEG, ME, OAM > app > > and the MPLS/MPLS-TP path, will add more information in the next version. > > OK, please do. > > ACK > > > > 6. > > > > mplsOamIdMeServicePointer OBJECT-TYPE > > > > SYNTAX RowPointer > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "This variable represents a pointer to the MPLS-TP > > transport path. This value MUST point at an entry in the > > mplsTunnelEntry if mplsOamIdMegServicePointerType > > is configured as lsp (1) or at an entry in the pwEntry if > > mplsOamIdMegServicePointerType is configured > > as pseudowire (2). > > > > How about mplsOamIdMegServicePointerTypesection is configured as section > > (3)? > > Section is not yet taken care in this MIB. Will add missing information > after > > internal discussion. > > OK, please do. > > > ACK > > > > And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP > > tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry > > and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry? > > No,Tunnel & PW entries are augmented to have the extra fields in the new > tables > > for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP > path to > > OAM config association. > > OK. > > ACK > > > > > 7. > > mplsOamIdMegServicePointerType OBJECT-TYPE > > > > SYNTAX INTEGER { > > lsp (1), > > pseudowire (2), > > section (3) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Indicates the service type for the MEG. > > If the service type indicates lsp, the service pointer > > in mplsOamIdMeTable points to an entry in > > the mplsTunnelTable [RFC3812]. > > > > Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP > > Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable > and > > reference be draft-ietf-mpls-tp-te-mib-08? > > No, as stated above, this MIB is mainly defined to provide OAM configs > for MPLS > > & MPLS-TP paths. > > OK. > > ACK > > Best regards, > Mach > > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.nu] > > > Sent: Thursday, August 21, 2014 6:31 PM > > > To: mpls@ietf.org > > > Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan > > > Cucchiara; Mach Chen; > > > Subject: Shepherds for MPLS MIB modules > > > > > > Working Group, > > > > > > We have for some time been looking for someone to help us shepherding > > > our MIB modules. I'm happy to announce that Mach Chen and Young Lee > > > has agreed to help us. > > > > > > Please help Mach and Young as they start working with the documents. > > > > > > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib. > > > > > > Further shepherd assignments will be done as soon as the details are > sorted > > out. > > > > > > > > > /Loa > > > for the mpls wg chairs > > > -- > > > > > > > > > Loa Andersson email: loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu Huawei > > > Technologies (consultant) phone: +46 739 81 21 64 > > --001a11c33b7c1ee8060502c052a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mach,

Thanks for the prompt response. P= lease see inline.


-Venkat.

On Wed, Sep 10, 2014= at 6:36 PM, Mach Chen <mach.chen@huawei.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">Hi Venkatesan,

Thanks for your response!

Please see my replies inline...

> From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com]
> Sent: Thursday, September 11, 2014 6:40 AM
> To: Mach Chen
> Cc: dr= aft-ietf-mpls-tp-oam-id-mib@tools.ietf.org; mpls-chairs@tools.ietf.org;
> VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara; <mpls-ads@tools.ietf.org>;
> mpls@ietf.org
> Subject: Re: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: She= pherds
> for MPLS MIB modules
>
> Hi Mach,
>
> Thanks for your thorough review. Please find below our responses in-li= ned.
>
> -MPLS OAM MIB team
>
> On Fri, Aug 29, 2014 at 2:18 AM, Mach Chen <mach.chen@huawei.com> wrote:
> Hi Authors/Editors,
>
> I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG ch= airs and
> Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-m= ib.
>
> I have reviewed version 05 of the draft, here are my comments and some=
> questions, please consider.
>
> 1.
> Extract the acronym when first use, for example, LSP in the Introducti= on, and it's
> not necessary to extract an acronym when each uses, for example, MPLS = in
> section 1 and section 3.2 .
> Thanks, will change it in the next version.
>
> 2.
> In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPL= S-TP
> co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP<= br> > Pseudowires Identifiers and Section Identifiers. And in Section 5 of R= FC6370,
> there are some text that describes the difference between "MPLS t= unnel" and
> "MPLS LSP". In this draft, there are many usages of "tu= nnel" in section 4, 5 and 6,
> and actually it should be "LSP". I know that sometimes peopl= e alternatively use
> tunnel and LSP, but it's better to use the term in an accurate way= hence to reduce
> the confusion.
> Yes, will state that explicitly in the next version.
>
> In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw= and
> section listed), it implies that the MPLS-TP point-to-point Tunnels id= entifiers are
> actually precluded in this document. Is my understanding right? If so,= it needs
> look through the document and refine the text to state it clearly.
>=C2=A0 mplsOamIdMegServicePointerType object is defined generically to = handle any
> kind of service pointer (Tunnel, LSP, PW) these service pointers can b= e used for
> MPLS/MPLS-TP path.

Here, I am not prefer to the difference between MPLS and MPLS-T= P.

Of cause, if the intention is to apply this MIB to both MPLS and MPLS-TP pa= th, it's better to add some text to explicitly state this (e.g., in the= Abstract and/or Introduction section).

Actually, the above question related to the definition of mplsOamIdMegServi= cePointerType, it's defined as below:
=C2=A0 =C2=A0 =C2=A0 =C2=A0mplsOamIdMegServicePointerType = OBJECT-TYPE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2=A0 INTEGE= R {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 lsp (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 pseudowire (2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 section (3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
Here, only lsp, pw and section listed, based on the fact that Tunnel= is not the same thing as LSP. If MPLS Tunnel is included, then there may n= eed the fourth item: tunnel (4), right?

Got it. Yes, Thanks.

>
> Here are some example that may need updates:
>
> Section 4.
>
> OLD:
> "
> The MIB module supports configuration of OAM identifiers for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point-to-point, co-routed bidirectio= nal, associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bidirectional MPLS tunnels and MPLS = Pseudowires.
> "
> NEW:
> "
> The MIB module supports configuration of OAM identifiers for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS-TP co-routed bidirectional LSPs= , associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bidirectional LSPs, Sections and Pse= udowires.
> "
> As mentioned above. we dont need to change the text (MPLS to MPLS-TP),= will
> enhance the existing text to make the intention of this MIB clear.

OK, I am fine with the idea to make this MIB generally apply to MPLS= and MPLS-TP, but as said above, some intention text may needed.

In addition, when you begin to enhance the text, please consider which path= s(e.g., Tunnel, LSP, PW and Section) you intend to include and make all rel= evant text consistent.
Sure. will update in the next v= ersion.=C2=A0

>
> Section 5.
>
> s/...configurations for MPLS Tunnels and Pseudowires/...configurations= for
> MPLS-TP LSPs, Sections and Pseudowires
>
> Section 5.1
>
> s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections a= nd
> Pseudowires.
>
> Section 6
>
> s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirect= ional LSP
>
> s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed > bidirectional LSP are illustrated here Same as above.

OK, same as above, the difference between Tunnel and LSP.
ACK.=C2=A0

>
> 3.
>
> For mplsOamIdMeTable, since this is the identifier MIB, why do we need= the
> following items?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMeProactiveOamPhbTCValue =3D 0, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMeOnDemandOamPhbTCValue=C2=A0 =3D = 0,
>
> It seems that they should not belong to this MIB, maybe better in othe= r MIB.
> PHB TC values are defined in this MIB to basically use these values in=
> Proactive(BFD)/OnDemand(LSP Ping) sessions.

I know they are useful, I am just not sure whether they should belon= g to this MIB, since this MIB is just an OAM identifier MIB.

Will discuss internally and d= ecide on this.=C2=A0
>
> 4.
>
> mplsOamIdMegPathFlow OBJECT-TYPE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 INTEGER {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0unidirectionalPointToPoint (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0coRoutedBidirectionalPointToPoint (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0associatedBidirectionalPointToPoint (3),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0unidirectionalPointToMultiPoint (4)
>
> Seems RFC6370 does not define how to identify a
> unidirectionalPointToMultiPoint path, and from the Introduction of thi= s
> document, the P2MP seems not be included.
>
> We will add more information for P2MP in the next version after the in= ternal
> discussion.

OK, please do.

ACK=C2=A0
>
> 5.
>
> mplsOamIdMegSubOperStatus OBJECT-TYPE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0BITS {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0megDown (0),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0meDown (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0oamAppDown (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0pathDown (3)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 0 (megD= own) indicates the MEG is down.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 1 (meDo= wn) indicates the ME table is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 down.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 2 (oamA= ppDown) indicates that the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAM application= has notified that the entity (LSP or PW)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 monitored by th= is MEG is down. Currently, BFD is the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only supported = OAM application.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The bit 3 (path= Down) indicates that the underlying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP or PW is do= wn."
>
> I am not sure what's the mean of "down" here, especially= the mean of "MEG is
> down", "ME table is down" and "LSP and PW is down&= quot;?
> We defined this object to notify the operational status of MEG, ME, OA= M app
> and the MPLS/MPLS-TP path, will add more information in the next versi= on.

OK, please do.

ACK=C2=A0
>
> 6.
>
> mplsOamIdMeServicePointer OBJECT-TYPE
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 RowPointer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAX-ACCESS=C2=A0 =C2=A0 read-c= reate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATUS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This variable rep= resents a pointer to the MPLS-TP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 transport path. This v= alue MUST point at an entry in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsTunnelEntry if mpl= sOamIdMegServicePointerType
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is configured as lsp (= 1) or at an entry in the pwEntry if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mplsOamIdMegServicePoi= nterType is configured
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as pseudowire (2).
>
> How about mplsOamIdMegServicePointerTypesection is configured as secti= on
> (3)?
> Section is not yet taken care in this MIB. Will add missing informatio= n after
> internal discussion.

OK, please do.


ACK=C2=A0
>
> And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-T= P
> tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEnt= ry
> and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry?
> No,Tunnel & PW entries are augmented to have the extra fields in t= he new tables
> for MPLS-TP. The base table should be sufficient for the MPLS/MPLS-TP = path to
> OAM config association.

OK.

ACK=C2=A0

>
> 7.
> mplsOamIdMegServicePointerType OBJECT-TYPE
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYNTAX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 INTEGER {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lsp (1),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pseudowire (2),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section (3)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAX-ACCESS=C2=A0 =C2=A0 read-c= reate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATUS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESCRIPTION
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates the ser= vice type for the MEG.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the service type in= dicates lsp, the service pointer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in mplsOamIdMeTable po= ints to an entry in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the mplsTunnelTable [R= FC3812].
>
> Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS= -TP
> Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTabl= e and
> reference be draft-ietf-mpls-tp-te-mib-08?
> No, as stated above, this MIB is mainly defined to provide OAM configs= for MPLS
> & MPLS-TP paths.

OK.

ACK=C2=A0

Best regards,
Mach

>
> Best regards,
> Mach
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.n= u]
> > Sent: Thursday, August 21, 2014 6:31 PM
> > To: mpls@ietf.org
> > Cc: mpls-chairs@too= ls.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan
> > Cucchiara; Mach Chen; <mpls-ads@tools.ietf.org>
> > Subject: Shepherds for MPLS MIB modules
> >
> > Working Group,
> >
> > We have for some time been looking for someone to help us shepher= ding
> > our MIB modules. I'm happy to announce that Mach Chen and You= ng Lee
> > has agreed to help us.
> >
> > Please help Mach and Young as they start working with the documen= ts.
> >
> > We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id= -mib.
> >
> > Further shepherd assignments will be done as soon as the details = are sorted
> out.
> >
> >
> > /Loa
> > for the mpls wg chairs
> > --
> >
> >
> > Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> > Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = loa@pi.nu Huawei
> > Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

--001a11c33b7c1ee8060502c052a6-- From nobody Wed Sep 10 18:56: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 DA0741A01C3 for ; Wed, 10 Sep 2014 18:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.271 X-Spam-Level: X-Spam-Status: No, score=-4.271 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 aKQMlrSCbOOr for ; Wed, 10 Sep 2014 18:55:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AE71A01BD for ; Wed, 10 Sep 2014 18:55:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMK72930; Thu, 11 Sep 2014 01:55:50 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Sep 2014 02:55:49 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Thu, 11 Sep 2014 09:55:42 +0800 From: Mach Chen To: Venkatesan Mahalingam Thread-Topic: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules Thread-Index: AQHPvSsIjXcmgWC890WmwTUyRwbbOJvnTCuwgBNDkYCAAKs+UP//iKgAgACIlmA= Date: Thu, 11 Sep 2014 01:55:41 +0000 Message-ID: References: <53F5CA67.9070500@pi.nu> In-Reply-To: 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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA9704BSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KHObjmLSSWPr_yEF_QZdVv5RaqI Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules 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, 11 Sep 2014 01:55:58 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA9704BSZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmVua2F0LA0KDQpUaGFua3MgZm9yIGNvbnNpZGVyaW5nIG15IGNvbW1lbnRzIGFuZCB5b3Vy IHByb21wdCByZXNwb25zZSENCg0KTG9va2luZyBmb3J3YXJkIHRvIHNlZSB0aGUgdXBkYXRlcy4N Cg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBWZW5rYXRlc2FuIE1haGFsaW5nYW0gW21h aWx0bzp2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIFNlcHRl bWJlciAxMSwgMjAxNCA5OjQ1IEFNDQpUbzogTWFjaCBDaGVuDQpDYzogZHJhZnQtaWV0Zi1tcGxz LXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn OyBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7IDxtcGxzLWFkc0B0 b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTaGVwaGVyZCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWIvL1JFOiBTaGVwaGVyZHMgZm9yIE1Q TFMgTUlCIG1vZHVsZXMNCg0KTWFjaCwNCg0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlc3BvbnNl LiBQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQotVmVua2F0Lg0KDQpPbiBXZWQsIFNlcCAxMCwgMjAx NCBhdCA2OjM2IFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNo LmNoZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgVmVua2F0ZXNhbiwNCg0KVGhhbmtzIGZvciB5 b3VyIHJlc3BvbnNlIQ0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLi4uDQoNCj4gRnJv bTogVmVua2F0ZXNhbiBNYWhhbGluZ2FtIFttYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWls LmNvbTxtYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbT5dDQo+IFNlbnQ6IFRodXJz ZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTQgNjo0MCBBTQ0KPiBUbzogTWFjaCBDaGVuDQo+IENjOiBk cmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1tcGxzLXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBWSUdPVVJF VVgsIE1BUlRJTiAoTUFSVElOKTsgSm9hbiBDdWNjaGlhcmE7IDxtcGxzLWFkc0B0b29scy5pZXRm Lm9yZzxtYWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+PjsNCj4gbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFNoZXBoZXJkIHJldmlldyBvZiBk cmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi8vUkU6IFNoZXBoZXJkcw0KPiBmb3IgTVBMUyBN SUIgbW9kdWxlcw0KPg0KPiBIaSBNYWNoLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgdGhvcm91Z2gg cmV2aWV3LiBQbGVhc2UgZmluZCBiZWxvdyBvdXIgcmVzcG9uc2VzIGluLWxpbmVkLg0KPg0KPiAt TVBMUyBPQU0gTUlCIHRlYW0NCj4NCj4gT24gRnJpLCBBdWcgMjksIDIwMTQgYXQgMjoxOCBBTSwg TWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5j b20+PiB3cm90ZToNCj4gSGkgQXV0aG9ycy9FZGl0b3JzLA0KPg0KPiBJIGFtIGFzc2lnbmVkIGFz IFNoZXBoZXJkIGZvciBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYiwgdGhlIFdHIGNoYWly cyBhbmQNCj4gU2hlcGhlcmQgYXJlIHdvcmtpbmcgb24gdGhlIHB1YmxpY2F0aW9uIG9mIGRyYWZ0 LWlldGYtbXBscy10cC1vYW0taWQtbWliLg0KPg0KPiBJIGhhdmUgcmV2aWV3ZWQgdmVyc2lvbiAw NSBvZiB0aGUgZHJhZnQsIGhlcmUgYXJlIG15IGNvbW1lbnRzIGFuZCBzb21lDQo+IHF1ZXN0aW9u cywgcGxlYXNlIGNvbnNpZGVyLg0KPg0KPiAxLg0KPiBFeHRyYWN0IHRoZSBhY3JvbnltIHdoZW4g Zmlyc3QgdXNlLCBmb3IgZXhhbXBsZSwgTFNQIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGFuZCBpdCdz DQo+IG5vdCBuZWNlc3NhcnkgdG8gZXh0cmFjdCBhbiBhY3JvbnltIHdoZW4gZWFjaCB1c2VzLCBm b3IgZXhhbXBsZSwgTVBMUyBpbg0KPiBzZWN0aW9uIDEgYW5kIHNlY3Rpb24gMy4yIC4NCj4gVGhh bmtzLCB3aWxsIGNoYW5nZSBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPg0KPiAyLg0KPiBJbiBS RkM2MzcwLCBpdCBkZWZpbmVzIE1QTFMtVFAgcG9pbnQtdG8tcG9pbnQgVHVubmVscyBpZGVudGlm aWVycywgTVBMUy1UUA0KPiBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBN UExTIExTUHMgaWRlbnRpZmllcnMsIE1QTFMtVFANCj4gUHNldWRvd2lyZXMgSWRlbnRpZmllcnMg YW5kIFNlY3Rpb24gSWRlbnRpZmllcnMuIEFuZCBpbiBTZWN0aW9uIDUgb2YgUkZDNjM3MCwNCj4g dGhlcmUgYXJlIHNvbWUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu ICJNUExTIHR1bm5lbCIgYW5kDQo+ICJNUExTIExTUCIuIEluIHRoaXMgZHJhZnQsIHRoZXJlIGFy ZSBtYW55IHVzYWdlcyBvZiAidHVubmVsIiBpbiBzZWN0aW9uIDQsIDUgYW5kIDYsDQo+IGFuZCBh Y3R1YWxseSBpdCBzaG91bGQgYmUgIkxTUCIuIEkga25vdyB0aGF0IHNvbWV0aW1lcyBwZW9wbGUg YWx0ZXJuYXRpdmVseSB1c2UNCj4gdHVubmVsIGFuZCBMU1AsIGJ1dCBpdCdzIGJldHRlciB0byB1 c2UgdGhlIHRlcm0gaW4gYW4gYWNjdXJhdGUgd2F5IGhlbmNlIHRvIHJlZHVjZQ0KPiB0aGUgY29u ZnVzaW9uLg0KPiBZZXMsIHdpbGwgc3RhdGUgdGhhdCBleHBsaWNpdGx5IGluIHRoZSBuZXh0IHZl cnNpb24uDQo+DQo+IEluIGFkZGl0aW9uLCBiYXNlZCBvbiB0aGUgbXBsc09hbUlkTWVnU2Vydmlj ZVBvaW50ZXJUeXBlIChvbmx5IGxzcCwgcHcgYW5kDQo+IHNlY3Rpb24gbGlzdGVkKSwgaXQgaW1w bGllcyB0aGF0IHRoZSBNUExTLVRQIHBvaW50LXRvLXBvaW50IFR1bm5lbHMgaWRlbnRpZmllcnMg YXJlDQo+IGFjdHVhbGx5IHByZWNsdWRlZCBpbiB0aGlzIGRvY3VtZW50LiBJcyBteSB1bmRlcnN0 YW5kaW5nIHJpZ2h0PyBJZiBzbywgaXQgbmVlZHMNCj4gbG9vayB0aHJvdWdoIHRoZSBkb2N1bWVu dCBhbmQgcmVmaW5lIHRoZSB0ZXh0IHRvIHN0YXRlIGl0IGNsZWFybHkuDQo+ICBtcGxzT2FtSWRN ZWdTZXJ2aWNlUG9pbnRlclR5cGUgb2JqZWN0IGlzIGRlZmluZWQgZ2VuZXJpY2FsbHkgdG8gaGFu ZGxlIGFueQ0KPiBraW5kIG9mIHNlcnZpY2UgcG9pbnRlciAoVHVubmVsLCBMU1AsIFBXKSB0aGVz ZSBzZXJ2aWNlIHBvaW50ZXJzIGNhbiBiZSB1c2VkIGZvcg0KPiBNUExTL01QTFMtVFAgcGF0aC4N CkhlcmUsIEkgYW0gbm90IHByZWZlciB0byB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIE1QTFMgYW5k IE1QTFMtVFAuDQoNCk9mIGNhdXNlLCBpZiB0aGUgaW50ZW50aW9uIGlzIHRvIGFwcGx5IHRoaXMg TUlCIHRvIGJvdGggTVBMUyBhbmQgTVBMUy1UUCBwYXRoLCBpdCdzIGJldHRlciB0byBhZGQgc29t ZSB0ZXh0IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcyAoZS5nLiwgaW4gdGhlIEFic3RyYWN0IGFu ZC9vciBJbnRyb2R1Y3Rpb24gc2VjdGlvbikuDQoNCkFjdHVhbGx5LCB0aGUgYWJvdmUgcXVlc3Rp b24gcmVsYXRlZCB0byB0aGUgZGVmaW5pdGlvbiBvZiBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRl clR5cGUsIGl0J3MgZGVmaW5lZCBhcyBiZWxvdzoNCiAgICAgICBtcGxzT2FtSWRNZWdTZXJ2aWNl UG9pbnRlclR5cGUgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgICAgIElOVEVHRVIg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxzcCAoMSksDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgcHNldWRvd2lyZSAoMiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg c2VjdGlvbiAoMykNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCkhlcmUsIG9ubHkgbHNwLCBw dyBhbmQgc2VjdGlvbiBsaXN0ZWQsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgVHVubmVsIGlzIG5v dCB0aGUgc2FtZSB0aGluZyBhcyBMU1AuIElmIE1QTFMgVHVubmVsIGlzIGluY2x1ZGVkLCB0aGVu IHRoZXJlIG1heSBuZWVkIHRoZSBmb3VydGggaXRlbTogdHVubmVsICg0KSwgcmlnaHQ/DQpHb3Qg aXQuIFllcywgVGhhbmtzLg0KDQo+DQo+IEhlcmUgYXJlIHNvbWUgZXhhbXBsZSB0aGF0IG1heSBu ZWVkIHVwZGF0ZXM6DQo+DQo+IFNlY3Rpb24gNC4NCj4NCj4gT0xEOg0KPiAiDQo+IFRoZSBNSUIg bW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcg0KPiAg ICAgICAgICBwb2ludC10by1wb2ludCwgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwsIGFzc29jaWF0 ZWQNCj4gICAgICAgICAgYmlkaXJlY3Rpb25hbCBNUExTIHR1bm5lbHMgYW5kIE1QTFMgUHNldWRv d2lyZXMuDQo+ICINCj4gTkVXOg0KPiAiDQo+IFRoZSBNSUIgbW9kdWxlIHN1cHBvcnRzIGNvbmZp Z3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcg0KPiAgICAgICAgICBNUExTLVRQIGNvLXJv dXRlZCBiaWRpcmVjdGlvbmFsIExTUHMsIGFzc29jaWF0ZWQNCj4gICAgICAgICAgYmlkaXJlY3Rp b25hbCBMU1BzLCBTZWN0aW9ucyBhbmQgUHNldWRvd2lyZXMuDQo+ICINCj4gQXMgbWVudGlvbmVk IGFib3ZlLiB3ZSBkb250IG5lZWQgdG8gY2hhbmdlIHRoZSB0ZXh0IChNUExTIHRvIE1QTFMtVFAp LCB3aWxsDQo+IGVuaGFuY2UgdGhlIGV4aXN0aW5nIHRleHQgdG8gbWFrZSB0aGUgaW50ZW50aW9u IG9mIHRoaXMgTUlCIGNsZWFyLg0KDQpPSywgSSBhbSBmaW5lIHdpdGggdGhlIGlkZWEgdG8gbWFr ZSB0aGlzIE1JQiBnZW5lcmFsbHkgYXBwbHkgdG8gTVBMUyBhbmQgTVBMUy1UUCwgYnV0IGFzIHNh aWQgYWJvdmUsIHNvbWUgaW50ZW50aW9uIHRleHQgbWF5IG5lZWRlZC4NCg0KSW4gYWRkaXRpb24s IHdoZW4geW91IGJlZ2luIHRvIGVuaGFuY2UgdGhlIHRleHQsIHBsZWFzZSBjb25zaWRlciB3aGlj aCBwYXRocyhlLmcuLCBUdW5uZWwsIExTUCwgUFcgYW5kIFNlY3Rpb24pIHlvdSBpbnRlbmQgdG8g aW5jbHVkZSBhbmQgbWFrZSBhbGwgcmVsZXZhbnQgdGV4dCBjb25zaXN0ZW50Lg0KU3VyZS4gd2ls bCB1cGRhdGUgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KPg0KPiBTZWN0aW9uIDUuDQo+DQo+IHMv Li4uY29uZmlndXJhdGlvbnMgZm9yIE1QTFMgVHVubmVscyBhbmQgUHNldWRvd2lyZXMvLi4uY29u ZmlndXJhdGlvbnMgZm9yDQo+IE1QTFMtVFAgTFNQcywgU2VjdGlvbnMgYW5kIFBzZXVkb3dpcmVz DQo+DQo+IFNlY3Rpb24gNS4xDQo+DQo+IHMvLi4uZm9yIE1QTFMgdHVubmVscyBhbmQgcHNldWRv d2lyZXMuLy4uLmZvciBNUExTLVRQIExTUHMsIFNlY3Rpb25zIGFuZA0KPiBQc2V1ZG93aXJlcy4N Cj4NCj4gU2VjdGlvbiA2DQo+DQo+IHMvLi4uTVBMUyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCB0 dW5uZWwvLi4uTVBMUy1UUCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCj4NCj4gcy8uLi5j by1yb3V0ZWQgTVBMUyB0dW5uZWwgYXJlIGlsbHVzdHJhdGVkIGhlcmUvLi4uTVBMUy1UUCBjby1y b3V0ZWQNCj4gYmlkaXJlY3Rpb25hbCBMU1AgYXJlIGlsbHVzdHJhdGVkIGhlcmUgU2FtZSBhcyBh Ym92ZS4NCg0KT0ssIHNhbWUgYXMgYWJvdmUsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gVHVubmVs IGFuZCBMU1AuDQpBQ0suDQoNCj4NCj4gMy4NCj4NCj4gRm9yIG1wbHNPYW1JZE1lVGFibGUsIHNp bmNlIHRoaXMgaXMgdGhlIGlkZW50aWZpZXIgTUlCLCB3aHkgZG8gd2UgbmVlZHRoZQ0KPiBmb2xs b3dpbmcgaXRlbXM/DQo+ICAgICAgICBtcGxzT2FtSWRNZVByb2FjdGl2ZU9hbVBoYlRDVmFsdWUg PSAwLA0KPiAgICAgICAgbXBsc09hbUlkTWVPbkRlbWFuZE9hbVBoYlRDVmFsdWUgID0gMCwNCj4N Cj4gSXQgc2VlbXMgdGhhdCB0aGV5IHNob3VsZCBub3QgYmVsb25nIHRvIHRoaXMgTUlCLCBtYXli ZSBiZXR0ZXIgaW4gb3RoZXIgTUlCLg0KPiBQSEIgVEMgdmFsdWVzIGFyZSBkZWZpbmVkIGluIHRo aXMgTUlCIHRvIGJhc2ljYWxseSB1c2UgdGhlc2UgdmFsdWVzIGluDQo+IFByb2FjdGl2ZShCRkQp L09uRGVtYW5kKExTUCBQaW5nKSBzZXNzaW9ucy4NCg0KSSBrbm93IHRoZXkgYXJlIHVzZWZ1bCwg SSBhbSBqdXN0IG5vdCBzdXJlIHdoZXRoZXIgdGhleSBzaG91bGQgYmVsb25nIHRvIHRoaXMgTUlC LCBzaW5jZSB0aGlzIE1JQiBpcyBqdXN0IGFuIE9BTSBpZGVudGlmaWVyIE1JQi4NCldpbGwgZGlz Y3VzcyBpbnRlcm5hbGx5IGFuZCBkZWNpZGUgb24gdGhpcy4NCj4NCj4gNC4NCj4NCj4gbXBsc09h bUlkTWVnUGF0aEZsb3cgT0JKRUNULVRZUEUNCj4gICAgICAgICAgIFNZTlRBWCAgICAgICAgSU5U RUdFUiB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5pZGlyZWN0aW9uYWxQb2ludFRv UG9pbnQgKDEpLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvUm91dGVkQmlkaXJlY3Rp b25hbFBvaW50VG9Qb2ludCAoMiksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgYXNzb2Np YXRlZEJpZGlyZWN0aW9uYWxQb2ludFRvUG9pbnQgKDMpLA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVuaWRpcmVjdGlvbmFsUG9pbnRUb011bHRpUG9pbnQgKDQpDQo+DQo+IFNlZW1zIFJG QzYzNzAgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBpZGVudGlmeSBhDQo+IHVuaWRpcmVjdGlvbmFs UG9pbnRUb011bHRpUG9pbnQgcGF0aCwgYW5kIGZyb20gdGhlIEludHJvZHVjdGlvbiBvZiB0aGlz DQo+IGRvY3VtZW50LCB0aGUgUDJNUCBzZWVtcyBub3QgYmUgaW5jbHVkZWQuDQo+DQo+IFdlIHdp bGwgYWRkIG1vcmUgaW5mb3JtYXRpb24gZm9yIFAyTVAgaW4gdGhlIG5leHQgdmVyc2lvbiBhZnRl ciB0aGUgaW50ZXJuYWwNCj4gZGlzY3Vzc2lvbi4NCg0KT0ssIHBsZWFzZSBkby4NCkFDSw0KPg0K PiA1Lg0KPg0KPiBtcGxzT2FtSWRNZWdTdWJPcGVyU3RhdHVzIE9CSkVDVC1UWVBFDQo+ICAgICAg ICAgICBTWU5UQVggICAgICAgQklUUyB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIG1lZ0Rv d24gKDApLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBtZURvd24gKDEpLA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICBvYW1BcHBEb3duICgyKSwNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgcGF0aERvd24gKDMpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgfQ0KPiAgICAgICAgICAg ICAgICBUaGUgYml0IDAgKG1lZ0Rvd24pIGluZGljYXRlcyB0aGUgTUVHIGlzIGRvd24uDQo+ICAg ICAgICAgICAgICAgIFRoZSBiaXQgMSAobWVEb3duKSBpbmRpY2F0ZXMgdGhlIE1FIHRhYmxlIGlz DQo+ICAgICAgICAgICAgICAgIGRvd24uDQo+ICAgICAgICAgICAgICAgIFRoZSBiaXQgMiAob2Ft QXBwRG93bikgaW5kaWNhdGVzIHRoYXQgdGhlDQo+ICAgICAgICAgICAgICAgIE9BTSBhcHBsaWNh dGlvbiBoYXMgbm90aWZpZWQgdGhhdCB0aGUgZW50aXR5IChMU1Agb3IgUFcpDQo+ICAgICAgICAg ICAgICAgIG1vbml0b3JlZCBieSB0aGlzIE1FRyBpcyBkb3duLiBDdXJyZW50bHksIEJGRCBpcyB0 aGUNCj4gICAgICAgICAgICAgICAgb25seSBzdXBwb3J0ZWQgT0FNIGFwcGxpY2F0aW9uLg0KPiAg ICAgICAgICAgICAgICBUaGUgYml0IDMgKHBhdGhEb3duKSBpbmRpY2F0ZXMgdGhhdCB0aGUgdW5k ZXJseWluZw0KPiAgICAgICAgICAgICAgICBMU1Agb3IgUFcgaXMgZG93bi4iDQo+DQo+IEkgYW0g bm90IHN1cmUgd2hhdCdzIHRoZSBtZWFuIG9mICJkb3duIiBoZXJlLCBlc3BlY2lhbGx5IHRoZSBt ZWFuIG9mICJNRUcgaXMNCj4gZG93biIsICJNRSB0YWJsZSBpcyBkb3duIiBhbmQgIkxTUCBhbmQg UFcgaXMgZG93biI/DQo+IFdlIGRlZmluZWQgdGhpcyBvYmplY3QgdG8gbm90aWZ5IHRoZSBvcGVy YXRpb25hbCBzdGF0dXMgb2YgTUVHLCBNRSwgT0FNIGFwcA0KPiBhbmQgdGhlIE1QTFMvTVBMUy1U UCBwYXRoLCB3aWxsIGFkZCBtb3JlIGluZm9ybWF0aW9uIGluIHRoZSBuZXh0IHZlcnNpb24uDQoN Ck9LLCBwbGVhc2UgZG8uDQpBQ0sNCj4NCj4gNi4NCj4NCj4gbXBsc09hbUlkTWVTZXJ2aWNlUG9p bnRlciBPQkpFQ1QtVFlQRQ0KPg0KPiAgICAgICAgICAgU1lOVEFYICAgICAgICBSb3dQb2ludGVy DQo+ICAgICAgICAgICBNQVgtQUNDRVNTICAgIHJlYWQtY3JlYXRlDQo+ICAgICAgICAgICBTVEFU VVMgICAgICAgIGN1cnJlbnQNCj4gICAgICAgICAgIERFU0NSSVBUSU9ODQo+ICAgICAgICAgICAg ICJUaGlzIHZhcmlhYmxlIHJlcHJlc2VudHMgYSBwb2ludGVyIHRvIHRoZSBNUExTLVRQDQo+ICAg ICAgICAgICAgICB0cmFuc3BvcnQgcGF0aC4gVGhpcyB2YWx1ZSBNVVNUIHBvaW50IGF0IGFuIGVu dHJ5IGluIHRoZQ0KPiAgICAgICAgICAgICAgbXBsc1R1bm5lbEVudHJ5IGlmIG1wbHNPYW1JZE1l Z1NlcnZpY2VQb2ludGVyVHlwZQ0KPiAgICAgICAgICAgICAgaXMgY29uZmlndXJlZCBhcyBsc3Ag KDEpIG9yIGF0IGFuIGVudHJ5IGluIHRoZSBwd0VudHJ5IGlmDQo+ICAgICAgICAgICAgICBtcGxz T2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgaXMgY29uZmlndXJlZA0KPiAgICAgICAgICAgICAg YXMgcHNldWRvd2lyZSAoMikuDQo+DQo+IEhvdyBhYm91dCBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9p bnRlclR5cGVzZWN0aW9uIGlzIGNvbmZpZ3VyZWQgYXMgc2VjdGlvbg0KPiAoMyk/DQo+IFNlY3Rp b24gaXMgbm90IHlldCB0YWtlbiBjYXJlIGluIHRoaXMgTUlCLiBXaWxsIGFkZCBtaXNzaW5nIGlu Zm9ybWF0aW9uIGFmdGVyDQo+IGludGVybmFsIGRpc2N1c3Npb24uDQoNCk9LLCBwbGVhc2UgZG8u DQoNCkFDSw0KPg0KPiBBbmQgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlLW1pYi0wOCBkZWZpbmVzIG1w bHNUdW5uZWxFeHRFbnRyeSBmb3IgTVBMUy1UUA0KPiB0dW5uZWxzIGFuZCBwd0V4dEVudHJ5IGZv ciBNUExTLVRQIFBXcywgc2hvdWxkIHRoZSBhYm92ZSBtcGxzVHVubmVsRW50cnkNCj4gYW5kIHB3 RW50cnkgYmUgY2hhbmdlZCB0byBtcGxzVHVubmVsRXh0RW50cnkgYW5kIHB3RXh0RW50cnk/DQo+ IE5vLFR1bm5lbCAmIFBXIGVudHJpZXMgYXJlIGF1Z21lbnRlZCB0byBoYXZlIHRoZSBleHRyYSBm aWVsZHMgaW4gdGhlIG5ldyB0YWJsZXMNCj4gZm9yIE1QTFMtVFAuIFRoZSBiYXNlIHRhYmxlIHNo b3VsZCBiZSBzdWZmaWNpZW50IGZvciB0aGUgTVBMUy9NUExTLVRQIHBhdGggdG8NCj4gT0FNIGNv bmZpZyBhc3NvY2lhdGlvbi4NCg0KT0suDQpBQ0sNCg0KPg0KPiA3Lg0KPiBtcGxzT2FtSWRNZWdT ZXJ2aWNlUG9pbnRlclR5cGUgT0JKRUNULVRZUEUNCj4NCj4gICAgICAgICAgIFNZTlRBWCAgICAg ICAgSU5URUdFUiB7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsc3AgKDEpLA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcHNldWRvd2lyZSAoMiksDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzZWN0aW9uICgzKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICB9 DQo+ICAgICAgICAgICBNQVgtQUNDRVNTICAgIHJlYWQtY3JlYXRlDQo+ICAgICAgICAgICBTVEFU VVMgICAgICAgIGN1cnJlbnQNCj4gICAgICAgICAgIERFU0NSSVBUSU9ODQo+ICAgICAgICAgICAg ICJJbmRpY2F0ZXMgdGhlIHNlcnZpY2UgdHlwZSBmb3IgdGhlIE1FRy4NCj4gICAgICAgICAgICAg IElmIHRoZSBzZXJ2aWNlIHR5cGUgaW5kaWNhdGVzIGxzcCwgdGhlIHNlcnZpY2UgcG9pbnRlcg0K PiAgICAgICAgICAgICAgaW4gbXBsc09hbUlkTWVUYWJsZSBwb2ludHMgdG8gYW4gZW50cnkgaW4N Cj4gICAgICAgICAgICAgIHRoZSBtcGxzVHVubmVsVGFibGUgW1JGQzM4MTJdLg0KPg0KPiBTaW5j ZSBkcmFmdC1pZXRmLW1wbHMtdHAtdGUtbWliLTA4IGRlZmluZXMgbXBsc1R1bm5lbEV4dFRhYmxl IGZvciBNUExTLVRQDQo+IFR1bm5lbHMgYW5kIFB3cywgc2hvdWxkIHRoZSBhYm92ZSBtcGxzVHVu bmVsVGFibGUgYmUgbXBsc1R1bm5lbEV4dFRhYmxlIGFuZA0KPiByZWZlcmVuY2UgYmUgZHJhZnQt aWV0Zi1tcGxzLXRwLXRlLW1pYi0wOD8NCj4gTm8sIGFzIHN0YXRlZCBhYm92ZSwgdGhpcyBNSUIg aXMgbWFpbmx5IGRlZmluZWQgdG8gcHJvdmlkZSBPQU0gY29uZmlncyBmb3IgTVBMUw0KPiAmIE1Q TFMtVFAgcGF0aHMuDQoNCk9LLg0KQUNLDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPg0KPiBC ZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT5dDQo+ID4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCA2OjMxIFBNDQo+ID4gVG86 IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4gQ2M6IG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IFZJR09V UkVVWCwgTUFSVElOIChNQVJUSU4pOyBKb2FuDQo+ID4gQ3VjY2hpYXJhOyBNYWNoIENoZW47IDxt cGxzLWFkc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc+Pg0K PiA+IFN1YmplY3Q6IFNoZXBoZXJkcyBmb3IgTVBMUyBNSUIgbW9kdWxlcw0KPiA+DQo+ID4gV29y a2luZyBHcm91cCwNCj4gPg0KPiA+IFdlIGhhdmUgZm9yIHNvbWUgdGltZSBiZWVuIGxvb2tpbmcg Zm9yIHNvbWVvbmUgdG8gaGVscCB1cyBzaGVwaGVyZGluZw0KPiA+IG91ciBNSUIgbW9kdWxlcy4g SSdtIGhhcHB5IHRvIGFubm91bmNlIHRoYXQgTWFjaCBDaGVuIGFuZCBZb3VuZyBMZWUNCj4gPiBo YXMgYWdyZWVkIHRvIGhlbHAgdXMuDQo+ID4NCj4gPiBQbGVhc2UgaGVscCBNYWNoIGFuZCBZb3Vu ZyBhcyB0aGV5IHN0YXJ0IHdvcmtpbmcgd2l0aCB0aGUgZG9jdW1lbnRzLg0KPiA+DQo+ID4gV2Un dmUgYXNzaWduZWQgTWFjaCBhcyBTaGVwaGVyZCBmb3IgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1p ZC1taWIuDQo+ID4NCj4gPiBGdXJ0aGVyIHNoZXBoZXJkIGFzc2lnbm1lbnRzIHdpbGwgYmUgZG9u ZSBhcyBzb29uIGFzIHRoZSBkZXRhaWxzIGFyZSBzb3J0ZWQNCj4gb3V0Lg0KPiA+DQo+ID4NCj4g PiAvTG9hDQo+ID4gZm9yIHRoZSBtcGxzIHdnIGNoYWlycw0KPiA+IC0tDQo+ID4NCj4gPg0KPiA+ IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5o dWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQo+ID4gU2VuaW9yIE1QTFMg RXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT4gSHVhd2VpDQo+ID4gVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3 MzkgODEgMjEgNjQ8dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Pg0KDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA9704BSZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxQ0ZDREE2LjhCRUE3RjYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMTA8L3c6Wm9vbT4NCjx3OlNw ZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6 VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNj aGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0K PHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFs d2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhl bWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3Okxp ZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6 Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFw cGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxp Z25DZWxsV2l0aFNwLz4NCjx3OkRvbnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3 OkRvbnRWZXJ0QWxpZ25JblR4YngvPg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hl ZENvbEJhbGFuY2UvPg0KPHc6VXNlRkVMYXlvdXQvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpC cm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0K PG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmlu IG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFs bEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+ DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4N CjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+ DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVu dD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50 U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERl ZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3Jt YXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2Mg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9u dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i U3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i RGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlz dCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBM aXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1w aGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHki Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFb ZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJ bXNvLWZvbnQtYWx0OlNpbVN1bjsNCgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTozIDY4MDQ2MDI4OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsN Cgltc28tZm9udC1hbHQ6IkNhbGlzdG8gTVQiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCglt c28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJDZW50dXJ5IEdvdGhpYyI7DQoJbXNvLWZvbnQtY2hhcnNl dDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZh cmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEwNzM3ODYxMTEgOSAwIDQx NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250 LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWdu YXR1cmU6LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 DQoJbXNvLWZvbnQtYWx0Oj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz87DQoJbXNvLWZv bnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9u dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAy NjIxNDUgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1x Zm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrl rovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5 bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWu i+S9kzsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uU3BlbGxFDQoJ e21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjoz Ni4wcHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5h bWU65pmu6YCa6KGo5qC8Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHls ZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7 DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2lu OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246 d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250LWtlcm5pbmc6 MS4wcHQ7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MjEuMHB0Ij4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkNCjxzcGFuIGNsYXNzPSJTcGVsbEUiPlZlbmthdDwvc3Bh bj4sPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWls eTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcw0KIGZvciBjb25zaWRlcmluZyBteSBjb21tZW50cyBhbmQg eW91ciBwcm9tcHQgcmVzcG9uc2UhPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGkt Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcNCiBmb3J3YXJkIHRvIHNl ZSB0aGUgdXBkYXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdA0KIHJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NYWNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGkt Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxm b250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCiBWZW5rYXRlc2FuIE1haGFsaW5nYW0gW21haWx0bzp2ZW5rYXQubWFoYWxp bmdhbXNAZ21haWwuY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDk6NDUgQU08YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWFjaCBD aGVuPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+ IGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTik7IEpvYW4gQ3VjY2hp YXJhOyAmbHQ7bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmcmZ3Q7OyBtcGxzQGlldGYub3JnPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6 IFNoZXBoZXJkIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi8vUkU6IFNo ZXBoZXJkcyBmb3IgTVBMUyBNSUIgbW9kdWxlczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1hY2gsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5UaGFua3MgZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuIFBsZWFz ZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPi1WZW5rYXQuPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9 kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBXZWQsIFNl cCAxMCwgMjAxNCBhdCA2OjM2IFBNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNo LmNoZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hY2guY2hlbkBodWF3ZWkuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBWZW5rYXRlc2FuLDxicj4NCjxicj4NClRoYW5rcyBm b3IgeW91ciByZXNwb25zZSE8YnI+DQo8YnI+DQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5l Li4uPGJyPg0KPGJyPg0KJmd0OyBGcm9tOiBWZW5rYXRlc2FuIE1haGFsaW5nYW0gW21haWx0bzo8 YSBocmVmPSJtYWlsdG86dmVua2F0Lm1haGFsaW5nYW1zQGdtYWlsLmNvbSI+dmVua2F0Lm1haGFs aW5nYW1zQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVy IDExLCAyMDE0IDY6NDAgQU08YnI+DQomZ3Q7IFRvOiBNYWNoIENoZW48YnI+DQomZ3Q7IENjOiA8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWJAdG9vbHMuaWV0Zi5v cmciPmRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliQHRvb2xzLmlldGYub3JnPC9hPjsNCjxh IGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTik7IEpv YW4gQ3VjY2hpYXJhOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtYWRzQHRvb2xzLmlldGYub3Jn Ij5tcGxzLWFkc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7Ozxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBS ZTogU2hlcGhlcmQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLy9SRTog U2hlcGhlcmRzPGJyPg0KJmd0OyBmb3IgTVBMUyBNSUIgbW9kdWxlczxicj4NCiZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9 kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IEhpIE1h Y2gsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGZvciB5b3VyIHRob3JvdWdoIHJldmlldy4g UGxlYXNlIGZpbmQgYmVsb3cgb3VyIHJlc3BvbnNlcyBpbi1saW5lZC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtTVBMUyBPQU0gTUlCIHRlYW08YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBGcmksIEF1ZyAy OSwgMjAxNCBhdCAyOjE4IEFNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbSI+bWFjaC5jaGVuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7IEhpIEF1dGhvcnMvRWRpdG9ycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFtIGFzc2lnbmVk IGFzIFNoZXBoZXJkIGZvciBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYiwgdGhlIFdHIGNo YWlycyBhbmQ8YnI+DQomZ3Q7IFNoZXBoZXJkIGFyZSB3b3JraW5nIG9uIHRoZSBwdWJsaWNhdGlv biBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ IGhhdmUgcmV2aWV3ZWQgdmVyc2lvbiAwNSBvZiB0aGUgZHJhZnQsIGhlcmUgYXJlIG15IGNvbW1l bnRzIGFuZCBzb21lPGJyPg0KJmd0OyBxdWVzdGlvbnMsIHBsZWFzZSBjb25zaWRlci48YnI+DQom Z3Q7PGJyPg0KJmd0OyAxLjxicj4NCiZndDsgRXh0cmFjdCB0aGUgYWNyb255bSB3aGVuIGZpcnN0 IHVzZSwgZm9yIGV4YW1wbGUsIExTUCBpbiB0aGUgSW50cm9kdWN0aW9uLCBhbmQgaXQnczxicj4N CiZndDsgbm90IG5lY2Vzc2FyeSB0byBleHRyYWN0IGFuIGFjcm9ueW0gd2hlbiBlYWNoIHVzZXMs IGZvciBleGFtcGxlLCBNUExTIGluPGJyPg0KJmd0OyBzZWN0aW9uIDEgYW5kIHNlY3Rpb24gMy4y IC48YnI+DQomZ3Q7IFRoYW5rcywgd2lsbCBjaGFuZ2UgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi48 YnI+DQomZ3Q7PGJyPg0KJmd0OyAyLjxicj4NCiZndDsgSW4gUkZDNjM3MCwgaXQgZGVmaW5lcyBN UExTLVRQIHBvaW50LXRvLXBvaW50IFR1bm5lbHMgaWRlbnRpZmllcnMsIE1QTFMtVFA8YnI+DQom Z3Q7IGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIE1QTFMgTFNQcyBpZGVu dGlmaWVycywgTVBMUy1UUDxicj4NCiZndDsgUHNldWRvd2lyZXMgSWRlbnRpZmllcnMgYW5kIFNl Y3Rpb24gSWRlbnRpZmllcnMuIEFuZCBpbiBTZWN0aW9uIDUgb2YgUkZDNjM3MCw8YnI+DQomZ3Q7 IHRoZXJlIGFyZSBzb21lIHRleHQgdGhhdCBkZXNjcmliZXMgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biAmcXVvdDtNUExTIHR1bm5lbCZxdW90OyBhbmQ8YnI+DQomZ3Q7ICZxdW90O01QTFMgTFNQJnF1 b3Q7LiBJbiB0aGlzIGRyYWZ0LCB0aGVyZSBhcmUgbWFueSB1c2FnZXMgb2YgJnF1b3Q7dHVubmVs JnF1b3Q7IGluIHNlY3Rpb24gNCwgNSBhbmQgNiw8YnI+DQomZ3Q7IGFuZCBhY3R1YWxseSBpdCBz aG91bGQgYmUgJnF1b3Q7TFNQJnF1b3Q7LiBJIGtub3cgdGhhdCBzb21ldGltZXMgcGVvcGxlIGFs dGVybmF0aXZlbHkgdXNlPGJyPg0KJmd0OyB0dW5uZWwgYW5kIExTUCwgYnV0IGl0J3MgYmV0dGVy IHRvIHVzZSB0aGUgdGVybSBpbiBhbiBhY2N1cmF0ZSB3YXkgaGVuY2UgdG8gcmVkdWNlPGJyPg0K Jmd0OyB0aGUgY29uZnVzaW9uLjxicj4NCiZndDsgWWVzLCB3aWxsIHN0YXRlIHRoYXQgZXhwbGlj aXRseSBpbiB0aGUgbmV4dCB2ZXJzaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IEluIGFkZGl0aW9u LCBiYXNlZCBvbiB0aGUgbXBsc09hbUlkTWVnU2VydmljZVBvaW50ZXJUeXBlIChvbmx5IGxzcCwg cHcgYW5kPGJyPg0KJmd0OyBzZWN0aW9uIGxpc3RlZCksIGl0IGltcGxpZXMgdGhhdCB0aGUgTVBM Uy1UUCBwb2ludC10by1wb2ludCBUdW5uZWxzIGlkZW50aWZpZXJzIGFyZTxicj4NCiZndDsgYWN0 dWFsbHkgcHJlY2x1ZGVkIGluIHRoaXMgZG9jdW1lbnQuIElzIG15IHVuZGVyc3RhbmRpbmcgcmln aHQ/IElmIHNvLCBpdCBuZWVkczxicj4NCiZndDsgbG9vayB0aHJvdWdoIHRoZSBkb2N1bWVudCBh bmQgcmVmaW5lIHRoZSB0ZXh0IHRvIHN0YXRlIGl0IGNsZWFybHkuPGJyPg0KJmd0OyZuYnNwOyBt cGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgb2JqZWN0IGlzIGRlZmluZWQgZ2VuZXJpY2Fs bHkgdG8gaGFuZGxlIGFueTxicj4NCiZndDsga2luZCBvZiBzZXJ2aWNlIHBvaW50ZXIgKFR1bm5l bCwgTFNQLCBQVykgdGhlc2Ugc2VydmljZSBwb2ludGVycyBjYW4gYmUgdXNlZCBmb3I8YnI+DQom Z3Q7IE1QTFMvTVBMUy1UUCBwYXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+SGVyZSwgSSBhbSBub3QgcHJlZmVyIHRvIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gTVBMUyBhbmQgTVBMUy1UUC48YnI+DQo8YnI+DQpPZiBjYXVzZSwgaWYgdGhl IGludGVudGlvbiBpcyB0byBhcHBseSB0aGlzIE1JQiB0byBib3RoIE1QTFMgYW5kIE1QTFMtVFAg cGF0aCwgaXQncyBiZXR0ZXIgdG8gYWRkIHNvbWUgdGV4dCB0byBleHBsaWNpdGx5IHN0YXRlIHRo aXMgKGUuZy4sIGluIHRoZSBBYnN0cmFjdCBhbmQvb3IgSW50cm9kdWN0aW9uIHNlY3Rpb24pLjxi cj4NCjxicj4NCkFjdHVhbGx5LCB0aGUgYWJvdmUgcXVlc3Rpb24gcmVsYXRlZCB0byB0aGUgZGVm aW5pdGlvbiBvZiBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUsIGl0J3MgZGVmaW5lZCBh cyBiZWxvdzo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttcGxzT2FtSWRNZWdTZXJ2 aWNlUG9pbnRlclR5cGUgT0JKRUNULVRZUEU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFNZTlRBWCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJTlRFR0VSIHs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxzcCAoMSksPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwc2V1ZG93aXJlICgyKSw8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlY3Rpb24gKDMp PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCkhlcmUsIG9ubHkgbHNwLCBw dyBhbmQgc2VjdGlvbiBsaXN0ZWQsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgVHVubmVsIGlzIG5v dCB0aGUgc2FtZSB0aGluZyBhcyBMU1AuIElmIE1QTFMgVHVubmVsIGlzIGluY2x1ZGVkLCB0aGVu IHRoZXJlIG1heSBuZWVkIHRoZSBmb3VydGggaXRlbTogdHVubmVsICg0KSwgcmlnaHQ/PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+R290IGl0LiBZZXMsIFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9 kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBIZXJlIGFyZSBzb21lIGV4YW1wbGUgdGhhdCBtYXkgbmVlZCB1cGRhdGVzOjxi cj4NCiZndDs8YnI+DQomZ3Q7IFNlY3Rpb24gNC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPTEQ6PGJy Pg0KJmd0OyAmcXVvdDs8YnI+DQomZ3Q7IFRoZSBNSUIgbW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3Vy YXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHBvaW50LXRvLXBvaW50LCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCwg YXNzb2NpYXRlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJp ZGlyZWN0aW9uYWwgTVBMUyB0dW5uZWxzIGFuZCBNUExTIFBzZXVkb3dpcmVzLjxicj4NCiZndDsg JnF1b3Q7PGJyPg0KJmd0OyBORVc6PGJyPg0KJmd0OyAmcXVvdDs8YnI+DQomZ3Q7IFRoZSBNSUIg bW9kdWxlIHN1cHBvcnRzIGNvbmZpZ3VyYXRpb24gb2YgT0FNIGlkZW50aWZpZXJzIGZvcjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1QTFMtVFAgY28tcm91dGVk IGJpZGlyZWN0aW9uYWwgTFNQcywgYXNzb2NpYXRlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGJpZGlyZWN0aW9uYWwgTFNQcywgU2VjdGlvbnMgYW5kIFBzZXVk b3dpcmVzLjxicj4NCiZndDsgJnF1b3Q7PGJyPg0KJmd0OyBBcyBtZW50aW9uZWQgYWJvdmUuIHdl IGRvbnQgbmVlZCB0byBjaGFuZ2UgdGhlIHRleHQgKE1QTFMgdG8gTVBMUy1UUCksIHdpbGw8YnI+ DQomZ3Q7IGVuaGFuY2UgdGhlIGV4aXN0aW5nIHRleHQgdG8gbWFrZSB0aGUgaW50ZW50aW9uIG9m IHRoaXMgTUlCIGNsZWFyLjxicj4NCjxicj4NCk9LLCBJIGFtIGZpbmUgd2l0aCB0aGUgaWRlYSB0 byBtYWtlIHRoaXMgTUlCIGdlbmVyYWxseSBhcHBseSB0byBNUExTIGFuZCBNUExTLVRQLCBidXQg YXMgc2FpZCBhYm92ZSwgc29tZSBpbnRlbnRpb24gdGV4dCBtYXkgbmVlZGVkLjxicj4NCjxicj4N CkluIGFkZGl0aW9uLCB3aGVuIHlvdSBiZWdpbiB0byBlbmhhbmNlIHRoZSB0ZXh0LCBwbGVhc2Ug Y29uc2lkZXIgd2hpY2ggcGF0aHMoZS5nLiwgVHVubmVsLCBMU1AsIFBXIGFuZCBTZWN0aW9uKSB5 b3UgaW50ZW5kIHRvIGluY2x1ZGUgYW5kIG1ha2UgYWxsIHJlbGV2YW50IHRleHQgY29uc2lzdGVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5TdXJlLiB3aWxsIHVwZGF0ZSBpbiB0 aGUgbmV4dCB2ZXJzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCiZndDs8YnI+DQomZ3Q7 IFNlY3Rpb24gNS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBzLy4uLmNvbmZpZ3VyYXRpb25zIGZvciBN UExTIFR1bm5lbHMgYW5kIFBzZXVkb3dpcmVzLy4uLmNvbmZpZ3VyYXRpb25zIGZvcjxicj4NCiZn dDsgTVBMUy1UUCBMU1BzLCBTZWN0aW9ucyBhbmQgUHNldWRvd2lyZXM8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBTZWN0aW9uIDUuMTxicj4NCiZndDs8YnI+DQomZ3Q7IHMvLi4uZm9yIE1QTFMgdHVubmVs cyBhbmQgcHNldWRvd2lyZXMuLy4uLmZvciBNUExTLVRQIExTUHMsIFNlY3Rpb25zIGFuZDxicj4N CiZndDsgUHNldWRvd2lyZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA2PGJyPg0KJmd0 Ozxicj4NCiZndDsgcy8uLi5NUExTIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHR1bm5lbC8uLi5N UExTLVRQIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUDxicj4NCiZndDs8YnI+DQomZ3Q7IHMv Li4uY28tcm91dGVkIE1QTFMgdHVubmVsIGFyZSBpbGx1c3RyYXRlZCBoZXJlLy4uLk1QTFMtVFAg Y28tcm91dGVkPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsIExTUCBhcmUgaWxsdXN0cmF0ZWQgaGVy ZSBTYW1lIGFzIGFib3ZlLjxicj4NCjxicj4NCk9LLCBzYW1lIGFzIGFib3ZlLCB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIFR1bm5lbCBhbmQgTFNQLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkFDSy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pjxicj4NCiZndDs8YnI+DQomZ3Q7IDMuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIG1wbHNPYW1J ZE1lVGFibGUsIHNpbmNlIHRoaXMgaXMgdGhlIGlkZW50aWZpZXIgTUlCLCB3aHkgZG8gd2UgbmVl ZHRoZTxicj4NCiZndDsgZm9sbG93aW5nIGl0ZW1zPzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgbXBsc09hbUlkTWVQcm9hY3RpdmVPYW1QaGJUQ1ZhbHVlID0gMCw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHNPYW1JZE1lT25EZW1hbmRPYW1QaGJU Q1ZhbHVlJm5ic3A7ID0gMCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBzZWVtcyB0aGF0IHRoZXkg c2hvdWxkIG5vdCBiZWxvbmcgdG8gdGhpcyBNSUIsIG1heWJlIGJldHRlciBpbiBvdGhlciBNSUIu PGJyPg0KJmd0OyBQSEIgVEMgdmFsdWVzIGFyZSBkZWZpbmVkIGluIHRoaXMgTUlCIHRvIGJhc2lj YWxseSB1c2UgdGhlc2UgdmFsdWVzIGluPGJyPg0KJmd0OyBQcm9hY3RpdmUoQkZEKS9PbkRlbWFu ZChMU1AgUGluZykgc2Vzc2lvbnMuPGJyPg0KPGJyPg0KSSBrbm93IHRoZXkgYXJlIHVzZWZ1bCwg SSBhbSBqdXN0IG5vdCBzdXJlIHdoZXRoZXIgdGhleSBzaG91bGQgYmVsb25nIHRvIHRoaXMgTUlC LCBzaW5jZSB0aGlzIE1JQiBpcyBqdXN0IGFuIE9BTSBpZGVudGlmaWVyIE1JQi48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5XaWxsIGRpc2N1c3MgaW50ZXJuYWxseSBhbmQgZGVjaWRl IG9uIHRoaXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMi IGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mZ3Q7PGJyPg0KJmd0OyA0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IG1wbHNPYW1JZE1lZ1BhdGhG bG93IE9CSkVDVC1UWVBFPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7U1lOVEFYJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElOVEVHRVIgezxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5pZGlyZWN0aW9u YWxQb2ludFRvUG9pbnQgKDEpLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Y29Sb3V0ZWRCaWRpcmVjdGlvbmFsUG9pbnRUb1BvaW50ICgyKSw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fzc29jaWF0ZWRCaWRp cmVjdGlvbmFsUG9pbnRUb1BvaW50ICgzKSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3VuaWRpcmVjdGlvbmFsUG9pbnRUb011bHRpUG9pbnQgKDQpPGJy Pg0KJmd0Ozxicj4NCiZndDsgU2VlbXMgUkZDNjM3MCBkb2VzIG5vdCBkZWZpbmUgaG93IHRvIGlk ZW50aWZ5IGE8YnI+DQomZ3Q7IHVuaWRpcmVjdGlvbmFsUG9pbnRUb011bHRpUG9pbnQgcGF0aCwg YW5kIGZyb20gdGhlIEludHJvZHVjdGlvbiBvZiB0aGlzPGJyPg0KJmd0OyBkb2N1bWVudCwgdGhl IFAyTVAgc2VlbXMgbm90IGJlIGluY2x1ZGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIHdpbGwg YWRkIG1vcmUgaW5mb3JtYXRpb24gZm9yIFAyTVAgaW4gdGhlIG5leHQgdmVyc2lvbiBhZnRlciB0 aGUgaW50ZXJuYWw8YnI+DQomZ3Q7IGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KT0ssIHBsZWFzZSBk by48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BQ0smbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlk ICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8YnI+DQomZ3Q7IDUuPGJyPg0KJmd0 Ozxicj4NCiZndDsgbXBsc09hbUlkTWVnU3ViT3BlclN0YXR1cyBPQkpFQ1QtVFlQRTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NZTlRBWCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0JJVFMgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttZWdEb3duICgwKSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7bWVEb3duICgxKSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7b2FtQXBwRG93biAoMiksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3BhdGhEb3duICgzKTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVGhlIGJpdCAwIChtZWdEb3duKSBpbmRpY2F0ZXMgdGhlIE1FRyBpcyBkb3duLjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRoZSBiaXQgMSAobWVEb3duKSBpbmRpY2F0ZXMgdGhlIE1FIHRhYmxlIGlzPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZG93bi48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBUaGUgYml0IDIgKG9hbUFwcERvd24pIGluZGljYXRlcyB0aGF0IHRo ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE9BTSBhcHBsaWNhdGlvbiBoYXMgbm90aWZpZWQgdGhhdCB0aGUgZW50aXR5IChM U1Agb3IgUFcpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgbW9uaXRvcmVkIGJ5IHRoaXMgTUVHIGlzIGRvd24uIEN1cnJlbnRs eSwgQkZEIGlzIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9ubHkgc3VwcG9ydGVkIE9BTSBhcHBsaWNhdGlvbi48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBUaGUgYml0IDMgKHBhdGhEb3duKSBpbmRpY2F0ZXMgdGhhdCB0aGUgdW5kZXJseWluZzxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IExTUCBvciBQVyBpcyBkb3duLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYW0g bm90IHN1cmUgd2hhdCdzIHRoZSBtZWFuIG9mICZxdW90O2Rvd24mcXVvdDsgaGVyZSwgZXNwZWNp YWxseSB0aGUgbWVhbiBvZiAmcXVvdDtNRUcgaXM8YnI+DQomZ3Q7IGRvd24mcXVvdDssICZxdW90 O01FIHRhYmxlIGlzIGRvd24mcXVvdDsgYW5kICZxdW90O0xTUCBhbmQgUFcgaXMgZG93biZxdW90 Oz88YnI+DQomZ3Q7IFdlIGRlZmluZWQgdGhpcyBvYmplY3QgdG8gbm90aWZ5IHRoZSBvcGVyYXRp b25hbCBzdGF0dXMgb2YgTUVHLCBNRSwgT0FNIGFwcDxicj4NCiZndDsgYW5kIHRoZSBNUExTL01Q TFMtVFAgcGF0aCwgd2lsbCBhZGQgbW9yZSBpbmZvcm1hdGlvbiBpbiB0aGUgbmV4dCB2ZXJzaW9u Ljxicj4NCjxicj4NCk9LLCBwbGVhc2UgZG8uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+QUNLJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZh Y2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m Z3Q7PGJyPg0KJmd0OyA2Ljxicj4NCiZndDs8YnI+DQomZ3Q7IG1wbHNPYW1JZE1lU2VydmljZVBv aW50ZXIgT0JKRUNULVRZUEU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1lOVEFYJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJv d1BvaW50ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtNQVgtQUNDRVNTJm5ic3A7ICZuYnNwOyByZWFkLWNyZWF0ZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NUQVRVUyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBjdXJyZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7REVTQ1JJUFRJT048YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7VGhpcyB2YXJpYWJsZSByZXByZXNlbnRzIGEgcG9p bnRlciB0byB0aGUgTVBMUy1UUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHBhdGguIFRoaXMgdmFsdWUgTVVTVCBwb2lu dCBhdCBhbiBlbnRyeSBpbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHNUdW5uZWxFbnRyeSBpZiBtcGxzT2FtSWRNZWdTZXJ2 aWNlUG9pbnRlclR5cGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGlzIGNvbmZpZ3VyZWQgYXMgbHNwICgxKSBvciBhdCBhbiBlbnRyeSBp biB0aGUgcHdFbnRyeSBpZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgbXBsc09hbUlkTWVnU2VydmljZVBvaW50ZXJUeXBlIGlzIGNvbmZp Z3VyZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGFzIHBzZXVkb3dpcmUgKDIpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhvdyBhYm91dCBt cGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGVzZWN0aW9uIGlzIGNvbmZpZ3VyZWQgYXMgc2Vj dGlvbjxicj4NCiZndDsgKDMpPzxicj4NCiZndDsgU2VjdGlvbiBpcyBub3QgeWV0IHRha2VuIGNh cmUgaW4gdGhpcyBNSUIuIFdpbGwgYWRkIG1pc3NpbmcgaW5mb3JtYXRpb24gYWZ0ZXI8YnI+DQom Z3Q7IGludGVybmFsIGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KT0ssIHBsZWFzZSBkby48YnIgc3R5 bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2lmICFzdXBwb3J0TGlu ZUJyZWFrTmV3TGluZV0+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVh ayI+DQo8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovk vZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QUNLJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1s ZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PGJyPg0KJmd0 OyBBbmQgZHJhZnQtaWV0Zi1tcGxzLXRwLXRlLW1pYi0wOCBkZWZpbmVzIG1wbHNUdW5uZWxFeHRF bnRyeSBmb3IgTVBMUy1UUDxicj4NCiZndDsgdHVubmVscyBhbmQgcHdFeHRFbnRyeSBmb3IgTVBM Uy1UUCBQV3MsIHNob3VsZCB0aGUgYWJvdmUgbXBsc1R1bm5lbEVudHJ5PGJyPg0KJmd0OyBhbmQg cHdFbnRyeSBiZSBjaGFuZ2VkIHRvIG1wbHNUdW5uZWxFeHRFbnRyeSBhbmQgcHdFeHRFbnRyeT88 YnI+DQomZ3Q7IE5vLFR1bm5lbCAmYW1wOyBQVyBlbnRyaWVzIGFyZSBhdWdtZW50ZWQgdG8gaGF2 ZSB0aGUgZXh0cmEgZmllbGRzIGluIHRoZSBuZXcgdGFibGVzPGJyPg0KJmd0OyBmb3IgTVBMUy1U UC4gVGhlIGJhc2UgdGFibGUgc2hvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBNUExTL01QTFMt VFAgcGF0aCB0bzxicj4NCiZndDsgT0FNIGNvbmZpZyBhc3NvY2lhdGlvbi48YnI+DQo8YnI+DQpP Sy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BQ0smbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlk ICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCiZndDs8YnI+DQomZ3Q7IDcuPGJy Pg0KJmd0OyBtcGxzT2FtSWRNZWdTZXJ2aWNlUG9pbnRlclR5cGUgT0JKRUNULVRZUEU8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1lO VEFYJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElOVEVHRVIgezxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xzcCAoMSksPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHNldWRvd2ly ZSAoMiksPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7c2VjdGlvbiAoMyk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01B WC1BQ0NFU1MmbmJzcDsgJm5ic3A7IHJlYWQtY3JlYXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1RBVFVTJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGN1cnJlbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtERVNDUklQVElPTjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtJbmRpY2F0ZXMgdGhlIHNlcnZpY2UgdHlwZSBmb3IgdGhl IE1FRy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IElmIHRoZSBzZXJ2aWNlIHR5cGUgaW5kaWNhdGVzIGxzcCwgdGhlIHNlcnZpY2UgcG9p bnRlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgaW4gbXBsc09hbUlkTWVUYWJsZSBwb2ludHMgdG8gYW4gZW50cnkgaW48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBtcGxz VHVubmVsVGFibGUgW1JGQzM4MTJdLjxicj4NCiZndDs8YnI+DQomZ3Q7IFNpbmNlIGRyYWZ0LWll dGYtbXBscy10cC10ZS1taWItMDggZGVmaW5lcyBtcGxzVHVubmVsRXh0VGFibGUgZm9yIE1QTFMt VFA8YnI+DQomZ3Q7IFR1bm5lbHMgYW5kIFB3cywgc2hvdWxkIHRoZSBhYm92ZSBtcGxzVHVubmVs VGFibGUgYmUgbXBsc1R1bm5lbEV4dFRhYmxlIGFuZDxicj4NCiZndDsgcmVmZXJlbmNlIGJlIGRy YWZ0LWlldGYtbXBscy10cC10ZS1taWItMDg/PGJyPg0KJmd0OyBObywgYXMgc3RhdGVkIGFib3Zl LCB0aGlzIE1JQiBpcyBtYWlubHkgZGVmaW5lZCB0byBwcm92aWRlIE9BTSBjb25maWdzIGZvciBN UExTPGJyPg0KJmd0OyAmYW1wOyBNUExTLVRQIHBhdGhzLjxicj4NCjxicj4NCk9LLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFDSyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAu NzVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L 5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCkJl c3QgcmVnYXJkcyw8YnI+DQpNYWNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxicj4N CiZndDsgTWFjaDxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRo dXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgNjozMSBQTTxicj4NCiZndDsgJmd0OyBUbzogPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7 IENjOiA8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnPC9hPjsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTik7IEpvYW48 YnI+DQomZ3Q7ICZndDsgQ3VjY2hpYXJhOyBNYWNoIENoZW47ICZsdDs8YSBocmVmPSJtYWlsdG86 bXBscy1hZHNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtYWRzQHRvb2xzLmlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogU2hlcGhlcmRzIGZvciBNUExTIE1JQiBtb2R1bGVzPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdvcmtpbmcgR3JvdXAsPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFdlIGhhdmUgZm9yIHNvbWUgdGltZSBiZWVuIGxvb2tpbmcgZm9yIHNv bWVvbmUgdG8gaGVscCB1cyBzaGVwaGVyZGluZzxicj4NCiZndDsgJmd0OyBvdXIgTUlCIG1vZHVs ZXMuIEknbSBoYXBweSB0byBhbm5vdW5jZSB0aGF0IE1hY2ggQ2hlbiBhbmQgWW91bmcgTGVlPGJy Pg0KJmd0OyAmZ3Q7IGhhcyBhZ3JlZWQgdG8gaGVscCB1cy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgUGxlYXNlIGhlbHAgTWFjaCBhbmQgWW91bmcgYXMgdGhleSBzdGFydCB3b3JraW5n IHdpdGggdGhlIGRvY3VtZW50cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2UndmUg YXNzaWduZWQgTWFjaCBhcyBTaGVwaGVyZCBmb3IgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1t aWIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEZ1cnRoZXIgc2hlcGhlcmQgYXNzaWdu bWVudHMgd2lsbCBiZSBkb25lIGFzIHNvb24gYXMgdGhlIGRldGFpbHMgYXJlIHNvcnRlZDxicj4N CiZndDsgb3V0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAv TG9hPGJyPg0KJmd0OyAmZ3Q7IGZvciB0aGUgbXBscyB3ZyBjaGFpcnM8YnI+DQomZ3Q7ICZndDsg LS08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTG9hIEFuZGVy c3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86bG9h QG1haWwwMS5odWF3ZWkuY29tIj4NCmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48YnI+DQomZ3Q7 ICZndDsgU2VuaW9yIE1QTFMgRXhwZXJ0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4gSHVhd2VpPGJyPg0KJmd0 OyAmZ3Q7IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25l OiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiPg0KJiM0Mzs0NiA3Mzkg ODEgMjEgNjQ8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA9704BSZXEMA510MBXchi_-- From nobody Mon Sep 15 00:16:12 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 410FA1A06D8 for ; Mon, 15 Sep 2014 00:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nmfU5bBUw3Kp for ; Mon, 15 Sep 2014 00:16:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE63D1A06BB for ; Mon, 15 Sep 2014 00:16:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1382718C1A9; Mon, 15 Sep 2014 09:16:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EC5AE238059; Mon, 15 Sep 2014 09:16:04 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 15 Sep 2014 09:16:04 +0200 From: To: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Thread-Topic: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast Thread-Index: AQHP0LTob11ImvmUwUKi6GJY97G0iA== Date: Mon, 15 Sep 2014 07:16:03 +0000 Message-ID: <10459_1410765365_54169234_10459_13562_1_7251d3f5-d818-4622-8af1-bef81ef7834a@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <5410225D.60105@pi.nu> In-Reply-To: <5410225D.60105@pi.nu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-ID: <6C8AAB6C1CEC1B4B957EBB3C95A2924A@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.15.22118 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4EZN6XUQ9idEpLWpNIPwt70oShA Subject: Re: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast 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, 15 Sep 2014 07:16:09 -0000 SGkgTG9hLA0KDQoyMDE0LTA5LTEwLCBMb2EgQW5kZXJzc29uOg0KPiBBcmUgeW91IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1zZWFtbGVzcy1tY2FzdD8N Cg0KSSdtIG5vdCBhd2FyZSBvZiBhbnkgbm9uLWRpc2Nsb3NlZCBJUFIgb24gZHJhZnQtaWV0Zi1t cGxzLXNlYW1sZXNzLW1jYXN0Lg0KDQotVGhvbWFzCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Sep 17 06:53: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 A8FA01A041D; Wed, 17 Sep 2014 06:53:47 -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 np-iKhwYMTcE; Wed, 17 Sep 2014 06:53:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2851A0110; Wed, 17 Sep 2014 06:53:44 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917135344.32751.18666.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 06:53:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/YSPlkco5pQ7v9osSluZuss1WHQs Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 17 Sep 2014 13:53:47 -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 : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-01.txt Pages : 5 Date : 2014-09-17 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-raza-mpls-oam-ipv6-rao-01 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 Fri Sep 19 02:28: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 19B6D1A0079; Fri, 19 Sep 2014 02:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 C4Hk3NcF4EbL; Fri, 19 Sep 2014 02:28:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF461A007B; Fri, 19 Sep 2014 02:28:40 -0700 (PDT) Received: from [192.168.0.100] (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 132941801487; Fri, 19 Sep 2014 11:28:39 +0200 (CEST) Message-ID: <541BF749.6010907@pi.nu> Date: Fri, 19 Sep 2014 11:28:41 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gregory Mirsky , "ipfix@ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NseSm14mq9X-z0UBuIRFzuqk2Gc Cc: "mpls@ietf.org" , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 19 Sep 2014 09:28:43 -0000 Greg, I'm not sure about this - would changing the names require updating all existing deployed MIBs? Can we get an mib doctor advice on this? /Loa On 2014-09-10 21:22, Gregory Mirsky wrote: > Dear All, > > in several places of describing MPLS Label element IEs the registry > still refers to the EXP field even though the RFC 5462 updated RFC 3032 > and renamed it “Traffic Class” (TC). Below is the list of IEs that may > benefit from updating Description and Reference information: > > ·mplsTopLabelStackSection > > ·mplsTopLabelStackSection2 > > ·mplsTopLabelStackSection3 > > ·mplsTopLabelStackSection4 > > ·mplsTopLabelStackSection5 > > ·mplsTopLabelStackSection6 > > ·mplsTopLabelStackSection7 > > ·mplsTopLabelStackSection8 > > ·mplsTopLabelStackSection9 > > ·mplsTopLabelStackSection10 > > ·mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be > created instead?) > > ·postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc > be created instead?) > > Regards, > > Greg > > > > _______________________________________________ > 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 Fri Sep 19 02:45: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 4A6E91A006B; Fri, 19 Sep 2014 02:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vQZRSrdVQHe8; Fri, 19 Sep 2014 02:45:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732001A006A; Fri, 19 Sep 2014 02:45:15 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-eb-541ba53136d1 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.97.05330.135AB145; Fri, 19 Sep 2014 05:38:26 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 19 Sep 2014 05:45:05 -0400 From: Gregory Mirsky To: Loa Andersson , "ipfix@ietf.org" Thread-Topic: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry Thread-Index: Ac/NKwbd4PEEn4EDQnes99jLrEnN8AG4pmqAAAfuZqA= Date: Fri, 19 Sep 2014 09:45:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B833FDE@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> In-Reply-To: <541BF749.6010907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPiK7RUukQgy8nOCyOXX3NbvFv7hxm izcnDjFa3Fq6ktWBxWPJkp9MHrOmt7EFMEVx2aSk5mSWpRbp2yVwZTx+fZGpYCNfxYHt15kb GFdxdzFyckgImEi86n3BBmGLSVy4tx7I5uIQEjjKKDHp2CVGkISQwHJGiTl78kFsNgEjiRcb e9hBbBEBB4nXT7+wgtjMAiESeyYtB6sXFoiVWNz0mAWiJk5i/9TdrBC2lcTPhptgy1gEVCWO bjwCNodXwFdizozb7BC7MiQ+3XsLNocTqGb61Otg9YxAx30/tYYJYpe4xK0n85kgjhaQWLLn PDOELSrx8vE/VghbSWLO62vMEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScss JC2zkLQsYGRZxchRWpxalptuZLCJERg5xyTYdHcw7nlpeYhRgINRiYd3gax0iBBrYllxZe4h RmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM4teHhiy77HyjV/WfMlz61o 4Fr8vvy25lZev0oZ/ZuaH47FHWDmnvziVFb+bRnlTIkn80/q6lRWrjD9YpnnKv5iWryw8avl p9Un88TozHnhpH/N5tDq9xU1x2P3y3Got+m6vJXz/HdxxtMZm7ltWw7tdwu/vmTz3daW2wty 3p6UXis6ddpdt2dKLMUZiYZazEXFiQCcH8rYfQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wnSQOHtyTyQ_0Mi4r-Y4cFX9w5s Cc: "mpls@ietf.org" , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 19 Sep 2014 09:45:17 -0000 Hi Loa, I haven't thought of possible impact of RFC 5462 to existing MIBs nor I've = checked for it. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Friday, September 19, 2014 10:29 AM To: Gregory Mirsky; ipfix@ietf.org Cc: mpls@ietf.org; MIB Doctors (E-mail) Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) E= ntities registry Greg, I'm not sure about this - would changing the names require updating all exi= sting deployed MIBs? Can we get an mib doctor advice on this? /Loa On 2014-09-10 21:22, Gregory Mirsky wrote: > Dear All, > > in several places of describing MPLS Label element IEs the registry=20 > still refers to the EXP field even though the RFC 5462 updated RFC=20 > 3032 and renamed it "Traffic Class" (TC). Below is the list of IEs=20 > that may benefit from updating Description and Reference information: > > *mplsTopLabelStackSection > > *mplsTopLabelStackSection2 > > *mplsTopLabelStackSection3 > > *mplsTopLabelStackSection4 > > *mplsTopLabelStackSection5 > > *mplsTopLabelStackSection6 > > *mplsTopLabelStackSection7 > > *mplsTopLabelStackSection8 > > *mplsTopLabelStackSection9 > > *mplsTopLabelStackSection10 > > *mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be=20 > created instead?) > > *postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc=20 > be created instead?) > > Regards, > > Greg > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=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 Fri Sep 19 04:52: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 F2FE51A011F; Fri, 19 Sep 2014 04:52:05 -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_HELO_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 swqLqexf9pG4; Fri, 19 Sep 2014 04:52:03 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59DC1A00E7; Fri, 19 Sep 2014 04:52:02 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 19 Sep 2014 11:51:39 +0000 Message-ID: <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson , Gregory Mirsky , References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> Date: Fri, 19 Sep 2014 12:49:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: AM3PR01CA041.eurprd01.prod.exchangelabs.com (10.141.191.31) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Forefront-PRVS: 0339F89554 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(252514010)(377454003)(24454002)(51704005)(199003)(13464003)(377424004)(86362001)(81342003)(79102003)(62966002)(80022003)(77982003)(46102003)(81542003)(74502003)(4396001)(74662003)(83322001)(47776003)(23746002)(88136002)(105586002)(116806002)(85306004)(50226001)(77156001)(95666004)(93916002)(84392001)(44716002)(106356001)(66066001)(20776003)(21056001)(19580395003)(44736004)(62236002)(107046002)(102836001)(77096002)(50466002)(101416001)(19580405001)(92726001)(33646002)(14496001)(87286001)(76482002)(87976001)(61296003)(89996001)(42186005)(85852003)(83072002)(99396002)(104166001)(92566001)(31966008)(90102001)(15975445006)(76176999)(81686999)(81816999)(97736003)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/R4wlsttoSxH1SJ9Rt5g26gCmF9U Cc: mpls@ietf.org, "MIB Doctors \(E-mail\)" Subject: Re: [mpls] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 19 Sep 2014 11:52:06 -0000 ----- Original Message ----- From: "Loa Andersson" To: "Gregory Mirsky" ; Cc: ; "MIB Doctors (E-mail)" Sent: Friday, September 19, 2014 10:28 AM Greg, I'm not sure about this - would changing the names require updating all existing deployed MIBs? Yes. See RFC2578 s.10. You cannot reuse an OID so this would need a new OID; messy, best left as one of those quaint, historic anomalies that litter our work. Updating the DESCRIPTION and REFERENCE is not a problem (but issuing any MIB module is a lot of work). Tom Petch [not a MIB doctor] Can we get an mib doctor advice on this? /Loa On 2014-09-10 21:22, Gregory Mirsky wrote: > Dear All, > > in several places of describing MPLS Label element IEs the registry > still refers to the EXP field even though the RFC 5462 updated RFC 3032 > and renamed it “Traffic Class” (TC). Below is the list of IEs that may > benefit from updating Description and Reference information: > > ·mplsTopLabelStackSection > > ·mplsTopLabelStackSection2 > > ·mplsTopLabelStackSection3 > > ·mplsTopLabelStackSection4 > > ·mplsTopLabelStackSection5 > > ·mplsTopLabelStackSection6 > > ·mplsTopLabelStackSection7 > > ·mplsTopLabelStackSection8 > > ·mplsTopLabelStackSection9 > > ·mplsTopLabelStackSection10 > > ·mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be > created instead?) > > ·postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc > be created instead?) > > Regards, > > Greg > > > > _______________________________________________ > 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Sep 19 05:00: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 AF3661A004C; Fri, 19 Sep 2014 02:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 O6LW3hVP5Hf6; Fri, 19 Sep 2014 02:53:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463971A004B; Fri, 19 Sep 2014 02:53:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEC93E86; Fri, 19 Sep 2014 11:53:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PYis_z1wZmlJ; Fri, 19 Sep 2014 11:53:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 19 Sep 2014 11:53:39 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 178AB20035; Fri, 19 Sep 2014 11:53:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id K8hhCEcs0KcK; Fri, 19 Sep 2014 11:53:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E98120036; Fri, 19 Sep 2014 11:53:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 104D52E6836D; Fri, 19 Sep 2014 11:53:36 +0200 (CEST) Date: Fri, 19 Sep 2014 11:53:36 +0200 From: Juergen Schoenwaelder To: Loa Andersson Message-ID: <20140919095336.GA22032@elstar.local> Mail-Followup-To: Loa Andersson , Gregory Mirsky , "ipfix@ietf.org" , "mpls@ietf.org" , "MIB Doctors (E-mail)" References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <541BF749.6010907@pi.nu> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3cethtfibiyaBAKeOoivKviBXHQ X-Mailman-Approved-At: Fri, 19 Sep 2014 05:00:19 -0700 Cc: "mpls@ietf.org" , "ipfix@ietf.org" , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] [MIB-DOCTORS] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 09:53:43 -0000 Hi, IEs are not used by MIB modules. Not sure this is relevant but according to SMIv2 rules, you can't rename a Textual Convention (TC). All you can do is create a new one and deprecate the old one. The question is whether doing this is worth anything. /js On Fri, Sep 19, 2014 at 11:28:41AM +0200, Loa Andersson wrote: > Greg, > > I'm not sure about this - would changing the names require updating all > existing deployed MIBs? > > Can we get an mib doctor advice on this? > > /Loa > > On 2014-09-10 21:22, Gregory Mirsky wrote: > >Dear All, > > > >in several places of describing MPLS Label element IEs the registry > >still refers to the EXP field even though the RFC 5462 updated RFC 3032 > >and renamed it “Traffic Class†(TC). Below is the list of IEs that may > >benefit from updating Description and Reference information: > > > >·mplsTopLabelStackSection > > > >·mplsTopLabelStackSection2 > > > >·mplsTopLabelStackSection3 > > > >·mplsTopLabelStackSection4 > > > >·mplsTopLabelStackSection5 > > > >·mplsTopLabelStackSection6 > > > >·mplsTopLabelStackSection7 > > > >·mplsTopLabelStackSection8 > > > >·mplsTopLabelStackSection9 > > > >·mplsTopLabelStackSection10 > > > >·mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be > >created instead?) > > > >·postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc > >be created instead?) > > > >Regards, > > > > Greg > > > > > > > >_______________________________________________ > >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 > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Sep 19 06:05: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 C05041A0137 for ; Fri, 19 Sep 2014 06:05:11 -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 jvJfsu68V4IU for ; Fri, 19 Sep 2014 06:05:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D041A0142 for ; Fri, 19 Sep 2014 06:05:10 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919130510.26180.34077.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 06:05:10 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/J20RMo6eMUNzEA73i3m0--34H9I 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: Fri, 19 Sep 2014 13:05:12 -0000 Deleted milestone "Submit draft-ietf-mpls-tp-1ton-protection for publication". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Sep 19 06:13: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 9FCA11A0127 for ; Fri, 19 Sep 2014 06:13: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 1rgpGZRmAhd1 for ; Fri, 19 Sep 2014 06:13:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F41A0142 for ; Fri, 19 Sep 2014 06:13:17 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919131317.29133.13167.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 06:13:17 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KkN0ZinykqJ6hgrjtAwHhu_FnX4 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: Fri, 19 Sep 2014 13:13:19 -0000 Changed milestone "Submit draft-ietf-mpls-seamless-mcast for publication", set due date to December 2014 from November 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Sep 19 06:15: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 73B041A0127 for ; Fri, 19 Sep 2014 06:15: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 grnbEEAoG8yB for ; Fri, 19 Sep 2014 06:15:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D38571A013B for ; Fri, 19 Sep 2014 06:15:14 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919131514.28378.91127.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 06:15:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xnX8u3E2AKuJGWkJAHrchetUNhk 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: Fri, 19 Sep 2014 13:15:21 -0000 Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to December 2014 from May 2014. Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication", set due date to December 2014 from June 2014. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Sep 19 06:19: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 92FBE1A0145 for ; Fri, 19 Sep 2014 06:19:02 -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 0lK5G9t799Hj for ; Fri, 19 Sep 2014 06:19:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC861A014C for ; Fri, 19 Sep 2014 06:19:00 -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.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919131900.373.99628.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 06:19:00 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qivpaPam9PUOjT42PoHqZFxA7PU 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: Fri, 19 Sep 2014 13:19:02 -0000 Changed milestone "Submit draft-ietf-mpls-p2mp-loose-path-reopt for publicatiion", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-lsp-ping-reply-mode-simple for publication", set state to active from review, accepting new milestone. Changed milestone "Submit draft-ietf-mpls-rfc6374-udp-return-path for publicatiion", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Sep 19 14:22: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 804F51A0ADE for ; Fri, 19 Sep 2014 14:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 x0HY1W2S7vh8 for ; Fri, 19 Sep 2014 14:22:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A8A1A068B for ; Fri, 19 Sep 2014 14:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46945; q=dns/txt; s=iport; t=1411161771; x=1412371371; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9FCR75ATFStdouyEUS8s6g3X5dNdj6LEWm5rddyFgKk=; b=Q2xw8J8B83aVv2BaIgxb7D588260wtRGJeJ56vV15LqHdv6dHVMYn3Wr EStJhO1NbYE1ggPdm87yQqOxED39C1f6oCk1UYQVBNOruviXmeo5dfmhZ ZXddO8OSJoy8NNK6hQKNSZu0tiRnpRpJgKYvosPv89lra3a14zCEjhOgi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAE2eHFStJV2U/2dsb2JhbABggkdGU1cE0B+BIwGBBBYBeYQDAQEBBC1BCxIBCBEDAQEBIQECBDkUCQgCBAENBYg+wxwBF48pLQcTEQYBBoRFBY8+gheLPpVOgh2BQ2yBBkKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,557,1406592000"; d="scan'208,217";a="356707109" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2014 21:22:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8JLMN50006151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 21:22:23 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 16:22:23 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoA= Date: Fri, 19 Sep 2014 21:22:22 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF83234599E5@FR711WXCHMBA07.zeu.alcatel-lucent.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.240.222] Content-Type: multipart/alternative; boundary="_000_D04213523B1BArgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VFrCXmKxr_T0BmiDwlDghrrqhE8 Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 19 Sep 2014 21:22:54 -0000 --_000_D04213523B1BArgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D04213523B1BArgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <838727A31A9BAE49A9E35D191CB84E76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Dimitri,

Thank you for your review comments.

Gist of your comments is that there is a way in RFC4875 to bulk the re= quests for queries via a path message and also add a list of S2Ls in a Path= Err message. 
This method can be used for re-optimizing a group of S2Ls without incr= ementing the LSP-ID as Tarek mentioned.

As you hinted below, proposed draft provides a signalling extension to= re-optimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing = the LSP-ID.

If you agree with above understanding, we can clarify in the draft acc= ordingly.

Thanks,
Rakesh



From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10= :49 AM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Tarek Saad (tsaad)= " <tsaad@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.=

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

Hello,

 

Here is my review of this document:

 

The statement "notification of preferred path = exists for a single S2L sub-LSP only." and what comes in Section 3 of = this document is questionable

 

i) there is a mode of operation already included in= RFC 4875 which allows such reorganization by sub-group ID cf. Section 14.2= . "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly

 

"14.2.  Sub-Group-Based Re-Optimization

 

   Any node may initiate re-optimization = of a set of S2L sub-LSPs by

   using incremental state update and the= n, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the PathErr) which expand= s the ERO (right ?) and sequence their signaling (thus any remerging betwee= n old and new sub-LSP follows the remerging (following Section 18), why would request to have such control taken by th= e root of the tree ?

 

The protocol format chain can be found here below t= o see possibility for generating such request via notification:<= /span>

 

   <notify session list>  = ;     ::=3D [ <notify session list> ]<= /span>

        &nb= sp;            =             &nb= sp; <upstream notify session> |

        &nb= sp;            =             &nb= sp; <downstream notify session>

 

   <upstream notify session> &= nbsp; ::=3D <SESSION> [ <ADMIN_STATUS> ]

        &nb= sp;            =             &nb= sp; [<POLICY_DATA>...]

        &nb= sp;            =             &nb= sp; <sender descriptor>

 

 

   <sender descriptor> ::=3D <SE= NDER_TEMPLATE> <SENDER_TSPEC>

        &nb= sp;            =             &nb= sp;  [ <ADSPEC> ]

 

   With:

 

       0  &= nbsp;           &nbs= p;    1         = ;          2   =             &nb= sp;   3

       0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;           &nbs= p;   IPv4 tunnel sender address     &nbs= p;            |=

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;   Reserved        &= nbsp;       |     &n= bsp;      LSP ID     &nbs= p;       |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;           &nbs= p;   Sub-Group Originator ID      &= nbsp;           &nbs= p;  |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;   Reserved        &= nbsp;       |     &n= bsp;      Sub-Group ID    &nbs= p;  |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

 

I read behind this draft that this new mode of oper= ation (the fact subpaths "are loose or abstract hop expanded" doe= sn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside incremental = state update --introduced for scaling reasons. In any case, the justificati= on/motivation for this mode of operation is missing in the document.

 

 

ii) with PathErr as defined in RFC 4875 it includes= a [ <S2L= sub-LSP descriptor list> ]

thus, it is even less clear why one would like to m= ove with or more generally signaling it differently ("Request flags&qu= ot; instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result= in transient data

duplication as the new Path messages for a set of S= 2L sub-LSPs may

transit one or more nodes with the old Path state f= or the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this comment, and would ref= ormulate it as follows: under which conditions the number of sub-LSPs is so= large that i) the receiver triggers re-signalling without having received the full sequence of sub-LSP, ii) th= e initiator has no mean to sequence the resulting Path messages such as to = avoid situation of Section 14.2, iii) assuming this would be the case, why = the procedure of Section 18 is not sufficient ? In more general terms why signal to the root a procedure than= can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide question, why do you con= sider only the case with loose ERO=92s ? I mean the fragmentation problem i= s only one cause of occurrence of duplication (which could happen from any transient event during establishment of P2MP = LSP), in that case, the question of introducing a more general procedure wi= th an EOL (end of list bit) would certainly be more appropriate as it would= solve two problems at once.

 

 

Regards,

Tarek

 

The proposed draft doesn=92t solve cases where this= would occur, and on the other, the cases it covers are already by RFC 4875= (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

 --_000_D04213523B1BArgandhiciscocom_-- From nobody Fri Sep 19 15:32: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 5B0831A88EA; Fri, 19 Sep 2014 15:32:56 -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 2__ZyJEtcERS; Fri, 19 Sep 2014 15:32:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 077091A88A9; Fri, 19 Sep 2014 15:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: danfrost@cisco.com,stbryant@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919223255.25330.11113.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 15:32:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Gk5opzciJFIGPFdYBzc55o05zAo Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6374 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: Fri, 19 Sep 2014 22:32:56 -0000 Dear Dan Frost, Stewart Bryant: An IPR disclosure that pertains to your RFC entitled "Packet Loss and Delay Measurement for MPLS Networks" (RFC6374) was submitted to the IETF Secretariat on 2014-09-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2436/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6374.""); The IETF Secretariat From nobody Mon Sep 22 04:25: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 A43B21A1A45 for ; Mon, 22 Sep 2014 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 TjJ-clV_Wg-o for ; Mon, 22 Sep 2014 04:25:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2921A007E for ; Mon, 22 Sep 2014 04:25:30 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3A0AD4D6F4F0A; Mon, 22 Sep 2014 11:25:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8MBPMJQ018882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 13:25:25 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 13:25:15 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Rakesh Gandhi (rgandhi)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPvgW6cw5mpw0exU2NDzkSYbYvrZvckC5AgADQ/PCAFWKrgIAAdHuAgBV2b4CAAFNIAIAELuxg Date: Mon, 22 Sep 2014 11:25:14 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832345BFC6@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <84675BAA8C49154AB81E2587BE8BDF83234599E5@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF832345BFC6FR711WXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8cYbdsxORnS2eQwI-E1wgJ7YyX0 Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 22 Sep 2014 11:25:37 -0000 --_000_84675BAA8C49154AB81E2587BE8BDF832345BFC6FR711WXCHMBA07z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Beside this gist, there is a point that would be worth discussing message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. + including a compatibility section somewhere in this document would certai= nly help. PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there's no explicit way for a mid-= LSR to notify the ingress to trigger this specific mode of reoptimization--= short of possibly re-using the PERR code/subcode for "preferable path exis= ts" as defined in rfc4736 and including the *full* list of S2Ls in the S2L = sub-LSPs descriptor in the PERR sent back to the ingress. However, as menti= oned in rfc4875, an LSR may fragment such signalled messages (e.g. when a s= ingle message may not be large enough to fit all S2L sub-LSPs).. In this ca= se, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-L= SPs in each and would require additional logic to infer all S2L sub-LSPs ar= e to be resigned (e..g. using section 14.1 method) by (example) waiting for= some time to aggregate all possible PERR messages before taking action. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the "path re-evalu= ation" flag - as defined defined in rfc4736-with a full list of S2L sub-LSP= s in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and= only a subset of the S2L sub-LSPs that are routed over same next-hop will = be propagated in the descriptor list of the PATH message propagated to down= stream mid-LSRs.. Consequently, when a preferable path exists at such mid-L= SRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. = The ingress LSR in this case can unambiguously use it to distinguish which = LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs." [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO's ? I mean the fragmentation problem is only one c= ause of occurrence of duplication (which could happen from any transient ev= ent during establishment of P2MP LSP), in that case, the question of introd= ucing a more general procedure with an EOL (end of list bit) would certainl= y be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn't solve cases where this would occur, and on the o= ther, the cases it covers are already by RFC 4875 (re-optimize a loose set = from a single branching point is already covered). Many thanks, -dimitri. --_000_84675BAA8C49154AB81E2587BE8BDF832345BFC6FR711WXCHMBA07z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Beside this gist, there is a point that = would be worth discussing

 

message fragmentation is one= possible cause of initiating re-signaling before the full list is being kn= own to the root but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure wi= th an EOL (end of list bit) could be more appropriate as it would solve two= problems at once.

 

+ including a compatibility section = somewhere in this document would certainly help.

 

PS: in the longer term, I anticipate the= need to collect practices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh G= andhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaa= d-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

Thank you for your review c= omments.

 

Gist of your comments is th= at there is a way in RFC4875 to bulk the requests for queries via a path me= ssage and also add a list of S2Ls in a PathErr message. 

This method can be used for= re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek men= tioned.

 

As you hinted below, propos= ed draft provides a signalling extension to re-optimize entire P2MP LSP/tre= e similar to P2P [RFC4736] by incrementing the LSP-ID.

 

If you agree with above und= erstanding, we can clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply = from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing t= he draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this do= cument:

 

The statement "notifica= tion of preferred path exists for a single S2L sub-LSP only." and what= comes in Section 3 of this document is questionable

 

i) there is a mode of operat= ion already included in RFC 4875 which allows such reorganization by sub-gr= oup ID cf. Section 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-= Based Re-Optimization<= /p>

 

   Any node may in= itiate re-optimization of a set of S2L sub-LSPs by

   using increment= al state update and then, optionally, combining

   multiple path m= essages."

 

[TS]: the draft is in agree= ment of the above statement from rfc4875 and this is called out in the draf= t (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that = receives (un)solicited PathErr notification(s)

   for individual= S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-= set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, = such re-optimization procedure may result in data duplication

" 

The make-before-break reopt= imization method as described in rfc4875 section 14.1 avoids the former dup= lication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR= to notify the ingress to trigger this specific mode of reoptimization-- sh= ort of possibly re-using the PERR code/subcode for “preferable path e= xists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PER= R sent back to the ingress. However, as mentioned in rfc4875, an LSR may fr= agment such signalled messages (e.g. when a single message may not be large= enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a su= b-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR = is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH mess= age that is intended to carry the “path re-evaluation” flag = 212; as defined defined in rfc4736—with a full list of S2L sub-LSPs i= n S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a = subset of the S2L sub-LSPs that are routed over same next-hop will be propa= gated in the descriptor list of the PATH message propagated to downstream m= id-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L= sub-LSPs traversing it.. The ingress LSR in this case can unambiguously us= e it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (i= nitiator of the PathErr) which expands the ERO (right ?) and sequence their= signaling (thus any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain ca= n be found here below to see possibility for generating such request via no= tification:

 

   <notify sess= ion list>       ::=3D [ <notify session= list> ]

    &nbs= p;            &= nbsp;           &nbs= p;     <upstream notify session> |

    &nbs= p;            &= nbsp;           &nbs= p;     <downstream notify session>

 

   <upstream no= tify session>   ::=3D <SESSION> [ <ADMIN_STATUS> ]=

    &nbs= p;            &= nbsp;           &nbs= p;     [<POLICY_DATA>...]

    &nbs= p;            &= nbsp;           &nbs= p;     <sender descriptor>

 

 

   <sender desc= riptor> ::=3D <SENDER_TEMPLATE> <SENDER_TSPEC>

    &nbs= p;            &= nbsp;           &nbs= p;      [ <ADSPEC> ]

 

   With:

 

    &nbs= p;  0           = ;        1     =             &nb= sp; 2           &nbs= p;       3=

    &nbs= p;  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       IPv4 tunnel sender address  = ;            &n= bsp;   |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          LSP ID  = ;           |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       Sub-Group Originator ID  &n= bsp;            = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          Sub-Group ID = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

 

I read behind this draft tha= t this new mode of operation (the fact subpaths "are loose or abstract= hop expanded" doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside increm= ental state update --introduced for scaling reasons. In any case, the justi= fication/motivation for this mode of operation is missing in the document.<= /span>

 

 

ii) with PathErr as defined = in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]

thus, it is even less clear = why one would like to move with or more generally signaling it differently = ("Request flags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization = may result in transient data<= /span>

duplication as the new Path = messages for a set of S2L sub-LSPs may

transit one or more nodes wi= th the old Path state for the same set of

S2L sub-LSPs.”

[TS]: Please see reply abov= e for the first one.

 

[DP2] I am not sure you have= captured this comment, and would reformulate it as follows: under which co= nditions the number of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence = of sub-LSP, ii) the initiator has no mean to sequence the resulting Path me= ssages such as to avoid situation of Section 14.2, iii) assuming this would= be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, the= re is a wide question, why do you consider only the case with loose EROR= 17;s ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establi= shment of P2MP LSP), in that case, the question of introducing a more gener= al procedure with an EOL (end of list bit) would certainly be more appropri= ate as it would solve two problems at once.

 

 

Regards,

Tarek

 

The proposed draft doesnR= 17;t solve cases where this would occur, and on the other, the cases it cov= ers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

--_000_84675BAA8C49154AB81E2587BE8BDF832345BFC6FR711WXCHMBA07z_-- From nobody Mon Sep 22 04:57: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 CAFE21A0332 for ; Sat, 20 Sep 2014 21:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 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, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 XsVBCH4vUgKJ for ; Sat, 20 Sep 2014 21:30:26 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411F61A0328 for ; Sat, 20 Sep 2014 21:30:26 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with comcast id tgWG1o0014s37d401gWRcH; Sun, 21 Sep 2014 04:30:25 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-01v.sys.comcast.net with comcast id tgWP1o0032yZEBF01gWPsV; Sun, 21 Sep 2014 04:30:25 +0000 From: "ietfdbh" To: "'t.petch'" , "'Loa Andersson'" , "'Gregory Mirsky'" , References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net> In-Reply-To: <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net> Date: Sun, 21 Sep 2014 00:30:16 -0400 Message-ID: <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5+qvJ1UOOe6iVwTjJOiME8Dlb3wMzivs2AiQJ/4Sai/cpMA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411273825; bh=oQsmIid9ODWhxDgEEvzwLcIDjtEuhYTam52jex9il2Q=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=whjcLraMeZHBI6h3Jmn5yC/5Ae6zCC2eSxN0/pNm6DIkRoXREdwQUBMX0Loc0zDBk r4ytd4Sbsg0NfLWzrnjXrHatc/lWLha2UBavhzHl0FHOoF8315tnBhAMcTe2Bb1FIm H1b79fp/xJV70UWujkVjLDbmB+IxhEC++ySvPqk5Ewcn+5lbqCy1MUYH4gzrAIcn6x 43pct37Rkb277FPHOf/OU39iAIIb/X1uCYNc+9cWiUtNmufdIWMAdR+k400k/LY6LV Il2sKMrjjMkEJlnFbszEq9uZZnhTcpXC+W163Ov/TCA/uhVbQcHGvLb0PJDU23onoo M5hLL0ewYEOsQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6ImAN-UIpHc8iLC8XgxRrUj4IV8 X-Mailman-Approved-At: Mon, 22 Sep 2014 04:57:05 -0700 Cc: mpls@ietf.org, "'MIB Doctors \(E-mail\)'" Subject: Re: [mpls] [MIB-DOCTORS] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 21 Sep 2014 04:30:28 -0000 Updating the description would be a problem if you change the semantics of the object. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of > t.petch > Sent: Friday, September 19, 2014 7:50 AM > To: Loa Andersson; Gregory Mirsky; ipfix@ietf.org > Cc: mpls@ietf.org; MIB Doctors (E-mail) > Subject: Re: [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information > Export (IPFIX) Entities registry > > ----- Original Message ----- > From: "Loa Andersson" > To: "Gregory Mirsky" ; > Cc: ; "MIB Doctors (E-mail)" > Sent: Friday, September 19, 2014 10:28 AM > > Greg, > > I'm not sure about this - would changing the names require updating all > existing deployed MIBs? > > > > Yes. See RFC2578 s.10. You cannot reuse an OID so this would need a new > OID; messy, best left as one of those quaint, historic anomalies that > litter our work. > > Updating the DESCRIPTION and REFERENCE is not a problem (but issuing > any MIB module is a lot of work). > > Tom Petch > [not a MIB doctor] > > > > > Can we get an mib doctor advice on this? > > /Loa > > On 2014-09-10 21:22, Gregory Mirsky wrote: > > Dear All, > > > > in several places of describing MPLS Label element IEs the registry > > still refers to the EXP field even though the RFC 5462 updated RFC > 3032 > > and renamed it "Traffic Class" (TC). Below is the list of IEs that may > > benefit from updating Description and Reference information: > > > > .mplsTopLabelStackSection > > > > .mplsTopLabelStackSection2 > > > > .mplsTopLabelStackSection3 > > > > .mplsTopLabelStackSection4 > > > > .mplsTopLabelStackSection5 > > > > .mplsTopLabelStackSection6 > > > > .mplsTopLabelStackSection7 > > > > .mplsTopLabelStackSection8 > > > > .mplsTopLabelStackSection9 > > > > .mplsTopLabelStackSection10 > > > > .mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be > > created instead?) > > > > .postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc > > be created instead?) > > > > Regards, > > > > Greg > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From nobody Mon Sep 22 05:25: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 5F4BC1A1AAC; Mon, 22 Sep 2014 05:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 rYqydeRgtire; Mon, 22 Sep 2014 05:25:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D3F1A1AB3; Mon, 22 Sep 2014 05:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3393; q=dns/txt; s=iport; t=1411388719; x=1412598319; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gfRB/HC1DsXv4/557YY+jqGSzN/mNxmIFpcoKX3ZvHw=; b=exdPiBxBrXiFLsrs0/p64/7Mn/P9pBlaVzqswlhdcYDm6cDPuS0jssU8 X1V/aGvQrhP1A5aUumgob4IqNaLFJ8DMkyj1CuSFu8EVgsSkVn/LHjjFk Uk2Tjx9t+ZJwggshS+9gKRDhmeTAuwhj2yjlYh+VAUYb26ACg5BWfPfAf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswUALgUIFStJssW/2dsb2JhbABdA4NhV8pKCguHPQMCAYEhAXmEAwEBAQQBAQEvAQUzAwoBDAICCxEEAQEBCRYIBwkDAgECAQkMHwkIBgEMAQUCAQGIJgMRDbxXCIc0ARMEBI8gEQFAEAcGC4Q6AQSdFodMhQKJBIIegUU7L4EPgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208";a="185394664" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Sep 2014 12:25:17 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8MCPH5O024936; Mon, 22 Sep 2014 12:25:17 GMT Message-ID: <5420152C.2060501@cisco.com> Date: Mon, 22 Sep 2014 14:25:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: ietfdbh , "'t.petch'" , "'Loa Andersson'" , "'Gregory Mirsky'" , ipfix@ietf.org References: <7347100B5761DC41A166AC17F22DF1121B82E898@eusaamb103.ericsson.se> <541BF749.6010907@pi.nu> <004a01cfd3ff$da773380$4001a8c0@gateway.2wire.net> <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net> In-Reply-To: <061e01cfd554$bfe4dd50$3fae97f0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kBXAO7B5W3Gfpctm0Ylfxv49ftQ Cc: mpls@ietf.org, "'MIB Doctors \(E-mail\)'" Subject: Re: [mpls] [MIB-DOCTORS] MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry 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, 22 Sep 2014 12:25:21 -0000 We could argue whether the semantic was actually changed since the EXP bits were used for QoS. Anyway, let's quote Jürgen: "The question is whether doing this is worth anything.". I'm not convinced... Regards, Benoit > Updating the description would be a problem if you change the semantics of > the object. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >> -----Original Message----- >> From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of >> t.petch >> Sent: Friday, September 19, 2014 7:50 AM >> To: Loa Andersson; Gregory Mirsky; ipfix@ietf.org >> Cc: mpls@ietf.org; MIB Doctors (E-mail) >> Subject: Re: [MIB-DOCTORS] [mpls] MPLS IEs in IANA's IP Flow Information >> Export (IPFIX) Entities registry >> >> ----- Original Message ----- >> From: "Loa Andersson" >> To: "Gregory Mirsky" ; >> Cc: ; "MIB Doctors (E-mail)" >> Sent: Friday, September 19, 2014 10:28 AM >> >> Greg, >> >> I'm not sure about this - would changing the names require updating all >> existing deployed MIBs? >> >> >> >> Yes. See RFC2578 s.10. You cannot reuse an OID so this would need a new >> OID; messy, best left as one of those quaint, historic anomalies that >> litter our work. >> >> Updating the DESCRIPTION and REFERENCE is not a problem (but issuing >> any MIB module is a lot of work). >> >> Tom Petch >> [not a MIB doctor] >> >> >> >> >> Can we get an mib doctor advice on this? >> >> /Loa >> >> On 2014-09-10 21:22, Gregory Mirsky wrote: >>> Dear All, >>> >>> in several places of describing MPLS Label element IEs the registry >>> still refers to the EXP field even though the RFC 5462 updated RFC >> 3032 >>> and renamed it "Traffic Class" (TC). Below is the list of IEs that may >>> benefit from updating Description and Reference information: >>> >>> .mplsTopLabelStackSection >>> >>> .mplsTopLabelStackSection2 >>> >>> .mplsTopLabelStackSection3 >>> >>> .mplsTopLabelStackSection4 >>> >>> .mplsTopLabelStackSection5 >>> >>> .mplsTopLabelStackSection6 >>> >>> .mplsTopLabelStackSection7 >>> >>> .mplsTopLabelStackSection8 >>> >>> .mplsTopLabelStackSection9 >>> >>> .mplsTopLabelStackSection10 >>> >>> .mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be >>> created instead?) >>> >>> .postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc >>> be created instead?) >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > . > From nobody Mon Sep 22 05:31: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 0C3F81A1ABB for ; Mon, 22 Sep 2014 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 lFbdTXPlfYpT for ; Mon, 22 Sep 2014 05:31:30 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1347A1A1A97 for ; Mon, 22 Sep 2014 05:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63853; q=dns/txt; s=iport; t=1411389090; x=1412598690; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=OZSrkixXm4g7Dxh6m3LMNRBFnp21X9PDXwkuSLThW5w=; b=AcU95uHUNvHW5iIAptP/GWLRMA7Mx6Rdhv9iYTPcYUW3g6EC81tEcBgq NKKawfWo5bVKRKPhbro9ONpepaX7gUC9B3r80B9DmW40ICu8Dm+2fNcUN 6/5juM9+0XDu5owvVCooU1zCnS47Lyo8/KfCXa4LRIDki/RPQrC7bmzmg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAFgWIFStJA2F/2dsb2JhbABggkhGU1cE0h0BgQsWAXmEAwEBAQQaE0ELEgEIEQMBAQEhAQIEORQJCAIEAQ0FiD7EHwEXjy4tBxMRBgECBIRFBY9AgheLP5VSgh6BQ2yBBkKBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,571,1406592000"; d="scan'208,217"; a="80073181" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 22 Sep 2014 12:31:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8MCVSbK025257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 12:31:28 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 07:31:26 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoCABFM6AP//z2wA Date: Mon, 22 Sep 2014 12:31:26 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832345BFC6@FR711WXCHMBA07.zeu.alcatel-lucent.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.240.222] Content-Type: multipart/alternative; boundary="_000_D0458CD03B383rgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Rjs4XtOY75XKUEjrhPQJstgs_h4 Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 22 Sep 2014 12:31:34 -0000 --_000_D0458CD03B383rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D0458CD03B383rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <26878FEA487371458AA31F1E2DE0CA2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Dimitri.

Please see inline .. <RG> ..

From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:= 25 AM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Tarek Saad (tsaad)= " <tsaad@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hi,

 

Beside this gist, there is a point that would be worth dis= cussing

<RG> Great, we will update the draft with the gist information.<= /div>

 

message fragmentation is one possible cause = of initiating re-signaling before the full list is being known to the root = but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general pr= ocedure with an EOL (end of list bit) could be more appropriate as it would= solve two problems at once.

 
<RG> We can solve the fragmentation issue (using EOL) for t= he RSVP messages containing S2L list. However, solving that does not solve = the re-optimization [RFC4736] issue this draft is addressing.  Please = see an example below.
    
A --------B ------ D, E,F,G,H,I,J 
   --------C ------- K,L,M,N,O,P,Q,R
  
In above case, the mid-point node B may send a PathErr with S2L list (= D,E,F,G,H,I, J) using an EOL bit. However, this can not be interpreted that= the node B is requesting to repot the whole LSP tree since part of the LSP= that traverse node C do not go via node B.


+ including a compatibility section somewhere in this = document would certainly help.

 

<RG> Ok, we can expand section 5.

Thanks,
Rakesh


PS: in the longer term, I anticipate the need to collect p= ractices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

Thank you for your review comments.

 

Gist of your comments is that there is a wa= y in RFC4875 to bulk the requests for queries via a path message and also a= dd a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a= group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provide= s a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P= [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we c= an clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,=

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..=

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferre= d path exists for a single S2L sub-LSP only." and what comes in Sectio= n 3 of this document is questionable

 

i) there is a mode of operation already incl= uded in RFC 4875 which allows such reorganization by sub-group ID cf. Secti= on 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimiz= ation

 

   Any node may initiate re-optimi= zation of a set of S2L sub-LSPs by

   using incremental state update = and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the = PathErr) which expands the ERO (right ?) and sequence their signaling (thus= any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here = below to see possibility for generating such request via notification:

 

   <notify session list>&nbs= p;      ::=3D [ <notify session list> ]

       &n= bsp;            = ;            &n= bsp;  <upstream notify session> |

       &n= bsp;            = ;            &n= bsp;  <downstream notify session>

 

   <upstream notify session>=    ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &n= bsp;            = ;            &n= bsp;  [<POLICY_DATA>...]=

       &n= bsp;            = ;            &n= bsp;  <sender descriptor>

 

 

   <sender descriptor> ::=3D= <SENDER_TEMPLATE> <SENDER_TSPEC>

       &n= bsp;            = ;            &n= bsp;   [ <ADSPEC> ]=

 

   With:

 

       0 =             &nb= sp;     1       &nbs= p;           2  = ;            &n= bsp;    3

       0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    IPv4 tunnel sender address    &nb= sp;            = |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       LSP ID    &nb= sp;        |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    Sub-Group Originator ID     =             &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       Sub-Group ID   &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

 

I read behind this draft that this new mode = of operation (the fact subpaths "are loose or abstract hop expanded&qu= ot; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside i= ncremental state update --introduced for scaling reasons. In any case, the = justification/motivation for this mode of operation is missing in the docum= ent.

 

 

ii) with PathErr as defined in RFC 4875 it i= ncludes a [ = <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would li= ke to move with or more generally signaling it differently ("Request f= lags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimizati= on may result in transient data

duplication as the new Path messages for a s= et of S2L sub-LSPs may=

transit one or more nodes with the old Path = state for the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this c= omment, and would reformulate it as follows: under which conditions the num= ber of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full seque= nce of sub-LSP, ii) the initiator has no mean to sequence the resulting Pat= h messages such as to avoid situation of Section 14.2, iii) assuming this w= ould be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide que= stion, why do you consider only the case with loose ERO=92s ? I mean the fr= agmentation problem is only one cause of occurrence of duplication (which could happen from any transient event = during establishment of P2MP LSP), in that case, the question of introducin= g a more general procedure with an EOL (end of list bit) would certainly be= more appropriate as it would solve two problems at once.

 

 

Regards,=

Tarek

 

The proposed draft doesn=92t solve cases whe= re this would occur, and on the other, the cases it covers are already by R= FC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.=

 

 

 --_000_D0458CD03B383rgandhiciscocom_-- From nobody Mon Sep 22 09:31: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 C44A21A1B70 for ; Mon, 22 Sep 2014 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 Fs-68KVEFIt8 for ; Mon, 22 Sep 2014 09:31:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1851A1B82 for ; Mon, 22 Sep 2014 09:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68189; q=dns/txt; s=iport; t=1411403461; x=1412613061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=90vq+KlsGm+EV2bjpfulaJ93bu5cXFA/8kgz7Yx91VI=; b=m9DPqQWpayxAPj9txw8REqtPDV3jhjIW+1U35RQc88Ejzp19icDFcWaA D0/xEgYzH0FGfR4Fd1j27M2DHjzUkZbGMVCN34z53LMmu5ufL0olZ3McI JmCQDySzU7GSCWNwbzava5XEgDOXvmcYDEHgp9hshLgL8CHaIV+bQma/D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAGhNIFStJA2E/2dsb2JhbABggkhGU1cE0hwBgQ4WAXmEAwEBAQQaE0ELEAIBCBEDAQEBIQECBAcyFAkIAgQBDQWIPsQ5AReKG4UTLQcTEQYBAgSERQWPQIIXiz+VUoIegUNsgQZCgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,572,1406592000"; d="scan'208,217"; a="80156371" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 22 Sep 2014 16:31:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8MGV0CV016191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 16:31:00 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 11:30:59 -0500 From: "Tarek Saad (tsaad)" To: "Rakesh Gandhi (rgandhi)" , "Papadimitriou, Dimitri (Dimitri)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPrlPaaXU7jlxb0kufCDvC+4iht5vdApOAgAAB9QCABLecAIARWWAAgAC3iICAFVwHgIAAbbAAgAQQKACAABJ/AP///96A Date: Mon, 22 Sep 2014 16:30:59 +0000 Message-ID: References: <84675BAA8C49154AB81E2587BE8BDF832345BFC6@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.86.253.42] Content-Type: multipart/alternative; boundary="_000_D045C4A513631Dtsaadciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ltS6VhzS48kuKyJ9EM10KstTn8g Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 22 Sep 2014 16:31:06 -0000 --_000_D045C4A513631Dtsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we=92re not sure = if best to integrate in current document or tracked with its own draft. Any= preference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D045C4A513631Dtsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Dimitri,

I discussed with Rakesh. We see the = value of having the EOL marker (for S2L list) to trigger sub-group reoptimi= zation as in stated rfc4875/section 14.2. 
As it's more generic mechanism = that can potentially be used in al= l signalling messages that contain the S2L sub-LSP descriptor list, we= =92re not sure if best to integrate in current document or tracked with its own draft. Any preference?
For triggering make-before-break reo= ptimization (rfc4875/section 14.1), we still think the explicit notificatio= n back to the root is preferable.

Regards,
Tarek

From: "Rakesh Gandhi (rgandhi)= " <rgandhi@cisco.com> Date: Monday, September 22, 2014 at= 8:31 AM
To: "Papadimitriou, Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>, Tarek Saad <tsaad@cisco.com>, "draft-tsaad-mpls-p= 2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: Re: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Thanks Dimitri.

Please see inline .. <RG> ..

From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:= 25 AM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Tarek Saad (tsaad)= " <tsaad@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hi,

 

Beside this gist, there is a point that would be worth disc= ussing

<RG> Great, we will update the draft with the gist information.<= /div>

 

message fragmentation is one possible cause o= f initiating re-signaling before the full list is being known to the root b= ut this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general proce= dure with an EOL (end of list bit) could be more appropriate as it would so= lve two problems at once.

 
<RG> We can solve the fragmentation issue (using EOL) for t= he RSVP messages containing S2L list. However, solving that does not solve = the re-optimization [RFC4736] issue this draft is addressing.  Please = see an example below.
    
A --------B ------ D, E,F,G,H,I,J 
   --------C ------- K,L,M,N,O,P,Q,R
  
In above case, the mid-point node B may send a PathErr with S2L list (= D,E,F,G,H,I, J) using an EOL bit. However, this can not be interpreted that= the node B is requesting to repot the whole LSP tree since part of the LSP= that traverse node C do not go via node B.


+ including a compatibility section somewhere in this d= ocument would certainly help.

 

<RG> Ok, we can expand section 5.

Thanks,
Rakesh


PS: in the longer term, I anticipate the need to collect pr= actices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

Thank you for your review comments.

 

Gist of your comments is that there is a way= in RFC4875 to bulk the requests for queries via a path message and also ad= d a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a = group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provides= a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P = [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we ca= n clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <<= a href=3D"mailto:dimitri.papadimitriou@alcatel-lucent.com">dimitri.papadimi= triou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi= ) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to the= MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,<= o:p>

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for = your feedback. Please see inline..<= /o:p>

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <<= a href=3D"mailto:dimitri.papadimitriou@alcatel-lucent.com">dimitri.papadimi= triou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferred= path exists for a single S2L sub-LSP only." and what comes in Section= 3 of this document is questionable=

 

i) there is a mode of operation already inclu= ded in RFC 4875 which allows such reorganization by sub-group ID cf. Sectio= n 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimiza= tion

 

   Any node may initiate re-optimiz= ation of a set of S2L sub-LSPs by

   using incremental state update a= nd then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the above= statement from rfc4875 and this is called out in the draft (below) with th= e shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)soli= cited PathErr notification(s)=

   for individual S2L sub-LSP(s), = may prematurely start re-optimizing=

   the sub-set of S2L sub-LS= Ps.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimizat= ion procedure may result in data duplication

" 

The make-before-break reoptimization method = as described in rfc4875 section 14.1 avoids the former duplication problem = by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub-= LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to expl= icitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inten= ded to carry the =93path re-evaluation=94 flag =97 as defined defined in rf= c4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the P= athErr) which expands the ERO (right ?) and sequence their signaling (thus = any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here b= elow to see possibility for generating such request via notification:

 

   <notify session list> = ;      ::=3D [ <notify session list> ]

       &nb= sp;            =             &nb= sp;  <upstream notify session> |

       &nb= sp;            =             &nb= sp;  <downstream notify session>

 

   <upstream notify session>&= nbsp;  ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &nb= sp;            =             &nb= sp;  [<POLICY_DATA>...]<= /o:p>

       &nb= sp;            =             &nb= sp;  <sender descriptor>=

 

 

   <sender descriptor> ::=3D = <SENDER_TEMPLATE> <SENDER_TSPEC>

       &nb= sp;            =             &nb= sp;   [ <ADSPEC> ]<= /o:p>

 

   With:

 

       0 &= nbsp;           &nbs= p;     1        = ;           2  =             &nb= sp;    3

       0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+

      |  &= nbsp;           &nbs= p;    IPv4 tunnel sender address    &nbs= p;             = |

      +-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+

      |  &= nbsp;    Reserved       &= nbsp;        |    &n= bsp;       LSP ID    &nbs= p;        |

      +-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+

      |  &= nbsp;           &nbs= p;    Sub-Group Originator ID     &= nbsp;           &nbs= p;   |

      +-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+

      |  &= nbsp;    Reserved       &= nbsp;        |    &n= bsp;       Sub-Group ID   &nbs= p;   |

      +-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+

 

I read behind this draft that this new mode o= f operation (the fact subpaths "are loose or abstract hop expanded&quo= t; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside increm= ental state update --introduced for scaling reasons. In any case, the justi= fication/motivation for this mode of operation is missing in the document.<= /span>

 

 

ii) with PathErr as defined in RFC 4875 it in= cludes a [ &= lt;S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would lik= e to move with or more generally signaling it differently ("Request fl= ags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimizati= on may result in transient data

duplication as the new Path messages for a se= t of S2L sub-LSPs may<= /p>

transit one or more nodes with the old Path s= tate for the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first o= ne.

 

[DP2] I am not sure you have captured this co= mment, and would reformulate it as follows: under which conditions the numb= er of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence = of sub-LSP, ii) the initiator has no mean to sequence the resulting Path me= ssages such as to avoid situation of Section 14.2, iii) assuming this would= be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide ques= tion, why do you consider only the case with loose ERO=92s ? I mean the fra= gmentation problem is only one cause of occurrence of duplication (which could happen from any transient event dur= ing establishment of P2MP LSP), in that case, the question of introducing a= more general procedure with an EOL (end of list bit) would certainly be mo= re appropriate as it would solve two problems at once.

 

 

Regards,<= o:p>

Tarek

 

The proposed draft doesn=92t solve cases wher= e this would occur, and on the other, the cases it covers are already by RF= C 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.<= o:p>

 

 

--_000_D045C4A513631Dtsaadciscocom_-- From nobody Mon Sep 22 09:41:42 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 5A70E1A1B25 for ; Mon, 22 Sep 2014 09:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 N6nXgpP8iRca for ; Mon, 22 Sep 2014 09:41:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACF31A1B1E for ; Mon, 22 Sep 2014 09:41:34 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 182247719364F; Mon, 22 Sep 2014 16:41:29 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8MGfVCa016081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 18:41:31 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 18:41:31 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Rakesh Gandhi (rgandhi)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPvgW6cw5mpw0exU2NDzkSYbYvrZvckC5AgADQ/PCAFWKrgIAAdHuAgBV2b4CAAFNIAIAELuxg///zuwCAADEr8A== Date: Mon, 22 Sep 2014 16:41:30 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832345D44A@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <84675BAA8C49154AB81E2587BE8BDF832345BFC6@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF832345D44AFR711WXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LVKkVjoXRULn6kXerMT0P2EcvWU Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 22 Sep 2014 16:41:41 -0000 --_000_84675BAA8C49154AB81E2587BE8BDF832345D44AFR711WXCHMBA07z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Monday, September 22, 2014 2:31 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. [DP] there are two cases. Case n=B01: sub-trees are topologically independe= nt (disjoint), thus operations can remain independent, and if C or B needs = it, the process here above solves the problem. Case n=B02: sub-trees are no= t topologically independent, then one needs an additional step, in this exa= mple A needs after EOL to ensure that C will cooperate in the global rearra= ngement (otherwise, C could after B request completes initiate its own rear= rangement); if you get this then answer from C would solve the problem. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there's no explicit way for a mid-= LSR to notify the ingress to trigger this specific mode of reoptimization--= short of possibly re-using the PERR code/subcode for "preferable path exis= ts" as defined in rfc4736 and including the *full* list of S2Ls in the S2L = sub-LSPs descriptor in the PERR sent back to the ingress. However, as menti= oned in rfc4875, an LSR may fragment such signalled messages (e.g. when a s= ingle message may not be large enough to fit all S2L sub-LSPs).. In this ca= se, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-L= SPs in each and would require additional logic to infer all S2L sub-LSPs ar= e to be resigned (e..g. using section 14.1 method) by (example) waiting for= some time to aggregate all possible PERR messages before taking action. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the "path re-evalu= ation" flag - as defined defined in rfc4736-with a full list of S2L sub-LSP= s in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and= only a subset of the S2L sub-LSPs that are routed over same next-hop will = be propagated in the descriptor list of the PATH message propagated to down= stream mid-LSRs.. Consequently, when a preferable path exists at such mid-L= SRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. = The ingress LSR in this case can unambiguously use it to distinguish which = LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs." [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO's ? I mean the fragmentation problem is only one c= ause of occurrence of duplication (which could happen from any transient ev= ent during establishment of P2MP LSP), in that case, the question of introd= ucing a more general procedure with an EOL (end of list bit) would certainl= y be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn't solve cases where this would occur, and on the o= ther, the cases it covers are already by RFC 4875 (re-optimize a loose set = from a single branching point is already covered). Many thanks, -dimitri. --_000_84675BAA8C49154AB81E2587BE8BDF832345D44AFR711WXCHMBA07z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

From: Rakesh G= andhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Monday, September 22, 2014 2:31 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaa= d-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Thanks Dimitri.<= /span>

 

Please see inline .. <RG= > ..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi,

 

Beside this gist, there is a= point that would be worth discussing

 

<RG> Great, we will u= pdate the draft with the gist information.

 

message fragmentation is one= possible cause of initiating re-signaling before the full list is being kn= own to the root but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure wi= th an EOL (end of list bit) could be more appropriate as it would solve two= problems at once.

 

<RG> We can solv= e the fragmentation issue (using EOL) for the RSVP messages containing S2L = list. However, solving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example below.

    

A --------B ------ D, E,F,G= ,H,I,J 

   --------C ----= --- K,L,M,N,O,P,Q,R

  

In above case, the mid-poin= t node B may send a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit= . However, this can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that traverse= node C do not go via node B.

 

[DP] there are two cases. Case n=B01: sub-trees are topologically inde=
pendent (disjoint), thus operations can remain independent, and if C or B n=
eeds it, the process here above solves the problem. Case n=B02: sub-trees a=
re not topologically independent, then one needs an additional step, in thi=
s example A needs after EOL to ensure that C will cooperate in the global r=
earrangement (otherwise, C could after B request completes initiate its own=
 rearrangement); if you get this then answer from C would solve the problem=
. 
 

 

+ including a compatibil= ity section somewhere in this document would certainly help.

 

 

<RG> Ok, we can expan= d section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I an= ticipate the need to collect practices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review c= omments.

 

Gist of your comments is th= at there is a way in RFC4875 to bulk the requests for queries via a path me= ssage and also add a list of S2Ls in a PathErr message. 

This method can be used for= re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek men= tioned.

 

As you hinted below, propos= ed draft provides a signalling extension to re-optimize entire P2MP LSP/tre= e similar to P2P [RFC4736] by incrementing the LSP-ID.

 

If you agree with above und= erstanding, we can clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply = from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing t= he draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this do= cument:

 

The statement "notifica= tion of preferred path exists for a single S2L sub-LSP only." and what= comes in Section 3 of this document is questionable

 

i) there is a mode of operat= ion already included in RFC 4875 which allows such reorganization by sub-gr= oup ID cf. Section 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-= Based Re-Optimization<= /p>

 

   Any node may in= itiate re-optimization of a set of S2L sub-LSPs by

   using increment= al state update and then, optionally, combining

   multiple path m= essages."

 

[TS]: the draft is in agree= ment of the above statement from rfc4875 and this is called out in the draf= t (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that = receives (un)solicited PathErr notification(s)

   for individual= S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-= set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, = such re-optimization procedure may result in data duplication

" 

The make-before-break reopt= imization method as described in rfc4875 section 14.1 avoids the former dup= lication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR= to notify the ingress to trigger this specific mode of reoptimization-- sh= ort of possibly re-using the PERR code/subcode for “preferable path e= xists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PER= R sent back to the ingress. However, as mentioned in rfc4875, an LSR may fr= agment such signalled messages (e.g. when a single message may not be large= enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a su= b-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR = is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH mess= age that is intended to carry the “path re-evaluation” flag = 212; as defined defined in rfc4736—with a full list of S2L sub-LSPs i= n S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a = subset of the S2L sub-LSPs that are routed over same next-hop will be propa= gated in the descriptor list of the PATH message propagated to downstream m= id-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L= sub-LSPs traversing it.. The ingress LSR in this case can unambiguously us= e it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (i= nitiator of the PathErr) which expands the ERO (right ?) and sequence their= signaling (thus any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain ca= n be found here below to see possibility for generating such request via no= tification:

 

   <notify sess= ion list>       ::=3D [ <notify session= list> ]

    &nbs= p;            &= nbsp;           &nbs= p;     <upstream notify session> |

    &nbs= p;            &= nbsp;           &nbs= p;     <downstream notify session>

 

   <upstream no= tify session>   ::=3D <SESSION> [ <ADMIN_STATUS> ]=

    &nbs= p;            &= nbsp;           &nbs= p;     [<POLICY_DATA>...]

    &nbs= p;            &= nbsp;           &nbs= p;     <sender descriptor>

 

 

   <sender desc= riptor> ::=3D <SENDER_TEMPLATE> <SENDER_TSPEC>

    &nbs= p;            &= nbsp;           &nbs= p;      [ <ADSPEC> ]

 

   With:

 

    &nbs= p;  0           = ;        1     =             &nb= sp; 2           &nbs= p;       3=

    &nbs= p;  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       IPv4 tunnel sender address  = ;            &n= bsp;   |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          LSP ID  = ;           |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       Sub-Group Originator ID  &n= bsp;            = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          Sub-Group ID = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

 

I read behind this draft tha= t this new mode of operation (the fact subpaths "are loose or abstract= hop expanded" doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside increm= ental state update --introduced for scaling reasons. In any case, the justi= fication/motivation for this mode of operation is missing in the document.<= /span>

 

 

ii) with PathErr as defined = in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]

thus, it is even less clear = why one would like to move with or more generally signaling it differently = ("Request flags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization = may result in transient data<= /span>

duplication as the new Path = messages for a set of S2L sub-LSPs may

transit one or more nodes wi= th the old Path state for the same set of

S2L sub-LSPs.”

[TS]: Please see reply abov= e for the first one.

 

[DP2] I am not sure you have= captured this comment, and would reformulate it as follows: under which co= nditions the number of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence = of sub-LSP, ii) the initiator has no mean to sequence the resulting Path me= ssages such as to avoid situation of Section 14.2, iii) assuming this would= be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, the= re is a wide question, why do you consider only the case with loose EROR= 17;s ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establi= shment of P2MP LSP), in that case, the question of introducing a more gener= al procedure with an EOL (end of list bit) would certainly be more appropri= ate as it would solve two problems at once.

 

 

Regards,

Tarek

 

The proposed draft doesnR= 17;t solve cases where this would occur, and on the other, the cases it cov= ers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

--_000_84675BAA8C49154AB81E2587BE8BDF832345D44AFR711WXCHMBA07z_-- From nobody Mon Sep 22 10:43: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 35ACF1A1B27 for ; Mon, 22 Sep 2014 10:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 4FBeZMNLg5Bw for ; Mon, 22 Sep 2014 10:43:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2556F1A1B57 for ; Mon, 22 Sep 2014 10:43:11 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 7465E41631F0; Mon, 22 Sep 2014 17:43:05 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s8MHh7rp004724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 19:43:07 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 19:43:07 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Tarek Saad (tsaad)" , "Rakesh Gandhi (rgandhi)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPvgW6cw5mpw0exU2NDzkSYbYvrZvckC5AgADQ/PCAFWKrgIAAdHuAgBV2b4CAAFNIAIAELuxg///zuwCAAELugIAAM0Qg Date: Mon, 22 Sep 2014 17:43:07 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832345D53C@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <84675BAA8C49154AB81E2587BE8BDF832345BFC6@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF832345D53CFR711WXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZcaUPALNDx9I_t5Y00OslBW7T4s Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 22 Sep 2014 17:43:22 -0000 --_000_84675BAA8C49154AB81E2587BE8BDF832345D53CFR711WXCHMBA07z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, as you ask the question, my preference is a single document; we mana= ged so far to keep a reduced set of documents for P2MP and willing to conti= nue along this track. This doesn't prevent combining different elements alt= ogether (this is how RFC 4875 came in) Thanks, -dimitri. From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Monday, September 22, 2014 6:31 PM To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-= mpls-p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we're not sure if= best to integrate in current document or tracked with its own draft. Any p= reference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there's no explicit way for a mid-= LSR to notify the ingress to trigger this specific mode of reoptimization--= short of possibly re-using the PERR code/subcode for "preferable path exis= ts" as defined in rfc4736 and including the *full* list of S2Ls in the S2L = sub-LSPs descriptor in the PERR sent back to the ingress. However, as menti= oned in rfc4875, an LSR may fragment such signalled messages (e.g. when a s= ingle message may not be large enough to fit all S2L sub-LSPs).. In this ca= se, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-L= SPs in each and would require additional logic to infer all S2L sub-LSPs ar= e to be resigned (e..g. using section 14.1 method) by (example) waiting for= some time to aggregate all possible PERR messages before taking action. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the "path re-evalu= ation" flag - as defined defined in rfc4736-with a full list of S2L sub-LSP= s in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and= only a subset of the S2L sub-LSPs that are routed over same next-hop will = be propagated in the descriptor list of the PATH message propagated to down= stream mid-LSRs.. Consequently, when a preferable path exists at such mid-L= SRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. = The ingress LSR in this case can unambiguously use it to distinguish which = LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs." [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO's ? I mean the fragmentation problem is only one c= ause of occurrence of duplication (which could happen from any transient ev= ent during establishment of P2MP LSP), in that case, the question of introd= ucing a more general procedure with an EOL (end of list bit) would certainl= y be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn't solve cases where this would occur, and on the o= ther, the cases it covers are already by RFC 4875 (re-optimize a loose set = from a single branching point is already covered). Many thanks, -dimitri. --_000_84675BAA8C49154AB81E2587BE8BDF832345D53CFR711WXCHMBA07z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, as you ask the question, my prefe= rence is a single document; we managed so far to keep a reduced set of docu= ments for P2MP and willing to continue along this track. This doesn’t prevent combining different elements altogether (this i= s how RFC 4875 came in)

 

Thanks,

-dimitri.

 

From: Tarek Sa= ad (tsaad) [mailto:tsaad@cisco.com]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft= -tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

I discussed with Rakesh. We see the value of having the = EOL marker (for S2L list) to trigger sub-group reoptimization as in stated = rfc4875/section 14.2. 

As it's more generic mechanism that can potentially= be used in all signalling messages that contain the S2L sub-LSP descr= iptor list, we’re not sure if best to integrate in current document or tracked with its own draft. Any preference?

For triggering make-before-break reoptimization (rfc4875= /section 14.1), we still think the explicit notification back to the root i= s preferable.

 

Regards,

Tarek

 

From: "Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco.com>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, Tarek Saad <tsaad= @cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.o= rg" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Thanks Dimitri.<= /span>

 

Please see inline .. <RG= > ..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi,

 

Beside this gist, there is a= point that would be worth discussing

 

<RG> Great, we will u= pdate the draft with the gist information.

 

message fragmentation is one= possible cause of initiating re-signaling before the full list is being kn= own to the root but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure wi= th an EOL (end of list bit) could be more appropriate as it would solve two= problems at once.

 

<RG> We can solv= e the fragmentation issue (using EOL) for the RSVP messages containing S2L = list. However, solving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example below.

    

A --------B ------ D, E,F,G= ,H,I,J 

   --------C ----= --- K,L,M,N,O,P,Q,R

  

In above case, the mid-poin= t node B may send a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit= . However, this can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that traverse= node C do not go via node B.

 

 

+ including a compatibil= ity section somewhere in this document would certainly help.

 

 

<RG> Ok, we can expan= d section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I an= ticipate the need to collect practices and production of a BCP.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review c= omments.

 

Gist of your comments is th= at there is a way in RFC4875 to bulk the requests for queries via a path me= ssage and also add a list of S2Ls in a PathErr message. 

This method can be used for= re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek men= tioned.

 

As you hinted below, propos= ed draft provides a signalling extension to re-optimize entire P2MP LSP/tre= e similar to P2P [RFC4736] by incrementing the LSP-ID.

 

If you agree with above und= erstanding, we can clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply = from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing t= he draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this do= cument:

 

The statement "notifica= tion of preferred path exists for a single S2L sub-LSP only." and what= comes in Section 3 of this document is questionable

 

i) there is a mode of operat= ion already included in RFC 4875 which allows such reorganization by sub-gr= oup ID cf. Section 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-= Based Re-Optimization<= /p>

 

   Any node may in= itiate re-optimization of a set of S2L sub-LSPs by

   using increment= al state update and then, optionally, combining

   multiple path m= essages."

 

[TS]: the draft is in agree= ment of the above statement from rfc4875 and this is called out in the draf= t (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that = receives (un)solicited PathErr notification(s)

   for individual= S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-= set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, = such re-optimization procedure may result in data duplication

" 

The make-before-break reopt= imization method as described in rfc4875 section 14.1 avoids the former dup= lication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR= to notify the ingress to trigger this specific mode of reoptimization-- sh= ort of possibly re-using the PERR code/subcode for “preferable path e= xists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PER= R sent back to the ingress. However, as mentioned in rfc4875, an LSR may fr= agment such signalled messages (e.g. when a single message may not be large= enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a su= b-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR = is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH mess= age that is intended to carry the “path re-evaluation” flag = 212; as defined defined in rfc4736—with a full list of S2L sub-LSPs i= n S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a = subset of the S2L sub-LSPs that are routed over same next-hop will be propa= gated in the descriptor list of the PATH message propagated to downstream m= id-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L= sub-LSPs traversing it.. The ingress LSR in this case can unambiguously us= e it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (i= nitiator of the PathErr) which expands the ERO (right ?) and sequence their= signaling (thus any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain ca= n be found here below to see possibility for generating such request via no= tification:

 

   <notify sess= ion list>       ::=3D [ <notify session= list> ]

    &nbs= p;            &= nbsp;           &nbs= p;     <upstream notify session> |

    &nbs= p;            &= nbsp;           &nbs= p;     <downstream notify session>

 

   <upstream no= tify session>   ::=3D <SESSION> [ <ADMIN_STATUS> ]=

    &nbs= p;            &= nbsp;           &nbs= p;     [<POLICY_DATA>...]

    &nbs= p;            &= nbsp;           &nbs= p;     <sender descriptor>

 

 

   <sender desc= riptor> ::=3D <SENDER_TEMPLATE> <SENDER_TSPEC>

    &nbs= p;            &= nbsp;           &nbs= p;      [ <ADSPEC> ]

 

   With:

 

    &nbs= p;  0           = ;        1     =             &nb= sp; 2           &nbs= p;       3=

    &nbs= p;  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       IPv4 tunnel sender address  = ;            &n= bsp;   |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          LSP ID  = ;           |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |            = ;       Sub-Group Originator ID  &n= bsp;            = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

    &nbs= p; |       Reserved    &n= bsp;           | &nb= sp;          Sub-Group ID = ;      |

    &nbs= p; +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+

 

I read behind this draft tha= t this new mode of operation (the fact subpaths "are loose or abstract= hop expanded" doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside increm= ental state update --introduced for scaling reasons. In any case, the justi= fication/motivation for this mode of operation is missing in the document.<= /span>

 

 

ii) with PathErr as defined = in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]

thus, it is even less clear = why one would like to move with or more generally signaling it differently = ("Request flags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization = may result in transient data<= /span>

duplication as the new Path = messages for a set of S2L sub-LSPs may

transit one or more nodes wi= th the old Path state for the same set of

S2L sub-LSPs.”

[TS]: Please see reply abov= e for the first one.

 

[DP2] I am not sure you have= captured this comment, and would reformulate it as follows: under which co= nditions the number of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence = of sub-LSP, ii) the initiator has no mean to sequence the resulting Path me= ssages such as to avoid situation of Section 14.2, iii) assuming this would= be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, the= re is a wide question, why do you consider only the case with loose EROR= 17;s ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establi= shment of P2MP LSP), in that case, the question of introducing a more gener= al procedure with an EOL (end of list bit) would certainly be more appropri= ate as it would solve two problems at once.

 

 

Regards,

Tarek

 

The proposed draft doesnR= 17;t solve cases where this would occur, and on the other, the cases it cov= ers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

--_000_84675BAA8C49154AB81E2587BE8BDF832345D53CFR711WXCHMBA07z_-- From nobody Mon Sep 22 14:49: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 26F141A1B36; Mon, 22 Sep 2014 14:49:28 -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 A61NcCYQf8NK; Mon, 22 Sep 2014 14:49:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E711A1AD5; Mon, 22 Sep 2014 14:49:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: danfrost@cisco.com,stbryant@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922214926.25483.74926.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 14:49:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aiq0L3izXFTFfrVMiXg3dvKJ37Y Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6374 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, 22 Sep 2014 21:49:28 -0000 Dear Dan Frost, Stewart Bryant: An IPR disclosure that pertains to your RFC entitled "Packet Loss and Delay Measurement for MPLS Networks" (RFC6374) was submitted to the IETF Secretariat on 2014-09-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2426/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6374.""); The IETF Secretariat From nobody Mon Sep 22 21:43: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 F35451A1A0A; Mon, 22 Sep 2014 21:43:03 -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 BHgkq4QIOiBz; Mon, 22 Sep 2014 21:43:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7A1A1A03; Mon, 22 Sep 2014 21:43:02 -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.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923044302.21988.63382.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 21:43:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OnkWLcxRXx4FQ7DPQ_iXn5FNliE Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-09.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, 23 Sep 2014 04:43:04 -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 : MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) Authors : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-09.txt Pages : 58 Date : 2014-09-22 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-te-mib-09 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 Sep 23 07:05: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 93E9E1A86E1; Tue, 23 Sep 2014 07:05:17 -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 xBhZx6AIFNWY; Tue, 23 Sep 2014 07:05:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCC41A8033; Tue, 23 Sep 2014 07:05:14 -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 s8NE56r9022324; Tue, 23 Sep 2014 15:05:06 +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 s8NE50Af022167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Sep 2014 15:05:03 +0100 From: "Adrian Farrel" To: "'IETF Secretariat'" , , References: <20140922214926.25483.74926.idtracker@ietfa.amsl.com> In-Reply-To: <20140922214926.25483.74926.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 15:04:58 +0100 Message-ID: <059501cfd737$5f397d50$1dac77f0$@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: AQHwUIU0D7pyKbeUiSfpFvBujkR+6JvNzMXA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20970.007 X-TM-AS-Result: No--9.947-10.0-31-10 X-imss-scan-details: No--9.947-10.0-31-10 X-TMASE-MatchedRID: csPTYAMX1+HoSitJVour/YbBPrt55wnwOhJ9m53n4aA4PPb1XDCZIXMu LKlM8AY7j7gRBvCZBYiZPixbU3iEJ6f0QmPqa4kezNY33yIEF4bnFDhXm/j3Iwendw/iiMGQPm4 XxTeJls/py2RAH6qC4YbVY+SXeWGJzzm+tbZixBqVfGv9KYnJw9ZKsq3DGpalIXhictBPoquTqU SZz6zmH6OMa7/ZLv31kZOl7WKIImrvXOvQVlExsFZ0V5tYhzdWxEHRux+uk8jHUU+U0ACZwCW1g /iQSNgeHtKE7NJIECjuoTBJPKfHTDo9Prtt23M6nqg/VrSZEiM= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NW25ZLfDFlgJJcUPZkmbDUgwROw Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: Re: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6374 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, 23 Sep 2014 14:05:17 -0000 All, As far as I can tell, this disclosure is probably 2436. Secretariat: Could you please confirm? 2436 seems to be an update to 1574 in that: - the document name has been updated to show an RFC - the patent has also been granted in Europe Adrian > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: 22 September 2014 22:49 > To: danfrost@cisco.com; stbryant@cisco.com > Cc: adrian@olddog.co.uk; akatlas@gmail.com; loa@pi.nu; swallow@cisco.com; > rcallon@juniper.net; mpls@ietf.org; ipr-announce@ietf.org > Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR > related to RFC 6374 > > > Dear Dan Frost, Stewart Bryant: > > An IPR disclosure that pertains to your RFC entitled "Packet Loss and Delay > Measurement for MPLS Networks" (RFC6374) was submitted to the IETF > Secretariat > on 2014-09-08 and has been posted on the "IETF Page of Intellectual Property > Rights Disclosures" (https://datatracker.ietf.org/ipr/2426/). The title of the > IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to > RFC 6374.""); > > The IETF Secretariat From nobody Tue Sep 23 10:27: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 2E4D91A87BB for ; Tue, 23 Sep 2014 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OPbVDghJCYXx for ; Tue, 23 Sep 2014 10:27:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7341A1B2C for ; Tue, 23 Sep 2014 10:27:17 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7664E2AC486; Tue, 23 Sep 2014 19:27:15 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 59757C8082; Tue, 23 Sep 2014 19:27:15 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 19:27:15 +0200 From: To: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Thread-Topic: late IPR poll on draft-ietf-mpls-seamless-mcast Thread-Index: AQHPzsefcoEXxUW+jkCaeVv6Ns9VfZwPB7JA Date: Tue, 23 Sep 2014 17:27:14 +0000 Message-ID: <30757_1411493235_5421AD73_30757_1773_1_827C642804B0E54C8D69DD2432E95E0B09DB5B38@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <201409122024.s8CKOjn09157@magenta.juniper.net> In-Reply-To: <201409122024.s8CKOjn09157@magenta.juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.16.70918 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/v2FAD70_44ia76AEbX-0cjVrDrg Subject: Re: [mpls] late IPR poll on draft-ietf-mpls-seamless-mcast 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, 23 Sep 2014 17:27:24 -0000 Hi Loa, I'm not aware of any non-disclosed IPR on draft-ietf-mpls-seamless-mcast. Regards, Ir=E8ne ------- Forwarded Message Date: Wed, 10 Sep 2014 12:05:17 +0200 From: Loa Andersson To: "mpls@ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" cc: "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Subject: late IPR poll on draft-ietf-mpls-seamless-mcast Working Group, draft-ietf-mpls-seamless-mcast have been through wglc and been updated afte= r the wglc. We are ready to request publication. However we have made a procedural mistake that needs to be corrected. In the mail that started the wglc I wrote: "There are one IPR disclosure against this document. The authors has stated that he is unaware of any other IPRs that relate to this document." It is correct that there are one IPR disclosure, but we had never done an I= PR poll and we did not have any responses. This was my mistake - I'm sorry = for that - this mail is intended to correct this mistake and start the IPR = poll. Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mcast? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). Currently there are one IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to thi= s 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= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) - --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 ------- End of Forwarded Message ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 23 11: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 05B801A882E for ; Tue, 23 Sep 2014 11:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 guSzh7_EsXCE for ; Tue, 23 Sep 2014 11:42:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BB81A797C for ; Tue, 23 Sep 2014 11:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74198; q=dns/txt; s=iport; t=1411497764; x=1412707364; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=VyYk2WXsdG26LJZpLzlbNsVBa9aO6t+XVvJBq0yK3/E=; b=U0irc6LmVcD8NTGzkIARTcnYFafu0zMMVvwAKFV1iG17aju2RldncnHp tdeayqTyrR15/Tr8iCQddQla1fS0MAdGA8dqMcH+dXRjh/59WWCcDEd2C mn0D5oeC5/5yio7vTjNUH1HAjYWZjMBSYPhzadvujiaKBzFnL+phKlT8f 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFABS+IVStJA2B/2dsb2JhbABggkhGU1cE0SMBgQwWAXqEAwEBAQQaE0ELEgEIEQMBAQEhAQIEORQJCAIEAQ0FiD7DGwEXjy8HAQEkBxMRBgECBIRFBY9CghiLQpVTgh+BQ2wBAYEECRcigQIBAQE X-IronPort-AV: E=Sophos;i="5.04,581,1406592000"; d="scan'208,217";a="357593351" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 23 Sep 2014 18:42:43 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8NIggcL016102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 18:42:42 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 13:42:42 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoCABFM6AP//z2wAgACI8QCAAXEfAA== Date: Tue, 23 Sep 2014 18:42:41 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832345D44A@FR711WXCHMBA07.zeu.alcatel-lucent.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: [161.44.213.29] Content-Type: multipart/alternative; boundary="_000_D04737183B7B7rgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2X0cafcDK12Sf7SbkumCTzmx5E0 Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 23 Sep 2014 18:42:49 -0000 --_000_D04737183B7B7rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Agree on the behaviour. We can add this in the draft along with the EOL mar= ker. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 12:41 PM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Resent-From: > Resent-To: Rakesh Gandhi >, "ro= bert.h.venator.civ@mail.mil" >, >, "y.kamite@ntt.com" = >, Zafar Ali > Resent-Date: Monday, 22 September, 2014 12:41 PM Hello, From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Monday, September 22, 2014 2:31 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. [DP] there are two cases. Case n=B01: sub-trees are topologically independe= nt (disjoint), thus operations can remain independent, and if C or B needs = it, the process here above solves the problem. Case n=B02: sub-trees are no= t topologically independent, then one needs an additional step, in this exa= mple A needs after EOL to ensure that C will cooperate in the global rearra= ngement (otherwise, C could after B request completes initiate its own rear= rangement); if you get this then answer from C would solve the problem. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D04737183B7B7rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Dimitri,

Agree on the behaviour. We can add this in the draft along with the EO= L marker.

Thanks,
Rakesh


From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 12= :41 PM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Tarek Saad (tsaad)= " <tsaad@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: Rakesh Gandhi <rgandhi@cisco.com>, "robert.h.venator.civ@mail.mil&quo= t; <robert.h.venator.ci= v@mail.mil>, <tsaad@cisco.com>, "y.kamite@ntt.com" <y.kamite@ntt.com>, Zafar Ali <zali@cisco.com>
Resent-Date: Monday, 22 September, = 2014 12:41 PM

Hello,

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Monday, September 22, 2014 2:31 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Thanks Dimitri.

 

Please see inline .. <RG> ..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi,<= /o:p>

 

Beside this gist, there is a point that woul= d be worth discussing<= /p>

 

<RG> Great, we will update the draft = with the gist information.

 

message fragmentation is one possible cause = of initiating re-signaling before the full list is being known to the root = but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general pr= ocedure with an EOL (end of list bit) could be more appropriate as it would= solve two problems at once.

 

<RG> We can solve the fragmentat= ion issue (using EOL) for the RSVP messages containing S2L list. However, s= olving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example belo= w.

    

A --------B ------ D, E,F,G,H,I,J 

   --------C ------- K,L,M,N,O,P,= Q,R

  

In above case, the mid-point node B may sen= d a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit. However, this = can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that tra= verse node C do not go via node B.

 

[DP] there are two cases. Case n=B01: sub-trees are topologically inde=
pendent (disjoint), thus operations can remain independent, and if C or B n=
eeds it, the process here above solves the problem. Case n=B02: sub-trees a=
re not topologically independent, then one needs an additional step, in thi=
s example A needs after EOL to ensure that C will cooperate in the global r=
earrangement (otherwise, C could after B request completes initiate its own=
 rearrangement); if you get this then answer from C would solve the problem=
. 
 

 

+ including a compatibility section some= where in this document would certainly help.

 

 

<RG> Ok, we can expand section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I anticipate the nee= d to collect practices and production of a BCP.

 

Thanks,

-dimitri.=

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review comments.<= span style=3D"color:black">

 

Gist of your comments is that there is a wa= y in RFC4875 to bulk the requests for queries via a path message and also a= dd a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a= group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provide= s a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P= [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we c= an clarify in the draft accordingly.

 

Thanks,<= o:p>

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,=

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..=

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferre= d path exists for a single S2L sub-LSP only." and what comes in Sectio= n 3 of this document is questionable

 

i) there is a mode of operation already incl= uded in RFC 4875 which allows such reorganization by sub-group ID cf. Secti= on 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimiz= ation

 

   Any node may initiate re-optimi= zation of a set of S2L sub-LSPs by

   using incremental state update = and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the = PathErr) which expands the ERO (right ?) and sequence their signaling (thus= any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here = below to see possibility for generating such request via notification:

 

   <notify session list>&nbs= p;      ::=3D [ <notify session list> ]

       &n= bsp;            = ;            &n= bsp;  <upstream notify session> |

       &n= bsp;            = ;            &n= bsp;  <downstream notify session>

 

   <upstream notify session>=    ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &n= bsp;            = ;            &n= bsp;  [<POLICY_DATA>...]=

       &n= bsp;            = ;            &n= bsp;  <sender descriptor>

 

 

   <sender descriptor> ::=3D= <SENDER_TEMPLATE> <SENDER_TSPEC>

       &n= bsp;            = ;            &n= bsp;   [ <ADSPEC> ]=

 

   With:

 

       0 =             &nb= sp;     1       &nbs= p;           2  = ;            &n= bsp;    3

       0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    IPv4 tunnel sender address    &nb= sp;            = |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       LSP ID    &nb= sp;        |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    Sub-Group Originator ID     =             &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       Sub-Group ID   &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

 

I read behind this draft that this new mode = of operation (the fact subpaths "are loose or abstract hop expanded&qu= ot; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside i= ncremental state update --introduced for scaling reasons. In any case, the = justification/motivation for this mode of operation is missing in the docum= ent.

 

 

ii) with PathErr as defined in RFC 4875 it i= ncludes a [ = <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would li= ke to move with or more generally signaling it differently ("Request f= lags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimizati= on may result in transient data

duplication as the new Path messages for a s= et of S2L sub-LSPs may=

transit one or more nodes with the old Path = state for the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this c= omment, and would reformulate it as follows: under which conditions the num= ber of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full seque= nce of sub-LSP, ii) the initiator has no mean to sequence the resulting Pat= h messages such as to avoid situation of Section 14.2, iii) assuming this w= ould be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide que= stion, why do you consider only the case with loose ERO=92s ? I mean the fr= agmentation problem is only one cause of occurrence of duplication (which could happen from any transient event = during establishment of P2MP LSP), in that case, the question of introducin= g a more general procedure with an EOL (end of list bit) would certainly be= more appropriate as it would solve two problems at once.

 

 

Regards,=

Tarek

 

The proposed draft doesn=92t solve cases whe= re this would occur, and on the other, the cases it covers are already by R= FC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.=

 

 

 --_000_D04737183B7B7rgandhiciscocom_-- From nobody Tue Sep 23 11:43: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 AC3CA1A1BE0 for ; Tue, 23 Sep 2014 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 sew02qV6xm_Q for ; Tue, 23 Sep 2014 11:43:40 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E0B1A8839 for ; Tue, 23 Sep 2014 11:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76688; q=dns/txt; s=iport; t=1411497820; x=1412707420; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5rj22SCuB0Jtam8o76cU+RdfB46Vgcj2ztqDr0D4d3I=; b=E4gFJL74TnHo8iUg2xXWQQI+7GNHl8v2aKf2vVZvX23z0K2WVziy5eXF h3W9oci/0G0hQKk+ESzyHsrWH55Qv34bNxlcscS88Lnwp8hawjXHmuiaD DuGaKGkgavEPBEWLYUZpguLa+jow0x0FWzQhkhj/1v47qvoiist1VSBER 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAJG+IVStJV2R/2dsb2JhbABggkhGU1cE0SMBgQwWAXqEAwEBAQQaE0ELEgEIEQMBAQEhAQIEORQJCAIEAQ0FiD7DEwEXihyFEy0HExEGAQIEhEUFj0KCGItClVOCH4FDbIEGQoECAQEB X-IronPort-AV: E=Sophos; i="5.04,581,1406592000"; d="scan'208,217"; a="80577198" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 23 Sep 2014 18:43:38 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8NIhcPr001727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 18:43:38 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 13:43:38 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoCABFM6AP//z2wAgACGAYCAABQngIABYCsA Date: Tue, 23 Sep 2014 18:43:37 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832345D53C@FR711WXCHMBA07.zeu.alcatel-lucent.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: [161.44.213.29] Content-Type: multipart/alternative; boundary="_000_D04737763B7BBrgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BjfLuj7fL1QrPAtPVHAI1YYEkd4 Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 23 Sep 2014 18:43:48 -0000 --_000_D04737763B7BBrgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Tarek, Ack, thanks. Regards, Rakesh From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 1:43 PM To: "Tarek Saad (tsaad)" >, Rakesh = Gandhi >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, as you ask the question, my preference is a single document; we mana= ged so far to keep a reduced set of documents for P2MP and willing to conti= nue along this track. This doesn=92t prevent combining different elements a= ltogether (this is how RFC 4875 came in) Thanks, -dimitri. From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Monday, September 22, 2014 6:31 PM To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-= mpls-p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we=92re not sure = if best to integrate in current document or tracked with its own draft. Any= preference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D04737763B7BBrgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Dimitri, Tarek,

Ack, thanks.

Regards,
Rakesh


From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 1:= 43 PM
To: "Tarek Saad (tsaad)" = <tsaad@cisco.com>, Rakesh Gand= hi <rgandhi@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hello, as you ask the question, my preference is a single = document; we managed so far to keep a reduced set of documents for P2MP and= willing to continue along this track. This doesn=92t prevent combining different elements altogether (this is ho= w RFC 4875 came in)

 

Thanks,

-dimitri.

 

From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

I= discussed with Rakesh. We see the value of having the EOL marker (for S2L = list) to trigger sub-group reoptimization as in stated rfc4875/section 14.2= . 

A= s it's more generic mechanism that can potentially be used in all sign= alling messages that contain the S2L sub-LSP descriptor list, we=92re = not sure if best to integrate in current document or tracked with its own draft. Any preference?

F= or triggering make-before-break reoptimization (rfc4875/section 14.1), we s= till think the explicit notification back to the root is preferable.=

 

R= egards,

Tarek

 

From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, Tarek Saad <tsaad= @cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.o= rg" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Thanks Dimitri.

 

Please see inline .. <RG> ..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi,<= /o:p>

 

Beside this gist, there is a point that woul= d be worth discussing<= /p>

 

<RG> Great, we will update the draft = with the gist information.

 

message fragmentation is one possible cause = of initiating re-signaling before the full list is being known to the root = but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general pr= ocedure with an EOL (end of list bit) could be more appropriate as it would= solve two problems at once.

 

<RG> We can solve the fragmentat= ion issue (using EOL) for the RSVP messages containing S2L list. However, s= olving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example belo= w.

    

A --------B ------ D, E,F,G,H,I,J 

   --------C ------- K,L,M,N,O,P,= Q,R

  

In above case, the mid-point node B may sen= d a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit. However, this = can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that tra= verse node C do not go via node B.

 

 

+ including a compatibility section some= where in this document would certainly help.

 

 

<RG> Ok, we can expand section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I anticipate the nee= d to collect practices and production of a BCP.

 

Thanks,

-dimitri.=

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review comments.<= span style=3D"color:black">

 

Gist of your comments is that there is a wa= y in RFC4875 to bulk the requests for queries via a path message and also a= dd a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a= group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provide= s a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P= [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we c= an clarify in the draft accordingly.

 

Thanks,<= o:p>

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,=

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..=

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferre= d path exists for a single S2L sub-LSP only." and what comes in Sectio= n 3 of this document is questionable

 

i) there is a mode of operation already incl= uded in RFC 4875 which allows such reorganization by sub-group ID cf. Secti= on 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimiz= ation

 

   Any node may initiate re-optimi= zation of a set of S2L sub-LSPs by

   using incremental state update = and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the = PathErr) which expands the ERO (right ?) and sequence their signaling (thus= any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here = below to see possibility for generating such request via notification:

 

   <notify session list>&nbs= p;      ::=3D [ <notify session list> ]

       &n= bsp;            = ;            &n= bsp;  <upstream notify session> |

       &n= bsp;            = ;            &n= bsp;  <downstream notify session>

 

   <upstream notify session>=    ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &n= bsp;            = ;            &n= bsp;  [<POLICY_DATA>...]=

       &n= bsp;            = ;            &n= bsp;  <sender descriptor>

 

 

   <sender descriptor> ::=3D= <SENDER_TEMPLATE> <SENDER_TSPEC>

       &n= bsp;            = ;            &n= bsp;   [ <ADSPEC> ]=

 

   With:

 

       0 =             &nb= sp;     1       &nbs= p;           2  = ;            &n= bsp;    3

       0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    IPv4 tunnel sender address    &nb= sp;            = |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       LSP ID    &nb= sp;        |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    Sub-Group Originator ID     =             &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       Sub-Group ID   &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

 

I read behind this draft that this new mode = of operation (the fact subpaths "are loose or abstract hop expanded&qu= ot; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside i= ncremental state update --introduced for scaling reasons. In any case, the = justification/motivation for this mode of operation is missing in the docum= ent.

 

 

ii) with PathErr as defined in RFC 4875 it i= ncludes a [ = <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would li= ke to move with or more generally signaling it differently ("Request f= lags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimizati= on may result in transient data

duplication as the new Path messages for a s= et of S2L sub-LSPs may=

transit one or more nodes with the old Path = state for the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this c= omment, and would reformulate it as follows: under which conditions the num= ber of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full seque= nce of sub-LSP, ii) the initiator has no mean to sequence the resulting Pat= h messages such as to avoid situation of Section 14.2, iii) assuming this w= ould be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide que= stion, why do you consider only the case with loose ERO=92s ? I mean the fr= agmentation problem is only one cause of occurrence of duplication (which could happen from any transient event = during establishment of P2MP LSP), in that case, the question of introducin= g a more general procedure with an EOL (end of list bit) would certainly be= more appropriate as it would solve two problems at once.

 

 

Regards,=

Tarek

 

The proposed draft doesn=92t solve cases whe= re this would occur, and on the other, the cases it covers are already by R= FC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.=

 

 

 --_000_D04737763B7BBrgandhiciscocom_-- From nobody Wed Sep 24 05:44: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 472E01A00CA for ; Wed, 24 Sep 2014 05:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 iCEUU_5e0T9M for ; Wed, 24 Sep 2014 05:44:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D504D1A00C0 for ; Wed, 24 Sep 2014 05:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79730; q=dns/txt; s=iport; t=1411562682; x=1412772282; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Rx8xfB2XyHb1vo54JsoilixtmDcYYLEeDUbAdlnUXwY=; b=dB6vuyuyfcSG1i0e9nwI0DaEtkdijV2xPxwYhRFogp/U6LWfDNuMh5N+ b4qipNjhz8elDfQHJ4pLoNgSQALwgZgiOEbLwlPud8GqjaGXdRHRSxQmY E3Q5pm3r/oPHi6DRHVdxjN0lbp9/i2zHEcabM8BFXObNADal6raZC63bp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAOq7IlStJA2L/2dsb2JhbABggkhGU1cE0g8BgQoWAXqEAwEBAQQaARJBCxIBCBEDAQEBIQECBDkUCQgCBAENBYg+wyEBF4oqhRwtBxMRBgECBIRFBYYjiSCCGItClVSCH4FDbIEGQoECAQEB X-IronPort-AV: E=Sophos;i="5.04,589,1406592000"; d="scan'208,217";a="354691229" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 24 Sep 2014 12:44:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8OCierG009820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 12:44:40 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 07:44:39 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoCABFM6AP//z2wAgACGAYCAABQngIACjjIA Date: Wed, 24 Sep 2014 12:44:39 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832345D53C@FR711WXCHMBA07.zeu.alcatel-lucent.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.245.220] Content-Type: multipart/alternative; boundary="_000_D04833663B98Crgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zaFUQAv9fWK4cHpK1fsAeVMLwxY Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 24 Sep 2014 12:44:48 -0000 --_000_D04833663B98Crgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Tarek, WG, I had a look at RFC4875 and there is one way to add begin and end for the S= 2L list as follows (using new C-types). Please let me know your thoughts. Existing C-type defines ------------------------------- ::=3D [ ] 19.3. S2L_SUB_LSP Object An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to = the P2MP LSP. 19.3.1. S2L_SUB_LSP IPv4 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1 19.3.2. S2L_SUB_LSP IPv6 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2 Define new =10C-types as follows: -------------------------------------- Begin of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type =3D 3 End of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type =3D 4 Begin of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type =3D 5 End of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type =3D 6 Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 1:43 PM To: "Tarek Saad (tsaad)" >, Rakesh = Gandhi >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, as you ask the question, my preference is a single document; we mana= ged so far to keep a reduced set of documents for P2MP and willing to conti= nue along this track. This doesn=92t prevent combining different elements a= ltogether (this is how RFC 4875 came in) Thanks, -dimitri. From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Monday, September 22, 2014 6:31 PM To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-= mpls-p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we=92re not sure = if best to integrate in current document or tracked with its own draft. Any= preference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D04833663B98Crgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <24718BD73377184490A6FEDE9C939700@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Dimitri, Tarek, WG,

I had a look at RFC4875 and there is one way to add begin and end for = the S2L list as follows (using new C-types). Please let me know your though= ts. 


Existing C-type defines
-------------------------------
  <S2L sub-LSP descriptor list> ::=3D <S2L_SUB_LSP> &= nbsp;[ <S2L sub-LSP descriptor list> ]

19.3. S2L_SUB_LSP Object
    An S2L_SUB_LSP object identifies a particular S2L sub-LS= P belonging to the P2MP LSP.

19.3.1. S2L_SUB_LSP IPv4 Object
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1<= /div>

19.3.2. S2L_SUB_LSP IPv6 Object
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2<= /div>


Define new C-types as follows:
--------------------------------------
Begin of IPv4 S2L List.
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type = =3D 3

End of IPv4 S2L List.
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type = =3D 4

Begin of IPv6 S2L List.
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type = =3D 5

End of IPv6 S2L List.
    S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type = =3D 6



Thanks,
Rakesh




From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 1:= 43 PM
To: "Tarek Saad (tsaad)" = <tsaad@cisco.com>, Rakesh Gand= hi <rgandhi@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hello, as you ask the question, my preference is a single = document; we managed so far to keep a reduced set of documents for P2MP and= willing to continue along this track. This doesn=92t prevent combining different elements altogether (this is ho= w RFC 4875 came in)

 

Thanks,

-dimitri.

 

From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri,

 

I= discussed with Rakesh. We see the value of having the EOL marker (for S2L = list) to trigger sub-group reoptimization as in stated rfc4875/section 14.2= . 

A= s it's more generic mechanism that can potentially be used in all sign= alling messages that contain the S2L sub-LSP descriptor list, we=92re = not sure if best to integrate in current document or tracked with its own draft. Any preference?

F= or triggering make-before-break reoptimization (rfc4875/section 14.1), we s= till think the explicit notification back to the root is preferable.=

 

R= egards,

Tarek

 

From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, Tarek Saad <tsaad= @cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.o= rg" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Thanks Dimitri.

 

Please see inline .. <RG> ..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi,<= /o:p>

 

Beside this gist, there is a point that woul= d be worth discussing<= /p>

 

<RG> Great, we will update the draft = with the gist information.

 

message fragmentation is one possible cause = of initiating re-signaling before the full list is being known to the root = but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general pr= ocedure with an EOL (end of list bit) could be more appropriate as it would= solve two problems at once.

 

<RG> We can solve the fragmentat= ion issue (using EOL) for the RSVP messages containing S2L list. However, s= olving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example belo= w.

    

A --------B ------ D, E,F,G,H,I,J 

   --------C ------- K,L,M,N,O,P,= Q,R

  

In above case, the mid-point node B may sen= d a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit. However, this = can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that tra= verse node C do not go via node B.

 

 

+ including a compatibility section some= where in this document would certainly help.

 

 

<RG> Ok, we can expand section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I anticipate the nee= d to collect practices and production of a BCP.

 

Thanks,

-dimitri.=

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review comments.<= span style=3D"color:black">

 

Gist of your comments is that there is a wa= y in RFC4875 to bulk the requests for queries via a path message and also a= dd a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a= group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provide= s a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P= [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we c= an clarify in the draft accordingly.

 

Thanks,<= o:p>

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,=

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..=

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferre= d path exists for a single S2L sub-LSP only." and what comes in Sectio= n 3 of this document is questionable

 

i) there is a mode of operation already incl= uded in RFC 4875 which allows such reorganization by sub-group ID cf. Secti= on 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimiz= ation

 

   Any node may initiate re-optimi= zation of a set of S2L sub-LSPs by

   using incremental state update = and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the = PathErr) which expands the ERO (right ?) and sequence their signaling (thus= any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here = below to see possibility for generating such request via notification:

 

   <notify session list>&nbs= p;      ::=3D [ <notify session list> ]

       &n= bsp;            = ;            &n= bsp;  <upstream notify session> |

       &n= bsp;            = ;            &n= bsp;  <downstream notify session>

 

   <upstream notify session>=    ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &n= bsp;            = ;            &n= bsp;  [<POLICY_DATA>...]=

       &n= bsp;            = ;            &n= bsp;  <sender descriptor>

 

 

   <sender descriptor> ::=3D= <SENDER_TEMPLATE> <SENDER_TSPEC>

       &n= bsp;            = ;            &n= bsp;   [ <ADSPEC> ]=

 

   With:

 

       0 =             &nb= sp;     1       &nbs= p;           2  = ;            &n= bsp;    3

       0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    IPv4 tunnel sender address    &nb= sp;            = |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       LSP ID    &nb= sp;        |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =             &nb= sp;    Sub-Group Originator ID     =             &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

      |  =      Reserved       =          |    &= nbsp;       Sub-Group ID   &nb= sp;   |

      +-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+<= /o:p>

 

I read behind this draft that this new mode = of operation (the fact subpaths "are loose or abstract hop expanded&qu= ot; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside i= ncremental state update --introduced for scaling reasons. In any case, the = justification/motivation for this mode of operation is missing in the docum= ent.

 

 

ii) with PathErr as defined in RFC 4875 it i= ncludes a [ = <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would li= ke to move with or more generally signaling it differently ("Request f= lags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimizati= on may result in transient data

duplication as the new Path messages for a s= et of S2L sub-LSPs may=

transit one or more nodes with the old Path = state for the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this c= omment, and would reformulate it as follows: under which conditions the num= ber of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full seque= nce of sub-LSP, ii) the initiator has no mean to sequence the resulting Pat= h messages such as to avoid situation of Section 14.2, iii) assuming this w= ould be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the = root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide que= stion, why do you consider only the case with loose ERO=92s ? I mean the fr= agmentation problem is only one cause of occurrence of duplication (which could happen from any transient event = during establishment of P2MP LSP), in that case, the question of introducin= g a more general procedure with an EOL (end of list bit) would certainly be= more appropriate as it would solve two problems at once.

 

 

Regards,=

Tarek

 

The proposed draft doesn=92t solve cases whe= re this would occur, and on the other, the cases it covers are already by R= FC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.=

 

 

 --_000_D04833663B98Crgandhiciscocom_-- From nobody Wed Sep 24 06:40: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 0540E1A00C0 for ; Wed, 24 Sep 2014 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 8FXMF44HA6-6 for ; Wed, 24 Sep 2014 06:40:17 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6F51A00BA for ; Wed, 24 Sep 2014 06:40:17 -0700 (PDT) Received: from [192.168.0.116] (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 92013180131A; Wed, 24 Sep 2014 15:40:15 +0200 (CEST) Message-ID: <5422C9BF.2010905@pi.nu> Date: Wed, 24 Sep 2014 15:40:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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/ZztF05F8nEQNsoMTyTLsikH-MVY Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Subject: [mpls] Implementation poll for 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, 24 Sep 2014 13:40:20 -0000 Working Group, We are preparing the Publication Request for draft-ietf-mpls-seamless-mcast. One question we have to answer in the Shepherd Write Up is about existing implementations. This is to start the Implementation Poll. If you have or are aware of existing implementations of draft-ietf-mpls-seamless-mcast please send this information to the working group mailing list or directly to the working group chairs. /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 Wed Sep 24 06:43: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 1E33A1A0099 for ; Wed, 24 Sep 2014 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 JyS6c24Pja2D for ; Wed, 24 Sep 2014 06:42:55 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466E51A00C0 for ; Wed, 24 Sep 2014 06:42:55 -0700 (PDT) Received: from [192.168.0.116] (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 0C544180131A for ; Wed, 24 Sep 2014 15:42:54 +0200 (CEST) Message-ID: <5422CA5D.9000208@pi.nu> Date: Wed, 24 Sep 2014 15:42:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mpls@ietf.org References: <5422C9BF.2010905@pi.nu> In-Reply-To: <5422C9BF.2010905@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/X5iljS09vwAgviVP4hbSKpJGWkI Subject: Re: [mpls] Implementation poll for draft-ietf-mpls-seamless-mcast 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, 24 Sep 2014 13:42:59 -0000 WG, Sorry - I missed completing the subject, done now! /Loa On 2014-09-24 15:40, Loa Andersson wrote: > Working Group, > > We are preparing the Publication Request for > draft-ietf-mpls-seamless-mcast. One question we have to answer in > the Shepherd Write Up is about existing implementations. > > This is to start the Implementation Poll. > > If you have or are aware of existing implementations of > draft-ietf-mpls-seamless-mcast please send this information to the > working group mailing list or directly to the working group chairs. > > /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 Wed Sep 24 07:13:06 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 E0C971A0110 for ; Wed, 24 Sep 2014 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 5u687UODWxsz for ; Wed, 24 Sep 2014 07:12:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DAC1A014A for ; Wed, 24 Sep 2014 07:12:51 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 66A06B7723CBB; Wed, 24 Sep 2014 14:12:44 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8OECjMu026971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 16:12:48 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 16:12:46 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "Rakesh Gandhi (rgandhi)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPvgW6cw5mpw0exU2NDzkSYbYvrZvckC5AgADQ/PCAFWKrgIAAdHuAgBV2b4CAAFNIAIAELuxg///zuwCAAELugIAAM0QggAKyKYCAADjAgA== Date: Wed, 24 Sep 2014 14:12:46 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832345F041@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <84675BAA8C49154AB81E2587BE8BDF832345D53C@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF832345F041FR711WXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aubCFa4koVNZNJZkjzKPpAxgGEs Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 24 Sep 2014 14:13:02 -0000 --_000_84675BAA8C49154AB81E2587BE8BDF832345F041FR711WXCHMBA07z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, There is another mean define special values e.g. 0x0...0 (BOL) and 0xF...F = (EOL) but leave it to the list to decide about format and encoding. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Wednesday, September 24, 2014 2:45 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Tarek, WG, I had a look at RFC4875 and there is one way to add begin and end for the S= 2L list as follows (using new C-types). Please let me know your thoughts. Existing C-type defines ------------------------------- ::=3D [ ] 19.3. S2L_SUB_LSP Object An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to = the P2MP LSP. 19.3.1. S2L_SUB_LSP IPv4 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1 19.3.2. S2L_SUB_LSP IPv6 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2 Define new C-types as follows: -------------------------------------- Begin of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type =3D 3 End of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type =3D 4 Begin of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type =3D 5 End of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type =3D 6 Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 1:43 PM To: "Tarek Saad (tsaad)" >, Rakesh = Gandhi >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, as you ask the question, my preference is a single document; we mana= ged so far to keep a reduced set of documents for P2MP and willing to conti= nue along this track. This doesn't prevent combining different elements alt= ogether (this is how RFC 4875 came in) Thanks, -dimitri. From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Monday, September 22, 2014 6:31 PM To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-= mpls-p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we're not sure if= best to integrate in current document or tracked with its own draft. Any p= reference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there's no explicit way for a mid-= LSR to notify the ingress to trigger this specific mode of reoptimization--= short of possibly re-using the PERR code/subcode for "preferable path exis= ts" as defined in rfc4736 and including the *full* list of S2Ls in the S2L = sub-LSPs descriptor in the PERR sent back to the ingress. However, as menti= oned in rfc4875, an LSR may fragment such signalled messages (e.g. when a s= ingle message may not be large enough to fit all S2L sub-LSPs).. In this ca= se, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-L= SPs in each and would require additional logic to infer all S2L sub-LSPs ar= e to be resigned (e..g. using section 14.1 method) by (example) waiting for= some time to aggregate all possible PERR messages before taking action. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the "path re-evalu= ation" flag - as defined defined in rfc4736-with a full list of S2L sub-LSP= s in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and= only a subset of the S2L sub-LSPs that are routed over same next-hop will = be propagated in the descriptor list of the PATH message propagated to down= stream mid-LSRs.. Consequently, when a preferable path exists at such mid-L= SRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. = The ingress LSR in this case can unambiguously use it to distinguish which = LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs." [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO's ? I mean the fragmentation problem is only one c= ause of occurrence of duplication (which could happen from any transient ev= ent during establishment of P2MP LSP), in that case, the question of introd= ucing a more general procedure with an EOL (end of list bit) would certainl= y be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn't solve cases where this would occur, and on the o= ther, the cases it covers are already by RFC 4875 (re-optimize a loose set = from a single branching point is already covered). Many thanks, -dimitri. --_000_84675BAA8C49154AB81E2587BE8BDF832345F041FR711WXCHMBA07z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

There is another mean define special values e.g. 0x0…= ;0 (BOL) and 0xF…F (EOL) but leave it to the list to decide about for= mat and encoding.

 

Thanks,

-dimitri.

 

From: Rakesh G= andhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Wednesday, September 24, 2014 2:45 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaa= d-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri, Tarek, WG,

 =

I had a look at RFC4875 = and there is one way to add begin and end for the S2L list as follows (usin= g new C-types). Please let me know your thoughts. 

 =

 =

Existing C-type defines<= o:p>

------------------------= -------

  <S2L sub-LSP d= escriptor list> ::=3D <S2L_SUB_LSP>  [ <S2L sub-LSP descri= ptor list> ]

 =

19.3. S2L_SUB_LSP Object=

    An S2L_SUB= _LSP object identifies a particular S2L sub-LSP belonging to the P2MP = LSP.

 =

19.3.1. S2L_SUB_LSP IPv4= Object

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1

 =

19.3.2. S2L_SUB_LSP IPv6= Object

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2

 =

 =

Define new C-types as fo= llows:

------------------------= --------------

Begin of IPv4 S2L List.<= o:p>

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type =3D 3

 =

End of IPv4 S2L List.

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type =3D 4

 =

Begin of IPv6 S2L List.<= o:p>

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type =3D 5

 =

End of IPv6 S2L List.

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type =3D 6

 =

 =

 =

Thanks,

Rakesh=

 

 

 

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 1:43 PM
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>, Rakesh Gandhi <rgandhi@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hello, as you ask the question, my preference = is a single document; we managed so far to keep a reduced set of documents = for P2MP and willing to continue along this track. This doesn’t prevent combining different elements altogether (this i= s how RFC 4875 came in)

 =

Thanks,

-dimitri.

 =

From: Tarek Saad (tsaad) [mail= to:tsaad@cisco.com]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

I discussed with Rakesh. We see the value of= having the EOL marker (for S2L list) to trigger sub-group reoptimization a= s in stated rfc4875/section 14.2. <= o:p>

As it's more generic mechanism that can= potentially be used in all signalling messages that contain the S2L s= ub-LSP descriptor list, we’re not sure if best to integrate in curren= t document or tracked with its own draft. Any preference?

For triggering make-before-break reoptimizat= ion (rfc4875/section 14.1), we still think the explicit notification back t= o the root is preferable.

 =

Regards,<= o:p>

Tarek<= /p>

 

From: "Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco.com>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, Tarek Saad <tsaad= @cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.o= rg" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Thanks Dimitri.

 

Please see inline .. <RG= > ..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi,

 =

Beside this gist, there is a point that would = be worth discussing

 

<RG> Great, we will u= pdate the draft with the gist information.

 =

message fragmentation is one possible cause of= initiating re-signaling before the full list is being known to the root bu= t this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure with an= EOL (end of list bit) could be more appropriate as it would solve two prob= lems at once.

 =

<RG> We can solv= e the fragmentation issue (using EOL) for the RSVP messages containing S2L = list. However, solving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example below.<= span style=3D"color:black">

    <= span style=3D"color:black">

A --------B ------ D, E,F,G= ,H,I,J 

   --------C ----= --- K,L,M,N,O,P,Q,R

  

In above case, the mid-poin= t node B may send a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit= . However, this can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that traverse= node C do not go via node B.=

 

 

+ including a compatibility section somewh= ere in this document would certainly help.

 =

 

<RG> Ok, we can expan= d section 5.

 

Thanks,

Rakesh

 

 

PS: in the longer term, I anticipate the need = to collect practices and production of a BCP.

 =

Thanks,

-dimitri.

 =

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review c= omments.

 

Gist of your comments is th= at there is a way in RFC4875 to bulk the requests for queries via a path me= ssage and also add a list of S2Ls in a PathErr message. 

This method can be used for= re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek men= tioned.

 

As you hinted below, propos= ed draft provides a signalling extension to re-optimize entire P2MP LSP/tre= e similar to P2P [RFC4736] by incrementing the LSP-ID.

 

If you agree with above und= erstanding, we can clarify in the draft accordingly.

 

Thanks,

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 =

See below for my answers:

 =

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply = from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing t= he draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (D= imitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,=

 =

Here is my review of this document:

 =

The statement "notification of preferred = path exists for a single S2L sub-LSP only." and what comes in Section = 3 of this document is questionable<= /o:p>

 =

i) there is a mode of operation already includ= ed in RFC 4875 which allows such reorganization by sub-group ID cf. Section= 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP basis, t= hat section states clearly

 =

"14.2.  Sub-Group-Based Re-Optimizat= ion

 =

   Any node may initiate re-optimiza= tion of a set of S2L sub-LSPs by

   using incremental state update an= d then, optionally, combining=

   multiple path messages."

 

[TS]: the draft is in agree= ment of the above statement from rfc4875 and this is called out in the draf= t (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that = receives (un)solicited PathErr notification(s)

   for individual= S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-= set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, = such re-optimization procedure may result in data duplication

" 

The make-before-break reopt= imization method as described in rfc4875 section 14.1 avoids the former dup= lication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR= to notify the ingress to trigger this specific mode of reoptimization-- sh= ort of possibly re-using the PERR code/subcode for “preferable path e= xists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PER= R sent back to the ingress. However, as mentioned in rfc4875, an LSR may fr= agment such signalled messages (e.g. when a single message may not be large= enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a su= b-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR = is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH mess= age that is intended to carry the “path re-evaluation” flag = 212; as defined defined in rfc4736—with a full list of S2L sub-LSPs i= n S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a = subset of the S2L sub-LSPs that are routed over same next-hop will be propa= gated in the descriptor list of the PATH message propagated to downstream m= id-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L= sub-LSPs traversing it.. The ingress LSR in this case can unambiguously us= e it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (initiator of the Pa= thErr) which expands the ERO (right ?) and sequence their signaling (thus a= ny remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have such contr= ol taken by the root of the tree ?<= /o:p>

 =

The protocol format chain can be found here be= low to see possibility for generating such request via notification:=

 =

   <notify session list> =       ::=3D [ <notify session list> ]=

       &nbs= p;            &= nbsp;           &nbs= p;  <upstream notify session> |

       &nbs= p;            &= nbsp;           &nbs= p;  <downstream notify session>

 =

   <upstream notify session>&n= bsp;  ::=3D <SESSION> [ <ADMIN_STATUS> ]

       &nbs= p;            &= nbsp;           &nbs= p;  [<POLICY_DATA>...]

       &nbs= p;            &= nbsp;           &nbs= p;  <sender descriptor><= /o:p>

 =

 =

   <sender descriptor> ::=3D &= lt;SENDER_TEMPLATE> <SENDER_TSPEC>

       &nbs= p;            &= nbsp;           &nbs= p;   [ <ADSPEC> ]

 =

   With:

 =

       0 &n= bsp;            = ;     1        =            2  &= nbsp;           &nbs= p;    3=

       0 1 2 3 4= 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp;            = ;    IPv4 tunnel sender address     = ;             |=

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp;    Reserved       &n= bsp;        |    &nb= sp;       LSP ID     = ;        |

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp;            = ;    Sub-Group Originator ID     &n= bsp;            = ;   |

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

      |  &n= bsp;    Reserved       &n= bsp;        |    &nb= sp;       Sub-Group ID    = ;   |

      +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

 =

I read behind this draft that this new mode of= operation (the fact subpaths "are loose or abstract hop expanded"= ; doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside incremental state u= pdate --introduced for scaling reasons. In any case, the justification/moti= vation for this mode of operation is missing in the document.

 =

 =

ii) with PathErr as defined in RFC 4875 it inc= ludes a [ &l= t;S2L sub-LSP descriptor list> ]=

thus, it is even less clear why one would like= to move with or more generally signaling it differently ("Request fla= gs" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result= in transient data

duplication as the new Path messages for a set= of S2L sub-LSPs may

transit one or more nodes with the old Path st= ate for the same set of

S2L sub-LSPs.”

[TS]: Please see reply abov= e for the first one.

 

[DP2] I am not sure you have captured this com= ment, and would reformulate it as follows: under which conditions the numbe= r of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence of sub-LS= P, ii) the initiator has no mean to sequence the resulting Path messages su= ch as to avoid situation of Section 14.2, iii) assuming this would be the c= ase, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the root a proc= edure than can be performed by the requestor itself ?

 =

[DP2] On the other hand, there is a wide quest= ion, why do you consider only the case with loose ERO’s ? I mean the = fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establi= shment of P2MP LSP), in that case, the question of introducing a more gener= al procedure with an EOL (end of list bit) would certainly be more appropri= ate as it would solve two problems at once.

 =

 =

Regards,

Tarek

 =

The proposed draft doesn’t solve cases w= here this would occur, and on the other, the cases it covers are already by= RFC 4875 (re-optimize a loose set from a single branching point is already covered).

 =

Many thanks,

-dimitri.

 =

 =

--_000_84675BAA8C49154AB81E2587BE8BDF832345F041FR711WXCHMBA07z_-- From nobody Wed Sep 24 08:19: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 07F981A016D for ; Wed, 24 Sep 2014 08:19:37 -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, 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 dAn_EX8e3WA0 for ; Wed, 24 Sep 2014 08:19:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAE11A0191 for ; Wed, 24 Sep 2014 08:19:35 -0700 (PDT) Received: from BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) by BY2PR05MB224.namprd05.prod.outlook.com (10.242.41.140) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Wed, 24 Sep 2014 15:19:11 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Wed, 24 Sep 2014 15:19:10 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.9]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.9]) with mapi id 15.00.1034.003; Wed, 24 Sep 2014 15:19:10 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Implementation poll for draft-ietf-mpls-seamless-mcast Thread-Index: AQHP2AGvd4deAVWKF0up9ZHzKI1W75wQZXyg Date: Wed, 24 Sep 2014 15:19:10 +0000 Message-ID: <9336d5c4f5ce4997add2d08f4dc58795@BY2PR05MB079.namprd05.prod.outlook.com> References: <5422C9BF.2010905@pi.nu> <5422CA5D.9000208@pi.nu> In-Reply-To: <5422CA5D.9000208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB078;UriScan:; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(377454003)(377424004)(13464003)(189002)(252514010)(24454002)(74316001)(4396001)(21056001)(107046002)(107886001)(31966008)(97736003)(2501002)(90102001)(19580395003)(83322001)(19580405001)(2656002)(87936001)(50986999)(101416001)(230783001)(76176999)(83072002)(85852003)(76482002)(54356999)(86362001)(92566001)(10300001)(99286002)(66066001)(95666004)(33646002)(77096002)(74662003)(108616004)(64706001)(76576001)(120916001)(20776003)(99396003)(106116001)(85306004)(74502003)(81542003)(81342003)(79102003)(80022003)(77982003)(46102003)(106356001)(105586002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB224; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CTRE8j4-CbPxySi9QwmRAbqAROk Subject: Re: [mpls] Implementation poll for draft-ietf-mpls-seamless-mcast 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, 24 Sep 2014 15:19:37 -0000 Hi, Juniper has an implementation. Jeffrey > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, September 24, 2014 9:43 AM > To: mpls@ietf.org > Subject: Re: [mpls] Implementation poll for draft-ietf-mpls-seamless- > mcast >=20 > WG, >=20 > Sorry - I missed completing the subject, done now! >=20 > /Loa >=20 > On 2014-09-24 15:40, Loa Andersson wrote: > > Working Group, > > > > We are preparing the Publication Request for > > draft-ietf-mpls-seamless-mcast. One question we have to answer in > > the Shepherd Write Up is about existing implementations. > > > > This is to start the Implementation Poll. > > > > If you have or are aware of existing implementations of > > draft-ietf-mpls-seamless-mcast please send this information to the > > working group mailing list or directly to the working group chairs. > > > > /Loa >=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 >=20 From nobody Thu Sep 25 01:57: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 F17281A1BA7; Thu, 25 Sep 2014 01:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 KKipxJGVkJro; Thu, 25 Sep 2014 01:57:34 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E2B1A02F9; Thu, 25 Sep 2014 01:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=577; q=dns/txt; s=iport; t=1411635454; x=1412845054; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=EApZqxNI8T0pGeiLMSIpPFZ3fFObN2w+tLIppxSWsow=; b=fIvoLhW4YhD9ZGCqevXsz2GM6h5N9voGUcxnAx5PcWtKX5SeodVKyfOJ L8Bl4AvYLrq8b4ptFZR1IOyzRuNwrs0IylgDEHLnd1HQVZ/eMT4EBPVk7 43o8jnJZt/80VxaO157U3WwehB/Fbn4sBmSHLsoG9Lx2DSnAQUr7AHht2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIKAHTYI1StJssW/2dsb2JhbABgg2FXtigFAXKTOgqIbQF6hAUBBQEBN2xbGggUARKIPg3CcgEXhhKNQYEdAQSWGIcJgWGKVIkfg2Q7LwGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,595,1406592000"; d="scan'208";a="184392061" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Sep 2014 08:57:31 +0000 Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8P8vTWe016453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 08:57:30 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 25 Sep 2014 10:57:27 +0200 To: "" , l3vpn@ietf.org, pim@ietf.org, rtgwg@ietf.org, mboned@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/xRs4CWRl7e1Dq4J6BnMPHimXY2k Subject: [mpls] BIER BOF 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, 25 Sep 2014 08:57:36 -0000 Hi Folks, If you are interested in a new forwarding mechanism for Multicast, = called: Bit Indexed Explicit Replication (BIER), please feel free to = register to the BOF list bier@ietf.org = (https://www.ietf.org/mailman/listinfo/bier) We have a BOF request pending for Hawaii. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Routing These drafts are available for reading, more will follow later. https://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt https://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt Thx, Ice. From nobody Thu Sep 25 08:00: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 1DBA21A0123; Thu, 25 Sep 2014 08:00:09 -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 iN-N2VEwSoOx; Thu, 25 Sep 2014 08:00:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B78541A7009; Thu, 25 Sep 2014 08:00:07 -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.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925150007.1506.89273.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 08:00:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ZhhrpKTTBKHuiUGa6Vf02_HUtCc Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-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: Thu, 25 Sep 2014 15:00: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 : RFC6374 UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-ietf-mpls-rfc6374-udp-return-path-02.txt Pages : 8 Date : 2014-09-25 Abstract: This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc6374-udp-return-path-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 Thu Sep 25 09:34: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 62CCC1A86E9; Thu, 25 Sep 2014 09:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SUBJ_ALL_CAPS=1.506] 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 d6Je0fkiC1pS; Thu, 25 Sep 2014 09:33:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1681A86F2; Thu, 25 Sep 2014 09:33:50 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 07D4289ACB973; Thu, 25 Sep 2014 16:33:47 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s8PGXmxw023064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 12:33:48 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 12:33:48 -0400 Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.51]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 00:33:45 +0800 From: "S, Somasundaram (Somasundaram)" To: IJsbrand Wijnands , "" , "l3vpn@ietf.org" , "pim@ietf.org" , "rtgwg@ietf.org" , "mboned@ietf.org" Thread-Topic: BIER BOF Thread-Index: AQHP2J+WZKoExKur8ka+5tYwF9CUipwSC3XQ Date: Thu, 25 Sep 2014 16:33:44 +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: [135.253.19.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nuLNEn-Th5RfDVvIME02gFyMviU Subject: Re: [mpls] BIER BOF 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, 25 Sep 2014 16:33:58 -0000 SSBjb3VsZG7igJl0IHZpZXcgdGhlIG90aGVyIGRyYWZ0cyBtZW50aW9uZWQgaW4gdGhlIGJvZiBw YWdlLi4uIA0KDQo+Pj4+Pj4+Pi4NCg0KTGlua3MgdG8gdGhlIG1haWxpbmcgbGlzdCwgZHJhZnQg Y2hhcnRlciBpZiBhbnksIHJlbGV2YW50IEludGVybmV0LURyYWZ0cywgZXRjLg0KDQogICAgTWFp bGluZyBMaXN0OiDigItodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXIN CiAgICBEcmFmdCBjaGFydGVyOiBUQkQNCiAgICBSZWxldmFudCBkcmFmdHM6DQogICAgICAgIGRy YWZ0LXNoZXBoZXJkLWJpZXItcHJvYmxlbS1zdGF0ZW1lbnQtMDANCiAgICAgICAgZHJhZnQtd2lq bmFuZHMtYmllci1hcmNoaXRlY3R1cmUtMDANCiAgICAgICAgZHJhZnQtd2lqbmFuZHMtbXBscy1i aWVyLWVuY2Fwc3VsYXRpb24tMDANCiAgICAgICAgZHJhZnQtcHNlbmFrLW9zcGYtYmllci1leHRl bnRpb25zLTAwDQogICAgICAgIGRyYWZ0LXJvc2VuLWwzdnBuLW12cG4tYmllci0wMA0KICAgICAg ICBkcmFmdC1rdW1hci1iaWVyLXVzZWNhc2VzLTAwDQogICAgICAgIG90aGVycyBUQkQNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Z3dnIFttYWlsdG86cnRnd2ctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElKc2JyYW5kIFdpam5hbmRzDQpTZW50OiBUaHVyc2Rh eSwgU2VwdGVtYmVyIDI1LCAyMDE0IDI6MjcgUE0NClRvOiA8bXBsc0BpZXRmLm9yZz47IGwzdnBu QGlldGYub3JnOyBwaW1AaWV0Zi5vcmc7IHJ0Z3dnQGlldGYub3JnOyBtYm9uZWRAaWV0Zi5vcmcN ClN1YmplY3Q6IEJJRVIgQk9GDQoNCkhpIEZvbGtzLA0KDQpJZiB5b3UgYXJlIGludGVyZXN0ZWQg aW4gYSBuZXcgZm9yd2FyZGluZyBtZWNoYW5pc20gZm9yIE11bHRpY2FzdCwgY2FsbGVkOiBCaXQg SW5kZXhlZCBFeHBsaWNpdCBSZXBsaWNhdGlvbiAoQklFUiksIHBsZWFzZSBmZWVsIGZyZWUgdG8g cmVnaXN0ZXIgdG8gdGhlIEJPRiBsaXN0IGJpZXJAaWV0Zi5vcmcgKGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmllcikNCg0KV2UgaGF2ZSBhIEJPRiByZXF1ZXN0IHBlbmRp bmcgZm9yIEhhd2FpaS4NCg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lr aS9XaWtpU3RhcnQjUm91dGluZw0KDQpUaGVzZSBkcmFmdHMgYXJlIGF2YWlsYWJsZSBmb3IgcmVh ZGluZywgbW9yZSB3aWxsIGZvbGxvdyBsYXRlci4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC13aWpuYW5kcy1iaWVyLWFyY2hpdGVjdHVyZS0wMC50eHQNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRpb24tMDAudHh0 DQoNCg0KVGh4LA0KDQpJY2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpydGd3ZyBtYWlsaW5nIGxpc3QNCnJ0Z3dnQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo= From nobody Thu Sep 25 10:16: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 8FD271A6FD6; Thu, 25 Sep 2014 10:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 V14NQA56DV3E; Thu, 25 Sep 2014 10:16:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A241A028B; Thu, 25 Sep 2014 10:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1974; q=dns/txt; s=iport; t=1411665402; x=1412875002; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rS7pqU+3Y9Oo8SrDmhoJxJmIOw91bXtbV8KN6lWghtI=; b=l83FkqrgilChYqZ7puQFCKaZ0JDlWOfTvcdx6g0adJl2y/C3CkRCf6DA cC10HdTAwRXWRlKCfIRCgPersyud0B9Pq/6pHs06BDrrzvPwsENLwDUl7 LDf20FzzHs5AQ+YPTxzPhotiCXunVjN5JegdFf8tQdkIwNooHJKjF90tw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIKAKhNJFStJssW/2dsb2JhbABgg2FXgwGzKwEBAQEBAQUBcgGTOQqHTgKBGwF7hAMBAQEDAQEBASBLCwUHBAsRAQMBAQMCIwMCAicfAwYIBhOINggNq02VbgEXgSyEZokqEQEdMwcGgnI2gR0BBJYahwmBYopUiSCDZTsvAYEOgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,598,1406592000"; d="scan'208";a="189545344" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Sep 2014 17:16:32 +0000 Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8PHGTDd022694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 17:16:31 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: IJsbrand Wijnands In-Reply-To: Date: Thu, 25 Sep 2014 19:16:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "S, Somasundaram (Somasundaram)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3W-Gs_WJE9Jov9zXuX-pfdOVuh4 Cc: "mboned@ietf.org" , "" , "l3vpn@ietf.org" , "pim@ietf.org" , "rtgwg@ietf.org" Subject: Re: [mpls] BIER BOF 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, 25 Sep 2014 17:16:43 -0000 Hi, That is correct and what I mentioned in the email below. The = architecture and encapsulation draft are available and the most = important IMO. The rest will follow shortly! Thx! Ice. On 25 Sep 2014, at 18:33, S, Somasundaram (Somasundaram) = wrote: > I couldn=E2=80=99t view the other drafts mentioned in the bof page...=20= >=20 >>>>>>>>> . >=20 > Links to the mailing list, draft charter if any, relevant = Internet-Drafts, etc. >=20 > Mailing List: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/bier > Draft charter: TBD > Relevant drafts: > draft-shepherd-bier-problem-statement-00 > draft-wijnands-bier-architecture-00 > draft-wijnands-mpls-bier-encapsulation-00 > draft-psenak-ospf-bier-extentions-00 > draft-rosen-l3vpn-mvpn-bier-00 > draft-kumar-bier-usecases-00 > others TBD >=20 > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of IJsbrand = Wijnands > Sent: Thursday, September 25, 2014 2:27 PM > To: ; l3vpn@ietf.org; pim@ietf.org; rtgwg@ietf.org; = mboned@ietf.org > Subject: BIER BOF >=20 > Hi Folks, >=20 > If you are interested in a new forwarding mechanism for Multicast, = called: Bit Indexed Explicit Replication (BIER), please feel free to = register to the BOF list bier@ietf.org = (https://www.ietf.org/mailman/listinfo/bier) >=20 > We have a BOF request pending for Hawaii. >=20 > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Routing >=20 > These drafts are available for reading, more will follow later. >=20 > https://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt > = https://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt >=20 >=20 > Thx, >=20 > Ice. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Thu Sep 25 14:26: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 EF3FF1A887A for ; Thu, 25 Sep 2014 14:26:31 -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 QE383paki0nU for ; Thu, 25 Sep 2014 14:26:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD3C1A888E for ; Thu, 25 Sep 2014 14:26: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.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925212630.30640.51583.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 14:26:30 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ixtEVII4G_8i1cb0mtX0Ihh6qKI 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, 25 Sep 2014 21:26:32 -0000 Changed milestone "Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication", resolved as "Done". URL: http://datatracker.ietf.org/wg/mpls/charter/ From nobody Fri Sep 26 05:07: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 5FA7F1A86F9; Thu, 25 Sep 2014 09:40:04 -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 uHNcM-B479z2; Thu, 25 Sep 2014 09:40:03 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A511A86E9; Thu, 25 Sep 2014 09:40:02 -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 s8PGe0cg004315; Thu, 25 Sep 2014 17:40:00 +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 s8PGdwgo004304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 17:39:59 +0100 From: "Adrian Farrel" To: Date: Thu, 25 Sep 2014 17:39:55 +0100 Message-ID: <026001cfd8df$571fc440$055f4cc0$@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: Ac/Y31PDbwg0+jQHTsCj10YZo9E84A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20976.000 X-TM-AS-Result: No--8.038-10.0-31-10 X-imss-scan-details: No--8.038-10.0-31-10 X-TMASE-MatchedRID: Pg8dl0A/1xTDkHnJwIRKW5mug812qIbzH181YDtIVaoifM7JMNHW63w9 3dJCnn/Pj7t4VaG2jYxZKgjvZO8woTZQQocM3TDMQVWLLVSdiGsZYA38gj3BxMKQkd8YrGEvUpN 5b4Xd/F3ofwk6BENqtzIO2PPoSTg7AMFp5W5WHQKeAiCmPx4NwLTrdaH1ZWqCmBlD3TjdXl76C0 ePs7A07Y6HM5rqDwqtuo5OMxWPiCb6SDeK1T+MjqUUhjuyPfy3/UDb+ZigOvEGwS4YI+T41w== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/o02i4piYP1KRTmd-rZ9aWbgc6g0 X-Mailman-Approved-At: Fri, 26 Sep 2014 05:07:20 -0700 Subject: [mpls] Proposal for a charter for BESS 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, 25 Sep 2014 16:40:04 -0000 Hi, L3VPN, L2VPN, IDR, MPLS, NVO3, and PWE3 are all Bcc'd. Please send your responses on the routing-discussion list. We have been working on a draft charter for the "BGP Enabled Services" working group (BESS) that will take over the BGP VPN work from L3VPN, L2VPN, and NVO3. You can see the working copy of this charter at https://datatracker.ietf.org/doc/charter-ietf-bess/ We will need to make specific decisions about which documents go where, but that will (hopefully) not change the discussion of the charter text. To move this forward, the IESG will consider this on 2nd October with a view to sending it out for formal IETF review. So your review comments now would be really helpful. Thanks, Adrian From nobody Fri Sep 26 10:24: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 4BBF81A0194 for ; Fri, 26 Sep 2014 10:24:23 -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, HTML_MESSAGE=0.001, 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 iE6wsO-L13m6 for ; Fri, 26 Sep 2014 10:24:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE0D1A014E for ; Fri, 26 Sep 2014 10:24:21 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 17:24:19 +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.1039.011; Fri, 26 Sep 2014 17:24:19 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/Xg== Date: Fri, 26 Sep 2014 17:24:19 +0000 Message-ID: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB633; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(19300405004)(79102003)(15202345003)(86362001)(15975445006)(95666004)(83322001)(31966008)(74316001)(87936001)(81542003)(108616004)(80022003)(99396003)(19580395003)(85306004)(106116001)(99286002)(50986999)(83072002)(2501002)(92566001)(54356999)(16236675004)(105586002)(66066001)(107046002)(101416001)(33646002)(77982003)(18717965001)(74502003)(90102001)(230783001)(106356001)(19625215002)(64706001)(81342003)(21056001)(85852003)(76576001)(76482002)(2656002)(4396001)(97736003)(20776003)(10300001)(46102003)(74662003)(120916001)(229853001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7f250327283a4c7eb9946c6179dd6525CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/47MhMpmel2kskF36vYKRLMP6VV4 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll for draft-chen-mpls-source-label 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, 26 Sep 2014 17:24:23 -0000 --_000_7f250327283a4c7eb9946c6179dd6525CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, The authors of draft-chen-mpls-source-label have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-source-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 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 documents will not advance to the next stage until a response has been received from each author and each 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, Ross (as MPLS WG co-chair) --_000_7f250327283a4c7eb9946c6179dd6525CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group,

 

The authors of draft-chen-mpls-source-l= abel have told the

working group chairs that the draft is = ready to be adopted as a working

group document.

 

Before starting the poll to see if we h= ave consensus to make this a

working group document we need to do an= IPR poll.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies t= o

draft-chen-mpls-source-label?

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details).

 

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 t= he MPLS wg mailing list. The

documents will not advance to the next = stage until a response

has been received from each author and = each contributor.

 

If you are on the MPLS WG email list bu= t are not listed as an author or

contributor, then please explicitly res= pond only if you are aware of any

IPR that has not yet been disclosed in = conformance with IETF rules.

 

Thanks, Ross

(as MPLS WG co-chair)=

 

--_000_7f250327283a4c7eb9946c6179dd6525CO2PR05MB636namprd05pro_-- From nobody Fri Sep 26 11:31: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 311001A01DC for ; Fri, 26 Sep 2014 11:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 Z8IzDnMznqCb for ; Fri, 26 Sep 2014 11:30:52 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5026C1A00D5 for ; Fri, 26 Sep 2014 11:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92411; q=dns/txt; s=iport; t=1411756252; x=1412965852; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0y4XXTf8KdQoBGR9bE7bhQeLDgMYXTJuCgLVoepIYsY=; b=h4WMM0QwArPyCNXk5iJrQo1U3tJR817HQC7cFVhzsiMFFKoS78CN7LEn AHYBUAXdmVSPX6lliFJDK3lXTsAx5H+vMZZDoZYz7QPRkJMWoUL5AMcDs bcxG1SP6FZOt+ha/mFtowW/8yPPM6DenG4BzlfUWEX0Xdd7cuqTsjOZLI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAACwJVStJV2d/2dsb2JhbABfgkhGU1cE0hQCgQwWAXuEAwEBAQQaARJBCxIBCBEDAQEBIQECBDkUCQgCBAENBYg+vzABF4oqhRwtBxMRBgECBIRFBYYoiSOCGItDlVyBaiAWgUNsgQZCgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,605,1406592000"; d="scan'208,217"; a="81632728" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 26 Sep 2014 18:30:50 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8QIUo6j012819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 18:30:50 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 13:30:50 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Papadimitriou, Dimitri (Dimitri)" , "Tarek Saad (tsaad)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPq95qpcS9d3xXQEOPndVqySylAZu9o6+AgB9jzoCAAAH2AIAEt5wAgBGcbYCAADFpAIAVnxmAgAAqnoCABFM6AP//z2wAgACGAYCAABQngIACjjIAgABbswCAAymxAA== Date: Fri, 26 Sep 2014 18:30:49 +0000 Message-ID: In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832345F041@FR711WXCHMBA07.zeu.alcatel-lucent.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: [161.44.213.29] Content-Type: multipart/alternative; boundary="_000_D04B26113BEA3rgandhiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/81ezJDALHY9msTM11OS0wYXOU-I Cc: "mpls@ietf.org" Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 26 Sep 2014 18:30:59 -0000 --_000_D04B26113BEA3rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitri, WG, Thanks Dimitri for your comments. Tarek and I were thinking that adding new C-types for BEGIN and END objects= may be preferred for compatibility reasons, as nodes not supporting can si= mply ignore them. We also do not need separate IPV4/IPv6 specific markers. Separate C-types for BEGIN and END allow smallest object size (length 4 byt= es). S2L_SUB_LSP Class =3D 50 (S2L_SUB_LSP), S2L_SUB_LSP_MARKER_BEGIN C= -Type =3D 3 (TBA) S2L_SUB_LSP Class =3D 50 (S2L_SUB_LSP) , S2L_SUB_LSP_MARKER_END = C-Type =3D 4 (TBA) Another option is to define one C-type for object S2L_SUB_LSP_MARKER and ha= ve BEGIN and END as parameter although that increases the length of the obj= ect to 8 bytes so may be less preferred. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Wednesday, 24 September, 2014 10:12 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, There is another mean define special values e.g. 0x0=850 (BOL) and 0xF=85F = (EOL) but leave it to the list to decide about format and encoding. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Wednesday, September 24, 2014 2:45 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Tarek, WG, I had a look at RFC4875 and there is one way to add begin and end for the S= 2L list as follows (using new C-types). Please let me know your thoughts. Existing C-type defines ------------------------------- ::=3D [ ] 19.3. S2L_SUB_LSP Object An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to = the P2MP LSP. 19.3.1. S2L_SUB_LSP IPv4 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1 19.3.2. S2L_SUB_LSP IPv6 Object S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2 Define new C-types as follows: -------------------------------------- Begin of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type =3D 3 End of IPv4 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type =3D 4 Begin of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type =3D 5 End of IPv6 S2L List. S2L_SUB_LSP Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type =3D 6 Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 1:43 PM To: "Tarek Saad (tsaad)" >, Rakesh = Gandhi >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, as you ask the question, my preference is a single document; we mana= ged so far to keep a reduced set of documents for P2MP and willing to conti= nue along this track. This doesn=92t prevent combining different elements a= ltogether (this is how RFC 4875 came in) Thanks, -dimitri. From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] Sent: Monday, September 22, 2014 6:31 PM To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-= mpls-p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, I discussed with Rakesh. We see the value of having the EOL marker (for S2L= list) to trigger sub-group reoptimization as in stated rfc4875/section 14.= 2. As it's more generic mechanism that can potentially be used in all signalli= ng messages that contain the S2L sub-LSP descriptor list, we=92re not sure = if best to integrate in current document or tracked with its own draft. Any= preference? For triggering make-before-break reoptimization (rfc4875/section 14.1), we = still think the explicit notification back to the root is preferable. Regards, Tarek From: "Rakesh Gandhi (rgandhi)" > Date: Monday, September 22, 2014 at 8:31 AM To: "Papadimitriou, Dimitri (Dimitri)" >, Tarek Saad >, "draft-tsaad-mpls-p2mp-loose-path-reopt= @tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thanks Dimitri. Please see inline .. .. From: , "Dimitri (Dimitri)" > Date: Monday, 22 September, 2014 7:25 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi, Beside this gist, there is a point that would be worth discussing Great, we will update the draft with the gist information. message fragmentation is one possible cause of initiating re-signaling befo= re the full list is being known to the root but this is decorrelated from l= oose or strict ERO; in that case, the question of introducing a more genera= l procedure with an EOL (end of list bit) could be more appropriate as it w= ould solve two problems at once. We can solve the fragmentation issue (using EOL) for the RSVP messages= containing S2L list. However, solving that does not solve the re-optimizat= ion [RFC4736] issue this draft is addressing. Please see an example below. A --------B ------ D, E,F,G,H,I,J --------C ------- K,L,M,N,O,P,Q,R In above case, the mid-point node B may send a PathErr with S2L list (D,E,F= ,G,H,I, J) using an EOL bit. However, this can not be interpreted that the = node B is requesting to repot the whole LSP tree since part of the LSP that= traverse node C do not go via node B. + including a compatibility section somewhere in this document would certai= nly help. Ok, we can expand section 5. Thanks, Rakesh PS: in the longer term, I anticipate the need to collect practices and prod= uction of a BCP. Thanks, -dimitri. From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Friday, September 19, 2014 11:22 PM To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thank you for your review comments. Gist of your comments is that there is a way in RFC4875 to bulk the request= s for queries via a path message and also add a list of S2Ls in a PathErr m= essage. This method can be used for re-optimizing a group of S2Ls without increment= ing the LSP-ID as Tarek mentioned. As you hinted below, proposed draft provides a signalling extension to re-o= ptimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the L= SP-ID. If you agree with above understanding, we can clarify in the draft accordin= gly. Thanks, Rakesh From: , "Dimitri (Dimitri)" > Date: Friday, 19 September, 2014 10:49 AM To: Rakesh Gandhi >, "Tarek Saa= d (tsaad)" >, "draft-tsaad-mpls-p2m= p-loose-path-reopt@tools.ietf.org" > Cc: "mpls@ietf.org" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello Rakesh, See below for my answers: From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Saturday, September 06, 2014 2:39 AM To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-= p2mp-loose-path-reopt@tools.ietf.org Cc: mpls@ietf.org Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi WG, Forwarding following reply from Tarek to the MPLS mailing list. Thanks Tarek and Dimitri. Regards, Rakesh From: "Tarek Saad (tsaad)" > Date: Friday, 5 September, 2014 1:42 PM To: "Papadimitriou, Dimitri (Dimitri)" >, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson >, "rtg-ads@tools.ietf.org" >, "mpls-chairs@tools.ietf.org= " >, Martin Vigoureux >, "draft-tsaad-mpls-p2mp-= loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hi Dimitri, Thanks much for reviewing the draft and for your feedback. Please see inlin= e.. From: , "Dimitri (Dimitri)" > Date: Monday, August 25, 2014 at 8:45 AM To: "BRUNGARD, DEBORAH A" >, Loa Ande= rsson >, "rtg-ads@tools.ietf.org" >, = "mpls-chairs@tools.ietf.org" >, "VIGOUREUX, MARTIN (M= ARTIN)" >, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" > Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" > Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support= to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Hello, Here is my review of this document: The statement "notification of preferred path exists for a single S2L sub-L= SP only." and what comes in Section 3 of this document is questionable i) there is a mode of operation already included in RFC 4875 which allows s= uch reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Op= timization." It looks as an over-reading to state this method is limited on= per-sub-LSP basis, that section states clearly "14.2. Sub-Group-Based Re-Optimization Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages." [TS]: the draft is in agreement of the above statement from rfc4875 and thi= s is called out in the draft (below) with the shortcoming mentioned in sect= ion 14.2 for duplication of traffic in certain cases. "The ingress LSR that receives (un)solicited PathErr notification(s) for individual S2L sub-LSP(s), may prematurely start re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] Section 14.2, such re-optimization procedure may result in data duplicat= ion " The make-before-break reoptimization method as described in rfc4875 section= 14.1 avoids the former duplication problem by resignaling all the S2L sub-= LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mi= d-LSR to notify the ingress to trigger this specific mode of reoptimization= -- short of possibly re-using the PERR code/subcode for =93preferable path = exists=94 as defined in rfc4736 and including the *full* list of S2Ls in th= e S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as= mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. wh= en a single message may not be large enough to fit all S2L sub-LSPs).. In t= his case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L= sub-LSPs in each and would require additional logic to infer all S2L sub-L= SPs are to be resigned (e..g. using section 14.1 method) by (example) waiti= ng for some time to aggregate all possible PERR messages before taking acti= on. We also believe having a sub-set of S2L sub-LSPs in the descriptor list in = the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group ba= sed reoptimization mode described in section 14.2. In other cases, a PATH message that is intended to carry the =93path re-eva= luation=94 flag =97 as defined defined in rfc4736=97with a full list of S2L= sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching L= SRs, and only a subset of the S2L sub-LSPs that are routed over same next-h= op will be propagated in the descriptor list of the PATH message propagated= to downstream mid-LSRs.. Consequently, when a preferable path exists at su= ch mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversi= ng it.. The ingress LSR in this case can unambiguously use it to distinguis= h which LSP mode of reoptimization to invoke. [DP2] It is the requestor (initiator of the PathErr) which expands the ERO = (right ?) and sequence their signaling (thus any remerging between old and = new sub-LSP follows the remerging (following Section 18), why would request= to have such control taken by the root of the tree ? The protocol format chain can be found here below to see possibility for ge= nerating such request via notification: ::=3D [ ] | ::=3D [ ] [...] ::=3D [ ] With: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sub-Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I read behind this draft that this new mode of operation (the fact subpaths= "are loose or abstract hop expanded" doesn't change the general comment) m= eans some would prefer alignment with P2P re-optimization and operate outsi= de incremental state update --introduced for scaling reasons. In any case, = the justification/motivation for this mode of operation is missing in the d= ocument. ii) with PathErr as defined in RFC 4875 it includes a [ ] thus, it is even less clear why one would like to move with or more general= ly signaling it differently ("Request flags" instead of an "code") would pr= event as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optim= ization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.=94 [TS]: Please see reply above for the first one. [DP2] I am not sure you have captured this comment, and would reformulate i= t as follows: under which conditions the number of sub-LSPs is so large tha= t i) the receiver triggers re-signalling without having received the full s= equence of sub-LSP, ii) the initiator has no mean to sequence the resulting= Path messages such as to avoid situation of Section 14.2, iii) assuming th= is would be the case, why the procedure of Section 18 is not sufficient ? I= n more general terms why signal to the root a procedure than can be perform= ed by the requestor itself ? [DP2] On the other hand, there is a wide question, why do you consider only= the case with loose ERO=92s ? I mean the fragmentation problem is only one= cause of occurrence of duplication (which could happen from any transient = event during establishment of P2MP LSP), in that case, the question of intr= oducing a more general procedure with an EOL (end of list bit) would certai= nly be more appropriate as it would solve two problems at once. Regards, Tarek The proposed draft doesn=92t solve cases where this would occur, and on the= other, the cases it covers are already by RFC 4875 (re-optimize a loose se= t from a single branching point is already covered). Many thanks, -dimitri. --_000_D04B26113BEA3rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Dimitri, WG, 

Thanks Dimitri for your comments.

Tarek and I were thinking that adding new C-types for BEGIN and END ob= jects may be preferred for compatibility reasons, as nodes not supporting c= an simply ignore them.

We also do not need separate IPV4/IPv6 specific markers. 

Separate C-types for BEGIN and END allow smallest object size (length = 4 bytes).

    S2L_SUB_LSP Class =3D 50 (S2L_SUB_LSP),  = ; S2L_SUB_LSP_MARKER_BEGIN    C-Type =3D 3 (TBA)

    S2L_SUB_LSP Class =3D 50 (S2L_SUB_LSP) ,=  S2L_SUB_LSP_MARKER_END        C-Type =3D 4 (TBA)


Another option is to define one C-type for object S2L_SUB_LSP_MAR= KER and have BEGIN and END as parameter although that increases the length = of the object to 8 bytes so may be less preferred.


Thanks,
Rakesh


From: <Papadimitriou>, "= Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Date: Wednesday, 24 September, 2014= 10:12 AM
To: Rakesh Gandhi <rgandhi@cisco.com>, "Tarek Saad (tsaad)= " <tsaad@cisco.com>, &quo= t;= draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: RE: RTG-DIR review request= ed - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loos= e-path-reopt an mpls wg doc

Hello,

 

There is another mean define special values e.g. 0x0=850 (BOL) an= d 0xF=85F (EOL) but leave it to the list to decide about format and encodin= g.

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
Sent: Wednesday, September 24, 2014 2:45 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hi Dimitri, Tarek, WG,

 =

I had a look at RFC4875 = and there is one way to add begin and end for the S2L list as follows (usin= g new C-types). Please let me know your thoughts. 

 =

 =

Existing C-type defines<= o:p>

------------------------= -------

  <S2L sub-LSP d= escriptor list> ::=3D <S2L_SUB_LSP>  [ <S2L sub-LSP descri= ptor list> ]

 =

19.3. S2L_SUB_LSP Object=

    An S2L_SUB= _LSP object identifies a particular S2L sub-LSP belonging to the P2MP = LSP.

 =

19.3.1. S2L_SUB_LSP IPv4= Object

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4 C-Type =3D 1

 =

19.3.2. S2L_SUB_LSP IPv6= Object

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6 C-Type =3D 2

 =

 =

Define new C-types as fo= llows:

------------------------= --------------

Begin of IPv4 S2L List.<= o:p>

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4_BOL C-Type =3D 3

 =

End of IPv4 S2L List.

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv4_EOL C-Type =3D 4

 =

Begin of IPv6 S2L List.<= o:p>

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6_BOL C-Type =3D 5

 =

End of IPv6 S2L List.

    S2L_SUB_LS= P Class =3D 50, S2L_SUB_LSP_IPv6_EOL C-Type =3D 6

 =

 =

 =

Thanks,

Rakesh=

 

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 1:43 PM
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>, Rakesh Gandhi <rgandhi@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc<= /o:p>

 

Hello, as you ask the question, my preference is a = single document; we managed so far to keep a reduced set of documents for P= 2MP and willing to continue along this track. This doesn=92t prevent combining different elements altogether (thi= s is how RFC 4875 came in)

 

Thanks,

-dimitri.

 

From: Tarek Saad (tsaad) [= mailto:tsaad@cisco.com]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

I discussed with Rakesh. We see the value of having the EOL ma= rker (for S2L list) to trigger sub-group reoptimization as in stated rfc487= 5/section 14.2. <= /p>

As it's more generic mechanism that can potentially be us= ed in all signalling messages that contain the S2L sub-LSP descriptor = list, we=92re not sure if best to integrate in current document or tracked with its own draft. Any preference?

For triggering make-before-break reoptimization (rfc4875/secti= on 14.1), we still think the explicit notification back to the root is pref= erable.

 =

Regards,<= /p>

Tarek<= /p>

 

From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, Tarek Saad <tsaad= @cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.o= rg" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Thanks Dimitri.

 

Please see inline .. <RG> ..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, 22 September, 2014 7:25 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi,

 

Beside this gist, there is a point that would be wo= rth discussing

 

<RG> Great, we will update the draft = with the gist information.

 

message fragmentation is one possible cause of init= iating re-signaling before the full list is being known to the root but thi= s is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure wi= th an EOL (end of list bit) could be more appropriate as it would solve two= problems at once.

 

<RG> We can solve the fragmentat= ion issue (using EOL) for the RSVP messages containing S2L list. However, s= olving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example belo= w.

    

A --------B ------ D, E,F,G,H,I,J 

   --------C ------- K,L,M,N,O,P,= Q,R

  

In above case, the mid-point node B may sen= d a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit. However, this = can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that tra= verse node C do not go via node B.<= /o:p>

 

 

+ including a compatibility section somewhere i= n this document would certainly help.

 

 

<RG> Ok, we can expand section 5.

 

Thanks,<= o:p>

Rakesh

 

 

PS: in the longer term, I anticipate the need to co= llect practices and production of a BCP.=

 

Thanks,

-dimitri.

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi Dimitri,

 

Thank you for your review comments.<= span style=3D"color:black">

 

Gist of your comments is that there is a wa= y in RFC4875 to bulk the requests for queries via a path message and also a= dd a list of S2Ls in a PathErr message. 

This method can be used for re-optimizing a= group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

 

As you hinted below, proposed draft provide= s a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P= [RFC4736] by incrementing the LSP-ID.

 

If you agree with above understanding, we c= an clarify in the draft accordingly.

 

Thanks,<= o:p>

Rakesh

 

 

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi@c= isco.com>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "mpls@ietf.org" &= lt;mpls@ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgand= hi) [mailto:rgandhi@cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org
Cc: mpls@ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 =

Hi WG,

 

Forwarding following reply from Tarek to th= e MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,=

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-= lucent.com>, DEBORAH BRUNGARD <= db3546@att.com>, Loa Andersson <loa@= pi.nu>, "rtg-ads@tools.ietf.org= " <rtg-ads@tools.ietf.org= >, "mpls-chairs@t= ools.ietf.org" <m= pls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-lo= ose-path-reopt@tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-= reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for= your feedback. Please see inline..=

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <= dimitri.papadim= itriou@alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Loa Andersson <loa@pi.nu>, "rtg-ad= s@tools.ietf.org" <rt= g-ads@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux@alcatel-l= ucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" <draf= t-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com&= gt;
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have = support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferred path = exists for a single S2L sub-LSP only." and what comes in Section 3 of = this document is questionable=

 

i) there is a mode of operation already included in= RFC 4875 which allows such reorganization by sub-group ID cf. Section 14.2= . "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP= basis, that section states clearly=

 

"14.2.  Sub-Group-Based Re-Optimization

 

   Any node may initiate re-optimization = of a set of S2L sub-LSPs by

   using incremental state update and the= n, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the abov= e statement from rfc4875 and this is called out in the draft (below) with t= he shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)sol= icited PathErr notification(s)

   for individual S2L sub-LSP(s),= may prematurely start re-optimizing

   the sub-set of S2L sub-L= SPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimiza= tion procedure may result in data duplication

" 

The make-before-break reoptimization method= as described in rfc4875 section 14.1 avoids the former duplication problem= by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there=92s no explicit way for a mid-LS= R to notify the ingress to trigger this specific mode of reoptimization-- s= hort of possibly re-using the PERR code/subcode for =93preferable path exis= ts=94 as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in th= e PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR m= ay fragment such signalled messages (e.g. when a single message may not be = large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets o= f S2L sub-LSPs in each and would require additional logic to infer all= S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by = (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub= -LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to exp= licitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is inte= nded to carry the =93path re-evaluation=94 flag =97 as defined defined in r= fc4736=97with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and onl= y a subset of the S2L sub-LSPs that are routed over same next-hop will be p= ropagated in the descriptor list of the PATH message propagated to downstre= am mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the s= ub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can una= mbiguously use it to distinguish which LSP mode of reoptimization to invoke= .

 

[DP2] It is the requestor (initiator of the PathErr= ) which expands the ERO (right ?) and sequence their signaling (thus any re= merging between old and new sub-LSP follows the remerging (following Section 18), why would request to have su= ch control taken by the root of the tree ?

 

The protocol format chain can be found here below t= o see possibility for generating such request via notification:

 

   <notify session list>  = ;     ::=3D [ <notify session list> ]

        &nb= sp;            =             &nb= sp; <upstream notify session> |

        &nb= sp;            =             &nb= sp; <downstream notify session>

 

   <upstream notify session> &= nbsp; ::=3D <SESSION> [ <ADMIN_STATUS> ]

        &nb= sp;            =             &nb= sp; [<POLICY_DATA>...]<= /span>

        &nb= sp;            =             &nb= sp; <sender descriptor>=

 

 

   <sender descriptor> ::=3D <SE= NDER_TEMPLATE> <SENDER_TSPEC>

        &nb= sp;            =             &nb= sp;  [ <ADSPEC> ]<= /span>

 

   With:

 

       0  &= nbsp;           &nbs= p;    1         = ;          2   =             &nb= sp;   3

       0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;           &nbs= p;   IPv4 tunnel sender address     &nbs= p;            |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;   Reserved        &= nbsp;       |     &n= bsp;      LSP ID     &nbs= p;       |=

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;           &nbs= p;   Sub-Group Originator ID      &= nbsp;           &nbs= p;  |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

      |   &= nbsp;   Reserved        &= nbsp;       |     &n= bsp;      Sub-Group ID    &nbs= p;  |

      +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+

 

I read behind this draft that this new mode of oper= ation (the fact subpaths "are loose or abstract hop expanded" doe= sn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside incremental = state update --introduced for scaling reasons. In any case, the justificati= on/motivation for this mode of operation is missing in the document.=

 

 

ii) with PathErr as defined in RFC 4875 it includes= a [ <S2L= sub-LSP descriptor list> ]

thus, it is even less clear why one would like to m= ove with or more generally signaling it differently ("Request flags&qu= ot; instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result= in transient data

duplication as the new Path messages for a set of S= 2L sub-LSPs may

transit one or more nodes with the old Path state f= or the same set of

S2L sub-LSPs.=94

[TS]: Please see reply above for the first = one.

 

[DP2] I am not sure you have captured this comment,= and would reformulate it as follows: under which conditions the number of = sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence of sub-LS= P, ii) the initiator has no mean to sequence the resulting Path messages su= ch as to avoid situation of Section 14.2, iii) assuming this would be the c= ase, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the root a proc= edure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide question, = why do you consider only the case with loose ERO=92s ? I mean the fragmenta= tion problem is only one cause of occurrence of duplication (which could happen from any transient event during establi= shment of P2MP LSP), in that case, the question of introducing a more gener= al procedure with an EOL (end of list bit) would certainly be more appropri= ate as it would solve two problems at once.

 

 

Regards,=

Tarek

 

The proposed draft doesn=92t solve cases where this= would occur, and on the other, the cases it covers are already by RFC 4875= (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

 --_000_D04B26113BEA3rgandhiciscocom_-- From nobody Sat Sep 27 17:42: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 2BA091A0086 for ; Sat, 27 Sep 2014 17:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 z0ymCI1i6oaU for ; Sat, 27 Sep 2014 17:42:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCD11A007D for ; Sat, 27 Sep 2014 17:42:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJZ51955; Sun, 28 Sep 2014 00:42:48 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 01:42:47 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.131]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 08:42:44 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwVtqgo Date: Sun, 28 Sep 2014 00:42:43 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.242.223] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DADC4F7SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TOv1m72z5ekgfQrR4westq5STtQ Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label 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, 28 Sep 2014 00:42:53 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DADC4F7SZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ross, I am not aware of any IPR applies to this document! Best regards, Mach ________________________________ From: mpls [mpls-bounces@ietf.org] on behalf of Ross Callon [rcallon@junipe= r.net] Sent: Saturday, September 27, 2014 1:24 To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-chen-mpls-source-label Working Group, The authors of draft-chen-mpls-source-label have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-source-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 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 documents will not advance to the next stage until a response has been received from each author and each 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, Ross (as MPLS WG co-chair) --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DADC4F7SZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

I am not aware of any IPR applies to this document!

 

Best regards,

Mach

 

From: mpls [mpls-bounces@ietf.org] on beha= lf of Ross Callon [rcallon@juniper.net]
Sent: Saturday, September 27, 2014 1:24
To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] IPR poll for draft-chen-mpls-source-label

Working Group,

 

The authors of draft-chen-mpls-source-label have told the<= /span>

working group chairs that the draft is ready to be adopted= as a working

group document.

 

Before starting the poll to see if we have consensus to ma= ke this a

working group document we need to do an IPR poll.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies to

draft-chen-mpls-source-label?

 

If so, has this IPR been disclosed in compliance with IETF= IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).

 

If you are listed as a document author or contributor plea= se respond to

this email regardless of whether or not you are aware of a= ny relevant

IPR. The response needs to be sent to the MPLS wg mailing = list. The

documents will not advance to the next stage until a respo= nse

has been received from each author and each 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 ar= e aware of any

IPR that has not yet been disclosed in conformance with IE= TF rules.

 

Thanks, Ross

(as MPLS WG co-chair)

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DADC4F7SZXEMA510MBXchi_-- From nobody Sat Sep 27 19:17: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 B70F81A0110 for ; Sat, 27 Sep 2014 19:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 mI-g5FSdPhzY for ; Sat, 27 Sep 2014 19:17:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799991A0103 for ; Sat, 27 Sep 2014 19:17:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB74446; Sun, 28 Sep 2014 02:17:21 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 03:17:20 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 10:17:12 +0800 From: Xuxiaohu To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwV0O+w Date: Sun, 28 Sep 2014 02:17:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC57C@NKGEML512-MBS.china.huawei.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC57CNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zA1-JEcuNyx4quTjKo3cpx0VybE Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label 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, 28 Sep 2014 02:17:27 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC57CNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR related to this draft. Best regards, Xiaohu From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Saturday, September 27, 2014 1:24 AM To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-chen-mpls-source-label Working Group, The authors of draft-chen-mpls-source-label have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-source-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 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 documents will not advance to the next stage until a response has been received from each author and each 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, Ross (as MPLS WG co-chair) --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC57CNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m = not aware of any IPR related to this draft.

 = ;

Best regar= ds,

Xiaohu

 = ;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Saturday, September 27, 2014 1:24 AM
To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] IPR poll for draft-chen-mpls-source-label=

 

Working Group,

 =

The authors of draft-che= n-mpls-source-label have told the

working group chairs tha= t the draft is ready to be adopted as a working

group document.

 =

Before starting the poll= to see if we have consensus to make this a

working group document w= e need to do an IPR poll.

 =

This mail starts that IP= R poll.

 =

Are you aware of any IPR= that applies to

draft-chen-mpls-source-l= abel?

 =

If so, has this IPR been= disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 36= 69 and 5378 for more details).

 =

If you are listed as a d= ocument 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

documents will not advan= ce to the next stage until a response

has been received from e= ach author and each contributor.

 =

If you are on the MPLS W= G 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 bee= n disclosed in conformance with IETF rules.

 =

Thanks, Ross<= /span>

(as MPLS WG co-chair)

 =

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC57CNKGEML512MBSchi_-- From nobody Sat Sep 27 23:22: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 4ED0C1A036C; Sat, 27 Sep 2014 23:22: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 COfQneDAYZ39; Sat, 27 Sep 2014 23:22:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5359B1A0347; Sat, 27 Sep 2014 23:22:46 -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.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140928062246.25905.95889.idtracker@ietfa.amsl.com> Date: Sat, 27 Sep 2014 23:22:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/otuN-EDUcDlUuSZejFVWjqy-wgU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-09.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, 28 Sep 2014 06:22: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 : Requirements for MPLS-TP Shared Mesh Protection Authors : Yaacov Weingarten Sam Aldrin Ping Pan Jeong-dong Ryoo Greg Mirsky Filename : draft-ietf-mpls-smp-requirements-09.txt Pages : 15 Date : 2014-09-27 Abstract: This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-09 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 Sat Sep 27 23:27: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 1477C1A0361; Sat, 27 Sep 2014 23:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 CVtpQ-dWRiLQ; Sat, 27 Sep 2014 23:27:02 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E2D1A0369; Sat, 27 Sep 2014 23:27:01 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 28 Sep 2014 15:27:01 +0900 Received: from SMTP2.etri.info ([169.254.2.204]) by SMTP4.etri.info ([169.254.3.126]) with mapi id 14.01.0355.002; Sun, 28 Sep 2014 15:26:54 +0900 From: Jeong Ryoo To: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-smp-requirements@tools.ietf.org" , "kathleen.moriarty.ietf@gmail.com" , "stephen.farrell@cs.tcd.ie" , "adrian@olddog.co.uk" , "inacio@cert.org" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHPsmNayeDI78BkGUuSzy4Zz94kZZwWWwq4 Date: Sun, 28 Sep 2014 06:26:53 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170@SMTP2.etri.info> References: <20140807171629.16181.95994.idtracker@ietfa.amsl.com> In-Reply-To: <20140807171629.16181.95994.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.41] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yGBSVMCzrZQfyxHpFQWGF3Q-Rg4 Cc: "mpls@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [mpls] ID Tracker State Update Notice: 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, 28 Sep 2014 06:27:05 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwgYWxsLg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIHRleHQgcHJvcG9zYWxz IHRvIHRoaXMgZHJhZnQuDQoNCkFmdGVyIGNsb3NlIGNvbnN1bHRhdGlvbiB3aXRoIEFkcmlhbiwN CmEgbmV3IHJldmlzaW9uIGhhcyBiZWVuIHByZXBhcmVkIGFuZCBwb3N0ZWQuDQoNClRoZSBjaGFu Z2VzIGFyZToNCi0gS2F0aGxlZW4ncyBwcm9wb3NlZCB0ZXh0IGlzIGFkZGVkIGluIFNlY3VyaXR5 IFNlY3Rpb24gKFNlY3Rpb24gNykNCi0gVG8gY2xhcmlmeSB0aGUgdGVybSBwcm90ZWN0aW9uIHVz ZWQgaW4gdGhpcyBkb2N1bWVudCwNCiAgYSBmZXcgc2VudGVuY2VzIGFyZSBhZGRlZCBhdCB0aGUg YmVnaW5uaW5nIG9mIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIEludHJvZHVjdGlvbiBTZWN0aW9u DQotIFR3byBuaXRzIGZyb20gQ2hyaXMgYXJlIGNvcnJlY3RlZC4NCi0gUkZDIDcyNTggaXMgYWRk ZWQgaW4gUmVmZXJlbmNlcyBzZWN0aW9uLCBhbmQgdHdvIHVudXNlZCByZWZlcmVuY2VzIGFyZSBy ZW1vdmVkLg0KDQpUaGVyZSBhcmUgdHdvIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGNvbnNpZGVy ZWQsIGJ1dCBkaWQgbm90IHJlc3VsdCBpbiB0ZXh0IGNoYW5nZXMuDQpUaGVpciByZWFzb25zIGZv ciBub3QgY2hhbmdpbmcgYXJlIGFzIGZvbGxvd3M6DQoxLiBDb21tZW50IG9uIHRoZSBsZXZlbCBv ZiByZWZlcmVuY2luZyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbg0KPT0+DQpUaGlzIGRvY3VtZW50 IHJlZmVycyBSRkNzIDU5MjEgYW5kIDU1ODYsIHdoaWNoIGFyZSBmdXJ0aGVyIHJlZmVyZW5jaW5n IGFzIGluIHRoZQ0KZm9sbG93aW5nIGRpYWdyYW0uDQooUGxlYXNlIHZpZXcgd2l0aCBjb3VyaWVy IGZvbnQuKQ0KUmVkdWNpbmcgb25lIGxldmVsIGRvZXMgbm90IHNlZW0gdG8gaGVscCBhIGxvdC4N CldlIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUgY3VycmVudCB0ZXh0IHRvIGF2b2lkIHJlcGVhdGlu ZyB0aGUgdGV4dHMgb2YgUkZDcyA1OTIxIGFuZCA1NTg2Lg0KW1RoaXMgZG9jdW1lbnRdLSstPiBb UkZDNTkyMV0tKy0+IFtSRkMzMDMxXQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgKy0+IFtSRkMzOTg1XS0rLT4gW1JGQzM3Njhd DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgKy0+IFtSRkMyNDAxXQ0KICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg Ky0+IFtSRkM1NjU5XS0rLT4gW1JGQzM5ODVdLSstPiBbUkZDMzc2OF0NCiAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgKy0+IFtSRkMy NDAxXQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICstPiBbUkZDNTI1NF0tKy0+ IFtSRkM0NDQ3XQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICArLT4gW1JGQzM5MTZdLS0tPiBbUkZDMjQwMV0NCiAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0+IFtS RkM0MTExXQ0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICArLT4gW1JGQzQzNjRdLSstPiBbUkZDNDAyM10NCiAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICstPiBbUkZDMjM4NV0NCiAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0+IFtSRkMzOTg1XS0rLT4g W1JGQzM3NjhdDQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICArLT4gW1JGQzI0MDFd DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICstPiBbUkZDNDEwN10NCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICstPiBb UkZDNTkyMF0NCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICstPiBbUkZDNjk0MV0NCiAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgKy0+IFtSRkM1NTg2XS0rLT4gW1JGQzQzODVdDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLT4gW1JGQzUwODVd LSstPiBbUkZDNDQ0N10NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLT4gW1JG QzM5MzFdLS0tPiBbUkZDMTc1MF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LT4gW1JGQzQwMjNdLS0tPiBbUkZDMjQwOV0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLT4gW1JGQzQzNzldLS0tPiBbUkZDMTgxMl0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLT4gW1JGQzA3OTJdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0+IFtSRkM0NDQzXS0rLT4gW1JGQzQzMDJdDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstPiBbUkZDNDIwM10tKy0+IFtS RkMzNjMwXS0rLT4gW1JGQzIzMjhdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgKy0+IFtSRkMyMTU0XQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgKy0+IFtSRkMyMTU0XQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLT4gW1JGQzQzMDFdDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstPiBbUkZDMjQwMV0NCg0KMi4gS2F0aGxlZW4ncyBzZWNvbmQgQ29tbWVudCwgd2hpY2ggb3Zl cmxhcHMgd2l0aCBTdGVwaGVuJ3MNCj09Pg0KVGhlIGlzc3VlIGhlcmUgY29uY2VybnMgdGhlIHF1 YWxpdHkgb2YgdGhlIGJhY2stdXAgcGF0aCBjb21wYXJlZCB0byB0aGUgcHJpbWFyeSBwYXRoLg0K VGh1cywgaWYgdGhlIGJhY2stdXAgcGF0aCBoYXMgbG93ZXIgc2VjdXJpdHkgKGZvciBleGFtcGxl LCBkb2VzIG5vdCBoYXZlIGxvd2VyDQpsYXllciBzZWN1cml0eSkgY2F1c2luZyBhIGZhaWxvdmVy IGlzIGEgd2F5IHRvIGJlIGFibGUgdG8gZ2V0IGF0IHRoZSBkYXRhLg0KT3IsIGlmIHRoZSBiYWNr LXVwIHBhdGggZ29lcyB0aHJvdWdoIGEgcG9pbnQgb2YgcGVydmFzaXZlIG1vbml0b3JpbmcsIHRo ZW4NCmNhdXNpbmcgYSBmYWlsb3ZlciBpcyBhIHdheSB0byBnZXQgYXQgdGhlIGRhdGEuDQpPciwg aWYgdGhlIGJhY2stdXAtcGF0aCBpcyBhbHJlYWR5IGNvbmdlc3RlZCwgdGhlbiBjYXVzaW5nIGEg ZmFpbG92ZXIgbWF5IGJlIGENCkRvUyBvbiB0aGUgcHJvdGVjdGVkIHRyYWZmaWMgb3Igb24gb3Ro ZXIgdHJhZmZpYyAoZS5nLiB0aHJvdWdoIHByZWVtcHRpb24pLg0KTm9uZSBvZiB0aGlzIGlzIHJh ZGljYWwgb3IgbmV3LiBJbiBmYWN0LCBpdCBpcyBub3QgbmV3Lg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ckplb25nLWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K67O064K4 IOyCrOuejCA6ICJJRVRGIFNlY3JldGFyaWF0IiA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRm Lm9yZz4NCuuztOuCuCDrgqDsp5wgOiAyMDE0LTA4LTA4IDAyOjE2OjQwICggKzA5OjAwICkNCuuw m+uKlCDsgqzrnowgOiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50c0B0b29scy5pZXRm Lm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHNAdG9vbHMuaWV0Zi5vcmc+DQrs sLjsobAgOg0K7KCc66qpIDogSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOg0KDQpJRVNH IHN0YXRlIGNoYW5nZWQgdG8gSUVTRyBFdmFsdWF0aW9uOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJv bSBJRVNHIEV2YWx1YXRpb24NCklEIFRyYWNrZXIgVVJMOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLw0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPjxicj4NCkhpLCBhbGwuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzIGFuZCB0ZXh0IHByb3Bvc2FscyZuYnNwO3RvIHRoaXMgZHJhZnQuPC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+QWZ0ZXIgY2xvc2UgY29uc3VsdGF0aW9uIHdpdGggQWRyaWFu LCA8YnI+DQphIG5ldyByZXZpc2lvbiBoYXMgYmVlbiBwcmVwYXJlZCBhbmQgcG9zdGVkLjwvZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPlRoZSBjaGFuZ2VzIGFyZTo8YnI+DQotIEthdGhsZWVuJ3Mg cHJvcG9zZWQgdGV4dCBpcyBhZGRlZCBpbiBTZWN1cml0eSBTZWN0aW9uIChTZWN0aW9uIDcpIDxi cj4NCi0gVG8gY2xhcmlmeSB0aGUgdGVybSBwcm90ZWN0aW9uIHVzZWQgaW4gdGhpcyBkb2N1bWVu dCwgPGJyPg0KJm5ic3A7IGEgZmV3IHNlbnRlbmNlcyBhcmUgYWRkZWQgYXQgdGhlIGJlZ2lubmlu ZyBvZiB0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBJbnRyb2R1Y3Rpb24gU2VjdGlvbjxicj4NCi0g VHdvIG5pdHMgZnJvbSBDaHJpcyBhcmUgY29ycmVjdGVkLjxicj4NCi0gUkZDIDcyNTggaXMgYWRk ZWQgaW4gUmVmZXJlbmNlcyBzZWN0aW9uLCZuYnNwO2FuZCB0d28mbmJzcDt1bnVzZWQgcmVmZXJl bmNlcyBhcmUgcmVtb3ZlZC4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvZGl2Pg0KPGRpdiBzdHlsZT0i TElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPlRoZXJlIGFyZSB0d28gY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gY29uc2lkZXJlZCwg YnV0IGRpZCBub3QgcmVzdWx0IGluIHRleHQgY2hhbmdlcy48YnI+DQpUaGVpciByZWFzb25zIGZv ciBub3QgY2hhbmdpbmcgYXJlIGFzIGZvbGxvd3M6PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+MS4mbmJzcDtDb21tZW50IG9uIHRoZSBsZXZlbCBvZiByZWZlcmVuY2luZyBp biB0aGUgc2VjdXJpdHkgc2VjdGlvbjxicj4NCj09Jmd0Ozxicj4NClRoaXMgZG9jdW1lbnQgcmVm ZXJzIFJGQ3MgNTkyMSBhbmQgNTU4Niwgd2hpY2ggYXJlIGZ1cnRoZXIgcmVmZXJlbmNpbmcgYXMg aW4gdGhlPGJyPg0KZm9sbG93aW5nIGRpYWdyYW0uPGJyPg0KKFBsZWFzZSB2aWV3IHdpdGggY291 cmllciBmb250Lik8YnI+DQpSZWR1Y2luZyBvbmUgbGV2ZWwgZG9lcyBub3Qgc2VlbSB0byBoZWxw IGEgbG90Ljxicj4NCldlIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUgY3VycmVudCB0ZXh0IHRvIGF2 b2lkIHJlcGVhdGluZyB0aGUgdGV4dHMgb2YgUkZDcyA1OTIxIGFuZCA1NTg2LjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPltUaGlzIGRvY3VtZW50XS0mIzQzOy0mZ3Q7IFtS RkM1OTIxXS0mIzQzOy0mZ3Q7IFtSRkMzMDMxXTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkMzOTg1XS0mIzQzOy0m Z3Q7IFtSRkMzNzY4XTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSZn dDsgW1JGQzI0MDFdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzU2NTldLSYjNDM7LSZndDsgW1JGQzM5ODVdLSYj NDM7LSZndDsgW1JGQzM3NjhdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDMjQwMV08YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzUyNTRdLSYjNDM7LSZn dDsgW1JGQzQ0NDddPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtS RkMzOTE2XS0tLSZndDsgW1JGQzI0MDFdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0mZ3Q7IFtSRkM0MTExXTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst Jmd0OyBbUkZDNDM2NF0tJiM0MzstJmd0OyBbUkZDNDAyM108YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtS RkMyMzg1XTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDMzk4 NV0tJiM0MzstJmd0OyBbUkZDMzc2OF08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkMyNDAxXTxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDNDEwN10mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzU5MjBdIDxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkM2OTQxXSA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkM1NTg2XS0mIzQzOy0mZ3Q7IFtS RkM0Mzg1XSA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkM1MDg1XS0mIzQzOy0m Z3Q7IFtSRkM0NDQ3XSA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkMzOTMxXS0tLSZn dDsgW1JGQzE3NTBdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDNDAyM10tLS0mZ3Q7 IFtSRkMyNDA5XTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzQzNzldLS0tJmd0OyBb UkZDMTgxMl08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mZ3Q7IFtSRkMwNzkyXTxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzQ0NDNdLSYjNDM7LSZndDsgW1JGQzQzMDJdPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstJmd0OyBbUkZDNDIwM10tJiM0MzstJmd0OyBbUkZDMzYzMF0tJiM0MzstJmd0 OyBbUkZDMjMyOF0NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDMjE1 NF08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst Jmd0OyBbUkZDMjE1NF0NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSZndDsgW1JGQzQzMDFdPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstJmd0OyBbUkZDMjQwMV08L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij48YnI+DQoyLiZuYnNwO0thdGhsZWVuJ3Mgc2Vjb25kIENvbW1lbnQsIHdoaWNo IG92ZXJsYXBzIHdpdGggU3RlcGhlbidzPGJyPg0KPT0mZ3Q7PGJyPg0KVGhlIGlzc3VlIGhlcmUg Y29uY2VybnMgdGhlIHF1YWxpdHkgb2YgdGhlIGJhY2stdXAgcGF0aCBjb21wYXJlZCB0byB0aGUg cHJpbWFyeSBwYXRoLjxicj4NClRodXMsIGlmIHRoZSBiYWNrLXVwIHBhdGggaGFzIGxvd2VyIHNl Y3VyaXR5IChmb3IgZXhhbXBsZSwgZG9lcyBub3QgaGF2ZSBsb3dlcjxicj4NCmxheWVyIHNlY3Vy aXR5KSBjYXVzaW5nIGEgZmFpbG92ZXIgaXMgYSB3YXkgdG8gYmUgYWJsZSB0byBnZXQgYXQgdGhl IGRhdGEuPGJyPg0KT3IsIGlmIHRoZSBiYWNrLXVwIHBhdGggZ29lcyB0aHJvdWdoIGEgcG9pbnQg b2YgcGVydmFzaXZlIG1vbml0b3JpbmcsIHRoZW48YnI+DQpjYXVzaW5nIGEgZmFpbG92ZXIgaXMg YSB3YXkgdG8gZ2V0IGF0IHRoZSBkYXRhLjxicj4NCk9yLCBpZiB0aGUgYmFjay11cC1wYXRoIGlz IGFscmVhZHkgY29uZ2VzdGVkLCB0aGVuIGNhdXNpbmcgYSBmYWlsb3ZlciBtYXkgYmUgYTxicj4N CkRvUyBvbiB0aGUgcHJvdGVjdGVkIHRyYWZmaWMgb3Igb24gb3RoZXIgdHJhZmZpYyAoZS5nLiB0 aHJvdWdoIHByZWVtcHRpb24pLjxicj4NCk5vbmUgb2YgdGhpcyBpcyByYWRpY2FsIG9yIG5ldy4g SW4gZmFjdCwgaXQgaXMgbm90IG5ldy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJl Z2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SmVvbmctZG9uZzxicj4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50IiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZu YnNwOzwvZGl2Pg0KPGRpdiBpZD0iT1JHTUFJTF9DT05URU5UIiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8Yj7rs7Trgrgg7IKs656MIDogPC9iPiZxdW90 O0lFVEYgU2VjcmV0YXJpYXQmcXVvdDsgJmx0O2lldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+67O064K4IOuCoOynnCA6IDwvYj4yMDE0LTA4LTA4IDAyOjE2OjQwICgg JiM0MzswOTowMCApPGJyPg0KPGI+67Cb64qUIOyCrOuejCA6IDwvYj5tcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRm LW1wbHMtc21wLXJlcXVpcmVtZW50c0B0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1tcGxz LXNtcC1yZXF1aXJlbWVudHNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+7LC47KGwIDogPC9i Pjxicj4NCjxiPuygnOuqqSA6IDwvYj5JRCBUcmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6IDxE UkFGVC1JRVRGLU1QTFMtU01QLVJFUVVJUkVNRU5UUy0wOC5UWFQ+DQo8YnI+DQo8YnI+DQpJRVNH IHN0YXRlIGNoYW5nZWQgdG8gSUVTRyBFdmFsdWF0aW9uOjpSZXZpc2VkIEktRCBOZWVkZWQgZnJv bSBJRVNHIEV2YWx1YXRpb248YnI+DQpJRCBUcmFja2VyIFVSTDogaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy88YnI+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A290C6170SMTP2etriinfo_-- From nobody Mon Sep 29 03:56: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 51B6B1A0386; Mon, 29 Sep 2014 03:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 X-BdBRWiRWIu; Mon, 29 Sep 2014 03:55:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A2A1A020A; Mon, 29 Sep 2014 03:55:57 -0700 (PDT) Received: from [192.168.0.100] (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 29A171801256; Mon, 29 Sep 2014 12:55:56 +0200 (CEST) Message-ID: <54293ABE.5000407@pi.nu> Date: Mon, 29 Sep 2014 12:55:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-ads@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/boGcmNCr-d6O5oSUt2rmp4Y_w5E Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , draft-filsfils-spring-segment-routing-mpls@tools.ietf.org, "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 10:56:00 -0000 Hello, I have been selected as the Routing Directorate QA reviewer for draft-filsfils-spring-segment-routing-mpls-03.txt. The Routing Directorate QA reviews are intended to be a support to improve the quality of RTG Area documents as the pass through the IETF process. This is the QA review at the time of wg document adoption poll. Document: draft-filsfils-spring-segment-routing-mpls-03.txt Reviewer: Loa Andersson Review Date: 2014-09-28 Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: Standards Track Please find the review at: http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 /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 Mon Sep 29 04:54: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 0191B1A8749; Mon, 29 Sep 2014 04:54:18 -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 zDiw4yyX6v71; Mon, 29 Sep 2014 04:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E64551A1B9C; Mon, 29 Sep 2014 04:54:16 -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.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140929115416.5605.68265.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 04:54:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FF64siRIoVsVsah_OGYF0l3xFeU Cc: mpls@ietf.org Subject: [mpls] Last Call: (Relayed Echo Reply mechanism for LSP Ping) 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, 29 Sep 2014 11:54:18 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Relayed Echo Reply mechanism for LSP Ping' 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-10-13. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1945/ http://datatracker.ietf.org/ipr/828/ From nobody Mon Sep 29 05:00: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 8EFB01A1BC4 for ; Sun, 28 Sep 2014 12:40:29 -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, HTML_MESSAGE=0.001, 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 keCFsMHNjF41 for ; Sun, 28 Sep 2014 12:40:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310DF1A1B91 for ; Sun, 28 Sep 2014 12:40:25 -0700 (PDT) Received: from BL2PR03MB372.namprd03.prod.outlook.com (10.141.89.15) by BL2PR03MB370.namprd03.prod.outlook.com (10.141.89.13) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Sun, 28 Sep 2014 19:39:28 +0000 Received: from BL2PR03MB372.namprd03.prod.outlook.com ([10.141.89.15]) by BL2PR03MB372.namprd03.prod.outlook.com ([10.141.89.15]) with mapi id 15.00.1039.011; Sun, 28 Sep 2014 19:39:28 +0000 From: Luyuan Fang To: Mach Chen , Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwVtqgogAE9CHA= Date: Sun, 28 Sep 2014 19:39:28 +0000 Message-ID: References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.70.160.102] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB370; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(164054003)(199003)(120916001)(66066001)(19625215002)(85306004)(85852003)(33646002)(83072002)(10300001)(2656002)(64706001)(50986999)(15202345003)(21056001)(31966008)(108616004)(74316001)(76176999)(54356999)(230783001)(20776003)(97736003)(19300405004)(90102001)(101416001)(15975445006)(81342003)(74662003)(80022003)(81542003)(77982003)(79102003)(74502003)(4396001)(76482002)(19609705001)(46102003)(95666004)(99286002)(83322001)(87936001)(19580395003)(107046002)(2501002)(16236675004)(99396003)(19580405001)(106116001)(86362001)(106356001)(86612001)(92566001)(2201001)(76576001)(105586002)(7059019)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB370; H:BL2PR03MB372.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b06c396cab644e11a9074a7a8634a9c9BL2PR03MB372namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/N3tVmQSbGmL11zVAXO3GED35-I4 X-Mailman-Approved-At: Mon, 29 Sep 2014 05:00:28 -0700 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label 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, 28 Sep 2014 19:40:29 -0000 --_000_b06c396cab644e11a9074a7a8634a9c9BL2PR03MB372namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here, I'm not aware of any IPR related to this draft. Thx, Luyuan From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Saturday, September 27, 2014 8:43 PM To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: RE: IPR poll for draft-chen-mpls-source-label Hi Ross, I am not aware of any IPR applies to this document! Best regards, Mach ________________________________ From: mpls [mpls-bounces@ietf.org] on behalf of Ross Callon [rcallon@junipe= r.net] Sent: Saturday, September 27, 2014 1:24 To: mpls@ietf.org; draft-chen-mpls-source-label@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] IPR poll for draft-chen-mpls-source-label Working Group, The authors of draft-chen-mpls-source-label have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-source-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 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 documents will not advance to the next stage until a response has been received from each author and each 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, Ross (as MPLS WG co-chair) --_000_b06c396cab644e11a9074a7a8634a9c9BL2PR03MB372namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Same here, I’m not = aware of any IPR related to this draft.

Thx,

Luyuan<= /p>

 <= /p>

From: Mach C= hen [mailto:mach.chen@huawei.com]
Sent: Saturday, September 27, 2014 8:43 PM
To: Ross Callon; mpls@ietf.org; draft-chen-mpls-source-label@tools.i= etf.org
Cc: mpls-chairs@tools.ietf.org
Subject: RE: IPR poll for draft-chen-mpls-source-label

 

Hi Ross,

 

I am not aware of any IPR applies to this docume= nt!

 

Best regards,

Mach

 

From: mpls [mpls-bounces@ietf.org]= on behalf of Ross Callon [rcallon@juniper.net]
Sent: Saturday, September 27, 2014 1:24
To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] IPR poll for draft-chen-mpls-source-label

Working Group,

 =

The authors of draft-chen-m= pls-source-label have told the

working group chairs that t= he draft is ready to be adopted as a working

group document.

 =

Before starting the poll to= see if we have consensus to make this a=

working group document we n= eed to do an IPR poll.=

 =

This mail starts that IPR p= oll.

 =

Are you aware of any IPR th= at applies to

draft-chen-mpls-source-labe= l?

 =

If so, has this IPR been di= sclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 = and 5378 for more details).

 =

If you are listed as a docu= ment author or contributor please respond to

this email regardless of wh= ether or not you are aware of any relevant

IPR. The response needs to = be sent to the MPLS wg mailing list. The

documents will not advance = to the next stage until a response<= /o:p>

has been received from each= author and each contributor.=

 =

If you are on the MPLS WG e= mail list but are not listed as an author or

contributor, then please ex= plicitly respond only if you are aware of any

IPR that has not yet been d= isclosed in conformance with IETF rules.=

 =

Thanks, Ross

(as MPLS WG co-chair)

 =

--_000_b06c396cab644e11a9074a7a8634a9c9BL2PR03MB372namprd03pro_-- From nobody Mon Sep 29 05:29: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 A51661A3BA4; Mon, 29 Sep 2014 05:29:04 -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, 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 0JICebDxwZpT; Mon, 29 Sep 2014 05:29:02 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DB01A3B9E; Mon, 29 Sep 2014 05:29:01 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 12:28:38 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 12:28:38 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUw Date: Mon, 29 Sep 2014 12:28:38 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> In-Reply-To: <54293ABE.5000407@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB609; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(377424004)(252514010)(189002)(51444003)(51704005)(97736003)(77982003)(120916001)(21056001)(106356001)(74502003)(81542003)(2656002)(101416001)(107046002)(74316001)(20776003)(74662003)(76576001)(81342003)(10300001)(108616004)(80022003)(87936001)(46102003)(83072002)(15975445006)(19580405001)(31966008)(85306004)(76176999)(95666004)(90102001)(86362001)(105586002)(54356999)(33646002)(64706001)(15202345003)(92566001)(230783001)(79102003)(83322001)(66066001)(50986999)(4396001)(76482002)(106116001)(85852003)(99396003)(19580395003)(110136001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mye_70rKvEODA8zz9Pqn9vxD_T4 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 12:29:04 -0000 Loa, and all, I have read the draft and your review on the Wiki page, and I think that yo= ur question about domain-wide labels is worth detailed discussion. In Section 2 "Illustration", the draft says that: - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attache= d node segment 102 - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the ne= xt-hop onto the node segment 102. =20 Upon receiving a packet from A destined to Z, PE1 pushes two labels on= to the packet: the top label is 102, the bottom label is LZ.=20 102 identifies the node segment to PE2 and hence transports the packet a= long the ECMP-aware shortest- path to PE2. To me this strongly suggests that label 102 is understood by P1, P2, P3 and= P4 as a domain-wide label for an LSP that terminates in PE2. This looks di= fferent from the downstream label allocation process as defined in RFC 3031= and RFC 5331.=20 RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that If the binding between L and F was made by a third party, say R3, and t= hen advertised to both Ru and Rd, we also refer to the label binding as=20 "upstream-assigned". In our case it seems that assignment of label 102 and its binding to FEC th= at is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P4 = should all treat this label as upstream-assigned. But this is never mention= ed in the draft. I concur with you that this requires discussion in the MPLS WG, and I am no= t sure such a discussion should be postponed until the SPRING WG LC. I must admit that I did not read other SPRING documents (including one on i= nteroperability with existing label distribution protocols), and hence I ca= n be wrong in my conclusions. But the MPLS WG looks to me like exactly the = place where this should be clarified. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Monday, September 29, 2014 1:56 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; draft-filsfils-spri= ng- > segment-routing-mpls@tools.ietf.org; ; mpls= - > chairs@tools.ietf.org > Subject: [spring] Routing Directorate QA review of draft-filsfils-spring- > segment-routing-mpls >=20 > Hello, >=20 > I have been selected as the Routing Directorate QA reviewer for draft-fil= sfils- > spring-segment-routing-mpls-03.txt. >=20 > The Routing Directorate QA reviews are intended to be a support to improv= e > the quality of RTG Area documents as the pass through the IETF process. >=20 > This is the QA review at the time of wg document adoption poll. >=20 > Document: draft-filsfils-spring-segment-routing-mpls-03.txt > Reviewer: Loa Andersson > Review Date: 2014-09-28 > Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: > Standards Track >=20 > Please find the review at: >=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 >=20 > /Loa >=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 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 05:56: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 7EBA81A872A; Mon, 29 Sep 2014 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 M_4T88bFoXRu; Mon, 29 Sep 2014 05:55:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818671A8727; Mon, 29 Sep 2014 05:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4691; q=dns/txt; s=iport; t=1411995357; x=1413204957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hqP18WRhHoIeaamVxk06L+FsuVM38yVza84PU7kLKOc=; b=Xc9yH1Vn4hQq/Vb8xDOP/L8NDLWLub2dBT6kQroWLkncuO5avLaBVzmG jfEz6o1HZk1xXmFZZs1zNL0WGnMURNJldeXwIgeiszeZ0KVuntYaa+dco Tpl+5LtzORoH0zI47jKv4XwEB1gi6s8JErwKpJEE9RZZseaUF378PvEfF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAL9VKVStJA2L/2dsb2JhbABggw5TW8oJCoZ6VAKBDRYBe4QDAQEBBAEBATcxAwsMAgICAQgRAQIBAQEBHgkHGwwLFAMGCAIEDgWIPg2/KgEXBI84EQEdMwcGgyiBHQWRZYQ6hwmBYpN7gXIYFoFDbAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="359151523" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2014 12:55:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8TCtusM012358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 12:55:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 07:55:56 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P6mpNjXcNynEqOMeDwWEw/7ZwYXfMAgAAHnoA= Date: Mon, 29 Sep 2014 12:55:55 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <7FC9028C075B3042BF0CEA7DCF62B4BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/goP-xIU4L0FRztoWSWsgAGfjVnk Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 12:55:59 -0000 Sasha, SIDs are globally allocated and distributed. So, the answer to your questio= n about P1, P2, P3 and P4 knowledge of the SID representing PE2 is "yes". R= outers within the domain must know the SID representing PE2 (e.g.: 102). Now, when it comes to the dataplane, it has to be understood that the label= on top of the packet MAY have local significance and therefore MAY change = at each hop according to mpls architecture. It is explained (succinctly, I = admit) in section 3. This because the SID represents an index into a label space, not a label va= lue. IOW, there is no requirement from SR to have globally assigned labels= . The SR architecture makes use of globally assigned indexes onto locally s= coped label space. This is, btw, what been implemented and currently (inter= op) tested. s. On Sep 29, 2014, at 2:28 PM, Alexander Vainshtein wrote: > Loa, and all, > I have read the draft and your review on the Wiki page, and I think that = your question about domain-wide labels is worth detailed discussion. > In Section 2 "Illustration", the draft says that: > - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attac= hed node segment 102 > - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the = next-hop onto the node segment 102. =20 > Upon receiving a packet from A destined to Z, PE1 pushes two labels o= nto the packet: the top label is 102, the bottom label is LZ.=20 > 102 identifies the node segment to PE2 and hence transports the packet = along the ECMP-aware shortest- path to PE2. >=20 > To me this strongly suggests that label 102 is understood by P1, P2, P3 a= nd P4 as a domain-wide label for an LSP that terminates in PE2. This looks = different from the downstream label allocation process as defined in RFC 30= 31 and RFC 5331.=20 > RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that > > If the binding between L and F was made by a third party, say R3, and = then advertised to both Ru and Rd, we also refer to the label binding as=20 > "upstream-assigned". > >=20 > In our case it seems that assignment of label 102 and its binding to FEC = that is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P= 4 should all treat this label as upstream-assigned. But this is never menti= oned in the draft. >=20 > I concur with you that this requires discussion in the MPLS WG, and I am = not sure such a discussion should be postponed until the SPRING WG LC. >=20 > I must admit that I did not read other SPRING documents (including one on= interoperability with existing label distribution protocols), and hence I = can be wrong in my conclusions. But the MPLS WG looks to me like exactly th= e place where this should be clarified. >=20 > My 2c, > Sasha=20 > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Monday, September 29, 2014 1:56 PM >> To: rtg-ads@tools.ietf.org >> Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; draft-filsfils-spr= ing- >> segment-routing-mpls@tools.ietf.org; ; mpl= s- >> chairs@tools.ietf.org >> Subject: [spring] Routing Directorate QA review of draft-filsfils-spring= - >> segment-routing-mpls >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate QA reviewer for draft-fi= lsfils- >> spring-segment-routing-mpls-03.txt. >>=20 >> The Routing Directorate QA reviews are intended to be a support to impro= ve >> the quality of RTG Area documents as the pass through the IETF process. >>=20 >> This is the QA review at the time of wg document adoption poll. >>=20 >> Document: draft-filsfils-spring-segment-routing-mpls-03.txt >> Reviewer: Loa Andersson >> Review Date: 2014-09-28 >> Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: >> Standards Track >>=20 >> Please find the review at: >>=20 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 >>=20 >> /Loa >>=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 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 06:03: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 208FB1A1BA9; Mon, 29 Sep 2014 06:02:57 -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, 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 Ywbbd4S7vDfl; Mon, 29 Sep 2014 06:02:55 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::714]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AD41A6F8F; Mon, 29 Sep 2014 06:02:42 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 13:02:19 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 13:02:19 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUwgAAM3ICAAABk4A== Date: Mon, 29 Sep 2014 13:02:18 +0000 Message-ID: <8d34f502f77b4c709473f4e043db7345@AM3PR03MB612.eurprd03.prod.outlook.com> References: <54293ABE.5000407@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB610; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(24454002)(51444003)(252514010)(13464003)(377454003)(189002)(377424004)(19580405001)(85306004)(83072002)(81342003)(110136001)(33646002)(20776003)(74662003)(81542003)(90102001)(85852003)(64706001)(15202345003)(86362001)(31966008)(66066001)(54356999)(83322001)(107046002)(92566001)(2656002)(87936001)(10300001)(74316001)(120916001)(74502003)(77982003)(21056001)(108616004)(50986999)(79102003)(80022003)(76482002)(95666004)(76576001)(76176999)(97736003)(19580395003)(15975445006)(46102003)(230783001)(106356001)(4396001)(106116001)(105586002)(101416001)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vjUZNRSLQvUUqxeAPmHHrA0TGXY Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 13:02:57 -0000 Stefano, Lots of thanks for a prompt and detailed response. If, as you say, the SID is just a global index into the local label space = of each LSR, then the statement "PE1 pushes two label on the packet: the to= p one is 102" (for SID=3D102) is grossly misleading IMO, and should be chan= ged. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Sent: Monday, September 29, 2014 3:56 PM > To: Alexander Vainshtein > Cc: Loa Andersson; rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; rtg- > ads@tools.ietf.org; draft-filsfils-spring-segment-routing-mpls@tools.ietf= .org; > ; mpls-chairs@tools.ietf.org > Subject: Re: [spring] Routing Directorate QA review of draft-filsfils-spr= ing- > segment-routing-mpls >=20 > Sasha, >=20 > SIDs are globally allocated and distributed. So, the answer to your quest= ion > about P1, P2, P3 and P4 knowledge of the SID representing PE2 is "yes". > Routers within the domain must know the SID representing PE2 (e.g.: 102). >=20 > Now, when it comes to the dataplane, it has to be understood that the lab= el > on top of the packet MAY have local significance and therefore MAY change > at each hop according to mpls architecture. It is explained (succinctly, = I admit) > in section 3. >=20 > This because the SID represents an index into a label space, not a label = value. > IOW, there is no requirement from SR to have globally assigned labels. Th= e > SR architecture makes use of globally assigned indexes onto locally scope= d > label space. This is, btw, what been implemented and currently (interop) > tested. >=20 > s. >=20 >=20 > On Sep 29, 2014, at 2:28 PM, Alexander Vainshtein wrote: > > Loa, and all, > > I have read the draft and your review on the Wiki page, and I think tha= t > your question about domain-wide labels is worth detailed discussion. > > In Section 2 "Illustration", the draft says that: > > - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its > > attached node segment 102 > > - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the > next-hop onto the node segment 102. > > Upon receiving a packet from A destined to Z, PE1 pushes two labels= onto > the packet: the top label is 102, the bottom label is LZ. > > 102 identifies the node segment to PE2 and hence transports the packe= t > along the ECMP-aware shortest- path to PE2. > > > > To me this strongly suggests that label 102 is understood by P1, P2, P3= and > P4 as a domain-wide label for an LSP that terminates in PE2. This looks > different from the downstream label allocation process as defined in RFC > 3031 and RFC 5331. > > RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that > > > > If the binding between L and F was made by a third party, say R3, > > and then advertised to both Ru and Rd, we also refer to the label bind= ing > as "upstream-assigned". > > > > > > In our case it seems that assignment of label 102 and its binding to FE= C that > is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P4 > should all treat this label as upstream-assigned. But this is never menti= oned > in the draft. > > > > I concur with you that this requires discussion in the MPLS WG, and I a= m > not sure such a discussion should be postponed until the SPRING WG LC. > > > > I must admit that I did not read other SPRING documents (including one = on > interoperability with existing label distribution protocols), and hence I= can be > wrong in my conclusions. But the MPLS WG looks to me like exactly the pl= ace > where this should be clarified. > > > > My 2c, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Loa > >> Andersson > >> Sent: Monday, September 29, 2014 1:56 PM > >> To: rtg-ads@tools.ietf.org > >> Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; > >> draft-filsfils-spring- segment-routing-mpls@tools.ietf.org; > >> ; mpls- chairs@tools.ietf.org > >> Subject: [spring] Routing Directorate QA review of > >> draft-filsfils-spring- segment-routing-mpls > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate QA reviewer for > >> draft-filsfils- spring-segment-routing-mpls-03.txt. > >> > >> The Routing Directorate QA reviews are intended to be a support to > >> improve the quality of RTG Area documents as the pass through the IETF > process. > >> > >> This is the QA review at the time of wg document adoption poll. > >> > >> Document: draft-filsfils-spring-segment-routing-mpls-03.txt > >> Reviewer: Loa Andersson > >> Review Date: 2014-09-28 > >> Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: > >> Standards Track > >> > >> Please find the review at: > >> > >> http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%20201 > >> 4 > >> > >> /Loa > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 06:52: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 B11EB1A1AD5; Mon, 29 Sep 2014 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 UcZAvk2tD_1F; Mon, 29 Sep 2014 06:52:17 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759981A6F8D; Mon, 29 Sep 2014 06:52:17 -0700 (PDT) Received: from [192.168.0.113] (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 094BC180131A; Mon, 29 Sep 2014 15:52:16 +0200 (CEST) Message-ID: <54296411.8060304@pi.nu> Date: Mon, 29 Sep 2014 15:52:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein References: <54293ABE.5000407@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2zg-DpsBNaMWd1EhmDGFK7nr7rI Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 13:52:18 -0000 Sasha, I did NOT mean to imply that this discussion in the MPLS wg should wait until the SPRING wg last call, on the contrary if the answer to my question is that this a domain wide label, then it has to be brought to the MPLS wg BEFORE this is adopted as a SPRING wg document. /Loa On 2014-09-29 14:28, Alexander Vainshtein wrote: > I concur with you that this requires discussion in the MPLS WG, and I am not sure such a discussion should be postponed until the SPRING WG LC. -- 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 Sep 29 06:56: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 238611A6FAB; Mon, 29 Sep 2014 06:56:19 -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, 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 p3WMvcN2kWCd; Mon, 29 Sep 2014 06:56:17 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::700]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CEB1A1AFF; Mon, 29 Sep 2014 06:56:17 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 29 Sep 2014 13:55:54 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1034.003; Mon, 29 Sep 2014 13:55:53 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP29P4IT/IjiSa90674LLz0cqIbpwYBOUwgAAcnICAAADKMA== Date: Mon, 29 Sep 2014 13:55:53 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: <54296411.8060304@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB611; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(24454002)(51704005)(189002)(252514010)(377454003)(199003)(83072002)(97736003)(90102001)(66066001)(101416001)(31966008)(106356001)(76576001)(79102003)(33646002)(50986999)(64706001)(85852003)(107046002)(110136001)(108616004)(105586002)(85306004)(83322001)(74662003)(86362001)(81342003)(19580405001)(74502003)(46102003)(76176999)(81542003)(4396001)(80022003)(77982003)(21056001)(120916001)(54356999)(87936001)(92566001)(74316001)(95666004)(10300001)(99396003)(2656002)(230783001)(20776003)(19580395003)(76482002)(106116001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BCOH9EhIQcaBBMhTYGz_OmqyAOQ Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 13:56:19 -0000 Loa, Seems we are in sync on this matter. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Loa Andersso= n > Sent: Monday, September 29, 2014 4:52 PM > To: Alexander Vainshtein > Cc: rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; chairs@tools.ietf.org>; draft-filsfils-spring-segment-routing- > mpls@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [RTG-DIR] [spring] Routing Directorate QA review of draft-fi= lsfils- > spring-segment-routing-mpls >=20 > Sasha, >=20 > I did NOT mean to imply that this discussion in the MPLS wg should wait u= ntil > the SPRING wg last call, on the contrary if the answer to my question is = that > this a domain wide label, then it has to be brought to the MPLS wg BEFORE > this is adopted as a SPRING wg document. >=20 > /Loa >=20 > On 2014-09-29 14:28, Alexander Vainshtein wrote: > > I concur with you that this requires discussion in the MPLS WG, and I a= m > not sure such a discussion should be postponed until the SPRING WG LC. >=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 From nobody Mon Sep 29 07:01: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 2400A1A1AD5; Mon, 29 Sep 2014 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 ZMlOz_CAmteI; Mon, 29 Sep 2014 07:00:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801961A0395; Mon, 29 Sep 2014 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1113; q=dns/txt; s=iport; t=1411999260; x=1413208860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L5vURmzUqYhr5WCXOXRtQ1bKwGALQMytFEn3gtcB3WE=; b=iFzPoswafIz0uelvoFUnyaqfWR61bEfPDx/Xg64Zu84Nyh0Eqt7oAt0h kvj0WPvbbQSsARWHpadlMZEtiuVXjjOLiprpXpZ0yRkRJB6x+c2KceuOh yqGmtkr6ZaqKvpRIKHulBUBmKiOusTjn4yaj6vEbFT2aHeGWMJqFfCFBY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANplKVStJV2Z/2dsb2JhbABggw5TW8oJCoZ6VAKBDhYBe4QEAQEEAQEBNzEDCw4CAgEIGB4QGwwLJQIEDgWIPg2/MwETBASPOBEBHTMHgy6BHQWRZYtDlV2CIIFDbIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="82361045" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 29 Sep 2014 14:00:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8TE0wj0007832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 14:00:58 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.174]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 09:00:58 -0500 From: "Stefano Previdi (sprevidi)" To: Loa Andersson Thread-Topic: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP2+ydV7DaNVEy4kS4FgFgzYomJJwYd4uA Date: Mon, 29 Sep 2014 14:00:58 +0000 Message-ID: References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: <54296411.8060304@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <495538B27EC7274ABA4B341AE71D5FAB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/oqqKEr1riv9bBuM8AWCttwQiD2s Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 14:01:01 -0000 On Sep 29, 2014, at 3:52 PM, Loa Andersson wrote: > Sasha, >=20 > I did NOT mean to imply that this discussion in the MPLS wg should > wait until the SPRING wg last call, on the contrary if the answer to > my question is that this a domain wide label, then it has to be brought > to the MPLS wg BEFORE this is adopted as a SPRING wg document. I agree with you and the answer is "no" we don't want to bring a discussion= about domain-wide labels because this is not a requirement of segment rout= ing. s. >=20 > /Loa >=20 > On 2014-09-29 14:28, Alexander Vainshtein wrote: >> I concur with you that this requires discussion in the MPLS WG, and I am= not sure such a discussion should be postponed until the SPRING WG LC. >=20 > --=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 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Sep 29 07:10:19 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 D166A1A1ABA; Mon, 29 Sep 2014 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 weCFFI2RKiUu; Mon, 29 Sep 2014 07:10:07 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038EF1A1A9E; Mon, 29 Sep 2014 07:10:07 -0700 (PDT) Received: from [192.168.0.113] (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 86F37180131A; Mon, 29 Sep 2014 16:10:05 +0200 (CEST) Message-ID: <5429683E.8040103@pi.nu> Date: Mon, 29 Sep 2014 16:10:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stefano Previdi (sprevidi)" References: <54293ABE.5000407@pi.nu> <54296411.8060304@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/66Oh2rawc1Z1pj4Cy2kXOQNjLC4 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] [RTG-DIR] [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-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: Mon, 29 Sep 2014 14:10:13 -0000 Stefano, I'm fine with that, but I guess that the SPRING wg chairs and/or the rtg AD's need to make the consensus call on that. /Loa On 2014-09-29 16:00, Stefano Previdi (sprevidi) wrote: > On Sep 29, 2014, at 3:52 PM, Loa Andersson wrote: >> Sasha, >> >> I did NOT mean to imply that this discussion in the MPLS wg should >> wait until the SPRING wg last call, on the contrary if the answer to >> my question is that this a domain wide label, then it has to be brought >> to the MPLS wg BEFORE this is adopted as a SPRING wg document. > > > I agree with you and the answer is "no" we don't want to bring a discussion about domain-wide labels because this is not a requirement of segment routing. > > s. > > >> >> /Loa >> >> On 2014-09-29 14:28, Alexander Vainshtein wrote: >>> I concur with you that this requires discussion in the MPLS WG, and I am not sure such a discussion should be postponed until the SPRING WG LC. >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > -- 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 Sep 29 17:04: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 CBADC1ACD5F for ; Mon, 29 Sep 2014 17:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.493 X-Spam-Level: X-Spam-Status: No, score=-101.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, 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 wDjIU3kFILjE for ; Mon, 29 Sep 2014 17:04:19 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C2F1ACDEA for ; Mon, 29 Sep 2014 17:04:19 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-0e-54299cfc0544 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AE.FD.05330.CFC99245; Mon, 29 Sep 2014 19:55:09 +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; Mon, 29 Sep 2014 20:04:08 -0400 From: Gregory Mirsky To: "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Thread-Topic: draft-raza-mpls-oam-ipv6-rao Thread-Index: Ac/cP9hGOmk/RUA1TEmd6+U/gBn/LA== Date: Tue, 30 Sep 2014 00:04:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B853A5A@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.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B853A5Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPlO7fOZohBstPcFrsmdPPYnFr6UpW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj0bsVTAWnVSrark9gbWCcId/FyMEhIWAi cfNZWBcjJ5ApJnHh3nq2LkYuDiGBo4wSh/5vYYdwljNKvN29kxWkik3ASOLFxh52kGYRgUSJ lfclQUxmAWWJU3dlQCqEBdQk2nesYQSxRQS0Jd63P4Cy9SQ+bnwFNoVFQFVi7u3rYDavgK/E rK1HmEFsRqAbvp9awwRiMwuIS9x6Mp8J4jYBiSV7zjND2KISLx//Y4WwFSX29U9nh6jPlzi6 8ggTxExBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM HKXFqWW56UYGmxiBEXJMgk13B+Oel5aHGAU4GJV4eB+0aIQIsSaWFVfmHmKU5mBREuedVTsv WEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj7BXmGcd8Kl7xSTR6qk7Num244+DU6i1BX6bO /Z13epnxgbIl3gFxcz6Vcpa4+bJxORkqCinHGjD1nW27zaB3fuMljVCV6REz4z58lvfgKEu9 kHVQav36rJb3oZuctJJXSGYeCN3lWf/9xbw5yQyr+WY1y3yVSRWe8vwx/17hVbfjL5R9u8eo xFKckWioxVxUnAgAd4rAh3ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/e4R7A69gA61s844dEF-ySdC_KJA Cc: "mpls@ietf.org" Subject: [mpls] draft-raza-mpls-oam-ipv6-rao 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, 30 Sep 2014 00:04:22 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B853A5Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, this is very useful work, thank you. I think that it will be useful to clar= ify the RFC 4379 in regard to use of Router Alert option in the IP header r= eferencing specifically IPv6 Router Alert Option for MPLS OAM value. E.g. t= he first paragraph of the section 4.3 can be extended by: In case of IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOUL= D be used. In case of IPv6 control plane, the allocated through this docume= nt IPv6 Router Alert Option value for MPLS OAM MUST be used. Similarly, text of the first paragraph of the Section 4.5 of RFC 4379 may b= e updated to clarify use of the new RAO value in IPv6 case: ... then the IP header MUST contain the Router Alert IP option. In case of = IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOULD be used. = In case of IPv6 control plane, the allocated through this document IPv6 Rou= ter Alert Option value for MPLS OAM MUST be used. If the reply is sent ... Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B853A5Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

this is very useful work, thank you. I think that it= will be useful to clarify the RFC 4379 in regard to use of Router Alert op= tion in the IP header referencing specifically IPv6 Router Alert Option for= MPLS OAM value. E.g. the first paragraph of the section 4.3 can be extended by:

In case of IPv4 control p= lane, the generic Option Value 0x0 [RFC2113] SHOULD be used. In case of IPv= 6 control plane, the allocated through this document IPv6 Router Alert Opti= on value for MPLS OAM MUST be used.

Similarly, text of the first paragraph of the Sectio= n 4.5 of RFC 4379 may be updated to clarify use of the new RAO value in IPv= 6 case:

… then the IP heade= r MUST contain the Router Alert IP option. In case of IPv4 control plane, t= he generic Option Value 0x0 [RFC2113] SHOULD be used. In case of IPv6 contr= ol plane, the allocated through this document IPv6 Router Alert Option value for MPLS OAM MUST be used. If the reply is = sent …

 

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B853A5Aeusaamb103erics_-- From nobody Mon Sep 29 17:05: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 0A4D41ACE32; Mon, 29 Sep 2014 17:05:04 -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 HCyL1vk5fP8m; Mon, 29 Sep 2014 17:05:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA05C1ACD5F; Mon, 29 Sep 2014 17:05:00 -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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930000500.7476.1694.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 17:05:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gdEIGUDsuihgsumWWOcqTisBeyA Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kini-mpls-spring-entropy-label-01.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, 30 Sep 2014 00:05:04 -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 : Entropy labels for source routed stacked tunnels Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Xiaohu Xu Wim Hendrickx Jeff Tantsura Filename : draft-kini-mpls-spring-entropy-label-01.txt Pages : 10 Date : 2014-09-29 Abstract: Source routed tunnel stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed stacked tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kini-mpls-spring-entropy-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kini-mpls-spring-entropy-label-01 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 Sep 29 18:28: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 4C8831A00B9 for ; Mon, 29 Sep 2014 18:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 8N3j8FZUscFF for ; Mon, 29 Sep 2014 18:28:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193E91A00B0 for ; Mon, 29 Sep 2014 18:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7451; q=dns/txt; s=iport; t=1412040505; x=1413250105; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mBtf6U7ffCu9sx5DZFLu3bgeawTyhJ83RSfiBboggPs=; b=dUbtBqH8tcyqqqZi6TJ39nrPPiJBKuqUEuV+B2CYPVtLN2tyktux9D+F OwpdyxvyO8oPcWb3Ce0a6R4skjEzW5OkRniBl7dlig6kfCrdKPWCfrLfS C5tX4abWUbp3/8EvnRdCQigx6s4vy+IVwbebVs+BWPISbuHOjra9IVJS0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAO4GKlStJA2I/2dsb2JhbABggkgjI4EqBNFqAoEPFgF7hAQBAQR5EAIBCD8HMhQRAQEEDgWIPgG/OAEXkB4Hgy6BHQWPS4Iai0OVXYNjbIFIgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,624,1406592000"; d="scan'208,217"; a="82544109" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 30 Sep 2014 01:28:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8U1S7xt007762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 01:28:07 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 20:28:07 -0500 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky Thread-Topic: draft-raza-mpls-oam-ipv6-rao Thread-Index: Ac/cP9hGOmk/RUA1TEmd6+U/gBn/LAAN9oqA Date: Tue, 30 Sep 2014 01:28:07 +0000 Message-ID: <3DACDB00-311E-4351-87C7-B8D98FECB373@cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B853A5A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B853A5A@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.75] Content-Type: multipart/alternative; boundary="_000_3DACDB00311E435187C7B8D98FECB373ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w6eaxWuKwlIALh-sa8nzJzjN64Y Cc: "mpls@ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] draft-raza-mpls-oam-ipv6-rao 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, 30 Sep 2014 01:28:27 -0000 --_000_3DACDB00311E435187C7B8D98FECB373ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for the review and insightful comments! I think you point out a useful clarification to make explicit -- at the sam= e time, the approach we took in draft-raza-mpls-oam-ipv6-rao is to define t= he IPv6 RAO usage only and not any IPv4 clarifications. The document is als= o not updating RFC 4379. One approach we could take to address this is to: 1. Update RFC 4379 2. Add a small section with these updates. SOmething like this (borrowing h= eavily from your text): ~~~ 4. Updates to RFC 4379. [RFC 4379] specifies the use of the Router Alert option in the IP header. S= ections 4.3 and 4.5 of [RFC 4379] are updated with the following addition, = for every time in which the Router Alert IP option is used: "In case of an = IPv4 header, the generic Router Alert Option Value 0x0 [RFC2113] SHOULD be = used. In case of an IPv6 header, the IPv6 Router Alert Option value allocat= ed through this document for MPLS OAM MUST be used." ~~~ But I do wonder if we want to keep the document as IPv6-specific as possibl= e. Thoughts? Thanks, Carlos. On Sep 29, 2014, at 8:04 PM, Gregory Mirsky > wrote: Dear All, this is very useful work, thank you. I think that it will be useful to clar= ify the RFC 4379 in regard to use of Router Alert option in the IP header r= eferencing specifically IPv6 Router Alert Option for MPLS OAM value. E.g. t= he first paragraph of the section 4.3 can be extended by: In case of IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOUL= D be used. In case of IPv6 control plane, the allocated through this docume= nt IPv6 Router Alert Option value for MPLS OAM MUST be used. Similarly, text of the first paragraph of the Section 4.5 of RFC 4379 may b= e updated to clarify use of the new RAO value in IPv6 case: =85 then the IP header MUST contain the Router Alert IP option. In case of = IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOULD be used. = In case of IPv6 control plane, the allocated through this document IPv6 Rou= ter Alert Option value for MPLS OAM MUST be used. If the reply is sent =85 Regards, Greg --_000_3DACDB00311E435187C7B8D98FECB373ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <35B2544C0690FF43808B1D50D14845C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Thank you Greg for the review and insightful comments!

I think you point out a useful clarification to make explicit -- at th= e same time, the approach we took in draft-raza-mpls-oam-ipv6-rao is to def= ine the IPv6 RAO usage only and not any IPv4 clarifications. The document i= s also not updating RFC 4379.

One approach we could take to address this is to:
1. Update RFC 4379
2. Add a small section with these updates. SOmething like this (borrow= ing heavily from your text):

~~~
4. Updates to RFC 4379.

[RFC 4= 379] specifies the use of the Router Alert option in the IP header. Se= ctions 4.3 and 4.5 of [RFC 4379] are updated with the following addition, f= or every time in which the Router Alert IP option is used: "In case of an IPv4 header, the generic Router Alert = Option Value 0x0 [RFC2113] SHOULD be used. In case of an IPv6 header, the I= Pv6 Router Alert Option value allocated through this document&nbs= p; for MPLS OAM MUST be used."
~~~

But I do wonder if we want to keep the document as IPv6-specific as po= ssible.

Thoughts?

Thanks,

Carlos.

On Sep 29, 2014, at 8:04 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,
this is very useful work, thank you. I think that it will be useful to clar= ify the RFC 4379 in regard to use of Router Alert option in the IP header r= eferencing specifically IPv6 Router Alert Option for MPLS OAM value. E.g. t= he first paragraph of the section 4.3 can be extended by:
In case of IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOUL= D be used. In case of IPv6 control plane, the allocated through this docume= nt IPv6 Router Alert Option value for MPLS OAM MUST be used.
Similarly, text of the first paragraph of the Section 4.5 of RFC 4379 may b= e updated to clarify use of the new RAO value in IPv6 case:
=85 then the IP header MUST contain the Router Alert IP option. In case of = IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOULD be used. = In case of IPv6 control plane, the allocated through this document IPv6 Rou= ter Alert Option value for MPLS OAM MUST be used. If the reply is sent =85
 
 
            &nb= sp;   Regards,
            &nb= sp;            =        Greg

--_000_3DACDB00311E435187C7B8D98FECB373ciscocom_-- From nobody Mon Sep 29 19:51: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 94FEE1A00ED for ; Mon, 29 Sep 2014 19:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 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, RP_MATCHES_RCVD=-0.786, 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 EL1ft1DwmNFq for ; Mon, 29 Sep 2014 19:51:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8031A00C9 for ; Mon, 29 Sep 2014 19:51:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB31209; Tue, 30 Sep 2014 02:51:47 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Sep 2014 03:51:46 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 10:51:43 +0800 From: Lizhenbin To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwY/4HA Date: Tue, 30 Sep 2014 02:51:42 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D232CFFE0@nkgeml506-mbx.china.huawei.com> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232CFFE0nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rqwwwmfoDeX8zPY54KBcnl8j434 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogSVBSIHBvbGwgZm9yIGRyYWZ0LWNoZW4tbXBs?= =?gb2312?b?cy1zb3VyY2UtbGFiZWw=?= 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, 30 Sep 2014 02:51:51 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232CFFE0nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9zcywNCg0KDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGllcyB0byB0aGlz IGRvY3VtZW50IQ0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoNCg0KDQoN CreivP7IyzogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb3NzIENh bGxvbg0Kt6LLzcqxvOQ6IDIwMTTE6jnUwjI3yNUgMToyNA0KytW8/sjLOiBtcGxzQGlldGYub3Jn OyBkcmFmdC1jaGVuLW1wbHMtc291cmNlLWxhYmVsQHRvb2xzLmlldGYub3JnDQqzrcvNOiBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNdIElQUiBwb2xsIGZvciBkcmFmdC1j aGVuLW1wbHMtc291cmNlLWxhYmVsDQoNCldvcmtpbmcgR3JvdXAsDQoNClRoZSBhdXRob3JzIG9m IGRyYWZ0LWNoZW4tbXBscy1zb3VyY2UtbGFiZWwgaGF2ZSB0b2xkIHRoZQ0Kd29ya2luZyBncm91 cCBjaGFpcnMgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gYmUgYWRvcHRlZCBhcyBhIHdvcmtp bmcNCmdyb3VwIGRvY3VtZW50Lg0KDQpCZWZvcmUgc3RhcnRpbmcgdGhlIHBvbGwgdG8gc2VlIGlm IHdlIGhhdmUgY29uc2Vuc3VzIHRvIG1ha2UgdGhpcyBhDQp3b3JraW5nIGdyb3VwIGRvY3VtZW50 IHdlIG5lZWQgdG8gZG8gYW4gSVBSIHBvbGwuDQoNClRoaXMgbWFpbCBzdGFydHMgdGhhdCBJUFIg cG9sbC4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0bw0KZHJhZnQt Y2hlbi1tcGxzLXNvdXJjZS1sYWJlbD8NCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Ns b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0 ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3Rl ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bw0K dGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2Yg YW55IHJlbGV2YW50DQpJUFIuIFRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBN UExTIHdnIG1haWxpbmcgbGlzdC4gVGhlDQpkb2N1bWVudHMgd2lsbCBub3QgYWR2YW5jZSB0byB0 aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlDQpoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVh Y2ggYXV0aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExT IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KY29udHJp YnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdh cmUgb2YgYW55DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3Jt YW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rcywgUm9zcw0KKGFzIE1QTFMgV0cgY28tY2hh aXIpDQoNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232CFFE0nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

I am not aware of any IPR applies= to this document!

 

Best regards,

Robin

 

 

 

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: mpls [mailto:mpls-bou= nces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA9=D4=C2<= span lang=3D"EN-US">27=C8=D5 1:24
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] IPR poll for draft-chen-mpls-source-label=

 

Working Group,

 =

The authors of draft-che= n-mpls-source-label have told the

working group chairs tha= t the draft is ready to be adopted as a working

group document.

 =

Before starting the poll= to see if we have consensus to make this a

working group document w= e need to do an IPR poll.

 =

This mail starts that IP= R poll.

 =

Are you aware of any IPR= that applies to

draft-chen-mpls-source-l= abel?

 =

If so, has this IPR been= disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 36= 69 and 5378 for more details).

 =

If you are listed as a d= ocument 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

documents will not advan= ce to the next stage until a response

has been received from e= ach author and each contributor.

 =

If you are on the MPLS W= G 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 bee= n disclosed in conformance with IETF rules.

 =

Thanks, Ross<= /span>

(as MPLS WG co-chair)

 =

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D232CFFE0nkgeml506mbxchi_-- From nobody Mon Sep 29 23:00: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 BF43F1A01D6 for ; Mon, 29 Sep 2014 23:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 phI5Ml4PDKBt for ; Mon, 29 Sep 2014 23:00:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF62E1A01D5 for ; Mon, 29 Sep 2014 23:00:24 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-bc-5429ee0602e3 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0F.DA.25146.60EE9245; Tue, 30 Sep 2014 01:40:54 +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, 30 Sep 2014 02:00:14 -0400 From: Gregory Mirsky To: "Carlos Pignataro (cpignata)" Thread-Topic: draft-raza-mpls-oam-ipv6-rao Thread-Index: Ac/cP9hGOmk/RUA1TEmd6+U/gBn/LAAN9oqAAAFaJAA= Date: Tue, 30 Sep 2014 06:00:14 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B853D88@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B853A5A@eusaamb103.ericsson.se> <3DACDB00-311E-4351-87C7-B8D98FECB373@cisco.com> In-Reply-To: <3DACDB00-311E-4351-87C7-B8D98FECB373@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B853D88eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLrHW5ftnWaIwcy7Mhaf3u1gsdgzp5/F 4tbSlawOzB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mlr+N7AXzEusuHH2ElsD Y2NIFyMnh4SAicSSp+3sELaYxIV769m6GLk4hASOMkqsXfyQFcJZziix9MlcZpAqNgEjiRcb e8A6RATMJBofT2ICKWIWaGGU2DVzO1AHB4ewgJbE7PmyEDXaEu/bHzBC2FYSG+9OBLNZBFQl +i+9Ygcp5xXwlTi82xBiVwOjxMsjO9lAajgFbCXWNmwC28UIdN33U2uYQGxmAXGJW0/mM0Fc LSCxZM95ZghbVOLl43+sELaSxJzX15gh6vMlTh+eCTaTV0BQ4uTMJywTGEVnIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZgrB2TYHPcwbjgk+Uh RgEORiUe3oRrmiFCrIllxZW5hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amDU3mP1ddZDvgKrHU1ftURsd50/IuMsKihYy2y+UjRFuFX2zefJ38TYJ7p+FiopjXyxtGty 9jxz5qZIk7kdB4O3n3usuSWPpSDc9ENim3Xwsjm7Xb4YaQVdFwm06jBZ2vdp/90bMz0f/PmR tvyAZODnb+uZqvMltPQqH+wsPBA+Y8nTrptqtk5KLMUZiYZazEXFiQAJI/+ElgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/fYl-uxqzyB_gmbUcpK-BJOXLOYQ Cc: "mpls@ietf.org" , "draft-raza-mpls-oam-ipv6-rao@tools.ietf.org" Subject: Re: [mpls] draft-raza-mpls-oam-ipv6-rao 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, 30 Sep 2014 06:00:28 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B853D88eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos, the most expedient response ever! I think that the new section is the best way to demonstrate importance and = applicability of the new value. Regards, Greg From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Monday, September 29, 2014 6:28 PM To: Gregory Mirsky Cc: draft-raza-mpls-oam-ipv6-rao@tools.ietf.org; mpls@ietf.org Subject: Re: draft-raza-mpls-oam-ipv6-rao Thank you Greg for the review and insightful comments! I think you point out a useful clarification to make explicit -- at the sam= e time, the approach we took in draft-raza-mpls-oam-ipv6-rao is to define t= he IPv6 RAO usage only and not any IPv4 clarifications. The document is als= o not updating RFC 4379. One approach we could take to address this is to: 1. Update RFC 4379 2. Add a small section with these updates. SOmething like this (borrowing h= eavily from your text): ~~~ 4. Updates to RFC 4379. [RFC 4379] specifies the use of the Router Alert option in the IP header. S= ections 4.3 and 4.5 of [RFC 4379] are updated with the following addition, = for every time in which the Router Alert IP option is used: "In case of an = IPv4 header, the generic Router Alert Option Value 0x0 [RFC2113] SHOULD be = used. In case of an IPv6 header, the IPv6 Router Alert Option value allocat= ed through this document for MPLS OAM MUST be used." ~~~ But I do wonder if we want to keep the document as IPv6-specific as possibl= e. Thoughts? Thanks, Carlos. On Sep 29, 2014, at 8:04 PM, Gregory Mirsky > wrote: Dear All, this is very useful work, thank you. I think that it will be useful to clar= ify the RFC 4379 in regard to use of Router Alert option in the IP header r= eferencing specifically IPv6 Router Alert Option for MPLS OAM value. E.g. t= he first paragraph of the section 4.3 can be extended by: In case of IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOUL= D be used. In case of IPv6 control plane, the allocated through this docume= nt IPv6 Router Alert Option value for MPLS OAM MUST be used. Similarly, text of the first paragraph of the Section 4.5 of RFC 4379 may b= e updated to clarify use of the new RAO value in IPv6 case: ... then the IP header MUST contain the Router Alert IP option. In case of = IPv4 control plane, the generic Option Value 0x0 [RFC2113] SHOULD be used. = In case of IPv6 control plane, the allocated through this document IPv6 Rou= ter Alert Option value for MPLS OAM MUST be used. If the reply is sent ... Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B853D88eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos,

the most expedient respon= se ever!

I think that the new sect= ion is the best way to demonstrate importance and applicability of the new = value.

 <= /p>

    &= nbsp;           Regards,<= o:p>

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

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, September 29, 2014 6:28 PM
To: Gregory Mirsky
Cc: draft-raza-mpls-oam-ipv6-rao@tools.ietf.org; mpls@ietf.org
Subject: Re: draft-raza-mpls-oam-ipv6-rao

 

Thank you Greg for the review and insightful comment= s!

 

I think you point out a useful clarification to make= explicit -- at the same time, the approach we took in draft-raza-mpls-oam-= ipv6-rao is to define the IPv6 RAO usage only and not any IPv4 clarificatio= ns. The document is also not updating RFC 4379.

 

One approach we could take to address this is to:

1. Update RFC 4379

2. Add a small section with these updates. SOmething= like this (borrowing heavily from your text):

 

~~~

4. Updates to RFC 4379.

 

[RFC 4379] specifies the use of the Router Alert opt= ion in the IP header. Sections 4.3 and 4.5 of [RFC 4379] are updated w= ith the following addition, for every time in which the Router Alert I= P option is used: "In case of an IPv4 header, the generic Router Alert Option Value 0x0 [RFC2113] SHOULD be used. In cas= e of an IPv6 header, the IPv6 Router Alert Option value allocated thro= ugh this document  for MPLS OAM MUST be used."

~~~

 

But I do wonder if we want to keep the document as I= Pv6-specific as possible.

 

Thoughts?

 

Thanks,

 

Carlos.

 

On Sep 29, 2014, at 8:04 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&= gt; wrote:



Dear All,

this is very useful work, thank you. I = think that it will be useful to clarify the RFC 4379 in regard to use of Ro= uter Alert option in the IP header referencing specifically IPv6 Router Alert Option for MPLS OAM value. E.g. the first paragraph of t= he section 4.3 can be extended by:

In case of IPv4 control plane, the gene= ric Option Value 0x0 [RFC2113] SHOULD be used. In case of IPv6 control plan= e, the allocated through this document IPv6 Router Alert Option value for MPLS OAM MUST be used.

Similarly, text of the first paragraph = of the Section 4.5 of RFC 4379 may be updated to clarify use of the new RAO= value in IPv6 case:

… then the IP header MUST contain= the Router Alert IP option. In case of IPv4 control plane, the generic Opt= ion Value 0x0 [RFC2113] SHOULD be used. In case of IPv6 control plane, the allocated through this document IPv6 Router Alert Option value = for MPLS OAM MUST be used. If the reply is sent …

 

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

--_000_7347100B5761DC41A166AC17F22DF1121B853D88eusaamb103erics_-- From nobody Tue Sep 30 05:38:16 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 889DE1A1A0D; Tue, 30 Sep 2014 05:38:11 -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 1T4M69_ZmezY; Tue, 30 Sep 2014 05:38:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D91A19ED; Tue, 30 Sep 2014 05:37:33 -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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930123733.16692.11728.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 05:37:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r_fPOqwlySDLx8UBV0uV7-4o5YI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-p2mp-loose-path-reopt-01.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, 30 Sep 2014 12:38:13 -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 : Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-ietf-mpls-p2mp-loose-path-reopt-01.txt Pages : 15 Date : 2014-09-30 Abstract: For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re- evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub- group of S2L sub-LSP(s) basis only. This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. This document also defines markers to indicate beginning and end of a S2L sub-LSP descriptor list when RSVP message needs to be fragmented due to large number of S2L sub-LSPs when performing re-optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-p2mp-loose-path-reopt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-p2mp-loose-path-reopt-01 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 Sep 30 06:41: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 095B21A1A13 for ; Tue, 30 Sep 2014 06:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 61kmiw-il8Up for ; Tue, 30 Sep 2014 06:41:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD901A19EC for ; Tue, 30 Sep 2014 06:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5240; q=dns/txt; s=iport; t=1412084478; x=1413294078; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=C+QEYLmWBeMbvUhL1yMLscG/Ble2lgK3NJ3c72j9gBw=; b=Wostz/+k+WkPfbp7bV6XXZoA3zcjLY8VPeUiNXTnj5OEDc9Z8YG9OxKU NXc+JRLse6i6Tv+Sdixpuv3pkg5Z0D5/TO/8+gajz9qd3ICpFFeRlNLC4 pHsIl8UDILWkPW51mWDbFKt8DHMedfIS3hIJRsDHRYO+ROQl38hZRLask 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAMOyKlStJA2E/2dsb2JhbABggw5TVwTKGgyHSwKBCBYBe4QDAQEBBAEBATcxAxcCBAEIEQQBAR8FBCIMCxQJCAIEARIJiDUNv08BFwSPOBEBVwaERQWRaotFlXCCIIFDbIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208";a="359561517" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 30 Sep 2014 13:40:59 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UDewim020648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 13:40:58 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 08:40:58 -0500 From: "Rakesh Gandhi (rgandhi)" To: "Nobo Akiya (nobo)" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc Thread-Index: AQHPschXiHIc3yovg0SKQvXLklkTc5waFYSA Date: Tue, 30 Sep 2014 13:40:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.242.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QU3Z_GobTQn51q-49CSEzmJ4vrU Subject: Re: [mpls] poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc 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, 30 Sep 2014 13:41:21 -0000 Thanks Nobo for the review comments. The latest draft addresses the review comments. Please have a look at this version: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-loose-path-reopt-0 1.txt Thanks, Rakesh On 2014-08-06 6:46 PM, "Nobo Akiya (nobo)" wrote: >Hi Loa, > >I have read this document and support the adoption as a WG document. Not >only does this document reduce signaling messages for P2MP-TE >re-evaluation and re-optimization, it allow a mid-point LSR to >re-evaluate groups of S2L sub-LSPs together without some S2L sub-LSP >grouping heuristics, which is quite beneficial. > >I have few suggestions to authors, but all are not at all stoppers before >its WG adoption.=20 > > >1. This is a protocol extension that introduces new objects and >procedures, but the document lacks RFC2119 words (i.e. MAY, SHOULD, MUST, >etc). It would be highly beneficial to make use of RFC2119 words where >necessary (particularly in Sections 3 and 4). > > >2. Abstract, first paragraph, last sentence was slightly difficult to >read and had a typo. Suggested new text. > >[OLD] > Existing mechanisms allow the path re-evaluation and the > signaling of a the notification of preferred path exists for a single > S2L sub-LSP only. > >[NEW] > Existing mechanisms, a mechanism for a head-end LSR to > trigger a new path re-evaluation and a mechanism for a mid-point LSR > to signal an availability of a preferred path, operate on a single > S2L sub-LSP only. > > >3. Section 3, second paragraph. > >[snip] > An > ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP > tree to trigger the re-evaluation request(s). >[snip] > >It may be beneficial to clarify the reason behind specifying one or more >S2L sub-LSPs, i.e. to specify the sub-groups. > > >4. Section 3, third paragraph. > >I'd like to propose a bit of rephrase in the last portion of this >sentence, for clarification purpose. > >[OLD] > A mid-point LSR that expands loose next-hop(s) for one or more S2L > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the > P2MP-TE LSP. > >[NEW] > A mid-point LSR that expands loose next-hop(s) for one or more S2L > sub-LSP path(s), and that receives a Path message with the "P2MP-TE > Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE > LSP tree by re-evaluating all S2L sub-LSP(s) that are expanded paths > of the loose next-hop(s) of the P2MP-TE LSP. > > >5. Section 3, third paragraph (towards the end). > >[snip] > In this case, the mid-point LSR that expands loose next- > hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L > sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to > the ingress node. >[snip] > >Similar to comment #3 above, it may be beneficial to clarify the reason >behind specifying one or more S2L sub-LSPs, i.e. to specify the >sub-groups. > > >6. There's also a typo in the Security Considerations section. > >[OLD] >it may be desirable for a a mid-point LSR to modify > >[NEW] >it may be desirable for a mid-point LSR to modify > >[NOTE] >s/a a /a / > > >Thanks! > >-Nobo > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Wednesday, July 30, 2014 6:10 AM >> To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN >> (MARTIN); draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org >> Subject: [mpls] poll to see if we have support to make draft-tsaad-mpls- >> p2mp-loose-path-reopt an mpls wg doc >>=20 >> Working Group, >>=20 >> This is to start a two week poll on adopting >> draft-tsaad-mpls-p2mp-loose-path-reopt-03 as an MPLS working group >> document. >>=20 >> 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. >>=20 >> There is one IPR claim against this document. >>=20 >> 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. >>=20 >> 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. >>=20 >> This poll ends August 14, 2014. >>=20 >> /Loa >>=20 >> for the MPLS wg co-chairs >> -- >>=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 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Sep 30 07:07: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 E9DEA1A1A2A for ; Tue, 30 Sep 2014 07:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 cM_zbYufMttv for ; Tue, 30 Sep 2014 07:07:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A6F1A1A1E for ; Tue, 30 Sep 2014 07:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1412086049; x=1413295649; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ALmA4erC7lmQ/MSZ88d2dPvxiyGh/GZVXrceZ9webXA=; b=N2Mcb03MJ+D/OX/QvnZIWHFH+jDvlHQ1roH1jGFbNmLucYYit7M2d5uL FGYDeyPvvaRkEGLyiQfrCS6cKYxMkCyORIGHngJ1uPwtI0wjX7MDdrHAJ nmfz6nJuicT8mZ5fDU1l329AXcUFFF6EW/HpBHtP8/bAXuGWR7dqGwE2D 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACW4KlStJV2d/2dsb2JhbABggw5TUwQEyiaHSwKBCBYBe4QEAgQ6PQISAQgOKEIlAgQBDQUJiDUIBb9CARePazMHhEsFkWqEO4cKgWWUC4NjbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208";a="359505769" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 30 Sep 2014 14:07:29 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8UE7RHu021129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 14:07:27 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 09:07:27 -0500 From: "Rakesh Gandhi (rgandhi)" To: Yuji Kamite , "Tarek Saad (tsaad)" , "Zafar Ali (zali)" , "Robert H. Venator" Thread-Topic: New Version Notification for draft-ietf-mpls-p2mp-loose-path-reopt-01.txt Thread-Index: AQHP3KtrXLAq7K32AU69C9xyJ9TG9JwZxyWA Date: Tue, 30 Sep 2014 14:07:27 +0000 Message-ID: In-Reply-To: <20140930123734.16692.55377.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.242.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <70E616992C80BA4F8B58C22373373F6C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/11DR21I0gv_VzGJFrCOSm4hyslw Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] New Version Notification for draft-ietf-mpls-p2mp-loose-path-reopt-01.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, 30 Sep 2014 14:07:31 -0000 Hi WG, We have updated the draft to address review comments. Changes are as follows: - Include sub-group based re-optimization mode where multiple Path messages are combined (Section 1.2, 3.2) as per review comments from Dimitri. - Add extension for BEGIN and END markers for the S2L sub-LSP in the descriptor list when Path messages are combined (Section 4.3, 7.3). - Editing changes as per review comments from Nobo Akiya (Multiple Sections). - Minor misc editing changes. Your review comments on the changes and this draft in general are welcome. Thanks, Rakesh On 2014-09-30 8:37 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-mpls-p2mp-loose-path-reopt-01.txt >has been successfully submitted by Rakesh Gandhi and posted to the >IETF repository. > >Name: draft-ietf-mpls-p2mp-loose-path-reopt >Revision: 01 >Title: Extensions to Resource Reservation Protocol For Re-optimization >of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs >Document date: 2014-09-30 >Group: mpls >Pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-loose-path-reopt- >01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-loose-path-reopt/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-mpls-p2mp-loose-path-reopt-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-p2mp-loose-path-reopt-0= 1 > >Abstract: > For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label > Switched Path (LSP), it is preferable in some cases to re-evaluate > and re-optimize the entire P2MP-TE LSP by re-signaling all its > Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism > for an ingress Label Switched Router (LSR) to trigger a new path re- > evaluation request and a mechanism for a mid-point LSR to notify an > availability of a preferred path, operate on an individual or a sub- > group of S2L sub-LSP(s) basis only. > > This document defines RSVP-TE signaling extensions to allow an > ingress node of a P2MP-TE LSP to request the re-evaluation of the > entire LSP tree containing one or more S2L sub-LSPs whose paths are > loose (or abstract) hop expanded, and for a mid-point LSR to notify > to the ingress node that a preferable tree exists for the entire > P2MP-TE LSP. This document also defines markers to indicate > beginning and end of a S2L sub-LSP descriptor list when RSVP message > needs to be fragmented due to large number of S2L sub-LSPs when > performing re-optimization. > > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Tue Sep 30 07:56: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 CBD0C1A1A5E for ; Tue, 30 Sep 2014 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 ZBdUZW-oUzYF for ; Tue, 30 Sep 2014 07:56:10 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51F91A19EC for ; Tue, 30 Sep 2014 07:56:07 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so5354552pdj.12 for ; Tue, 30 Sep 2014 07:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=7Bcb06YJpqMhZ8uAt98b34wev9LYLR0WdPweGqrG6W8=; b=t7cOoSagwAkS/NsPV8+kXhIEVfJAdsra6FiIDJli/SLjSMCRWVQMyKRQuW69QFj09k +V87jOqRt9Axm0r7d7o66DSmLyGsbbAJqdsZJTggSmvC/RRrYkgCVu27s+zoGy3L4iTt BFZ0/dOvrRSuTdOSGgk6nha5hjTrKKkeUOayjYKFdRI/NELhq9r3WwJOl7abjiTwKo6F VjYTHE/JUbnB+Qt8SlClZ2+givanOfbg1wI4dAl5WCPFh603SqKXbFOvaJi4b0SP9qQZ I+bnQDCaq4HeYM2rlhkPDIkrqnnlMLVuDr1ZaVQ+t+Nno/jQpxtYujYVR/Nw8jAQwVVW hczg== X-Received: by 10.68.68.193 with SMTP id y1mr13046820pbt.136.1412088967271; Tue, 30 Sep 2014 07:56:07 -0700 (PDT) Received: from Lizhong-PC ([114.62.196.216]) by mx.google.com with ESMTPSA id ji11sm15391655pbd.37.2014.09.30.07.55.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Sep 2014 07:56:06 -0700 (PDT) Date: Tue, 30 Sep 2014 22:55:59 +0800 From: "Lizhong Jin" To: loa , eric.osborne , pranjal.dutta , eric.gray , mpls-chairs , martin.vigoureux References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com>, <5419AFA0.4050609@pi.nu> X-Priority: 3 X-GUID: B81B0006-1BA0-4076-9023-21D2F258B3E0 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2014093022552988855513@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart656853186244_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gbxoXOOhLu9LCKtSyT0nJSL87cA Cc: mpls , draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 30 Sep 2014 14:56:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart656853186244_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgTG9hLCBhdXRob3JzLA0KSSByZXZpZXcgdGhpcyBkb2N1bWVudC4gSXQgaXMgYSBzaG9ydCBk b2N1bWVudCwgYW5kIGlzIHVzZWZ1bGwgYW5kIHRlY2huaWNhbGx5IHNvdW5kLiBBbmQgSSBiZWxp ZXZlIGl0IGlzIHJlYWR5IGZvciBhZG9wdGlvbi4NCk9uZSBzbWFsbCBjb21tZW50IGlzIHRoZSBu YW1lIG9mIHRoZSBvcHRpb24gdmFsdWUuIE1QTFMgT0FNIGlzIGEgZ2VuZXJhbCB0ZXJtLCBub3Qg YSBzcGVjaWFsIHByb3RvY29sLiBDdXJyZW50bHkgSVB2NiBSQU8gaXMgb25seSBkZWZpbmVkIGZv ciBzcGVjaWFsIHByb3RvY29sLiBNeSBjb25jZXJuIGlzLCBpdCBzZWVtcyBhbGwga2luZHMgb2Yg ZnV0dXJlIE1QTFMgT0FNIHByb3RvY29scyBhcmUgcmVxdWlyZWQgdG8gdXNlIHRoZSBvcHRpb24g dmFsdWUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0LCB3aGljaCBtYXkgbm90IGJlIGEgZ29vZCBjaG9p Y2UgZm9yIHRoZW0uDQoNCg0KDQpSZWdhcmRzDQpMaXpob25nIEppbg0KIA0KRnJvbTogTG9hIEFu ZGVyc3Nvbg0KRGF0ZTogMjAxNC0wOS0xNyAyMzo1OA0KVG86IE9zYm9ybmUsIEVyaWM7IExpemhv bmcgSmluOyBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsgRXJpYyBHcmF5OyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikNClN1YmplY3Q6IE1Q TFMtUlQgcmV2aWV3IG9mIEktRCBBY3Rpb246IGRyYWZ0LXJhemEtbXBscy1vYW0taXB2Ni1yYW8t MDEudHh0DQpFcmljLCBMaXpob25nLCBQcmFuamFsIGFuZCBFcmljLA0KIA0KWW91IGhhdmUgYmUg c2VsZWN0ZWQgYXMgTVBMUy1SVCByZXZpZXdlcnMgZm9yIGRyYWZ0LXJhemEtbXBscy0NCm9hbS1p cHY2LXJhby4NCiANCk5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMg ZW1haWwgc28gdGhhdCB5b3UgY2FuIGtub3cNCnRoYXQgdGhpcyByZXZpZXcgaXMgZ29pbmcgb24u IEhvd2V2ZXIsIHBsZWFzZSBkbyBub3QgcmV2aWV3IHlvdXIgb3duDQpkb2N1bWVudC4NCiANClJl dmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQs IGlzIGl0DQp1c2VmdWwgKGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGlu IG9wZXJhdGlvbmFsDQpuZXR3b3JrcyksIGFuZCBpcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkg c291bmQ/ICBXZSBhcmUgaW50ZXJlc3RlZA0KaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVu dCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRw0KYWRvcHRpb24gKGllLCBpdCBkb2Vz bid0IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQphIGdv b2Qgc3RhcnQpLg0KIA0KUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0 aG9ycywgV0cgY28tY2hhaXJzIGFuZA0KV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBM UyBXRyBlbWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQptYXkgYmUgc2VudCBwcml2 YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0KIA0KSWYgeW91IGhhdmUgdGVjaG5pY2FsIGNv bW1lbnRzIHlvdSBzaG91bGQgdHJ5IHRvIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQNCipyZWFsbHkq IG5lZWQgdG8gYmUgcmVzb2x2ZWQgYmVmb3JlIGFkb3B0aW5nIGl0IGFzIGEgd29ya2luZyBncm91 cA0KZG9jdW1lbnQsIGFuZCB3aGF0IGNhbiB3YWl0IHVudGlsIHRoZSBkb2N1bWVudCBpcyBhIHdv cmtpbmcgZ3JvdXANCmRvY3VtZW50IGFuZCB0aGUgd29ya2luZyBncm91cCBoYXMgdGhlIHJldmlz aW9uIGNvbnRyb2wuDQogDQpBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQgYnkgT2N0 IDEsIDIwMTQ/IFBsZWFzZSByZXNwb25kIGluIGENCnRpbWVseSBmYXNoaW9uLiANCiANCiANClRo YW5rcywgTG9hDQooYXMgTVBMUyBXRyBjaGFpcikNCiANCiANCi0tLS0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LXJhemEtbXBscy1vYW0t aXB2Ni1yYW8tMDEudHh0DQpEYXRlOiBXZWQsIDE3IFNlcCAyMDE0IDA2OjUzOjQ0IC0wNzAwDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNClJlcGx5LVRvOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNDOiBtcGxzQGlldGYub3JnDQog DQogDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV29ya2luZyANCkdyb3VwIG9m IHRoZSBJRVRGLg0KIA0KICAgICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBSb3V0ZXIgQWxl cnQgT3B0aW9uIGZvciBNUExTIE9BTQ0KICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2FtcmFu IFJhemENCiAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vYm8gQWtpeWENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LXJhemEtbXBscy1vYW0taXB2Ni1yYW8tMDEudHh0DQpQYWdlcyAgICAgICAgICAgOiA1DQpEYXRl ICAgICAgICAgICAgOiAyMDE0LTA5LTE3DQogDQpBYnN0cmFjdDoNCiAgICBSRkM0Mzc5IGRlZmlu ZXMgdGhlIE1QTFMgTFNQIFBpbmcvVHJhY2Vyb3V0ZSBtZWNoYW5pc20sIGluIHdoaWNoIHRoZQ0K ICAgIFJvdXRlciBBbGVydCBvcHRpb24gbXVzdCBiZSBzZXQgaW4gdGhlIElQIGhlYWRlciBvZiB0 aGUgTVBMUyBFY2hvDQogICAgUmVxdWVzdCBtZXNzYWdlcywgYW5kIG1heSBjb25kaXRpb25hbGx5 IGJlIHNldCBpbiB0aGUgSVAgaGVhZGVyIG9mDQogICAgdGhlIE1QTFMgRWNobyBSZXBseSBtZXNz YWdlcy4gIFdoaWxlIGEgZ2VuZXJpYyAiUm91dGVyIHNoYWxsIGV4YW1pbmUNCiAgICBwYWNrZXQi IE9wdGlvbiBWYWx1ZSBpcyB1c2VkIGZvciB0aGUgSVB2NCBSb3V0ZXIgQWxlcnQgT3B0aW9uIChS QU8pLA0KICAgIHRoZXJlIGlzIG5vIGdlbmVyaWMgUm91dGVyIEFsZXJ0IE9wdGlvbiBWYWx1ZSBk ZWZpbmVkIGZvciBJUHY2IHRoYXQNCiAgICBjYW4gYmUgdXNlZC4gIFRoaXMgZG9jdW1lbnQgYWxs b2NhdGVzIGEgbmV3IGdlbmVyaWMgSVB2NiBSb3V0ZXIgQWxlcnQNCiAgICBPcHRpb24gVmFsdWUg dGhhdCBjYW4gYmUgdXNlZCBieSBNUExTIE9BTSB0b29scywgaW5jbHVkaW5nIHRoZSBNUExTDQog ICAgRWNobyBSZXF1ZXN0IGFuZCBNUExTIEVjaG8gUmVwbHkgbWVzc2FnZXMgZm9yIE1QTFMgSVB2 Ni4NCiANCiAgICBUaGUgaW5pdGlhbCBtb3RpdmF0aW9uIHRvIHJlcXVlc3QgYW4gSVB2NiBSb3V0 ZXIgQWxlcnQgT3B0aW9uIChSQU8pDQogICAgY29kZSBwb2ludCBmb3IgTVBMUyBPQU0gY29tZXMg ZnJvbSBNUExTIExTUCBQaW5nL1RyYWNlcm91dGUuDQogICAgSG93ZXZlciwgdGhpcyBjb2RlcG9p bnQgaXMgYXBwbGljYWJsZSB0byBhbGwgTVBMUyBPQU0gYW5kIG5vdCBsaW1pdGVkDQogICAgdG8g TVBMUyBMU1AgUGluZy9UcmFjZXJvdXRlLg0KIA0KIA0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLw0KIA0KVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLTAxDQogDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLTAxDQogDQogDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ LUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFm dCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0Kb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiANCiANCg== ------=_001_NextPart656853186244_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A<= div>Hi Loa, authors,
I review this document. It is = a short document, and is usefull and technically soundMPLS OAM is a general term= , not a special protocol. Currently IPv6 RAO is only defined for special p= rotocol. My concern is, it seems all kinds of future MPLS OAM protocols ar= e required to use the option value defined in this draft, which may not be= a good choice for them.
=0A

=0A
=
<= div>Regards
Lizhong Jin
=0A
&nb= sp;
Date: 2014-09-17 = 23:58
To: Osborne, Eric; Lizhong Jin= ; Dutta, Pranjal K (Pr= anjal); Eric Gray; mpls-chairs@tools.ietf.org; <= a href=3D"mailto:martin.vigoureux@alcatel-lucent.com">VIGOUREUX, MARTIN (M= ARTIN)
Subject: MPLS-RT review of I-D Action: d= raft-raza-mpls-oam-ipv6-rao-01.txt
Eric, Lizhon= g, Pranjal and Eric,
=0A
 
=0A
You have be selected= as MPLS-RT reviewers for draft-raza-mpls-
=0A
oam-ipv6-rao.=0A
 
=0A
Note to authors: You have been CC'd on this e= mail so that you can know
=0A
that this review is going on. Howev= er, please do not review your own
=0A
document.
=0A
&nbs= p;
=0A
Reviews should comment on whether the document is coherent= , is it
=0A
useful (ie, is it likely to be actually useful in ope= rational
=0A
networks), and is the document technically sound?&nb= sp; We are interested
=0A
in knowing whether the document is read= y to be considered for WG
=0A
adoption (ie, it doesn't have to be= perfect at this point, but should be
=0A
a good start).
=0A=
 
=0A
Reviews should be sent to the document authors, W= G co-chairs and
=0A
WG secretary, and CC'd to the MPLS WG email l= ist. If necessary, comments
=0A
may be sent privately to only the= WG chairs.
=0A
 
=0A
If you have technical comment= s you should try to be explicit about what
=0A
*really* need to b= e resolved before adopting it as a working group
=0A
document, an= d what can wait until the document is a working group
=0A
documen= t and the working group has the revision control.
=0A
 =0A
Are you able to review this draft by Oct 1, 2014? Please respond = in a
=0A
timely fashion.
=0A
 
=0A
 =
=0A
Thanks, Loa
=0A
(as MPLS WG chair)
=0A
&nb= sp;
=0A
 
=0A
-------- Original Message --------=0A
Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt
= =0A
Date: Wed, 17 Sep 2014 06:53:44 -0700
=0A
From: internet-= drafts@ietf.org
=0A
Reply-To: internet-drafts@ietf.org
=0ATo: i-d-announce@ietf.org
=0A
CC: mpls@ietf.org
=0A
&= nbsp;
=0A
 
=0A
A New Internet-Draft is available f= rom the on-line Internet-Drafts
=0A
directories.
=0A
&n= bsp; This draft is a work item of the Multiprotocol Label Switching Workin= g
=0A
Group of the IETF.
=0A
 
=0A
 =         Title    &n= bsp;      : IPv6 Router Alert Option for MPLS OAM=
=0A
         Authors&nbs= p;        : Kamran Raza
=0A
&n= bsp;           &nbs= p;            =   Nobo Akiya
=0A
       &= nbsp;           &nb= sp;       Carlos Pignataro
=0A
Fil= ename        : draft-raza-mpls-oam-ipv6= -rao-01.txt
=0A
Pages       &= nbsp;   : 5
=0A
Date     &nbs= p;      : 2014-09-17
=0A
 
=0A=
Abstract:
=0A
    RFC4379 defines the MPLS LS= P Ping/Traceroute mechanism, in which the
=0A
    = Router Alert option must be set in the IP header of the MPLS Echo
=0A=
    Request messages, and may conditionally be set in = the IP header of
=0A
    the MPLS Echo Reply messa= ges.  While a generic "Router shall examine
=0A
  =   packet" Option Value is used for the IPv4 Router Alert Option (RAO)= ,
=0A
    there is no generic Router Alert Option = Value defined for IPv6 that
=0A
    can be used.&n= bsp; This document allocates a new generic IPv6 Router Alert
=0A
=     Option Value that can be used by MPLS OAM tools, includ= ing the MPLS
=0A
    Echo Request and MPLS Echo Re= ply messages for MPLS IPv6.
=0A
 
=0A
  &= nbsp; The initial motivation to request an IPv6 Router Alert Option (RAO)<= /div>=0A
    code point for MPLS OAM comes from MPLS LS= P Ping/Traceroute.
=0A
    However, this codepoint= is applicable to all MPLS OAM and not limited
=0A
  &n= bsp; to MPLS LSP Ping/Traceroute.
=0A
 
=0A
 <= /div>=0A
The IETF datatracker status page for this draft is:
=0A<= div>https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/
= =0A
 
=0A
There's also a htmlized version available at:<= /div>=0A
http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01=0A
 
=0A
A diff from the previous version is availab= le at:
=0A
http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam= -ipv6-rao-01
=0A
 
=0A
 
=0A
Please n= ote that it may take a couple of minutes from the time of submission
= =0A
until the htmlized version and diff are available at tools.ietf.or= g.
=0A
 
=0A
Internet-Drafts are also available by = anonymous FTP at:
=0A
ftp://ftp.ietf.org/internet-drafts/
= =0A
 
=0A
______________________________________________= _
=0A
I-D-Announce mailing list
=0A
I-D-Announce@ietf.or= g
=0A
https://www.ietf.org/mailman/listinfo/i-d-announce
=0A=
Internet-Draft directories: http://www.ietf.org/shadow.html
=0A<= div>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
=0A
 
= =0A
 
=0A
=0A ------=_001_NextPart656853186244_=------ From nobody Tue Sep 30 07:59:46 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 0CCBA1A1A58 for ; Tue, 30 Sep 2014 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.285 X-Spam-Level: X-Spam-Status: No, score=-15.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 36MKtlaGmodT for ; Tue, 30 Sep 2014 07:59:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F19A1A1A5D for ; Tue, 30 Sep 2014 07:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20037; q=dns/txt; s=iport; t=1412089182; x=1413298782; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4y62AhXkdCy4QgUgAQb4gCExERKFe1QYIw8D0wAdsg8=; b=Ho/phHGpVs+q7Rvf9/FsVHqriyqaB+wxUNepzx6Eo4UaSuxizd/W/lMF +zudOimu9GXFC2UrH6AyOcxoRhFsTKFJP6qV8cjwQ6azJ4augQiZ5emlw nyRS+U8XENWiE+dTgYDpjihS65sIrNe/q5Pj4iO7hrLKlkAVkfQGHsi3w U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFABzEKlStJA2L/2dsb2JhbABggkgjI1NTBASEGsQdgWMBCYdNAoEJFgF7hAMBAQEEAQEBawsMBAIBCA4DAwECKAchBgsUCQgCBAENBQmIIQMRAQcFuAoNhx4BF41ugU4KBwE/DQQGAQYDgi5TgUEFj1CCGoQ7hHqCEIFljT8DhkmDY2wBgQUJFyKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208,217";a="359573146" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 30 Sep 2014 14:59:41 +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 s8UExfW2025157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 14:59:41 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 09:59:41 -0500 From: "Carlos Pignataro (cpignata)" To: Lizhong Jin , loa , "eric.osborne" , "pranjal.dutta" , "eric.gray" , mpls-chairs , "martin.vigoureux" Thread-Topic: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Thread-Index: AQHP3L7IHKsJaAsg9UiXBrJoWlw725wZ1ZIA Date: Tue, 30 Sep 2014 14:59:39 +0000 Message-ID: References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com> <5419AFA0.4050609@pi.nu> <2014093022552988855513@gmail.com> In-Reply-To: <2014093022552988855513@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.82.214.75] Content-Type: multipart/alternative; boundary="_000_D0503D2E69F0Ccpignataciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HmLVpWQSuRqazYvVq41b3wwMgOY Cc: mpls , draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 30 Sep 2014 14:59:45 -0000 --_000_D0503D2E69F0Ccpignataciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Lizhong! Future MPLS OAM protocols are not required to use this RAO value, but this = is available for them to use. The text currently says: The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. Thanks, Carlos. From: Lizhong Jin > Date: Tuesday, September 30, 2014 at 10:55 AM To: Loa Andersson >, "eric.osborne" >, "pranjal.dutta" >, "eric.gra= y" >, mpls-chairs >, Martin Vigour= eux > Cc: draft-raza-mpls-oam-ipv6-rao >, mpls > Subject: Re: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.= txt Resent-From: > Resent-To: Carlos Pignataro >= , Nobo Akiya >, >, >, Loa = Andersson >, Ross Callon >, Martin Vigoureux > Resent-Date: Tuesday, September 30, 2014 at 10:56 AM Hi Loa, authors, I review this document. It is a short document, and is usefull and technica= lly sound. And I believe it is ready for adoption. One small comment is the name of the option value. MPLS OAM is a general te= rm, not a special protocol. Currently IPv6 RAO is only defined for special = protocol. My concern is, it seems all kinds of future MPLS OAM protocols ar= e required to use the option value defined in this draft, which may not be = a good choice for them. ________________________________ Regards Lizhong Jin From: Loa Andersson Date: 2014-09-17 23:58 To: Osborne, Eric; Lizhong Jin; Dutta, Pranjal K (Pranjal); Eric Gray; mpls-chairs@tools.ietf= .org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Eric, Lizhong, Pranjal and Eric, You have be selected as MPLS-RT reviewers for draft-raza-mpls- oam-ipv6-rao. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by Oct 1, 2014? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Date: Wed, 17 Sep 2014 06:53:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org 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 : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-01.txt Pages : 5 Date : 2014-09-17 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam-ipv6-rao-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D0503D2E69F0Ccpignataciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C94B7971A29FA4D83B3E74A0DD00F18@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks, Lizhong!

Future MPLS OAM protocols are not r= equired to use this = RAO value, but this is available for them to use.

The text currently says:
   The initial motivation to request an IPv6 Router Alert Option (RAO)
   code point for MPLS OAM comes from MPLS LSP Ping/Traceroute.
   However, this codepoint is applicable to all MPLS OAM and not limited
   to MPLS LSP Ping/Traceroute.
Thanks,

Carlos.

From: Lizhong Jin <lizho.jin@gmail.com>
Date: Tuesday, September 30, 2014 a= t 10:55 AM
To: Loa Andersson <loa@pi.nu>, "eric.osborne" <eric.osborne@level3.com>, "pran= jal.dutta" <pra= njal.dutta@alcatel-lucent.com>, "eric.gray" <eric.g= ray@ericsson.com>, mpls-chairs <mpls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-= lucent.com>
Cc: draft-raza-mpls-oam-ipv6-rao &l= t;draft-raza= -mpls-oam-ipv6-rao@tools.ietf.org>, mpls <mpls@ietf.org>
Subject: Re: MPLS-RT review of I-D = Action: draft-raza-mpls-oam-ipv6-rao-01.txt
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: Carlos Pignataro <cpignata@cisco.com>, Nobo Akiya &= lt;nobo@cisco.com>, <skraza@cisco.com>, <swallow@cisco.com>, Loa Andersson <loa@pi.nu>, Ross Cal= lon <rcallon@juniper.net>,= Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Resent-Date: Tuesday, September 30,= 2014 at 10:56 AM

Hi Loa, authors,
I review this document. It is a short document, and is usefull and&nbs= p;technically sound. And I believe it is ready for adoption.
One small comment is the name of the option value. MPLS OAM i= s a general term, not a special protocol. Currently IPv6 RAO is only define= d for special protocol. My concern is, it seems all kinds of future MPLS OAM protocols are required to use the op= tion value defined in this draft, which may not be a good choice for them.<= /span>

Regards
Lizhong Jin
 
Date: 2014-09-17 23:58
Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam= -ipv6-rao-01.txt
Eric, Lizhong, Pranjal and Eric,
 
You have be selected as MPLS-RT reviewers for draft-raza-mpls-
oam-ipv6-rao.
 
Note to authors: You have been CC'd on this email so that you can know=
that this review is going on. However, please do not review your own
document.
 
Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?  We are interes= ted
in knowing whether the document is ready to be considered for WG
adoption (ie, it doesn't have to be perfect at this point, but should = be
a good start).
 
Reviews should be sent to the document authors, WG co-chairs and
WG secretary, and CC'd to the MPLS WG email list. If necessary, commen= ts
may be sent privately to only the WG chairs.
 
If you have technical comments you should try to be explicit about wha= t
*really* need to be resolved before adopting it as a working group
document, and what can wait until the document is a working group
document and the working group has the revision control.
 
Are you able to review this draft by Oct 1, 2014? Please respond in a<= /div>
timely fashion.
 
 
Thanks, Loa
(as MPLS WG chair)
 
 
-------- Original Message --------
Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt
Date: Wed, 17 Sep 2014 06:53:44 -0700
 
 
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  &nbs= p;        : IPv6 Router Alert Option for= MPLS OAM
         Authors  &n= bsp;      : Kamran Raza
           &nbs= p;            &= nbsp;  Nobo Akiya
           &nbs= p;            &= nbsp;  Carlos Pignataro
Filename        : draft-raza-mpls-o= am-ipv6-rao-01.txt
Pages           : 5<= /div>
Date           = : 2014-09-17
 
Abstract:
    RFC4379 defines the MPLS LSP Ping/Traceroute mechan= ism, in which the
    Router Alert option must be set in the IP header of= the MPLS Echo
    Request messages, and may conditionally be set in t= he IP header of
    the MPLS Echo Reply messages.  While a generic= "Router shall examine
    packet" Option Value is used for the IPv4 Rout= er Alert Option (RAO),
    there is no generic Router Alert Option Value defin= ed for IPv6 that
    can be used.  This document allocates a new ge= neric IPv6 Router Alert
    Option Value that can be used by MPLS OAM tools, in= cluding the MPLS
    Echo Request and MPLS Echo Reply messages for MPLS = IPv6.
 
    The initial motivation to request an IPv6 Router Al= ert Option (RAO)
    code point for MPLS OAM comes from MPLS LSP Ping/Tr= aceroute.
    However, this codepoint is applicable to all MPLS O= AM and not limited
    to MPLS LSP Ping/Traceroute.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/
 
There's also a htmlized version available at:
 
A diff from the previous version is available at:
 
 
Please note that it may take a couple of minutes from the time of subm= ission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
 
_______________________________________________
I-D-Announce mailing list
 --_000_D0503D2E69F0Ccpignataciscocom_-- From nobody Tue Sep 30 08:11: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 1985B1A1A23 for ; Tue, 30 Sep 2014 08:11:22 -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, HTML_MESSAGE=0.001, 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 gdJ8CqKt0xxJ for ; Tue, 30 Sep 2014 08:11:17 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::714]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D591A19EC for ; Tue, 30 Sep 2014 08:11:15 -0700 (PDT) Received: from DB4PR03MB623.eurprd03.prod.outlook.com (10.141.235.14) by DB4PR03MB624.eurprd03.prod.outlook.com (10.141.235.155) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 30 Sep 2014 15:10:51 +0000 Received: from DB4PR03MB623.eurprd03.prod.outlook.com ([10.141.235.14]) by DB4PR03MB623.eurprd03.prod.outlook.com ([10.141.235.14]) with mapi id 15.00.1034.003; Tue, 30 Sep 2014 15:10:51 +0000 From: Alexander Vainshtein To: Lizhong Jin Thread-Topic: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Thread-Index: AQHP3L67z1/MOvhA8Eieh8kPX13dR5wZxDgA Date: Tue, 30 Sep 2014 15:10:51 +0000 Message-ID: <0e0f49f9aeb7488c856e2d98bb261da3@DB4PR03MB623.eurprd03.prod.outlook.com> References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com>, <5419AFA0.4050609@pi.nu> <2014093022552988855513@gmail.com> In-Reply-To: <2014093022552988855513@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR03MB624; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(13464003)(377424004)(164054003)(199003)(189002)(377454003)(15202345003)(76576001)(85852003)(101416001)(230783001)(19580405001)(15975445006)(106116001)(19580395003)(19617315012)(54356999)(120916001)(95666004)(105586002)(80022003)(76482002)(66066001)(19609705001)(19300405004)(10300001)(76176999)(19625215002)(74316001)(85306004)(50986999)(110136001)(87936001)(31966008)(108616004)(97736003)(21056001)(33646002)(86362001)(107046002)(106356001)(46102003)(92566001)(64706001)(4396001)(16236675004)(2656002)(20776003)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB624; H:DB4PR03MB623.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0e0f49f9aeb7488c856e2d98bb261da3DB4PR03MB623eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cbFrbyvyJb8N8CwpII1nzrhMLU0 Cc: mpls , draft-raza-mpls-oam-ipv6-rao , mpls-chairs Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 30 Sep 2014 15:11:22 -0000 --_000_0e0f49f9aeb7488c856e2d98bb261da3DB4PR03MB623eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong Jin hi, Regarding your comment on the option value name (I assume that this is what= you have in mind, if ): Please notice that in the case of IPv4, the (intended) name of the option i= s "Router shall examine the packet". This is vague enough IMO to cover multiple protocols. All the rest of speci= fic values deal with nested reservations. So, I'd say that the IPv6 Router Alert Option value name that says "MPLS OA= M" sounds good enough, especially since the draft explicitly claims (in the= Introduction) that this value is applicable to all MPLS OAM protocols. My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Tuesday, September 30, 2014 5:56 PM To: loa; eric.osborne; pranjal.dutta; eric.gray; mpls-chairs; martin.vigour= eux Cc: mpls; draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-= rao-01.txt Hi Loa, authors, I review this document. It is a short document, and is usefull and technica= lly sound. And I believe it is ready for adoption. One small comment is the name of the option value. MPLS OAM is a general te= rm, not a special protocol. Currently IPv6 RAO is only defined for special = protocol. My concern is, it seems all kinds of future MPLS OAM protocols ar= e required to use the option value defined in this draft, which may not be = a good choice for them. ________________________________ Regards Lizhong Jin From: Loa Andersson Date: 2014-09-17 23:58 To: Osborne, Eric; Lizhong Jin; Dutta, Pranjal K (Pranjal); Eric Gray; mpls-chairs@tools.ietf= .org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Eric, Lizhong, Pranjal and Eric, You have be selected as MPLS-RT reviewers for draft-raza-mpls- oam-ipv6-rao. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by Oct 1, 2014? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Date: Wed, 17 Sep 2014 06:53:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org 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 : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-01.txt Pages : 5 Date : 2014-09-17 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam-ipv6-rao-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_0e0f49f9aeb7488c856e2d98bb261da3DB4PR03MB623eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong Jin hi,

Regarding your comment on= the option value name (I assume that this is what you have in mind, if )= :

Please notice that in the= case of IPv4, the (intended) name of the option is “Router shall exa= mine the packet”.

This is vague enough IMO = to cover multiple protocols. All the rest of specific values deal with nest= ed reservations.

So, I’d say that th= e IPv6 Router Alert Option value name that says “MPLS OAM”= sounds good enough, especially since the draft explicitly claims (in the I= ntroduction) that this value is applicable to all MPLS OAM protocols.<= /o:p>

 <= /p>

My 2c,<= /p>

    &= nbsp;  Sasha

Email: Alexander.Vainshte= in@ecitele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Tuesday, September 30, 2014 5:56 PM
To: loa; eric.osborne; pranjal.dutta; eric.gray; mpls-chairs; martin= .vigoureux
Cc: mpls; draft-raza-mpls-oam-ipv6-rao
Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oa= m-ipv6-rao-01.txt

 

Hi Loa, authors,<= /p>

I review this document. It is a sho= rt document, and is usefull and techn= ically sound. And I believe it is ready for adoption.

One small comment is the name of th= e option value. MPLS OAM is a general= term, not a special protocol. Currently IPv6 RAO is only defined for special protocol. My concern is, it seems all kinds of future MPLS OAM= protocols are required to use the option value defined in this draft, whic= h may not be a good choice for them.

 

Regards

Lizhong Jin

 

From: Loa Andersson

Date: 2014-09-17 23:58<= /o:p>

Subject: MPLS-RT review of I-D Ac= tion: draft-raza-mpls-oam-ipv6-rao-01.txt

Eric, Lizhong, Pranjal and Eric,

 

You have be selected as MPLS-RT rev= iewers for draft-raza-mpls-

oam-ipv6-rao.

 

Note to authors: You have been CC'd= on this email so that you can know

that this review is going on. Howev= er, please do not review your own

document.

 

Reviews should comment on whether t= he document is coherent, is it

useful (ie, is it likely to be actu= ally useful in operational

networks), and is the document tech= nically sound?  We are interested

in knowing whether the document is = ready to be considered for WG

adoption (ie, it doesn't have to be= perfect at this point, but should be

a good start).

 

Reviews should be sent to the docum= ent authors, WG co-chairs and

WG secretary, and CC'd to the MPLS = WG email list. If necessary, comments

may be sent privately to only the W= G chairs.

 

If you have technical comments you = should try to be explicit about what

*really* need to be resolved before= adopting it as a working group

document, and what can wait until t= he document is a working group

document and the working group has = the revision control.

 

Are you able to review this draft b= y Oct 1, 2014? Please respond in a

timely fashion.

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

-------- Original Message --------<= o:p>

Subject: I-D Action: draft-raza-mpl= s-oam-ipv6-rao-01.txt

Date: Wed, 17 Sep 2014 06:53:44 -07= 00

 

 

A New Internet-Draft is available f= rom the on-line Internet-Drafts

directories.

  This draft is a work item of= the Multiprotocol Label Switching Working

Group of the IETF.

 

      = ;   Title         &n= bsp; : IPv6 Router Alert Option for MPLS OAM

      = ;   Authors         : Kam= ran Raza

      = ;            &n= bsp;        Nobo Akiya=

      = ;            &n= bsp;        Carlos Pignataro<= /span>

Filename    &nb= sp;   : draft-raza-mpls-oam-ipv6-rao-01.txt

Pages     =       : 5

Date     &= nbsp;      : 2014-09-17

 

Abstract:

    RFC4379 defines = the MPLS LSP Ping/Traceroute mechanism, in which the

    Router Alert opt= ion must be set in the IP header of the MPLS Echo

    Request messages= , and may conditionally be set in the IP header of

    the MPLS Echo Re= ply messages.  While a generic "Router shall examine

    packet" Opt= ion Value is used for the IPv4 Router Alert Option (RAO),=

    there is no gene= ric Router Alert Option Value defined for IPv6 that

    can be used.&nbs= p; This document allocates a new generic IPv6 Router Alert

    Option Value tha= t can be used by MPLS OAM tools, including the MPLS

    Echo Request and= MPLS Echo Reply messages for MPLS IPv6.

 

    The initial moti= vation to request an IPv6 Router Alert Option (RAO)

    code point for M= PLS OAM comes from MPLS LSP Ping/Traceroute.

    However, this co= depoint is applicable to all MPLS OAM and not limited

    to MPLS LSP Ping= /Traceroute.

 

 

The IETF datatracker status page fo= r this draft is:

 

There's also a htmlized version ava= ilable at:

 

A diff from the previous version is= available at:

 

 

Please note that it may take a coup= le 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:

 

___________________________________= ____________

I-D-Announce mailing list

Internet-Draft directories: http://www.ietf.org/shadow.html=

 

 

--_000_0e0f49f9aeb7488c856e2d98bb261da3DB4PR03MB623eurprd03pro_-- From nobody Tue Sep 30 08:20: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 3A9D11A1A5A for ; Tue, 30 Sep 2014 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mx6pUMyjliVe for ; Tue, 30 Sep 2014 08:19:56 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E1C1A1A60 for ; Tue, 30 Sep 2014 08:19:47 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d4-542a7125b622 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.5D.25146.5217A245; Tue, 30 Sep 2014 11:00:21 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 30 Sep 2014 11:19:45 -0400 From: Gregory Mirsky To: Ross Callon , "mpls@ietf.org" , "draft-chen-mpls-source-label@tools.ietf.org" Thread-Topic: IPR poll for draft-chen-mpls-source-label Thread-Index: AQHP2a60FyqJgb73LUWTG9eWVk7/XpwV90VQ Date: Tue, 30 Sep 2014 15:19:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85414B@eusaamb103.ericsson.se> References: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <7f250327283a4c7eb9946c6179dd6525@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B85414Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLrHT1e1UCvEYN5WRYs5WyeyWHy/tITF 4tbSlawWf1dcYXFg8Viy5CeTx/Wmq+weXy5/ZgtgjuKySUnNySxLLdK3S+DK6Dy5iqXgcVzF pTc/WRoYH4V0MXJySAiYSGy93cMCYYtJXLi3nq2LkYtDSOAoo8TjC/PYIZzljBLrnq0Aq2IT MJJ4sbEHLCECkvhw7BMbSIJZwFbizpNrjF2MHBzCAmYS36Y5gYRFBMwlTu/YBhYWAeqdudIP JMwioCrxfctWsJG8Ar4Sf3Y0MoHYQgKhEk+mzgCzOQXCJJ5vX88MYjMCHff91BomiE3iEree zGeCOFpAYsme88wQtqjEy8f/WCFsJYk5r68xQ9TnS7x8eRtql6DEyZlPWCYwis5CMmoWkrJZ SMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I8NNjMCYOybB5riDccEn y0OMAhyMSjy8Cdc0Q4RYE8uKK3MPMUpzsCiJ82pWzwsWEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwGjqtriq9PgxCa7vPgH7QsKyXPMW3WWdfFrtrfLkCZXms1zP8+e6NwueOPG0qPwNw+Qd Nyyeae5xWDazzO3I5RkM0z/Jv49pK0xf/VDzz/pC3WfsC83PZk3iLbXNTLgy+5ua7+XpmmuW ZkwVtfe6vO8c55fJy9RfXchf/cBpneDW9dPOPFlROqdAiaU4I9FQi7moOBEArgg9EZoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AuayA-SqmEFHdKMM9CapQUnL25E Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label 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, 30 Sep 2014 15:19:59 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B85414Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR that this document is based on. Regards, Greg From: Ross Callon [mailto:rcallon@juniper.net] Sent: Friday, September 26, 2014 10:24 AM To: mpls@ietf.org; draft-chen-mpls-source-label@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: IPR poll for draft-chen-mpls-source-label Working Group, The authors of draft-chen-mpls-source-label have told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the poll to see if we have consensus to make this a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-chen-mpls-source-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). 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 documents will not advance to the next stage until a response has been received from each author and each 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, Ross (as MPLS WG co-chair) --_000_7347100B5761DC41A166AC17F22DF1121B85414Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not aware of an= y IPR that this document is based on.

 <= /p>

    &= nbsp;           Regards,<= o:p>

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

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Friday, September 26, 2014 10:24 AM
To: mpls@ietf.org; draft-chen-mpls-source-label@tools.ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: IPR poll for draft-chen-mpls-source-label=

 

Working Group,

 

The authors of draft-chen-mpls-source-l= abel have told the

working group chairs that the draft is = ready to be adopted as a working

group document.

 

Before starting the poll to see if we h= ave consensus to make this a

working group document we need to do an= IPR poll.

 

This mail starts that IPR poll.

 

Are you aware of any IPR that applies t= o

draft-chen-mpls-source-label?

 

If so, has this IPR been disclosed in c= ompliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for= more details).

 

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 t= he MPLS wg mailing list. The

documents will not advance to the next = stage until a response

has been received from each author and = each contributor.

 

If you are on the MPLS WG email list bu= t are not listed as an author or

contributor, then please explicitly res= pond only if you are aware of any

IPR that has not yet been disclosed in = conformance with IETF rules.

 

Thanks, Ross

(as MPLS WG co-chair)=

 

--_000_7347100B5761DC41A166AC17F22DF1121B85414Beusaamb103erics_-- From nobody Tue Sep 30 08:22: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 9E38C1A1A54 for ; Tue, 30 Sep 2014 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 oSBTyfl_M8tw for ; Tue, 30 Sep 2014 08:22:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A45B1A1A5D for ; Tue, 30 Sep 2014 08:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39179; q=dns/txt; s=iport; t=1412090558; x=1413300158; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wBO4k8OwKmQCJ/AUG+kBSFflvRa0Z16H6yzYKkuhMrg=; b=hxsfpKyze1reIFDEyweOXs4ioyrT9QC5rhafNXjpgFgjWgi2ckXM1R75 SqCqnt1PIaL10x7+tvMaASbZcmgJrR3TNCLsmBqLKpVIgiwMlHu3srJ/k sU+Hb0Y+vNKHDTneZw3LeSLW+EtPvuqGuTVYDfSm9DNkeLu28yEruM+Vt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAHjJKlStJV2Z/2dsb2JhbABggkhGU1MEBIVewlmBYwEJh00CgQoWAXuEAwEBAQQBAQEqQQsMBAIBCBEDAQEBIQEGByEGCxQJCAIEAQ0FCYghAxEIBbgFDYceAReNboFOCgcBJQcSAQ0EBgEGA4IuU4FBBY4NgUOCGoQ7hDlBghCBOyqNPwOGSYNjbAGBBQkXIoECAQEB X-IronPort-AV: E=Sophos;i="5.04,627,1406592000"; d="scan'208,217";a="359523071" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 30 Sep 2014 15:22:37 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8UFMZPC011058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 15:22:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 10:22:35 -0500 From: "Kamran Raza (skraza)" To: Alexander Vainshtein , Lizhong Jin Thread-Topic: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Thread-Index: AQHP3MDTLjergRbt6EuA5i1Vf9E2DpwZ2/kA Date: Tue, 30 Sep 2014 15:22:34 +0000 Message-ID: References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com> <5419AFA0.4050609@pi.nu> <2014093022552988855513@gmail.com> <0e0f49f9aeb7488c856e2d98bb261da3@DB4PR03MB623.eurprd03.prod.outlook.com> In-Reply-To: <0e0f49f9aeb7488c856e2d98bb261da3@DB4PR03MB623.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [161.44.212.198] Content-Type: multipart/alternative; boundary="_000_D050427FE45Eskrazaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CPfiVXH8JlxRNOqaySecVuq4XE4 Cc: mpls , mpls-chairs , draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 30 Sep 2014 15:22:40 -0000 --_000_D050427FE45Eskrazaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, thanks Sasha. That=92s exactly what authors had noted and that led to = the current definition of =93MPLS OAM=94 which is not as generic as IPv4 an= d not very specific/limited to leave room open for others to reuse it, if t= hey will. Thx - Kamran (As a co-author) From: Alexander Vainshtein > Date: Tuesday, September 30, 2014 at 11:10 AM To: Lizhong Jin > Cc: mpls >, draft-raza-mpls-oam-ipv6-ra= o >, mpls-chairs > Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-= rao-01.txt Lizhong Jin hi, Regarding your comment on the option value name (I assume that this is what= you have in mind, if ): Please notice that in the case of IPv4, the (intended) name of the option i= s =93Router shall examine the packet=94. This is vague enough IMO to cover multiple protocols. All the rest of speci= fic values deal with nested reservations. So, I=92d say that the IPv6 Router Alert Option value name that says =93MPL= S OAM=94 sounds good enough, especially since the draft explicitly claims (= in the Introduction) that this value is applicable to all MPLS OAM protocol= s. My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Tuesday, September 30, 2014 5:56 PM To: loa; eric.osborne; pranjal.dutta; eric.gray; mpls-chairs; martin.vigour= eux Cc: mpls; draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-= rao-01.txt Hi Loa, authors, I review this document. It is a short document, and is usefull and technica= lly sound. And I believe it is ready for adoption. One small comment is the name of the option value. MPLS OAM is a general te= rm, not a special protocol. Currently IPv6 RAO is only defined for special = protocol. My concern is, it seems all kinds of future MPLS OAM protocols ar= e required to use the option value defined in this draft, which may not be = a good choice for them. ________________________________ Regards Lizhong Jin From: Loa Andersson Date: 2014-09-17 23:58 To: Osborne, Eric; Lizhong Jin; Dutta, Pranjal K (Pranjal); Eric Gray; mpls-chairs@tools.ietf= .org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Eric, Lizhong, Pranjal and Eric, You have be selected as MPLS-RT reviewers for draft-raza-mpls- oam-ipv6-rao. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by Oct 1, 2014? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) -------- Original Message -------- Subject: I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt Date: Wed, 17 Sep 2014 06:53:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org 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 : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-01.txt Pages : 5 Date : 2014-09-17 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-raza-mpls-oam-ipv6-rao-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D050427FE45Eskrazaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <670E91D30C31B842982EC16D818417AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Yes, thanks Sasha. That=92s exactly what authors had noted and that le= d to the current definition of =93MPLS OAM=94 which is not as generic as IP= v4 and not very specific/limited to leave room open for others to reuse it,= if they will.

Thx
-
Kamran
(As a co-author)

From: Alexander Vainshtein <Alexander.Vainshtein@ecitel= e.com>
Date: Tuesday, September 30, 2014 a= t 11:10 AM
To: Lizhong Jin <lizho.jin@gmail.com>
Cc: mpls <mpls@ietf.org>, draft-raza-mpls-oam-ipv6-rao <draft-raza-mpls-oam= -ipv6-rao@tools.ietf.org>, mpls-chairs <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] MPLS-RT review = of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt

Lizhong Jin hi,

Regarding your comment on the option value name (I assume that this is what you have in mind, if )= :

Please notice that in the case of I= Pv4, the (intended) name of the option is =93Router shall examine the packe= t=94.

This is vague enough IMO to cover m= ultiple protocols. All the rest of specific values deal with nested reserva= tions.

So, I=92d say that the IPv6 Router Alert Option value name that says =93MPLS OAM=94 sounds = good enough, especially since the draft explicitly claims (in the Introduct= ion) that this value is applicable to all MPLS OAM protocols.

 

My 2c,

      = ; Sasha

Email: Alexander.Vainshtein@ec= itele.com

Mobile: 054-9266302

 

From: mpls [mai= lto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Tuesday, September 30, 2014 5:56 PM
To: loa; eric.osborne; pranjal.dutta; eric.gray; mpls-chairs; martin= .vigoureux
Cc: mpls; draft-raza-mpls-oam-ipv6-rao
Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oa= m-ipv6-rao-01.txt

 

Hi Loa, authors,<= /p>

I review this document. It is a sho= rt document, and is usefull and techn= ically sound. And I believe it is ready for adoption.

One small comment is the name of th= e option value. MPLS OAM is a general= term, not a special protocol. Currently IPv6 RAO is only defined for special protocol. My concern is, it seems all kinds of future MPLS OAM= protocols are required to use the option value defined in this draft, whic= h may not be a good choice for them.

 

Regards

Lizhong Jin

 

From:=  Loa Andersson<= /p>

Date:=  2014-09-17 23:58

Subject:<= /b> MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.= txt

Eric, Lizhong, Pranjal and Eric,

 

You have be selected as MPLS-RT rev= iewers for draft-raza-mpls-

oam-ipv6-rao.

 

Note to authors: You have been CC'd= on this email so that you can know

that this review is going on. Howev= er, please do not review your own

document.

 

Reviews should comment on whether t= he document is coherent, is it

useful (ie, is it likely to be actu= ally useful in operational

networks), and is the document tech= nically sound?  We are interested

in knowing whether the document is = ready to be considered for WG

adoption (ie, it doesn't have to be= perfect at this point, but should be

a good start).

 

Reviews should be sent to the docum= ent authors, WG co-chairs and

WG secretary, and CC'd to the MPLS = WG email list. If necessary, comments

may be sent privately to only the W= G chairs.

 

If you have technical comments you = should try to be explicit about what

*really* need to be resolved before= adopting it as a working group

document, and what can wait until t= he document is a working group

document and the working group has = the revision control.

 

Are you able to review this draft b= y Oct 1, 2014? Please respond in a

timely fashion.

 

 

Thanks, Loa

(as MPLS WG chair)

 

 

-------- Original Message --------<= o:p>

Subject: I-D Action: draft-raza-mpl= s-oam-ipv6-rao-01.txt

Date: Wed, 17 Sep 2014 06:53:44 -07= 00

 

 

A New Internet-Draft is available f= rom the on-line Internet-Drafts

directories.

  This draft is a work item of= the Multiprotocol Label Switching Working

Group of the IETF.

 

      = ;   Title         &n= bsp; : IPv6 Router Alert Option for MPLS OAM

      = ;   Authors         : Kam= ran Raza

      = ;            &n= bsp;        Nobo Akiya=

      = ;            &n= bsp;        Carlos Pignataro<= /span>

Filename    &nb= sp;   : draft-raza-mpls-oam-ipv6-rao-01.txt

Pages     =       : 5

Date     &= nbsp;      : 2014-09-17

 

Abstract:

    RFC4379 defines = the MPLS LSP Ping/Traceroute mechanism, in which the

    Router Alert opt= ion must be set in the IP header of the MPLS Echo

    Request messages= , and may conditionally be set in the IP header of

    the MPLS Echo Re= ply messages.  While a generic "Router shall examine

    packet" Opt= ion Value is used for the IPv4 Router Alert Option (RAO),=

    there is no gene= ric Router Alert Option Value defined for IPv6 that

    can be used.&nbs= p; This document allocates a new generic IPv6 Router Alert

    Option Value tha= t can be used by MPLS OAM tools, including the MPLS

    Echo Request and= MPLS Echo Reply messages for MPLS IPv6.

 

    The initial moti= vation to request an IPv6 Router Alert Option (RAO)

    code point for M= PLS OAM comes from MPLS LSP Ping/Traceroute.

    However, this co= depoint is applicable to all MPLS OAM and not limited

    to MPLS LSP Ping= /Traceroute.

 

 

The IETF datatracker status page fo= r this draft is:

 

There's also a htmlized version ava= ilable at:

 

A diff from the previous version is= available at:

 

 

Please note that it may take a coup= le 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:

 

___________________________________= ____________

I-D-Announce mailing list

Internet-Draft directories: http://www.ietf.org/shadow.html=

 

 

 --_000_D050427FE45Eskrazaciscocom_-- From nobody Tue Sep 30 09:13: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 45EB21A1A62 for ; Tue, 30 Sep 2014 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 9wM_Ynodhfug for ; Tue, 30 Sep 2014 09:13:35 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96421A1A6C for ; Tue, 30 Sep 2014 09:13:35 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id fp1so6369906pdb.35 for ; Tue, 30 Sep 2014 09:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=KhTGle/eDpCsVDrHuTRpq+I+VWavInb5KzgYfPy69Y8=; b=IyV2TTQz46L+vw/E+RoHtJ1Hna8q6o1oNkUlxAr1DUC47h2zWaoXhsDCk3IcD6TfIH Tx2YivqwA/yxDOYjr3dLnDkpPzI6ues6Htm5sKqjKXHXr9duEPBZROn830d2QR+flkDU 1WUb1tLtqKI6C7qiq3Y5sUMXd5xx0NXVWfPLdqdajzfxkZ7YnmSuZlIHVCylPMxfIDiV X1wRTfPxyWbivuaGwiHXQXDuR6iu0kY8CyTd7WpWR9Ut+v574cNgfty4Pqvj0Zsc2shy 9AvL4iYpF4R9ZJa2kTNTg03P7zpSurul6bH9LJqyASJNrcyRkZ0MerhvJ13ffKb9t9QN dB/Q== X-Received: by 10.68.231.38 with SMTP id td6mr13378175pbc.131.1412093615239; Tue, 30 Sep 2014 09:13:35 -0700 (PDT) Received: from Lizhong-PC ([114.62.198.108]) by mx.google.com with ESMTPSA id ei1sm15538811pbd.46.2014.09.30.09.13.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Sep 2014 09:13:33 -0700 (PDT) Date: Wed, 1 Oct 2014 00:13:25 +0800 From: "Lizhong Jin" To: "Carlos Pignataro (cpignata)" , loa , eric.osborne , pranjal.dutta , eric.gray , mpls-chairs , martin.vigoureux References: <20140917135344.32751.18666.idtracker@ietfa.amsl.com>, <5419AFA0.4050609@pi.nu>, <2014093022552988855513@gmail.com>, X-Priority: 3 X-GUID: E0C093AC-8C1F-4037-8C45-D68D246F97B7 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201410010013203831052@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart353368331428_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wrhoOgHJf3aMz6oiUslSlOTdAO4 Cc: mpls , draft-raza-mpls-oam-ipv6-rao Subject: Re: [mpls] MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.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, 30 Sep 2014 16:13:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart353368331428_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 T0ssIHNpbmNlIGl0IGlzIHZlcnkgbG9vc2UsIGxlYXZlIGl0IGFzIGl0IGlzLg0KDQoNCg0KUmVn YXJkcw0KTGl6aG9uZyBKaW4NCiANCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0K RGF0ZTogMjAxNC0wOS0zMCAyMjo1OQ0KVG86IExpemhvbmcgSmluOyBsb2E7IGVyaWMub3Nib3Ju ZTsgcHJhbmphbC5kdXR0YTsgZXJpYy5ncmF5OyBtcGxzLWNoYWlyczsgbWFydGluLnZpZ291cmV1 eA0KQ0M6IGRyYWZ0LXJhemEtbXBscy1vYW0taXB2Ni1yYW87IG1wbHMNClN1YmplY3Q6IFJlOiBN UExTLVJUIHJldmlldyBvZiBJLUQgQWN0aW9uOiBkcmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFv LTAxLnR4dA0KVGhhbmtzLCBMaXpob25nIQ0KDQpGdXR1cmUgTVBMUyBPQU0gcHJvdG9jb2xzIGFy ZSBub3QgcmVxdWlyZWQgdG8gdXNlIHRoaXMgUkFPIHZhbHVlLCBidXQgdGhpcyBpcyBhdmFpbGFi bGUgZm9yIHRoZW0gdG8gdXNlLg0KDQpUaGUgdGV4dCBjdXJyZW50bHkgc2F5czoNCiAgIFRoZSBp bml0aWFsIG1vdGl2YXRpb24gdG8gcmVxdWVzdCBhbiBJUHY2IFJvdXRlciBBbGVydCBPcHRpb24g KFJBTykKICAgY29kZSBwb2ludCBmb3IgTVBMUyBPQU0gY29tZXMgZnJvbSBNUExTIExTUCBQaW5n L1RyYWNlcm91dGUuCiAgIEhvd2V2ZXIsIHRoaXMgY29kZXBvaW50IGlzIGFwcGxpY2FibGUgdG8g YWxsIE1QTFMgT0FNIGFuZCBub3QgbGltaXRlZAogICB0byBNUExTIExTUCBQaW5nL1RyYWNlcm91 dGUuDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KRnJvbTogTGl6aG9uZyBKaW4gPGxpemhvLmppbkBn bWFpbC5jb20+DQpEYXRlOiBUdWVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTQgYXQgMTA6NTUgQU0N ClRvOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+LCAiZXJpYy5vc2Jvcm5lIiA8ZXJpYy5vc2Jv cm5lQGxldmVsMy5jb20+LCAicHJhbmphbC5kdXR0YSIgPHByYW5qYWwuZHV0dGFAYWxjYXRlbC1s dWNlbnQuY29tPiwgImVyaWMuZ3JheSIgPGVyaWMuZ3JheUBlcmljc3Nvbi5jb20+LCBtcGxzLWNo YWlycyA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBNYXJ0aW4gVmlnb3VyZXV4IDxtYXJ0 aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbT4NCkNjOiBkcmFmdC1yYXphLW1wbHMtb2Ft LWlwdjYtcmFvIDxkcmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvQHRvb2xzLmlldGYub3JnPiwg bXBscyA8bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBNUExTLVJUIHJldmlldyBvZiBJLUQg QWN0aW9uOiBkcmFmdC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLTAxLnR4dA0KUmVzZW50LUZyb206 IDxkcmFmdC1hbGlhcy1ib3VuY2VzQHRvb2xzLmlldGYub3JnPg0KUmVzZW50LVRvOiBDYXJsb3Mg UGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+LCBOb2JvIEFraXlhIDxub2JvQGNpc2NvLmNv bT4sIDxza3JhemFAY2lzY28uY29tPiwgPHN3YWxsb3dAY2lzY28uY29tPiwgTG9hIEFuZGVyc3Nv biA8bG9hQHBpLm51PiwgUm9zcyBDYWxsb24gPHJjYWxsb25AanVuaXBlci5uZXQ+LCBNYXJ0aW4g Vmlnb3VyZXV4IDxtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbT4NClJlc2VudC1E YXRlOiBUdWVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTQgYXQgMTA6NTYgQU0NCg0KSGkgTG9hLCBh dXRob3JzLA0KSSByZXZpZXcgdGhpcyBkb2N1bWVudC4gSXQgaXMgYSBzaG9ydCBkb2N1bWVudCwg YW5kIGlzIHVzZWZ1bGwgYW5kIHRlY2huaWNhbGx5IHNvdW5kLiBBbmQgSSBiZWxpZXZlIGl0IGlz IHJlYWR5IGZvciBhZG9wdGlvbi4NCk9uZSBzbWFsbCBjb21tZW50IGlzIHRoZSBuYW1lIG9mIHRo ZSBvcHRpb24gdmFsdWUuIE1QTFMgT0FNIGlzIGEgZ2VuZXJhbCB0ZXJtLCBub3QgYSBzcGVjaWFs IHByb3RvY29sLiBDdXJyZW50bHkgSVB2NiBSQU8gaXMgb25seSBkZWZpbmVkIGZvciBzcGVjaWFs IHByb3RvY29sLiBNeSBjb25jZXJuIGlzLCBpdCBzZWVtcyBhbGwga2luZHMgb2YgZnV0dXJlIE1Q TFMgT0FNIHByb3RvY29scyBhcmUgcmVxdWlyZWQgdG8gdXNlIHRoZSBvcHRpb24gdmFsdWUgZGVm aW5lZCBpbiB0aGlzIGRyYWZ0LCB3aGljaCBtYXkgbm90IGJlIGEgZ29vZCBjaG9pY2UgZm9yIHRo ZW0uDQoNCg0KDQpSZWdhcmRzDQpMaXpob25nIEppbg0KIA0KRnJvbTogTG9hIEFuZGVyc3Nvbg0K RGF0ZTogMjAxNC0wOS0xNyAyMzo1OA0KVG86IE9zYm9ybmUsIEVyaWM7IExpemhvbmcgSmluOyBE dXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsgRXJpYyBHcmF5OyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikNClN1YmplY3Q6IE1QTFMtUlQgcmV2 aWV3IG9mIEktRCBBY3Rpb246IGRyYWZ0LXJhemEtbXBscy1vYW0taXB2Ni1yYW8tMDEudHh0DQpF cmljLCBMaXpob25nLCBQcmFuamFsIGFuZCBFcmljLA0KIA0KWW91IGhhdmUgYmUgc2VsZWN0ZWQg YXMgTVBMUy1SVCByZXZpZXdlcnMgZm9yIGRyYWZ0LXJhemEtbXBscy0NCm9hbS1pcHY2LXJhby4N CiANCk5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1haWwgc28g dGhhdCB5b3UgY2FuIGtub3cNCnRoYXQgdGhpcyByZXZpZXcgaXMgZ29pbmcgb24uIEhvd2V2ZXIs IHBsZWFzZSBkbyBub3QgcmV2aWV3IHlvdXIgb3duDQpkb2N1bWVudC4NCiANClJldmlld3Mgc2hv dWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQp1 c2VmdWwgKGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlv bmFsDQpuZXR3b3JrcyksIGFuZCBpcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICBX ZSBhcmUgaW50ZXJlc3RlZA0KaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFk eSB0byBiZSBjb25zaWRlcmVkIGZvciBXRw0KYWRvcHRpb24gKGllLCBpdCBkb2Vzbid0IGhhdmUg dG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQphIGdvb2Qgc3RhcnQp Lg0KIA0KUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycywgV0cg Y28tY2hhaXJzIGFuZA0KV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBlbWFp bCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQptYXkgYmUgc2VudCBwcml2YXRlbHkgdG8g b25seSB0aGUgV0cgY2hhaXJzLg0KIA0KSWYgeW91IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIHlv dSBzaG91bGQgdHJ5IHRvIGJlIGV4cGxpY2l0IGFib3V0IHdoYXQNCipyZWFsbHkqIG5lZWQgdG8g YmUgcmVzb2x2ZWQgYmVmb3JlIGFkb3B0aW5nIGl0IGFzIGEgd29ya2luZyBncm91cA0KZG9jdW1l bnQsIGFuZCB3aGF0IGNhbiB3YWl0IHVudGlsIHRoZSBkb2N1bWVudCBpcyBhIHdvcmtpbmcgZ3Jv dXANCmRvY3VtZW50IGFuZCB0aGUgd29ya2luZyBncm91cCBoYXMgdGhlIHJldmlzaW9uIGNvbnRy b2wuDQogDQpBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQgYnkgT2N0IDEsIDIwMTQ/ IFBsZWFzZSByZXNwb25kIGluIGENCnRpbWVseSBmYXNoaW9uLiANCiANCiANClRoYW5rcywgTG9h DQooYXMgTVBMUyBXRyBjaGFpcikNCiANCiANCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0tLS0NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LXJhemEtbXBscy1vYW0taXB2Ni1yYW8t MDEudHh0DQpEYXRlOiBXZWQsIDE3IFNlcCAyMDE0IDA2OjUzOjQ0IC0wNzAwDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNClJlcGx5LVRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN ClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNDOiBtcGxzQGlldGYub3JnDQogDQogDQpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgDQpkaXJlY3Rvcmllcy4NCiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg TXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV29ya2luZyANCkdyb3VwIG9mIHRoZSBJRVRG Lg0KIA0KICAgICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBSb3V0ZXIgQWxlcnQgT3B0aW9u IGZvciBNUExTIE9BTQ0KICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2FtcmFuIFJhemENCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5vYm8gQWtpeWENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgIENhcmxvcyBQaWduYXRhcm8NCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXJhemEtbXBs cy1vYW0taXB2Ni1yYW8tMDEudHh0DQpQYWdlcyAgICAgICAgICAgOiA1DQpEYXRlICAgICAgICAg ICAgOiAyMDE0LTA5LTE3DQogDQpBYnN0cmFjdDoNCiAgICBSRkM0Mzc5IGRlZmluZXMgdGhlIE1Q TFMgTFNQIFBpbmcvVHJhY2Vyb3V0ZSBtZWNoYW5pc20sIGluIHdoaWNoIHRoZQ0KICAgIFJvdXRl ciBBbGVydCBvcHRpb24gbXVzdCBiZSBzZXQgaW4gdGhlIElQIGhlYWRlciBvZiB0aGUgTVBMUyBF Y2hvDQogICAgUmVxdWVzdCBtZXNzYWdlcywgYW5kIG1heSBjb25kaXRpb25hbGx5IGJlIHNldCBp biB0aGUgSVAgaGVhZGVyIG9mDQogICAgdGhlIE1QTFMgRWNobyBSZXBseSBtZXNzYWdlcy4gIFdo aWxlIGEgZ2VuZXJpYyAiUm91dGVyIHNoYWxsIGV4YW1pbmUNCiAgICBwYWNrZXQiIE9wdGlvbiBW YWx1ZSBpcyB1c2VkIGZvciB0aGUgSVB2NCBSb3V0ZXIgQWxlcnQgT3B0aW9uIChSQU8pLA0KICAg IHRoZXJlIGlzIG5vIGdlbmVyaWMgUm91dGVyIEFsZXJ0IE9wdGlvbiBWYWx1ZSBkZWZpbmVkIGZv ciBJUHY2IHRoYXQNCiAgICBjYW4gYmUgdXNlZC4gIFRoaXMgZG9jdW1lbnQgYWxsb2NhdGVzIGEg bmV3IGdlbmVyaWMgSVB2NiBSb3V0ZXIgQWxlcnQNCiAgICBPcHRpb24gVmFsdWUgdGhhdCBjYW4g YmUgdXNlZCBieSBNUExTIE9BTSB0b29scywgaW5jbHVkaW5nIHRoZSBNUExTDQogICAgRWNobyBS ZXF1ZXN0IGFuZCBNUExTIEVjaG8gUmVwbHkgbWVzc2FnZXMgZm9yIE1QTFMgSVB2Ni4NCiANCiAg ICBUaGUgaW5pdGlhbCBtb3RpdmF0aW9uIHRvIHJlcXVlc3QgYW4gSVB2NiBSb3V0ZXIgQWxlcnQg T3B0aW9uIChSQU8pDQogICAgY29kZSBwb2ludCBmb3IgTVBMUyBPQU0gY29tZXMgZnJvbSBNUExT IExTUCBQaW5nL1RyYWNlcm91dGUuDQogICAgSG93ZXZlciwgdGhpcyBjb2RlcG9pbnQgaXMgYXBw bGljYWJsZSB0byBhbGwgTVBMUyBPQU0gYW5kIG5vdCBsaW1pdGVkDQogICAgdG8gTVBMUyBMU1Ag UGluZy9UcmFjZXJvdXRlLg0KIA0KIA0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLw0KIA0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVy c2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yYXph LW1wbHMtb2FtLWlwdjYtcmFvLTAxDQogDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1yYXphLW1wbHMtb2FtLWlwdjYtcmFvLTAxDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiANCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5ub3Vu Y2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0Kb3IgZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiANCiANCg== ------=_001_NextPart353368331428_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
OK, since it is very loose, l= eave it as it is.
=0A

=0A
Regards
Lizhong Jin
=0A
 
Date: 2014-09= -30 22:59
Subject: Re: MPL= S-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt
=0A
Thanks, Lizh= ong!
=0A

=0A
=0A
Future MPLS OAM protocols are not <= span style=3D"font-weight: bold;">required to use this RAO value,=0A but this is available for them to use.
=0A

=0A
=0A
The text currently says:
=0A=0A
   The initial motivation to request an IPv6 Router Alert Optio=
n (RAO)=0A   code point for MPLS OAM comes from MPLS LSP Ping/Traceroute.=
=0A   However, this codepoint is applicable to all MPLS OAM and not limite=
d=0A   to MPLS LSP Ping/Traceroute.
=0A
=0A
Thanks,
=0A=

=0A
=0A
Carlos.
=0A

=0A
=0A=0A
=0AFrom: Lizhong Jin <lizho.jin@gmail.com>
=0ADate: Tuesday, September 30, 2014 at 10:55= AM
=0ATo: Loa Andersson <loa@pi.nu>, "eric.osborne" <eric.osborne@level3.com>, "pran= jal.dutta" <pranjal= .dutta@alcatel-lucent.com>,=0A "eric.gray" <eric.gray@ericsson.com>, mpls-chairs <mpls-chairs@tools.ietf.org&g= t;, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
=0ACc: draft-raza-mpls-oam-ipv6-rao <draft-raza-mpls-oam-ipv6-r= ao@tools.ietf.org>, mpls <mpls@= ietf.org>
=0ASubject: Re= : MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt
=0A= Resent-From: <draft-alias-bounces@tools.ietf.org>
=0AResent-To: Carlos Pign= ataro <cpignata@cisco.com>= , Nobo Akiya <nobo@cisco.com>,= <skraza@cisco.com>, <swallow@cisco.com>,=0A Loa Anders= son <loa@pi.nu>, Ross Callon <rcallon@juniper.net>, Martin V= igoureux <martin= .vigoureux@alcatel-lucent.com>
=0AResent-Date: Tuesday, September 30, 2014 at 10:56 AM
=0A=0A

=0A
=0A
=0A
=0A
Hi Loa, authors= ,
=0A
I review this document. It is a short document, and is usef= ull and technically sound. And I=0A believe it is re= ady for adoption.
=0A
One small comment is the name of the= option value. MPLS OAM is a general term, not a special protoco= l. Currently IPv6 RAO is only defined for special protocol. My concern is,= =0A it seems all kinds of future MPLS OAM protocols are required to use th= e option value defined in this draft, which may not be a good choice for t= hem.
=0A

=0A
=0A
=0A
=0A
=0A
Rega= rds
=0A
Lizhong Jin
=0A
=0A
=0A
=0A 
=0A
=0A
=0A=0A
Date: = 2014-09-17 23:58
=0A=0A
Subject: = ;MPLS-RT review of I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt
= =0A
=0A
=0A
=0A
Eric, Lizhong, Pranjal and Eric,
= =0A
 
=0A
You have be selected as MPLS-RT reviewers for = draft-raza-mpls-
=0A
oam-ipv6-rao.
=0A
 
=0ANote to authors: You have been CC'd on this email so that you can know<= /div>=0A
that this review is going on. However, please do not review y= our own
=0A
document.
=0A
 
=0A
Reviews sh= ould comment on whether the document is coherent, is it
=0A
usefu= l (ie, is it likely to be actually useful in operational
=0A
netw= orks), and is the document technically sound?  We are interested=0A
in knowing whether the document is ready to be considered for WG<= /div>=0A
adoption (ie, it doesn't have to be perfect at this point, bu= t should be
=0A
a good start).
=0A
 
=0A
R= eviews should be sent to the document authors, WG co-chairs and
=0AWG secretary, and CC'd to the MPLS WG email list. If necessary, comment= s
=0A
may be sent privately to only the WG chairs.
=0A
&= nbsp;
=0A
If you have technical comments you should try to be exp= licit about what
=0A
*really* need to be resolved before adopting= it as a working group
=0A
document, and what can wait until the = document is a working group
=0A
document and the working group ha= s the revision control.
=0A
 
=0A
Are you able to r= eview this draft by Oct 1, 2014? Please respond in a
=0A
timely f= ashion.
=0A
 
=0A
 
=0A
Thanks, Loa<= /div>=0A
(as MPLS WG chair)
=0A
 
=0A
 =0A
-------- Original Message --------
=0A
Subject: I-D Ac= tion: draft-raza-mpls-oam-ipv6-rao-01.txt
=0A
Date: Wed, 17 Sep 2= 014 06:53:44 -0700
=0A=0A=0A= =0A=0A 
=0A
 
=0A
A New Internet-Draft is availabl= e from the on-line Internet-Drafts
=0A
directories.
=0A  This draft is a work item of the Multiprotocol Label Switching Wor= king
=0A
Group of the IETF.
=0A
 
=0A
&nb= sp;        Title    = ;       : IPv6 Router Alert Option for MPLS = OAM
=0A
         Authors&= nbsp;        : Kamran Raza
=0A            &= nbsp;           &nb= sp;  Nobo Akiya
=0A
      &nbs= p;            =         Carlos Pignataro
=0A
F= ilename        : draft-raza-mpls-oam-ip= v6-rao-01.txt
=0A
Pages       =     : 5
=0A
Date     &nbs= p;      : 2014-09-17
=0A
 
=0A=
Abstract:
=0A
    RFC4379 defines the MPLS LS= P Ping/Traceroute mechanism, in which the
=0A
    = Router Alert option must be set in the IP header of the MPLS Echo
=0A=
    Request messages, and may conditionally be set in = the IP header of
=0A
    the MPLS Echo Reply messa= ges.  While a generic "Router shall examine
=0A
  =   packet" Option Value is used for the IPv4 Router Alert Option (RAO)= ,
=0A
    there is no generic Router Alert Option = Value defined for IPv6 that
=0A
    can be used.&n= bsp; This document allocates a new generic IPv6 Router Alert
=0A
=     Option Value that can be used by MPLS OAM tools, includ= ing the MPLS
=0A
    Echo Request and MPLS Echo Re= ply messages for MPLS IPv6.
=0A
 
=0A
  &= nbsp; The initial motivation to request an IPv6 Router Alert Option (RAO)<= /div>=0A
    code point for MPLS OAM comes from MPLS LS= P Ping/Traceroute.
=0A
    However, this codepoint= is applicable to all MPLS OAM and not limited
=0A
  &n= bsp; to MPLS LSP Ping/Traceroute.
=0A
 
=0A
 <= /div>=0A
The IETF datatracker status page for this draft is:
=0A<= div>https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/=0A
 
=0A
There's also a htmlized version available a= t:
=0A=0A
 
=0A
A diff from the previous version is ava= ilable at:
=0A=0A
 
=0A
 
=0A=
Please note that it may take a couple of minutes from the time of sub= mission
=0A
until the htmlized version and diff are available at = tools.ietf.org.
=0A
 
=0A
Internet-Drafts are also = available by anonymous FTP at:
=0A=0A
&nb= sp;
=0A
_______________________________________________
=0A<= div>I-D-Announce mailing list
=0A=0A=0A
Internet-Draft directories: http://www.ietf.org/shadow.html
=0A= =0A
 
=0A
 <= /div>=0A
=0A
=0A
=0A
=0A=0A
<= /blockquote>=0A ------=_001_NextPart353368331428_=------ From nobody Tue Sep 30 10:48: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 37A1D1A7005; Tue, 30 Sep 2014 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 1B861_3xL7bu; Tue, 30 Sep 2014 10:48:30 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CDF1A7004; Tue, 30 Sep 2014 10:48:26 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id l18so14645885wgh.21 for ; Tue, 30 Sep 2014 10:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+1NfDci6qe6WhAjwLrc5I8lLis5owNJ6I/fdh4zYQ9M=; b=Ufx1a8opfkIqWleBcLfH8xCzg9ZaBh75xX22kiI2Oo5+jep/I0OyBUUURyBqCWmCYl D7AXciJjkVPMq/dljPn5W49El3EUctsPnUUyh2VPnraFHSDHcSLjFMfeeuFAzgULwePC buk4j+dVWnUUR0IOZfhy/I421FYIKbVLmllsg0qeSwThMdbmEXo8ZBpMw46U/dO8trQn 3SJO0mn+HCyz0bXQ0Pb/+a8blsD/leO5UD2U5Oa+oCBEUdCpuKzGY4HDMSRfry6Fn4Yv WYkoTCQ/J+WmzdNUcizyPAnE0PIduwyuqOOSjwA/Qvvc4LqZZSjcVr8lg89ofdr5VY6/ qP7g== X-Received: by 10.180.21.165 with SMTP id w5mr7399976wie.46.1412099305648; Tue, 30 Sep 2014 10:48:25 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.194.235.33 with HTTP; Tue, 30 Sep 2014 10:47:55 -0700 (PDT) In-Reply-To: <20140930000500.7476.1694.idtracker@ietfa.amsl.com> References: <20140930000500.7476.1694.idtracker@ietfa.amsl.com> From: Sriganesh Kini Date: Tue, 30 Sep 2014 10:47:55 -0700 X-Google-Sender-Auth: yETbyb48uKT9mIgDRH23eNYHFxw Message-ID: To: "spring@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bae48e880395305044bfd64 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S4gIwAWWMYOi3g-O4TKg6g_eZXg Cc: "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: [mpls] Fwd: I-D Action: draft-kini-mpls-spring-entropy-label-01.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, 30 Sep 2014 17:48:32 -0000 --047d7bae48e880395305044bfd64 Content-Type: text/plain; charset=UTF-8 FYI Comments welcome. Sri ---------- Forwarded message ---------- From: Date: Mon, Sep 29, 2014 at 5:05 PM Subject: [mpls] I-D Action: draft-kini-mpls-spring-entropy-label-01.txt To: i-d-announce@ietf.org Cc: mpls@ietf.org 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 : Entropy labels for source routed stacked tunnels Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Xiaohu Xu Wim Hendrickx Jeff Tantsura Filename : draft-kini-mpls-spring-entropy-label-01.txt Pages : 10 Date : 2014-09-29 Abstract: Source routed tunnel stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed stacked tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kini-mpls-spring-entropy-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kini-mpls-spring-entropy-label-01 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 --047d7bae48e880395305044bfd64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI

Comments welcome.


Sri

---------- Forward= ed message ----------
From: <internet-drafts@ie= tf.org>
Date: Mon, Sep 29, 2014 at 5:05 PM
Subject: [mp= ls] I-D Action: draft-kini-mpls-spring-entropy-label-01.txt
To: i-d-announce@ietf.org
Cc: mpls@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiprotocol Label Switching Workin= g Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Entropy labels for source routed stacked tunnels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Srig= anesh Kini
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kireeti Kompella
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Siva Sivabalan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stephane Litkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Rob Shakir
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Xiaohu Xu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wim Hendrickx
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jeff Tantsura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-kin= i-mpls-spring-entropy-label-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-09-29

Abstract:
=C2=A0 =C2=A0Source routed tunnel stacking is a technique that can be lever= aged to
=C2=A0 =C2=A0provide a method to steer a packet through a controlled set of=
=C2=A0 =C2=A0segments.=C2=A0 This can be applied to the Multi Protocol Labe= l Switching
=C2=A0 =C2=A0(MPLS) data plane.=C2=A0 Entropy label (EL) is a technique use= d in MPLS to
=C2=A0 =C2=A0improve load balancing.=C2=A0 This document examines and descr= ibes how ELs
=C2=A0 =C2=A0are to be applied to source routed stacked tunnels.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kini-mpls-= spring-entropy-label/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-kini-mpls-spring-ent= ropy-label-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-kini= -mpls-spring-entropy-label-01


Please note that it may take a couple of minutes from the time of submissio= n
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
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7bae48e880395305044bfd64-- From nobody Tue Sep 30 11:49: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 88C941A8783; Tue, 30 Sep 2014 11:48:57 -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 rLnH9lxhz41f; Tue, 30 Sep 2014 11:48:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 955C61A877A; Tue, 30 Sep 2014 11:48:55 -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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 11:48:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/FSR6cUxKQRzWUP-L2TGpRbcZeB4 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-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: Tue, 30 Sep 2014 18:48:57 -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 : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping Authors : Elisa Bellagamba Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Pages : 21 Date : 2014-09-30 Abstract: This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-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 Tue Sep 30 11:54: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 279AE1A8795 for ; Tue, 30 Sep 2014 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 54KTqeA5PzkZ for ; Tue, 30 Sep 2014 11:54:09 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF291A8785 for ; Tue, 30 Sep 2014 11:54:08 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-2f-542aa35dba2f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.3C.25146.D53AA245; Tue, 30 Sep 2014 14:34:37 +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, 30 Sep 2014 14:54:04 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Thread-Index: AQHP3N9Ltra7YGjVskmZRDRD+RFpPJwaBRUg Date: Tue, 30 Sep 2014 18:54:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B854360@eusaamb103.ericsson.se> References: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> In-Reply-To: <20140930184855.14746.88552.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXSPt27sYq0Qg+9b1SxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO0dRxkLngtW3P7A0sB4mbeLkZNDQsBE4seUfiYIW0ziwr31 bF2MXBxCAkcZJc5+PcUI4SxnlPj65y87SBWbgJHEi409YLaIgLLEkYndrCC2sECQxMG/jUAN HEDxYImHmzIhSowkOtdOACthEVCVaDt4nxHE5hXwlZh1ajcLiC0k4Cixcc46sFZOASeJZUej QMKMQPd8P7UG7DZmAXGJW0/mQ90pILFkz3lmCFtU4uXjf6wQtpLEnNfXmCHqdSQW7P7EBmFr Syxb+JoZYq2gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chwEyMw6I9JsDnu YFzwyfIQowAHoxIPb8I1zRAh1sSy4srcQ4zSHCxK4rya1fOChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAuW/h3B9Mp+cPiPbY3Ymb8u+vcEOP74oLD1Y9mv15z5aTbXvR/+GmmlNKtfift ZMbUN+FvZf1nd6qZvNtScf55d04N198uEy7vX7q39taszxNYoBOnbOBd+e6b6OfvOid6fx8L n/XCSijjuq7KtNcyDD/lS3n0jv85xRZcOiu0+5jArNiehuNKLMUZiYZazEXFiQCAbWZ6WwIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AN-SGBnjUIXCYcCOZfdEHf-hVTM Subject: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.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, 30 Sep 2014 18:54:11 -0000 Dear All, minor updates and bringing this work back on track. Your comments, questions and suggestions always welcome and greatly appreci= ated. Regards, Greg PS. RSVP-based companion doc been in the IESG queue been prepared for AD to= review. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, September 30, 2014 11:49 AM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Configuration of Pro-Active Operations, Administr= ation, and Maintenance (OAM) Functions for MPLS-based Transport Networks us= ing LSP Ping Authors : Elisa Bellagamba Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt Pages : 21 Date : 2014-09-30 Abstract: This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-07 Please note that it may take a couple of minutes from the time of submissio= n 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 Sep 30 18:46: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 800471A0018; Tue, 30 Sep 2014 18:46:45 -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 2q4WX7AO6jE5; Tue, 30 Sep 2014 18:46:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E991A000C; Tue, 30 Sep 2014 18:46:44 -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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141001014644.15080.3529.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 18:46:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zwtsEbgtCs4UVlrVAUV3OAclGN4 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-raza-mpls-oam-ipv6-rao-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: Wed, 01 Oct 2014 01:46:45 -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 : IPv6 Router Alert Option for MPLS OAM Authors : Kamran Raza Nobo Akiya Carlos Pignataro Filename : draft-raza-mpls-oam-ipv6-rao-02.txt Pages : 5 Date : 2014-09-30 Abstract: RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert option must be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS IPv6. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this codepoint is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-raza-mpls-oam-ipv6-rao-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/