From nobo@cisco.com Fri Nov 1 11:07:04 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1521E80B2 for ; Fri, 1 Nov 2013 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X08UxUKRMJPw for ; Fri, 1 Nov 2013 11:06:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A2D8C11E818D for ; Fri, 1 Nov 2013 11:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=947; q=dns/txt; s=iport; t=1383329212; x=1384538812; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W8qUqc00UuFj1hu1Fn2kZJeM6LIzbXk5DUTRry1LW+I=; b=myrdqZVh0ROXf7F6K65g1CbLLueT8rjLEg9HnCLqkh0ySPf0P1z2Xy1K ZmC3dJgnn0P9MOLzK7HdFBEqODGofGTv9sYG6/JazS1/YxODVgn9RHUM3 lN0fh/gGDurnbWw0qqQXtvAdoPEpQnMuZ6MAgqZ4IPr3LIydUotTTTPIu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAJXtc1KtJV2c/2dsb2JhbABZgmYhgQu/ZIEeFnSCJQEBAQQ6MRoCAgIBCBEEAQELFAkHGxcUCQgCBAESCId/Ab1UBI4LgRg4BoMagQ4DqhODJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,618,1378857600"; d="scan'208";a="279558458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2013 18:06:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA1I6Tfg028159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 18:06:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 1 Nov 2013 13:06:28 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: review of draft-akiya-mpls-entropy-lsp-ping Thread-Index: AQHO1r2Br+uxl4CPTkKKg3piP/TqB5oQpA4g Date: Fri, 1 Nov 2013 18:06:28 +0000 Message-ID: References: <52733261.9070208@pi.nu> In-Reply-To: <52733261.9070208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] review of draft-akiya-mpls-entropy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:07:05 -0000 Thank you for thorough review and great comments Loa! ACK, post-Vancouver, I will work with authors to address work through provi= ded comments as well as follow-up on the IANA/Security aspects. -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, November 01, 2013 12:47 AM > To: draft-akiya-mpls-entropy-lsp-ping@tools.ietf.org; mpls- > chairs@tools.ietf.org; mpls@ietf.org > Subject: review of draft-akiya-mpls-entropy-lsp-ping >=20 > Authors, >=20 > I've reviewed you draft (draft-akiya-mpls-entropy-lsp-ping) there are som= e > comments but in general I thin this should be progressed. >=20 > Please do not update until after your agenda slot in Vancouver. >=20 > /Loa > -- >=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 cpignata@cisco.com Fri Nov 1 11:58:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC911E81D2 for ; Fri, 1 Nov 2013 11:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.204 X-Spam-Level: X-Spam-Status: No, score=-109.204 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNJ8GdcPnQ+9 for ; Fri, 1 Nov 2013 11:58:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77511E8221 for ; Fri, 1 Nov 2013 11:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9112; q=dns/txt; s=iport; t=1383332306; x=1384541906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5tmAeMIN4WrXusacjGFWNvVQmbh0KwbP6YULY5LsZ1U=; b=eW2thanfNWX1UPcO+L4QPT5yhC33hQkSb8wM6Qzu/PVpGf3LeeyJ7XE/ yjMQBnF2wvWn/7Sp2uAd7ufk9E0brtZGUH4winAE5lcB/z+cjQhTcK3d5 JnV3Pa+DxdXSWJypsKjz4/7PeCVete6fNXfpcm1aAa5ch6MU0Gfmvtb1N o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEj5c1KtJV2c/2dsb2JhbABZgweBC4MIvFyBHhZ0giUBAQEDAWsOBQsCAQYCGAodBQIyFBEBAQQOBQgGh3MGjzubWAiSOY4OC4EOMQeCZzmBDgOQLoEwmDWDJoFoQg X-IronPort-AV: E=Sophos;i="4.93,618,1378857600"; d="asc'?scan'208";a="279395663" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 01 Nov 2013 18:58:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA1IwOGp026056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 18:58:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 1 Nov 2013 13:58:24 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: AD review of draft-ietf-mpls-in-udp Thread-Index: Ac7HiaXROcI88rhSTwi1i42VDdiSNwB4ZqMAAFJcaoAC9dF/gAAPWyxQACU2qYA= Date: Fri, 1 Nov 2013 18:58:23 +0000 Message-ID: <95067C434CE250468B77282634C96ED33365C3C0@xmb-aln-x02.cisco.com> References: <005a01cec789$a7669d10$f633d730$@olddog.co.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0821620A@NKGEML512-MBS.china.huawei.com> <00be01ceca8a$ca1e6410$5e5b2c30$@olddog.co.uk> <95067C434CE250468B77282634C96ED33365369E@xmb-aln-x02.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08223D3A@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08223D3A@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_23ACEB3E-BAF2-4869-97E2-7B7B5B4E302D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: distinguished MPLS chairs , "mpls@ietf.org" , "draft-ietf-mpls-in-udp@tools.ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:58:37 -0000 --Apple-Mail=_23ACEB3E-BAF2-4869-97E2-7B7B5B4E302D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Xiaohu, On Nov 1, 2013, at 2:23 AM, Xuxiaohu wrote: > Hi Carlos, >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C21=C8=D5 1:53 >> =CA=D5=BC=FE=C8=CB: Adrian Farrel >> =B3=AD=CB=CD: Xuxiaohu; draft-ietf-mpls-in-udp@tools.ietf.org; = distinguished MPLS chairs; >> mpls@ietf.org >> =D6=F7=CC=E2: Re: AD review of draft-ietf-mpls-in-udp >>=20 >> Hi, >>=20 >> On Oct 16, 2013, at 12:14 PM, Adrian Farrel = wrote: >>=20 >>> Hello, >>>=20 >>> Just cutting down to the conversation... >>>=20 >>>>> Abstract >>> [snip] >>>>> "...applicable in some circumstances" says nothing, of course. >>>>> Either don't say this, or explicitly state the circumstance. Since >>>>> (see below) the applicability is very specific and there is a = clear >>>>> use case that is the target of your work, I strongly suggest that >>>>> you call out this case in the Abstract. >>>>=20 >>>> Is it ok for you if the above sentence is changed to"... applicable >>>> in some circumstances where IP-based encapsulation for MPLS is >>>> required and fine- grained load-balancing of IP tunneled MPLS = packets is >> required as well..."? >>> Or can >>>> you suggest any text on this point? >>>=20 >>> That helps a lot. >>> Thanks. >>=20 >> I do not think adding the proposed text is the best fix. Saying = "circumstances >> where IP-based encapsulation for MPLS is required and fine-grained >> load-balancing of IP tunneled MPLS packets is required as well" = implies >> potentially that existing IP-based encapsulation for MPLS are not = appropriate >> for fine-grained load-balancing of IP tunneled MPLS packets, and = that's not >> necessarily the case, since fields in other encapsulations can be = used (and are >> used) for that (e.g., GRE Key, L2TPv3 Session ID). >=20 >> Also, this proposal contradicts your (Adrian's) point below about the = inability to >> know what's encapsulated in MPLS (the proposed text says "of IP = tunneled >> MPLS packets"). >=20 > I have changed it to "load-balancing of MPLS packet over IP networks". >=20 >> Additionally, please note that RFC 4023 says in the abstract "Each of = these is >> applicable in some circumstances." which sets the expectation that it = will be >> answered in the doc as applicability. >>=20 >> I'd propose just removing the "...applicable in some circumstances" = or be even >> more specific about the applicability. >=20 > The abstract is changed to:=20 >=20 > "This document specifies an IP-based encapsulation for MPLS, called = MPLS-in-UDP (User Datagram Protocol), which is applicable in some = circumstances where IP-based encapsulation for MPLS is required and = further fine-grained load-balancing of MPLS packets over IP networks is = required as well. Although other IP-based encapsulations for MPLS can = improve the load-balancing as well by using some fields in the = encapsulation headers, one major benefit of MPLS-in-UDP comparing to = other IP-based encapsulations for MPLS is that the former can improve = the load-balancing without any requirement on the core of the IP = networks." I do not think this is accurate either. It does most definitely impose = requirements on core routers. Those requirements include the use of UDP = ports in the hash function for ECMP. I believe what you are trying to = say is that every IP router and every IP network already does this for = UDP ports without any penalty, but not for GRE Keys or for the IPv6 flow = label field. I'm not sure how to best approach this in the absence of = any pointer that would substantiate the statement. Do you know of any = paper that studies this? Perhaps one approach is to be explicit about = the assumptions. >=20 > [snip] >=20 >>> If I am correct and it is never appropriate, it would be better to = say that >>> "using zero checksum is NOT RECOMMENDED because of..." and then = point >> to the >>> text you quoted. >>>=20 >>> if I am incorrect then please discuss with me further. >>=20 >> A further point that does not imply you are incorrect, but I will = note that other >> MPLS-in-IP encapsulations do not have a checksum in the transport, = and >> perhaps that's what needs to be added to the document. >=20 > I have added "... note that other MPLS-in-IP encapsulations do not = have a checksum in the transport header..." to the doc. >=20 Ack. Thanks, Carlos. > Best regards, > Xiaohu >=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>>=20 >>>>> Section 4 >>>>>=20 >>>>> As for other common processing procedures associated with = tunneling >>>>> encapsulation technologies including but not limited to Maximum >>>>> Transmission Unit (MTU) and preventing fragmentation and = reassembly, >>>>> Time to Live (TTL) and differentiated services, the corresponding >>>>> "Common Procedures" defined in [RFC4023] which are applicable for >>>>> MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be >> followed. >>>>>=20 >>>>> I think it is probably important to consider PMTU in the presence = of >>>>> ECMP (probably not necessary in the case of LAG). How does the >>>>> source know the PMTU for each different value of the source port >>>>> that it might apply? >>>>=20 >>>> IMHO, it is a common issue for any load-balancing mechanism. Would = it >>>> be >>> better >>>> to write a separate doc to address this common issue? >>>=20 >>> That is a really good question. >>> I think discovering PMTU is technology dependent, but the general >>> issue of discovery in ECMP doesn't appear to be well discussed. >>>=20 >>>>> As far as I can see Section 5 is not ECN-friendly and says that = when >>>>> the payload protocol of the MPLS packet is not "TCP-friendly" the >>>>> application generating the packets must use magic to avoid = swamping >>>>> the network. >>>>>=20 >>>>> We will see what the TSV area congestion experts have to say, but = I >>>>> think we will find that the approach here is simplistic unless the >>>>> network across which the UDP tunnel runs is used for no other >>>>> traffic except UDP tunnels carrying MPLS packets. >>>>=20 >>>> We originally just intented to mention this issue to the same = extent >>>> as MPLS >>> over >>>> L2TPv3 [rfc4817]. BTW, it seems that MPLS in IP or GRE [RFC4023] >>>> doesn't mention this point at all. We would like to see what the = TSV >>>> area congestion experts have to say as well on this point. >>>=20 >>> Yeah, this is fine. I am not an expert in this stuff and we will = need >>> their opinions. Perhaps they won't say anything :-) >>>=20 >>>>> Section 6 seems to indicate a major draw-back of this scheme. You >>>>> have to note that MPLS networks are able to get away with having >>>>> very little security because it is very hard to inject MPLS = packets into a >> network. >>>>> But MPLS-in-(foo-in-)IP encapsulation provides a way to inject >>>>> packets just like any packet can be injected into an IP network. >>>>=20 >>>> Sure. It's the same issue with any other IP-based encapsulations = for MPLS. >>>=20 >>> Indeed, hence my point about security, below... >>>=20 >>>>> Security (such as IPsec) provides a way to ensure that rogue = packets >>>>> do not have their headers stripped and their payload MPLS packets >>>>> added to an LSP. >>>>=20 >>>>> You are making a clear statement that using IPsec means that there >>>>> is no point in doing MPLS-in-UDP encapsulation. You need to follow = up on >> this! >>>>>=20 >>>>> The first thing to do is to enhance the applicability text in >>>>> Section 1 to say where you would deploy this such that security is = not an >> issue. >>>>=20 >>>>> The second thing is to talk about the security mechanisms that can >>>>> be applied at the edges of the network to reduce the likelihood of >>>>> such attacks being possible. >>>>>=20 >>>>> Lastly (or probably firstly!) you need to describe the attack = vector >>>>> and the implications of such an attack so that the >>>>> implementer/deployer is clear what the risks are. >>>>=20 >>>> Will fix it. >>>=20 >>> OK. I also wonder whether you looked at DTLS. >>>=20 >>> Thanks for all the work. >>>=20 >>> Adrian >>>=20 >=20 --Apple-Mail=_23ACEB3E-BAF2-4869-97E2-7B7B5B4E302D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJz+c8ACgkQtfDPGTp3USw/6wCfQAEOtg0HfxQCwAynXRGikbhw AJ4AnjeSPlWsyQ+QDCdYGgMVPMBL0tLo =YFQ1 -----END PGP SIGNATURE----- --Apple-Mail=_23ACEB3E-BAF2-4869-97E2-7B7B5B4E302D-- From loa@pi.nu Fri Nov 1 23:54:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976D921E8108 for ; Fri, 1 Nov 2013 23:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIbtxm-tlMZl for ; Fri, 1 Nov 2013 23:54:53 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 52AFC21E8103 for ; Fri, 1 Nov 2013 23:54:53 -0700 (PDT) Received: from [10.136.231.160] (unknown [124.127.168.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F0AD018014F6 for ; Sat, 2 Nov 2013 07:54:51 +0100 (CET) Message-ID: <5274A1BA.9080402@pi.nu> Date: Sat, 02 Nov 2013 14:54:50 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5260B904.2090802@pi.nu> In-Reply-To: <5260B904.2090802@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closed : working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 06:54:59 -0000 Working Group, this working group last call is closed. There have been comment. Could the authors please address the comments and post a new version as necessary. /Loa for the mpls wg co-chairs On 2013-10-18 12:28, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-p2mp-framework-04. > > Please send your comment to working group mailing lists (mpls@ietf.org). > > We did an IPR poll on this document prior to starting the wglc. > The each authors responded to the IPR poll that they not aware of > any IPR's relating to this document. > > There are no IPRs disclosed against this document. > > The working group last call will end Friday November 1, 2913. > > /Loa > 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 lberger@labn.net Sun Nov 3 22:22:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD511E82E1 for ; Sun, 3 Nov 2013 22:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut3iFe+YZH-Z for ; Sun, 3 Nov 2013 22:22:53 -0800 (PST) Received: from outbound-ss-1738.bluehost.com (outbound-ss-1738.bluehost.com [74.220.192.106]) by ietfa.amsl.com (Postfix) with SMTP id F327811E81A0 for ; Sun, 3 Nov 2013 22:22:52 -0800 (PST) Received: (qmail 8126 invoked by uid 0); 4 Nov 2013 06:22:28 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 4 Nov 2013 06:22:28 -0000 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=5nYGJY+dgNpq08RRJPkseuaBpfzGMEZJF+2Dn8iS+VA=; b=ajHJhfRBL7fRIlwETj1hNijSinrZX4GzlXQ5peX/csb/wegcuIg6HZpT8g0x1Nxo4op2NrSkYKQMkcgIx88SxAsFn0F8UsrDNGZ6A0oLz+NRGTNBAi9tq7lQdTKA6MfA; Received: from box313.bluehost.com ([69.89.31.113]:47801 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VdDYS-0001iG-4i; Sun, 03 Nov 2013 23:22:28 -0700 Message-ID: <52771FCD.1030406@labn.net> Date: Sun, 03 Nov 2013 20:17:17 -0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Zhenlong Cui , mpls@ietf.org References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> In-Reply-To: <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> X-Enigmail-Version: 1.6 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} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:22:57 -0000 Zhenlong, Thank you for the comments. Please see below for responses in-line. On 10/22/2013 2:18 AM, Zhenlong Cui wrote: > Dear authors, > > I have a comment/question on this draft. > > As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. > In this case, the drop-and-continue node will become an intermediate point. Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. > So, can we configure a MEP on an intermediate node(= drop-and-continue node)? I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit nodes. Assuming you are asking about the case stated in the previous point, that a node is both egress and transit, then I think it could have both MEP and MIP functionality separately instantiated. Section 3.7 already covers P2MP MIPs and MEPs. > As described in section 3.3 of RFC 6371, a MEP terminates all the OAM packets it receives from the MEG, > may discards silently if addressing information in the OAM payload is different with termination node. > It means that the intermediate node must NOT be configured as a MEP when per-node OAM configuration is used, > because downstream nodes can't receive the OAM packets from root node. Why do you say this? If a node is both transit and egress, it will replicate OAM packets (just like the data) when performing its transit role before then terminating the data/OAM packets as part of its egress role. > > On the other hand, if the intermediate node can't be configured as a MEP, the path protection may > not be able to work at this point. I think this is a serious problem. > Perhaps I'm missing something, but I simply don't see an issue here that isn't already addressed in RFC6371 (and 4875.) I guess 6371 could have shown this case as an example, or provided a related detailed walk through, but either way I don't see any "serious problem" here. Perhaps the best way to proceed on this is to propose text to the already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? Thanks, Lou > Best regards, > zhenlong > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Friday, October 18, 2013 1:29 PM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >> Subject: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework >> >> Working Group, >> >> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. >> >> Please send your comment to working group mailing lists (mpls@ietf.org). >> >> We did an IPR poll on this document prior to starting the wglc. >> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. >> >> There are no IPRs disclosed against this document. >> >> The working group last call will end Friday November 1, 2913. >> >> /Loa >> 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > > From martin.vigoureux@alcatel-lucent.com Sun Nov 3 22:29:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4F211E819B for ; Sun, 3 Nov 2013 22:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-lbLLlJujhb for ; Sun, 3 Nov 2013 22:28:58 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A1AE111E8181 for ; Sun, 3 Nov 2013 22:28:56 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA46StAr029500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Nov 2013 00:28:56 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id rA46St0w020770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Nov 2013 01:28:55 -0500 Received: from [135.244.33.24] (135.5.27.17) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 4 Nov 2013 01:28:55 -0500 Message-ID: <52773EA4.5050000@alcatel-lucent.com> Date: Mon, 4 Nov 2013 07:28:52 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: <5267A362.9030804@alcatel-lucent.com> <526AEDB5.3080001@alcatel-lucent.com> In-Reply-To: <526AEDB5.3080001@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [mpls] Updated Agenda [Re: IETF88 - MPLS - Agenda available - Please send your presentation material] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:29:03 -0000 All, due to slots cancellations more time was given to some presentations, especially those of Wednesday. Presenters you may update your presentation to take this into account. -m Le 26/10/2013 00:16, Martin Vigoureux a écrit : > All, > > the agenda has been modified to resolve certain overlap issues between WGs. > Please take a look at it: > http://www.ietf.org/proceedings/88/agenda/agenda-88-mpls > > Speakers, the request to send your slides continues to apply. > > -m > > Le 23/10/2013 12:22, Martin Vigoureux a écrit : >> All, >> >> the draft agenda is on-line: >> http://www.ietf.org/proceedings/88/agenda/agenda-88-mpls >> >> Please have a look at it. Tell us if we have missed anything. >> Please note that it is not the final agenda and that as such it is >> subject to change. >> >> Speakers, please start sending me your presentation material, and please >> do so before November the 4th. >> >> Thank you. >> >> Martin >> >> _______________________________________________ >> 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 c-sai@bx.jp.nec.com Mon Nov 4 00:59:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB921F9D98 for ; Mon, 4 Nov 2013 00:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJfM3VLUCEZv for ; Mon, 4 Nov 2013 00:59:09 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 617A811E81B6 for ; Mon, 4 Nov 2013 00:58:48 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rA48wk0W021845; Mon, 4 Nov 2013 17:58:46 +0900 (JST) Received: from mailsv.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id rA48wkE09981; Mon, 4 Nov 2013 17:58:46 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id rA48wkoq024987; Mon, 4 Nov 2013 17:58:46 +0900 (JST) Received: from shikibu.jp.nec.com ([10.26.220.2] [10.26.220.2]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-516890; Mon, 4 Nov 2013 17:56:58 +0900 Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Mon, 4 Nov 2013 17:56:56 +0900 From: "Zhenlong Cui" To: "'Lou Berger'" , References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> In-Reply-To: <52771FCD.1030406@labn.net> Date: Mon, 4 Nov 2013 17:56:55 +0900 Message-ID: <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq2YUNvecA== Content-Language: ja Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 08:59:13 -0000 Hi Lou, Thank you for your reply. I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on a transit node. However, I think that this draft need further explanation for the OAM behavior on transit nodes. The P2MP OAM behaviors are described in section 4. All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves, thus every OAM packet is sent to all leaves, and thus can impact all the MEs in a P2MP MEG. If an OAM packet is to be processed by only a specific leaf, it requires information to indicate to all other leaves that the packet must be discarded. To address a packet to an intermediate node in the tree, TTL based addressing is used to set the radius and addressing information in the OAM payload is used to identify the specific destination node. My comments: 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. The case of per-interface should also be described, if you like to mention about the per-node case in this draft. 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on a transit node. e.g.) When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed by a MIP functionality, before it identifies the addressing information. Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. Best reagrds, zhenlong > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Monday, November 04, 2013 1:17 PM > To: Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework > > Zhenlong, > Thank you for the comments. Please see below for responses in-line. > > On 10/22/2013 2:18 AM, Zhenlong Cui wrote: > > Dear authors, > > > > I have a comment/question on this draft. > > > > As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. > > In this case, the drop-and-continue node will become an intermediate point. > > Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. > > > So, can we configure a MEP on an intermediate node(= drop-and-continue node)? > > I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit nodes. > Assuming you are asking about the case stated in the previous point, that a node is both egress and transit, then I think > it could have both MEP and MIP functionality separately instantiated. Section 3.7 already covers P2MP MIPs and MEPs. > > > As described in section 3.3 of RFC 6371, a MEP terminates all the OAM > > packets it receives from the MEG, may discards silently if addressing information in the OAM payload is different with > termination node. > > It means that the intermediate node must NOT be configured as a MEP > > when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. > > Why do you say this? If a node is both transit and egress, it will replicate OAM packets (just like the data) when performing > its transit role before then terminating the data/OAM packets as part of its egress role. > > > > > On the other hand, if the intermediate node can't be configured as a > > MEP, the path protection may not be able to work at this point. I think this is a serious problem. > > > > Perhaps I'm missing something, but I simply don't see an issue here that isn't already addressed in RFC6371 (and 4875.) > I guess 6371 could have shown this case as an example, or provided a related detailed walk through, but either way I don't > see any "serious problem" here. > > Perhaps the best way to proceed on this is to propose text to the already referenced "additional detail" draft > draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? > > Thanks, > Lou > > > Best regards, > > zhenlong > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of Loa Andersson > >> Sent: Friday, October 18, 2013 1:29 PM > >> To: mpls@ietf.org > >> Cc: mpls-chairs@tools.ietf.org; > >> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >> Subject: [mpls] working group last call on > >> draft-ietf-mpls-tp-p2mp-framework > >> > >> Working Group, > >> > >> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. > >> > >> Please send your comment to working group mailing lists (mpls@ietf.org). > >> > >> We did an IPR poll on this document prior to starting the wglc. > >> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. > >> > >> There are no IPRs disclosed against this document. > >> > >> The working group last call will end Friday November 1, 2913. > >> > >> /Loa > >> 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 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > From internet-drafts@ietf.org Mon Nov 4 10:15:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030B21E8097; Mon, 4 Nov 2013 10:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQqiiPnqMlO5; Mon, 4 Nov 2013 10:15:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4111621F9EF6; Mon, 4 Nov 2013 10:15:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104181532.10172.10734.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 10:15:32 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:15:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Traffic Engineering (TE) Management Information = Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-07.txt Pages : 59 Date : 2013-11-04 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 managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-te-mib-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 liuzhiheng@chinamobile.com Sun Nov 3 01:12:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97521E80D0 for ; Sun, 3 Nov 2013 01:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgw0V0sOYfFs for ; Sun, 3 Nov 2013 01:12:40 -0700 (PDT) Received: from SMTP.HSIA.FAIRMONT.COM (smtp.hsia.fairmont.com [142.131.15.59]) by ietfa.amsl.com (Postfix) with ESMTP id 2304B21E80B9 for ; Sun, 3 Nov 2013 01:12:40 -0700 (PDT) Received: from p1308.superclick.com (unverified [64.114.24.114]) by smtp.hsia.fairmont.com (Vircom SMTPRS 5.22.7.16456) with ESMTP id for ; Sun, 3 Nov 2013 03:12:30 -0500 X-Modus-BlackList: 64.114.24.114=OK;liuzhiheng@chinamobile.com=OK X-Modus-Trusted: 64.114.24.114=NO X-Modus-Audit: FALSE;0;0;0 Received: from CMCCVic ([172.16.33.193]) (authenticated bits=0) by p1308.superclick.com (8.13.1/8.13.1) with ESMTP id rA38CXco029129 for ; Sun, 3 Nov 2013 01:12:34 -0700 From: =?utf-8?B?5YiY5b+X5oGS?= To: Date: Sun, 3 Nov 2013 16:12:36 +0800 Message-ID: <02a001ced86c$757f2ee0$607d8ca0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac7YbF8sBGtW/bzgQFCeX33FHDeUhA== Content-Language: zh-cn X-Mailman-Approved-At: Mon, 04 Nov 2013 13:35:31 -0800 Subject: [mpls] Request for comments: New Version Notification for draft-li-mpls-ldp-mt-mib-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 08:12:48 -0000 hi, guys =20 we propose update of mpls multiple topology MIB draft. the link is as = below=EF=BC=9A =20 http://www.ietf.org/id/draft-li-mpls-ldp-mt-mib-05.txt =20 Any comments and suggestions are welcome. Thank you All the Best! Vic Liu && Chen Li -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8821=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=B8=80 23:31 =E6=94=B6=E4=BB=B6=E4=BA=BA: Vic Liu; vic; Tao Chou; Quintin Zhao; Chen = Li; Lu Huang; Lianyuan Li; Emily Chen =E4=B8=BB=E9=A2=98: New Version Notification for = draft-li-mpls-ldp-mt-mib-05.txt A new version of I-D, draft-li-mpls-ldp-mt-mib-05.txt has been = successfully submitted by Vic Liu and posted to the IETF repository. Filename: draft-li-mpls-ldp-mt-mib Revision: 05 Title: Management Information Base for MPLS LDP Multi Topology Creation date: 2013-10-19 Group: mpls Number of pages: 29 URL: = http://www.ietf.org/internet-drafts/draft-li-mpls-ldp-mt-mib-05.txt Status: = http://datatracker.ietf.org/doc/draft-li-mpls-ldp-mt-mib Htmlized: http://tools.ietf.org/html/draft-li-mpls-ldp-mt-mib-05 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-li-mpls-ldp-mt-mib-05 Abstract: This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for Multi-Topology Networks over Multi-protocol Label Switching(MPLS) Label Switching Routers(LSRs). = =20 this draft is updated under reviewers' comments and add a new author = Vic. Please kindly help us post it. thank you very much 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 lberger@labn.net Tue Nov 5 11:06:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112EB21E80BE for ; Tue, 5 Nov 2013 11:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.866 X-Spam-Level: X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLpFJJn3GUg for ; Tue, 5 Nov 2013 11:06:11 -0800 (PST) Received: from outbound-ss-899.hostmonster.com (outbound-ss-899.hostmonster.com [69.89.16.13]) by ietfa.amsl.com (Postfix) with SMTP id 5AD8811E813B for ; Tue, 5 Nov 2013 11:06:07 -0800 (PST) Received: (qmail 19224 invoked by uid 0); 5 Nov 2013 19:06:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy19-pub.mail.unifiedlayer.com with SMTP; 5 Nov 2013 19:06:00 -0000 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=hRi6Vf3A8MrqDSZwGrX07e9QhjbRsPEbdAV2G6v0ZWo=; b=2aGdUWVT1bVZBEGoaPRAcHFHadpWrJ0Xu48LWkXESoUCtHO+1ZeYyGMwaJzBJWvFE+0NOsi2hJQEyBAT61A6BwcuMr0ZqpHto9c6Yh+CSAwVFMnkP3jLZuus06W9voOi; Received: from box313.bluehost.com ([69.89.31.113]:43756 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vdlwu-0004X8-EZ; Tue, 05 Nov 2013 12:06:00 -0700 Message-ID: <52794190.9060303@labn.net> Date: Tue, 05 Nov 2013 11:05:52 -0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Zhenlong Cui , mpls@ietf.org References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> In-Reply-To: <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> X-Enigmail-Version: 1.6 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} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:06:16 -0000 Zhenlong, Perhaps the issue is in the slightly different language used in the draft versus the section 3.7 of rfc6371. RFC6371 says: o To send an OAM packet to a single MIP, ... The OAM packet must contain sufficient information to identify the target MIP and therefore is processed only by the target MIP and can be silently discarded by the others. To better align with this text, the draft should be revised to replace "addressing information" with "additional information" Will this address your comment? If not, do you have some text/changes in mind that would? Much thanks, Lou On 11/4/2013 12:56 AM, Zhenlong Cui wrote: > Hi Lou, > > Thank you for your reply. > > I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on a transit node. > > However, I think that this draft need further explanation for the OAM behavior on transit nodes. > > The P2MP OAM behaviors are described in section 4. > All the traffic sent over a P2MP transport path, including OAM > packets generated by a MEP, is sent (multicast) from the root to all > the leaves, thus every OAM packet is sent to all leaves, and thus can > impact all the MEs in a P2MP MEG. If an OAM packet is to be > processed by only a specific leaf, it requires information to > indicate to all other leaves that the packet must be discarded. To > address a packet to an intermediate node in the tree, TTL based > addressing is used to set the radius and addressing information in > the OAM payload is used to identify the specific destination node. > > > My comments: > > 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. > The case of per-interface should also be described, if you like to mention about the per-node case in this draft. > > 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on a transit node. > e.g.) > When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed by a MIP functionality, before it identifies the addressing information. > Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. > > > Best reagrds, > zhenlong > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Monday, November 04, 2013 1:17 PM >> To: Zhenlong Cui; mpls@ietf.org >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework >> >> Zhenlong, >> Thank you for the comments. Please see below for responses in-line. >> >> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: >>> Dear authors, >>> >>> I have a comment/question on this draft. >>> >>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. >>> In this case, the drop-and-continue node will become an intermediate point. >> >> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. >> >>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? >> >> I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit nodes. >> Assuming you are asking about the case stated in the previous point, that a node is both egress and transit, then I think >> it could have both MEP and MIP functionality separately instantiated. Section 3.7 already covers P2MP MIPs and MEPs. >> >>> As described in section 3.3 of RFC 6371, a MEP terminates all the OAM >>> packets it receives from the MEG, may discards silently if addressing information in the OAM payload is different with >> termination node. >>> It means that the intermediate node must NOT be configured as a MEP >>> when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. >> >> Why do you say this? If a node is both transit and egress, it will replicate OAM packets (just like the data) when performing >> its transit role before then terminating the data/OAM packets as part of its egress role. >> >>> >>> On the other hand, if the intermediate node can't be configured as a >>> MEP, the path protection may not be able to work at this point. I think this is a serious problem. >>> >> >> Perhaps I'm missing something, but I simply don't see an issue here that isn't already addressed in RFC6371 (and 4875.) >> I guess 6371 could have shown this case as an example, or provided a related detailed walk through, but either way I don't >> see any "serious problem" here. >> >> Perhaps the best way to proceed on this is to propose text to the already referenced "additional detail" draft >> draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? >> >> Thanks, >> Lou >> >>> Best regards, >>> zhenlong >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>> Of Loa Andersson >>>> Sent: Friday, October 18, 2013 1:29 PM >>>> To: mpls@ietf.org >>>> Cc: mpls-chairs@tools.ietf.org; >>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >>>> Subject: [mpls] working group last call on >>>> draft-ietf-mpls-tp-p2mp-framework >>>> >>>> Working Group, >>>> >>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. >>>> >>>> Please send your comment to working group mailing lists (mpls@ietf.org). >>>> >>>> We did an IPR poll on this document prior to starting the wglc. >>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. >>>> >>>> There are no IPRs disclosed against this document. >>>> >>>> The working group last call will end Friday November 1, 2913. >>>> >>>> /Loa >>>> 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 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>> > > > > > From skraza@cisco.com Tue Nov 5 11:17:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8044E11E81BB for ; Tue, 5 Nov 2013 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-zdq3Zzpd3T for ; Tue, 5 Nov 2013 11:17:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B4A7421E8085 for ; Tue, 5 Nov 2013 11:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2634; q=dns/txt; s=iport; t=1383679059; x=1384888659; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qGd3xcXtBSylr5GL3koV/XJUWxqI82ak19HwmYJl4t8=; b=FjF/XfAFTNAG7KTekktqSuGXXsVjNoOydycyMa2OIuBpducBs8OxqUF4 nkJgVwa4vchFYF1kfeioNWwACwhP62MeNs1h9SFIP+o0MfeKBK11gu+qt XgP/Q/otLGN2r00qGrUz7ZsP3V5pnshP74ZG4wStgqZNHkubFHww+Bkhu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFABZEeVKtJXG+/2dsb2JhbABZgwc4U784gSwWdIInAQQBAQE3NAsSAQgtCTcLJQEBBAENBYgBDb50j1kHCoQlA5gKkgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="281063644" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2013 19:17:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5JHbgR001866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 19:17:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:17:36 -0600 From: "Kamran Raza (skraza)" To: "adrian@olddog.co.uk" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-ldp-ip-pw-capability Thread-Index: Ac7LO08u/cU1gZSjRe6Id4NFyYN+9APBzWOA Date: Tue, 5 Nov 2013 19:17:35 +0000 Message-ID: In-Reply-To: <02fe01cecb3b$59333440$0b999cc0$@olddog.co.uk> 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.255.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <97183A124FD3184BA4565473B6C064F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:17:45 -0000 Thanks Adrian. We agree with most of your comments and I will re-spin a revised ID right after IETF. -- Kamran [ one authors' behalf ] On 2013-10-17 9:18 AM, "Adrian Farrel" wrote: >Hello authors of draft-ietf-mpls-ldp-ip-pw-capability, > >I have done my usual AD review of your draft having received the >publication request. The purpose of my review is to remove any >issues that I can find before the document reaches IETF last call >and IESG evaluation. > >Technically, this is a fine piece of work, but I'm afraid I have a >few of editorial issues. I hope they will be quick for you to fix so >we can move ahead with the IETF last call. > >Please feel free to discuss/reject any of my requests. > >Thanks for the work, >Adrian > >=3D=3D=3D > >IPoMPLS is not a common term. Fortunately you do define it quite early >in the document, but not until after you have used it a couple of times. >Could you please at least expand the acronym in the Abstract and >Introduction, and maybe give a forward pointer to the definition from >the Introduction. > >But be really careful! The term "IP Label Switching" seems to be hardly >used anywhere (says Google) except: >- in this I-D >- in IOS to mean "hop-by-hop label switching" (about which I am also > none the wiser :-) >- in old material as a synonym for MPLS. >So your definition of IPoMPLS in Section 2 doesn't actually tell us >what it is. > >--- > >You need to take some care with acronyms on first use. You can check at >http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt to see >which are well known and don't need to be expanded. > >I see >P2P >PW >LSR >P2MP >mLDP >FEC >L2VPN >PE > >--- > >Are you sure you don't want IANA to manage a registry for > > State: Defines the type of application state (to be controlled). > The value of this field is defined as follows: > 1: IPv4 Label switching > 2: IPv6 Label switching > 3: P2P PW FEC128 signaling > 4: P2P PW FEC129 signaling > 0, 5-15: Reserved. > >What does "Reserved" mean? > >--- > >It seems (to me) odd that you require four SEC elements to disallow >all four listed states. I would have thought bit flags would be more >efficient with 1 disallows and 0 allows. > >But since this is a case of "I would not have done it this way", you >do not need to make this change on my account provided the WG is OK >with what you have here. > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Nov 6 09:55:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3521E816B for ; Wed, 6 Nov 2013 09:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT9DNvCoPCQI for ; Wed, 6 Nov 2013 09:55:45 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8A21E816D for ; Wed, 6 Nov 2013 09:55:44 -0800 (PST) Received: from [31.133.151.83] (dhcp-9753.meeting.ietf.org [31.133.151.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 617CE1802038; Wed, 6 Nov 2013 18:55:42 +0100 (CET) Message-ID: <527A829D.40704@pi.nu> Date: Wed, 06 Nov 2013 09:55:41 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPT poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:55:51 -0000 Working Group, The editors and authors work with the working group chairs to prepare draft-ryoogray-mpls-tp-psc-itu for the poll to see if we have consensus to adopt it as a working group document. In order to expedite the process we will start the IPR poll now. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ryoogray-mpls-tp-psc-itu? 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 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 loa@pi.nu Wed Nov 6 10:03:25 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4711E80D9 for ; Wed, 6 Nov 2013 10:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdhRqoSOxlWK for ; Wed, 6 Nov 2013 10:03:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1D21E808D for ; Wed, 6 Nov 2013 10:03:13 -0800 (PST) Received: from [31.133.151.83] (dhcp-9753.meeting.ietf.org [31.133.151.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F08051802038; Wed, 6 Nov 2013 19:03:11 +0100 (CET) Message-ID: <527A845F.3030603@pi.nu> Date: Wed, 06 Nov 2013 10:03:11 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" References: <527A829D.40704@pi.nu> In-Reply-To: <527A829D.40704@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:03:25 -0000 Folks, A small correction in the subject line. /Loa On 2013-11-06 09:55, Loa Andersson wrote: > Working Group, > > The editors and authors work with the working group chairs to prepare > draft-ryoogray-mpls-tp-psc-itu for the poll to see if we have consensus > to adopt it as a working group document. In order to expedite the > process we will start the IPR poll now. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ryoogray-mpls-tp-psc-itu? > > 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 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 ryoo@etri.re.kr Wed Nov 6 10:16:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DD911E8164 for ; Wed, 6 Nov 2013 10:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgtalWWkll00 for ; Wed, 6 Nov 2013 10:16:25 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 303A511E8241 for ; Wed, 6 Nov 2013 10:16:25 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 7 Nov 2013 03:16:19 +0900 Received: from SMTP2.etri.info ([169.254.2.161]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Thu, 7 Nov 2013 03:16:20 +0900 From: "Ryoo, Jeong-dong" To: Loa Andersson , "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu Thread-Index: AQHO2xp8VKMWL7neXk22bJiytH17z5oYgeYV Date: Wed, 6 Nov 2013 18:16:19 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286A5926@SMTP2.etri.info> References: <527A829D.40704@pi.nu>,<527A845F.3030603@pi.nu> In-Reply-To: <527A845F.3030603@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.44] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286A5926SMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:16:32 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286A5926SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4N ClNlbnQgOiAyMDEzLTExLTA3IDAzOjAzOjIzICggKzA5OjAwICkNClRvIDogbXBsc0BpZXRmLm9y ZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dUB0b29scy5p ZXRmLm9yZyA8ZHJhZnQtcnlvb2dyYXktbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwg VklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikgPG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNl bnQuY29tPg0KQ2MgOg0KU3ViamVjdCA6IENvcnJlY3Rpb246IElQUiBwb2xsIG9uIGRyYWZ0LXJ5 b29ncmF5LW1wbHMtdHAtcHNjLWl0dQ0KDQoNCkZvbGtzLA0KDQpBIHNtYWxsIGNvcnJlY3Rpb24g aW4gdGhlIHN1YmplY3QgbGluZS4NCg0KL0xvYQ0KDQpPbiAyMDEzLTExLTA2IDA5OjU1LCBMb2Eg QW5kZXJzc29uIHdyb3RlOg0KPiBXb3JraW5nIEdyb3VwLA0KPg0KPiBUaGUgZWRpdG9ycyBhbmQg YXV0aG9ycyB3b3JrIHdpdGggdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIHRvIHByZXBhcmUNCj4g ZHJhZnQtcnlvb2dyYXktbXBscy10cC1wc2MtaXR1IGZvciB0aGUgcG9sbCB0byBzZWUgaWYgd2Ug aGF2ZSBjb25zZW5zdXMNCj4gdG8gYWRvcHQgaXQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 LiBJbiBvcmRlciB0byBleHBlZGl0ZSB0aGUNCj4gcHJvY2VzcyB3ZSB3aWxsIHN0YXJ0IHRoZSBJ UFIgcG9sbCBub3cuDQo+DQo+IFRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsLg0KPg0KPiBB cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LXJ5b29ncmF5LW1w bHMtdHAtcHNjLWl0dT8NCj4NCj4gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCj4gKHNlZSBSRkNzIDM5NzksIDQ4Nzks IDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+IElmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQo+ IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudA0KPiBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0 aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuKiBUaGUNCj4gZG9jdW1lbnRzIHdpbGwgbm90IGFkdmFu Y2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KPiBoYXMgYmVlbiByZWNlaXZl ZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4NCj4gSWYgeW91IGFyZSBvbiB0 aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IN Cj4gY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55DQo+IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2Vk IGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCj4NCj4gVGhhbmtzLCBMb2ENCj4gKGFz IE1QTFMgV0cgY28tY2hhaXIpDQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1h aWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVj aG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286A5926SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+SmVvbmctZG9uZzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi Pjxicj4NCjxicj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi IGlkPSJNYWlsU2lnbiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90OyAmbHQ7bG9hQHBp Lm51Jmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0xMS0wNyAwMzowMzoyMyAoICYjNDM7MDk6 MDAgKTxicj4NCjxiPlRvIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 LCBkcmFmdC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0 LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDssIG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnICZsdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDssIFZJR09V UkVVWCwgTUFSVElOIChNQVJUSU4pICZsdDttYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50 LmNvbSZndDs8YnI+DQo8Yj5DYyA6IDwvYj48YnI+DQo8Yj5TdWJqZWN0IDogPC9iPkNvcnJlY3Rp b246IElQUiBwb2xsIG9uIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dTxicj4NCjxicj4N Cjxicj4NCkZvbGtzLDxicj4NCjxicj4NCkEgc21hbGwgY29ycmVjdGlvbiBpbiB0aGUgc3ViamVj dCBsaW5lLjxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+DQpPbiAyMDEzLTExLTA2IDA5OjU1LCBM b2EgQW5kZXJzc29uIHdyb3RlOjxicj4NCiZndDsgV29ya2luZyBHcm91cCw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyB3b3JrIHdpdGggdGhlIHdvcmtpbmcgZ3Jv dXAgY2hhaXJzIHRvIHByZXBhcmU8YnI+DQomZ3Q7IGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNj LWl0dSBmb3IgdGhlIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzPGJyPg0KJmd0OyB0 byBhZG9wdCBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIEluIG9yZGVyIHRvIGV4cGVk aXRlIHRoZTxicj4NCiZndDsgcHJvY2VzcyB3ZSB3aWxsIHN0YXJ0IHRoZSBJUFIgcG9sbCBub3cu PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwuPGJyPg0K Jmd0Ozxicj4NCiZndDsgQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBk cmFmdC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHU/PGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgc28s IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXM8YnI+DQomZ3Q7IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBt b3JlIGRldGFpbHMpLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEg ZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvPGJyPg0KJmd0 OyB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBv ZiBhbnkgcmVsZXZhbnQ8YnI+DQomZ3Q7IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBz ZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZTxicj4NCiZndDsgZG9jdW1lbnRz IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZTxicj4N CiZndDsgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3Iu PGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0 IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3I8YnI+DQomZ3Q7IGNvbnRyaWJ1dG9y LCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9m IGFueTxicj4NCiZndDsgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29u Zm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcywgTG9h PGJyPg0KJmd0OyAoYXMgTVBMUyBXRyBjby1jaGFpcik8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+ DQo8YnI+DQpMb2EgQW5kZXJzc29uIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208YnI+DQpT ZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29u c3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286A5926SMTP2etriinfo_-- From eosborne@cisco.com Wed Nov 6 10:34:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1D11E8127 for ; Wed, 6 Nov 2013 10:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.699 X-Spam-Level: X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3U+0mv7-Sap for ; Wed, 6 Nov 2013 10:34:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 06A1C11E8115 for ; Wed, 6 Nov 2013 10:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1747; q=dns/txt; s=iport; t=1383762847; x=1384972447; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JBlKmDWl1TnEniCva1di2Sn87scpILCvAs1b5+mbM6s=; b=gJAjEDK18+pNZ5VXPwMZLmZqg6UEP2uzxHvcS01TEGfUFlfd6pEgsmKI nLRlb76/9+nIKLwwzG5RLggNmPMuKnG6MfUS4eqJzb1CR1LXwou2Z31J0 r7P+bQRLSXiH0F+CiODiwF/KKwGrTocRNhUtEvga9wbw0bh2fPReXWxeq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAO2KelKtJXG+/2dsb2JhbABagweBC782gSYWdIIlAQEBBDoxAwYRAgICAQgRBAEBCxQJBxsXFAkIAgQBEgiHeb8jBI4MEIEIOAaDGoEQA5QslWqDJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="281615810" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 06 Nov 2013 18:34:05 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA6IY4NC005910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 18:34:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 12:34:04 -0600 From: "Eric Osborne (eosborne)" To: Loa Andersson , "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: IPT poll on draft-ryoogray-mpls-tp-psc-itu Thread-Index: AQHO2xl3SFWTstl0UU+MSv2iqulbb5oYh0fg Date: Wed, 6 Nov 2013 18:34:04 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210456340@xmb-rcd-x09.cisco.com> References: <527A829D.40704@pi.nu> In-Reply-To: <527A829D.40704@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] IPT poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:34:12 -0000 I am not aware of any IPR that applies to this draft. eric > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, November 06, 2013 9:56 AM > To: mpls@ietf.org; draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: IPT poll on draft-ryoogray-mpls-tp-psc-itu >=20 > Working Group, >=20 > The editors and authors work with the working group chairs to prepare > draft-ryoogray-mpls-tp-psc-itu for the poll to see if we have consensus > to adopt it as a working group document. In order to expedite the > process we will start the IPR poll now. >=20 > This mail starts the IPR poll. >=20 > Are you aware of any IPR that applies to draft-ryoogray-mpls-tp-psc-itu? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > 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 contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From cts@etri.re.kr Wed Nov 6 11:06:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDE121E816E for ; Wed, 6 Nov 2013 11:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMdOGmc7-0O5 for ; Wed, 6 Nov 2013 11:06:24 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9753E21E8087 for ; Wed, 6 Nov 2013 11:06:22 -0800 (PST) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 7 Nov 2013 04:06:18 +0900 Received: from SMTP4.etri.info ([169.254.3.218]) by SMTP3.etri.info ([169.254.157.203]) with mapi id 14.01.0355.002; Thu, 7 Nov 2013 04:06:14 +0900 From: Taesik Cheung To: Loa Andersson , "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu Thread-Index: AQHO2xp7p3ABykmPnUea+iVZmu6bs5oYj1QN Date: Wed, 6 Nov 2013 19:06:14 +0000 Message-ID: References: <527A829D.40704@pi.nu>,<527A845F.3030603@pi.nu> In-Reply-To: <527A845F.3030603@pi.nu> Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: VGFlc2lrIENoZXVuZw== x-originating-ip: [129.254.28.45] Content-Type: multipart/alternative; boundary="_000_AD98114A73E97041A2EDDCC3F3D10B032BA37A86SMTP4etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:06:30 -0000 --_000_AD98114A73E97041A2EDDCC3F3D10B032BA37A86SMTP4etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpUYWVzaWsNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb20gOiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NClNlbnQgOiAyMDEz LTExLTA3IDAzOjAzOjIzICggKzA5OjAwICkNClRvIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRm Lm9yZz4sIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyA8ZHJh ZnQtcnlvb2dyYXktbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwgbXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwgVklHT1VSRVVYLCBN QVJUSU4gKE1BUlRJTikgPG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tPg0KQ2Mg Og0KU3ViamVjdCA6IENvcnJlY3Rpb246IElQUiBwb2xsIG9uIGRyYWZ0LXJ5b29ncmF5LW1wbHMt dHAtcHNjLWl0dQ0KDQoNCkZvbGtzLA0KDQpBIHNtYWxsIGNvcnJlY3Rpb24gaW4gdGhlIHN1Ympl Y3QgbGluZS4NCg0KL0xvYQ0KDQpPbiAyMDEzLTExLTA2IDA5OjU1LCBMb2EgQW5kZXJzc29uIHdy b3RlOg0KPiBXb3JraW5nIEdyb3VwLA0KPg0KPiBUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyB3b3Jr IHdpdGggdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIHRvIHByZXBhcmUNCj4gZHJhZnQtcnlvb2dy YXktbXBscy10cC1wc2MtaXR1IGZvciB0aGUgcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5z dXMNCj4gdG8gYWRvcHQgaXQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBJbiBvcmRlciB0 byBleHBlZGl0ZSB0aGUNCj4gcHJvY2VzcyB3ZSB3aWxsIHN0YXJ0IHRoZSBJUFIgcG9sbCBub3cu DQo+DQo+IFRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsLg0KPg0KPiBBcmUgeW91IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0 dT8NCj4NCj4gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMNCj4gKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUz NzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQo+IHRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dA0KPiBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyB3ZyBt YWlsaW5nIGxpc3QuKiBUaGUNCj4gZG9jdW1lbnRzIHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KPiBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2gg YXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4NCj4gSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBl bWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCj4gY29udHJpYnV0 b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUg b2YgYW55DQo+IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1h bmNlIHdpdGggSUVURiBydWxlcy4NCj4NCj4gVGhhbmtzLCBMb2ENCj4gKGFzIE1QTFMgV0cgY28t Y2hhaXIpDQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWku Y29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChj b25zdWx0YW50KSBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K --_000_AD98114A73E97041A2EDDCC3F3D10B032BA37A86SMTP4etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+VGFlc2lrPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCIgaWQ9Ik1haWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJMSU5FLUhFSUdIVDogMTVwdCI+PGI+RnJvbSA6IDwvYj4mcXVvdDtMb2EgQW5kZXJzc29uJnF1 b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTExLTA3IDAzOjAz OjIzICggJiM0MzswOTowMCApPGJyPg0KPGI+VG8gOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBs c0BpZXRmLm9yZyZndDssIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRm Lm9yZyAmbHQ7ZHJhZnQtcnlvb2dyYXktbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnJmd0 OywgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnJmd0OywgVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikgJmx0O21hcnRpbi52aWdvdXJldXhA YWxjYXRlbC1sdWNlbnQuY29tJmd0Ozxicj4NCjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3Qg OiA8L2I+Q29ycmVjdGlvbjogSVBSIHBvbGwgb24gZHJhZnQtcnlvb2dyYXktbXBscy10cC1wc2Mt aXR1PGJyPg0KPGJyPg0KPGJyPg0KRm9sa3MsPGJyPg0KPGJyPg0KQSBzbWFsbCBjb3JyZWN0aW9u IGluIHRoZSBzdWJqZWN0IGxpbmUuPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCk9uIDIwMTMt MTEtMDYgMDk6NTUsIExvYSBBbmRlcnNzb24gd3JvdGU6PGJyPg0KJmd0OyBXb3JraW5nIEdyb3Vw LDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBlZGl0b3JzIGFuZCBhdXRob3JzIHdvcmsgd2l0aCB0 aGUgd29ya2luZyBncm91cCBjaGFpcnMgdG8gcHJlcGFyZTxicj4NCiZndDsgZHJhZnQtcnlvb2dy YXktbXBscy10cC1wc2MtaXR1IGZvciB0aGUgcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5z dXM8YnI+DQomZ3Q7IHRvIGFkb3B0IGl0IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gSW4g b3JkZXIgdG8gZXhwZWRpdGUgdGhlPGJyPg0KJmd0OyBwcm9jZXNzIHdlIHdpbGwgc3RhcnQgdGhl IElQUiBwb2xsIG5vdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIG1haWwgc3RhcnRzIHRoZSBJ UFIgcG9sbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0dT88YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlczxicj4NCiZndDsgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3Bv bmQgdG88YnI+DQomZ3Q7IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudDxicj4NCiZndDsgSVBSLiAqVGhlIHJlc3BvbnNl IG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiogVGhlPGJyPg0K Jmd0OyBkb2N1bWVudHMgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBh IHJlc3BvbnNlPGJyPg0KJmd0OyBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFu ZCBjb250cmlidXRvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB5b3UgYXJlIG9uIHRoZSBNUExT IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcjxicj4NCiZn dDsgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55PGJyPg0KJmd0OyBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRp c2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhhbmtzLCBMb2E8YnI+DQomZ3Q7IChhcyBNUExTIFdHIGNvLWNoYWlyKTxicj4NCjxicj4N Ci0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVh d2VpLmNvbTxicj4NClNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVj aG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD98114A73E97041A2EDDCC3F3D10B032BA37A86SMTP4etriinfo_-- From huubatwork@gmail.com Wed Nov 6 16:35:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7915C21E8191 for ; Wed, 6 Nov 2013 16:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVFqxh-kVt9m for ; Wed, 6 Nov 2013 16:35:50 -0800 (PST) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0111E815E for ; Wed, 6 Nov 2013 16:35:44 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id b11so113439eae.39 for ; Wed, 06 Nov 2013 16:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QdjP/UcRd4ik9PqdtcyKiPU0tPrLzWHnyxV3XFFXfhM=; b=SFbJuYM9oefqfNcLj4vByHqL2havn6IP4/T0nCU4VuL/Jvo3zB/d52IfRIl6TX3/SV gZJpfYhV52XOAzIDdj5k6qgmZiIw5Jvdg6XsGnAS1rJHJJ3JlgiayANjMAU3uc9baYuU 07yGLhNToFxE319xQoomabxztTVcjAl8TH1iaFcjHenpDxVxa2XKmtV7zYrnZeOY3zil E7EFn56JcR1avF32sjtAdwFSa4j0HWU1ZwmV1b/bDpQOLIADAgZy5ruD8c6bBAXHTcc3 Ivxwxo6kiwCQ/qfQBQ2HfWON0GLa6HJZJqK9E4no3TzNY5/htUr177UvOyfG79VXYt2n MqxA== X-Received: by 10.15.45.135 with SMTP id b7mr699297eew.135.1383784544242; Wed, 06 Nov 2013 16:35:44 -0800 (PST) Received: from dhcp-a40e.meeting.ietf.org (dhcp-a40e.meeting.ietf.org. [31.133.164.14]) by mx.google.com with ESMTPSA id h8sm2053900eew.16.2013.11.06.16.35.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 16:35:43 -0800 (PST) Message-ID: <527AE05E.8000602@gmail.com> Date: Thu, 07 Nov 2013 01:35:42 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <527A829D.40704@pi.nu> In-Reply-To: <527A829D.40704@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] IPT poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:35:51 -0000 I am not aware if any IPR that applies to this draft, Regards, Huub (van Helvoort) ============== > Working Group, > > The editors and authors work with the working group chairs to prepare > draft-ryoogray-mpls-tp-psc-itu for the poll to see if we have consensus > to adopt it as a working group document. In order to expedite the > process we will start the IPR poll now. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ryoogray-mpls-tp-psc-itu? > > 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 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) -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From eric.gray@ericsson.com Wed Nov 6 17:24:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6111E81DC for ; Wed, 6 Nov 2013 17:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZEHkLlGS8eV for ; Wed, 6 Nov 2013 17:24:13 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AE36A11E81BC for ; Wed, 6 Nov 2013 17:24:13 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-fc-527aebbc0140 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 15.38.04556.CBBEA725; Thu, 7 Nov 2013 02:24:13 +0100 (CET) Received: from EUSAAMB104.ericsson.se ([147.117.188.121]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 20:24:12 -0500 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu Thread-Index: AQHO2xp/3pa2Sw1yMUqQxSHCxcQkgJoY+bFQ Date: Thu, 7 Nov 2013 01:24:12 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF63298FBEB@eusaamb104.ericsson.se> References: <527A829D.40704@pi.nu> <527A845F.3030603@pi.nu> In-Reply-To: <527A845F.3030603@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPgu7e11VBBiv7BS0mXO9mtPg3dw6z xZ1dX1gtvl9awmJxa+lKVgdWj9Zne1k9liz5yeQxa3obm8eXy5/ZAliiuGxSUnMyy1KL9O0S uDJ+Tv7OWrCUr6JlYx9zA+NM7i5GTg4JAROJeTsfMUHYYhIX7q1n62Lk4hASOMIocbpnJhOE s4xRYuqziYwgVWwCGhLH7qxlBEmICCxjkngy+wcLSEJYwEWifVEbmC0i4CrxbQHIKBDbSOLS +zVgcRYBFYndc6+A2bwCvhLf5v1jB7GFBKwlHu5+AHYGp4CqxKLTF1hBbEagk76fWgMWZxYQ l7j1ZD7UqQISS/acZ4awRSVePv7HCmErS3yf84gFol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmE ZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAmPomASb4w7GBZ8sDzFKc7AoifN+ eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRoerhn33yN+KXm19ztSlvTreZtaa7jP/O Juk6jYJP14X/RjWHrHu8QXB+nMOMdcnW6e1n9V9+9ZKdsirj+K6IZv+FU2MWzmpPLm/5ONlC /3+DzzLb/DtLq9iucS09Hi0ZGfI1aEbzg2d82wOTBL8qlr2aMTNX27fkrdf1afncE8tUor7d mbtQiaU4I9FQi7moOBEAD+WvWm8CAAA= Subject: Re: [mpls] Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:24:20 -0000 I am unaware of IPR related to this draft. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, November 06, 2013 1:03 PM To: mpls@ietf.org; draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org; mpls-chai= rs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu Folks, A small correction in the subject line. /Loa On 2013-11-06 09:55, Loa Andersson wrote: > Working Group, > > The editors and authors work with the working group chairs to prepare=20 > draft-ryoogray-mpls-tp-psc-itu for the poll to see if we have=20 > consensus to adopt it as a working group document. In order to=20 > expedite the process we will start the IPR poll now. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ryoogray-mpls-tp-psc-itu? > > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > 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 documents will not advance to the next stage until a=20 > 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=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that 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 From nobo@cisco.com Wed Nov 6 23:51:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6811E8177 for ; Wed, 6 Nov 2013 23:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxcUcpddlAzT for ; Wed, 6 Nov 2013 23:51:26 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E78DE11E8141 for ; Wed, 6 Nov 2013 23:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=933; q=dns/txt; s=iport; t=1383810686; x=1385020286; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=y1ap8IrXnxJDv/IhC1IjZA0+dkX+SSVt3ui3ss8KI50=; b=iZGXwleESqTmvTr5I2aIgLE896488oxwAVcfmFnE9ENmDDk+9d0u80qx sbJ+5BrNjh8Y6m5mtLjtt5XyddFRR+/CUjGGiwuXqcISQHTr4CAwheZkI maHsZeHyb8XJvwAnrpgBEq6irdw5qWkBG4M2wl1sf82f2kQrtVOiein6o A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAAtFe1KtJXG+/2dsb2JhbABZgmYhgQu/DIEjFm0HgiUBAQEDATo/BQ0BKhRCJgEEDg0Th2AGAb4FjgeBITGDJ4EQA6oWgyaCKg X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="281805290" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2013 07:51:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA77pPV9011631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 07:51:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 01:51:24 -0600 From: "Nobo Akiya (nobo)" To: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: Comment on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac7bieAe3j4zI+A+Rcq0NrmUMXL15g== Date: Thu, 7 Nov 2013 07:51:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comment on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:51:31 -0000 Hi Authors, I didn't get a chance to comment on your draft at the WG session today, so = sending to the list. My concern is similar to what Greg Mirsky stated. Simp= ly running 2 independent BFD sessions (as described in the slides) will hav= e issues. > 3. Ingress Failure Detection >=20 > Exactly how the failure of the ingress (e.g. R1 in Figure 1) is > detected is out of scope for this document. I believe, at least, definition of the "failure" should be defined in the d= raft. Without it, it can be interpreted by readers as complete node outage,= outage of all involved links, outage of just primary-backup link, or even = something else. And without defining what the "failure" is, it's difficult = to figure out the right techniques to detect the failure. And that can easi= ly result in deviating detection implementations for described solution to = not kick off in expected manner. -Nobo From nobo@cisco.com Thu Nov 7 00:02:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA211E8250 for ; Thu, 7 Nov 2013 00:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plzvxTJmkxKx for ; Thu, 7 Nov 2013 00:02:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3861B11E817B for ; Thu, 7 Nov 2013 00:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=593; q=dns/txt; s=iport; t=1383811358; x=1385020958; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/8J38Yml0/5lBcw9MSAoc7eiuwyVyw/SPl4LccZUFxI=; b=KhOgGthJdsVkWTwrBo+pANVOHiR0MTBclU8gyJM/xTv+Nilu/Al92maL 6ne53UsxSh8C0HbsMCvmcZdsjmF103Qh7UZjGr3fJ7ztvmI6/Bwj2StzL SoxajL0PNFs3gQHYtLjxzwozwHHizqV0vPHjlpWaqHkYJy0PZTZ7+99lz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAJZIe1KtJXHB/2dsb2JhbABZgmYhgQu/DIEjFm0HgicBBDo/EgEqFEImAQQODYd5Ab13jygxgyeBEAOULJVqgyaCKg X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="281795771" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 07 Nov 2013 08:02:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA782bZB022824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 08:02:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 02:02:37 -0600 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac7bjm3cTBhLnI0pTpa7M681uYyPWw== Date: Thu, 7 Nov 2013 08:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:02:56 -0000 Hi MPLS WG Members, First of all, thanks for many comments during WG session on Tuesday. A. For new TLV processing by responder, we will review for further error co= nditions and introduce new error code if we see the need. B. For pre-defined preference Reply Mode: Current proposed order: 1. control-channel 2. reverse-lsp 3. IP path That was what author felt as a reasonable order based on input from some, a= t the time of writing the draft. However, we would like to seek for further= input from others in the WG, particularly from operators. Thanks! -Nobo From nobo@cisco.com Thu Nov 7 00:23:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B383321E80D1 for ; Thu, 7 Nov 2013 00:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBNJpFvxOtD7 for ; Thu, 7 Nov 2013 00:23:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2350D21E80B8 for ; Thu, 7 Nov 2013 00:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1383812580; x=1385022180; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=fNVungvaM+yzqfT5CROWpPiqZpUzUPqBAjAOMPwz5Xo=; b=OI4xdYa15ZUEvZEEU4l7PWGeeXvKVeiESD2VmBtQYULk/TMPfqcfrHoz KweqcgXrDqcaWe83cYax1hJ91lpYMY76SZYVxUeyijcqJKHbGPx+jzrBC 4Oo34OAfYAM2ALrzGKhD141koCnMKQ4nZKWaVmY/fA4i38gHkq7+KymEM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUGAHxNe1KtJXG8/2dsb2JhbABZgmYhgQu/DYEjFm0HgiUBAQEDATo/BQ0BKhRCJgEEDg2HcwYBvXmPKDGDJ4EQA6oWgyaCKg X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="281776934" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2013 08:22:59 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA78Mx0E019002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 08:22:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 02:22:59 -0600 From: "Nobo Akiya (nobo)" To: "draft-ravisingh-mpls-el-for-seamless-mpls@tools.ietf.org" Thread-Topic: Comments on draft-ravisingh-mpls-el-for-seamless-mpls Thread-Index: Ac7bkJ2xL0omkkvnRZ2jAuXiLdjyFQ== Date: Thu, 7 Nov 2013 08:22:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comments on draft-ravisingh-mpls-el-for-seamless-mpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:23:05 -0000 Hi Ravi, Yimin, I have couple of comments. 1. Stitched LSP - Proposed really offers optimization in stitched scenario. a. Allows EL usage for even wider than just EL capable segments. b. Potentially speeds data traversal over stitched LSP as number of times E= LI/EL popped/pushed are reduced. Document sort of eludes to this, but I think it'll be beneficial to state t= hat things will work as is (RFC6790), but proposal can be used as optimizat= ion. 2. Hierarchical LSP > B. Preventing multiple (ELI+EL) pairs underneath a given forwarding > label in the stack: I highly support above statement. Having multiple ELs in the stack will, ye= t again, cause more changes required in LSP traceroute wrt multipath inform= ation handling, and requires even more complex computation by initiator to = traverse ECMP paths. -Nobo From alessandro.dalessandro@telecomitalia.it Thu Nov 7 00:55:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B627921E815C for ; Thu, 7 Nov 2013 00:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3YgpD0kXJs0 for ; Thu, 7 Nov 2013 00:55:49 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA4221E812B for ; Thu, 7 Nov 2013 00:55:46 -0800 (PST) Content-Type: multipart/mixed; boundary="_e9af9c96-b6fe-41f6-af29-0c228410a862_" Received: from TELHUB002RM001.telecomitalia.local (10.19.3.67) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 7 Nov 2013 09:55:44 +0100 Received: from TELMBB002RM001.telecomitalia.local ([169.254.3.199]) by TELHUB002RM001.telecomitalia.local ([10.19.3.67]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 09:55:44 +0100 From: D'Alessandro Alessandro Gerardo To: "loa@pi.nu" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu Thread-Index: Ac7blyRfKNP6XdpGWUGEAvd0uKOqkQ== Date: Thu, 7 Nov 2013 08:55:44 +0000 Message-ID: <2uuhygh2ytf9xixii9cjgay2.1383814615268@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [mpls] R: Correction: IPR poll on draft-ryoogray-mpls-tp-psc-itu X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:55:54 -0000 --_e9af9c96-b6fe-41f6-af29-0c228410a862_ Content-Type: multipart/alternative; boundary="_000_2uuhygh2ytf9xixii9cjgay21383814615268emailandroidcom_" --_000_2uuhygh2ytf9xixii9cjgay21383814615268emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG5vdCBhd2FyZSBvZiBhbnkgaXByIHJlbGV2YW50IHRvIHRoZSBkcmFmdCBpbiB0aGUgc3Vi amVjdA0KQnINCkFsZXNzYW5kcm8NCg0KSW52aWF0byBkYSBTYW1zdW5nIE1vYmlsZQ0KDQoNCg0K LS0tLS0tLS0gTWVzc2FnZ2lvIG9yaWdpbmFsZSAtLS0tLS0tLQ0KT2dnZXR0bzpDb3JyZWN0aW9u OiBJUFIgcG9sbCBvbiBkcmFmdC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHUNCkRhOkxvYSBBbmRl cnNzb24gPGxvYUBwaS5udT4NCkE6Im1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPiwiZHJh ZnQtcnlvb2dyYXktbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtcnlvb2dy YXktbXBscy10cC1wc2MtaXR1QHRvb2xzLmlldGYub3JnPiwibXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmciIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4sIlZJR09VUkVVWCwgTUFSVElOIChN QVJUSU4pIiA8bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+DQpDYzoNCg0KDQpG b2xrcywNCg0KQSBzbWFsbCBjb3JyZWN0aW9uIGluIHRoZSBzdWJqZWN0IGxpbmUuDQoNCi9Mb2EN Cg0KT24gMjAxMy0xMS0wNiAwOTo1NSwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4gV29ya2luZyBH cm91cCwNCj4NCj4gVGhlIGVkaXRvcnMgYW5kIGF1dGhvcnMgd29yayB3aXRoIHRoZSB3b3JraW5n IGdyb3VwIGNoYWlycyB0byBwcmVwYXJlDQo+IGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0 dSBmb3IgdGhlIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzDQo+IHRvIGFkb3B0IGl0 IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gSW4gb3JkZXIgdG8gZXhwZWRpdGUgdGhlDQo+ IHByb2Nlc3Mgd2Ugd2lsbCBzdGFydCB0aGUgSVBSIHBvbGwgbm93Lg0KPg0KPiBUaGlzIG1haWwg c3RhcnRzIHRoZSBJUFIgcG9sbC4NCj4NCj4gQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg YXBwbGllcyB0byBkcmFmdC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHU/DQo+DQo+IElmIHNvLCBo YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzDQo+IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp bHMpLg0KPg0KPiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250 cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bw0KPiB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQNCj4gSVBSLiAqVGhlIHJl c3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiogVGhl DQo+IGRvY3VtZW50cyB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEg cmVzcG9uc2UNCj4gaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJp YnV0b3IuDQo+DQo+IElmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQo+IGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBl eHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPiBJUFIgdGhh dCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuDQo+DQo+IFRoYW5rcywgTG9hDQo+IChhcyBNUExTIFdHIGNvLWNoYWlyKQ0KDQotLQ0KDQoN CkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5o dWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxv YUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5k aXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4g UXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0 ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBh bCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4N Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDow MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwn YW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4N Cg0K --_000_2uuhygh2ytf9xixii9cjgay21383814615268emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <22F69058ADAD1A48A40CDB47FB262332@telecomitalia.local> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KSSdtIG5vdCBhd2Fy ZSBvZiBhbnkgaXByIHJlbGV2YW50IHRvIHRoZSBkcmFmdCBpbiB0aGUgc3ViamVjdA0KPGRpdj5C cjwvZGl2Pg0KPGRpdj5BbGVzc2FuZHJvPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4NyUiPkludmlhdG8gZGEgU2Ftc3VuZyBNb2JpbGU8L3NwYW4+PC9kaXY+DQo8YnI+DQo8YnI+ DQo8YnI+DQotLS0tLS0tLSBNZXNzYWdnaW8gb3JpZ2luYWxlIC0tLS0tLS0tPGJyPg0KT2dnZXR0 bzpDb3JyZWN0aW9uOiBJUFIgcG9sbCBvbiBkcmFmdC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHU8 YnI+DQpEYTpMb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KQTomcXVvdDttcGxz QGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OywmcXVvdDtkcmFmdC1yeW9vZ3Jh eS1tcGxzLXRwLXBzYy1pdHVAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LXJ5b29ncmF5 LW1wbHMtdHAtcHNjLWl0dUB0b29scy5pZXRmLm9yZyZndDssJnF1b3Q7bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0OywmcXVv dDtWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKSZxdW90OyAmbHQ7bWFydGluLnZpZ291cmV1eEBh bGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0KQ2M6PGJyPg0KPGJyPg0KPGJyPg0KPGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRl eHQiPkZvbGtzLDxicj4NCjxicj4NCkEgc21hbGwgY29ycmVjdGlvbiBpbiB0aGUgc3ViamVjdCBs aW5lLjxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+DQpPbiAyMDEzLTExLTA2IDA5OjU1LCBMb2Eg QW5kZXJzc29uIHdyb3RlOjxicj4NCiZndDsgV29ya2luZyBHcm91cCw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGUgZWRpdG9ycyBhbmQgYXV0aG9ycyB3b3JrIHdpdGggdGhlIHdvcmtpbmcgZ3JvdXAg Y2hhaXJzIHRvIHByZXBhcmU8YnI+DQomZ3Q7IGRyYWZ0LXJ5b29ncmF5LW1wbHMtdHAtcHNjLWl0 dSBmb3IgdGhlIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzPGJyPg0KJmd0OyB0byBh ZG9wdCBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIEluIG9yZGVyIHRvIGV4cGVkaXRl IHRoZTxicj4NCiZndDsgcHJvY2VzcyB3ZSB3aWxsIHN0YXJ0IHRoZSBJUFIgcG9sbCBub3cuPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwuPGJyPg0KJmd0 Ozxicj4NCiZndDsgQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm dC1yeW9vZ3JheS1tcGxzLXRwLXBzYy1pdHU/PGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgc28sIGhh cyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs ZXM8YnI+DQomZ3Q7IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3Jl IGRldGFpbHMpLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9j dW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvPGJyPg0KJmd0OyB0 aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh bnkgcmVsZXZhbnQ8YnI+DQomZ3Q7IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50 IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZTxicj4NCiZndDsgZG9jdW1lbnRzIHdp bGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZTxicj4NCiZn dDsgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPGJy Pg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1 dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3I8YnI+DQomZ3Q7IGNvbnRyaWJ1dG9yLCB0 aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFu eTxicj4NCiZndDsgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcywgTG9hPGJy Pg0KJmd0OyAoYXMgTVBMUyBXRyBjby1jaGFpcik8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8 YnI+DQpMb2EgQW5kZXJzc29uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVtYWlsOiBsb2FAbWFp bDAxLmh1YXdlaS5jb208YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbG9hQHBpLm51PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29u c3VsdGFudCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIx IDY0PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8 IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQot LT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWw7IGZv bnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0iMzk1 Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6aW9uZSBk ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmln b3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBk aXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWduPSJqdXN0 aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBs aW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxzcGFuIGNs YXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5z aS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFuPjwvcD4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZlcmRhbmEi PjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEkuRGlzY2xh aW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0iNDAiPlJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVj ZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2uuhygh2ytf9xixii9cjgay21383814615268emailandroidcom_-- --_e9af9c96-b6fe-41f6-af29-0c228410a862_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_e9af9c96-b6fe-41f6-af29-0c228410a862_-- From lizho.jin@gmail.com Thu Nov 7 07:17:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B21621E82A9 for ; Thu, 7 Nov 2013 07:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwdO2LM9zYMm for ; Thu, 7 Nov 2013 07:17:32 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A021E82B2 for ; Thu, 7 Nov 2013 07:17:05 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so723079pdj.5 for ; Thu, 07 Nov 2013 07:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=yZLTpLbH2R2R7DEFSxj5h2H/qjyIcxQ+LKW/VBhhrSY=; b=plnHZtFRi5zrom6SzmWeWBIb5puBX7sFscKzBxgoxAhFlfuoTZojM3SFpMgyzsAKVP J+SW6i+jGUGmYawNx32ou6TpdvF4+YNCyCG44GrhFRKcMwhhRPdvE7TecekbQkVeHBcu mJ+35uW3ONtmRs2vvpSSTIS48ch5eyrl0utz0hYusXyaWe76Mx2EsqIzGhEpo6+L+5/n UiLLImneLmt+mZnw/szFyOofqwhEDL4afrKGQIRPdL0lai4lPj+7v8vsT8jJxdg5pbnY BS420c/vTGeS4vrLrIciy1r7NDDfpSEuM+jQULNCddfxgVaqx51a4aQyfJBK3EhLBL+Q Lihw== X-Received: by 10.66.235.106 with SMTP id ul10mr10011057pac.19.1383837425317; Thu, 07 Nov 2013 07:17:05 -0800 (PST) Received: from LizhongPC ([114.62.211.56]) by mx.google.com with ESMTPSA id og5sm5733087pbb.10.2013.11.07.07.17.00 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Nov 2013 07:17:04 -0800 (PST) From: "Lizhong Jin" To: "'Loa Andersson'" , "'Dutta, Pranjal K \(Pranjal\)'" , , "'Curtis Villamizar'" , , , "'VIGOUREUX, MARTIN \(MARTIN\)'" , References: <526DDCFE.6060403@pi.nu> In-Reply-To: <526DDCFE.6060403@pi.nu> Date: Thu, 7 Nov 2013 23:16:56 +0800 Message-ID: <527baef0.c582440a.6058.345d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7Tj6YNqagsltOnQQWCjikHXKk95gF3/7sw Content-Language: zh-cn Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:17:33 -0000 Hi Authors, I am reviewing this draft as MPLS-RT review. Overall the document is = technically sound, and I need some clarification from the authors before = adoption. I also review draft-rekhter-mpls-pim-sm-over-mldp, and both = the two drafts are technically feasible to set up a (*, G) tree. Whether = adopting the two methods is left to the WG to decide. 1. section 5,=20 If PIM is not enabled for group G, and an IGMP/MLD group membership report for G has been received, the Egress LSR may determine the "proxy device" for G (following the procedures defined in [RFC4605]). It can then set up an MP-LSP using the proxy device as the Ingress LSR. =20 [Lizhong] I am confused here by the description in section 4.2. In = section 4.2, it is said, the ingress LSR is manually configured, not = discovered by procedures defined in RFC4605. 2. section 5, If PIM is enabled and the identified group is a PIM-SSM group, all multicast sources known for the group on the Ingress LSR are to be forwarded down the MP-LSP. [Lizhong] Is it assumed that the PIM-SSM MP-LSP is already there, = and the new wildcard source based MP-LSP is only to aggregate the = PIM-SSM MP-LSP? In that case, will the original PIM-SSM MP-LSP still be = kept or be deleted by egress LSR? It is not clear here for PIM-SSM case. 3. section 5, If PIM is not enabled for identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. [Lizhong] For point 1&3, the dataplane behavior is missing. E.g, = all multicast traffic with group address G SHOULD be forwarded to the = MP-LSP. 4. Section 6.=20 [Lizhong] it seems the section 6 procedure is specifically described for = static multicast use case described in section 4.3, right? Otherwise, if = the stream has PIM-SSM address, will the original PIM-SSM MP-LSP still = be kept or be deleted by egress LSR? Regards Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, October 28, 2013 11:42 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.manral@hp.com; > Curtis Villamizar; draft-wijnands-mpls-mldp-in-band-wildcard- > encoding@tools.ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > (MARTIN) > Subject: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard- > encoding >=20 > Lizhong, Pranjal, Vishwas and Curtis, >=20 > You have been selected as an MPLS Review team reviewers for > draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01. >=20 > 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. >=20 > 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). >=20 > Reviews should be sent to the document authors, WG co-chairs and > secretary, and CC'd to the MPLS WG email list. If necessary, comments > may be sent privately to only the WG chairs. >=20 > Are you able to review this draft by November 11, 2013? >=20 >=20 > Thanks, Loa > (as MPLS WG chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu Nov 7 09:21:59 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568F221E8205 for ; Thu, 7 Nov 2013 09:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M68aBhxtJrJV for ; Thu, 7 Nov 2013 09:21:53 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7E21E81EE for ; Thu, 7 Nov 2013 09:21:37 -0800 (PST) Received: from [31.133.167.83] (dhcp-a753.meeting.ietf.org [31.133.167.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E117C18014F6; Thu, 7 Nov 2013 18:21:36 +0100 (CET) Message-ID: <527BCC20.3070202@pi.nu> Date: Thu, 07 Nov 2013 09:21:36 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "mpls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:21:59 -0000 Folks, On 2013-11-07 00:02, Nobo Akiya (nobo) wrote: > > B. For pre-defined preference Reply Mode: > > Current proposed order: > 1. control-channel > 2. reverse-lsp > 3. IP path > > That was what author felt as a reasonable order based on input from some, at the time of writing the draft. However, we would like to seek for further input from others in the WG, particularly from operators. Thanks! I can understand why we came up with with this order of preference; I can also understand the logic behind what Curtis said "If the IP path is there, use that! It will always work" However thinking about it I'm more and more convinced that the order of preference need to established not as something that is once and for all fixed by the standard. I think that the operator would benefit from be able to decide the order of preference at configuration time. /Loa > > -Nobo > > _______________________________________________ > 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 aldrin.ietf@gmail.com Thu Nov 7 10:41:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9E321E8222 for ; Thu, 7 Nov 2013 10:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CsvAquI9IMy for ; Thu, 7 Nov 2013 10:41:13 -0800 (PST) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E864521E814E for ; Thu, 7 Nov 2013 10:40:40 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id mx11so394969bkb.31 for ; Thu, 07 Nov 2013 10:40:24 -0800 (PST) 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=pRrJIIKIzWS5+OJknong9YNek4XCOSlJ1ENj4+DkOpo=; b=Y1oSyLOwIl5w6xk9l6prXAiGyTTC0afmPKnZOKmltDIe51w+LIE7pHOo/NCG3O2I4I nGqp0Es3TbQm4X2ajwdo0+FfNwE5Wb8uO9w/cjHYDKMMmTfPv/+IGgLd9eende78nqHx Uo+X8QXL7IRw1SrNKlQbzusHxMo/xlep5eyHrgxbfvGeyXUh+KjQC7cQAusPpeYFsDHR zs/YacgssLQOIUtIscL5OAZkG+C8urlWF2dHnvKIsSbc3HfsYgFrsTNYjXiDfNhop2E5 y86ABK/gk4fpW2K8nAKsLHUMxOLXiNPVNTOKIrkhS55Nr+XSucn6zQLKwS87WzSLSepG ZldQ== X-Received: by 10.204.247.71 with SMTP id mb7mr7518278bkb.7.1383849624009; Thu, 07 Nov 2013 10:40:24 -0800 (PST) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:5cdd:e353:c670:b4d3]) by mx.google.com with ESMTPSA id pk7sm3237543bkb.2.2013.11.07.10.40.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 10:40:23 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sam Aldrin In-Reply-To: Date: Thu, 7 Nov 2013 10:40:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1816) Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:41:16 -0000 Hi Nobo and authors, I have few comments about this draft, which I raised in the meeting as = well. - Why do you need a new reply mode 6, when reply mode 4 and 5 (via = another draft) are already present? If you think reply mode 5 doesn=92t = suffice the need to support reverse LSP, then the = should be fixed rather than introduce another = mode. - As others pointed out, IP is the best option available for all FEC = types, albeit TP LSP. - Regarding the order of preference, my opinion is, the source should = select the preference of the reply mode. The existing reply modes does = exactly that. Receiver should not chose different reply mode to what was = sent by source. Agree with draft on that aspect and neither does the = existing RFC4379 does differently. - Regarding multiple reply options and preference within a single = request, I see it as more of optimization solution for the OAM workflow. = The cost incurred to support the new type is too high and do not support = adding one more mode. Would like to keep it simple as it is, without = these new changes required on the network device, while it could be = achieved by the application/user without any change. Draft specific comment (though I do not prefer multiple return types in = the first place :D) - Sec 3.3 point #5 , is incorrect. TLV should allow this. Reason is, if = the first preferred return mode could not be supported, one could use = reply mode 1 as next preference, where it will not reply. cheers -sam On Nov 7, 2013, at 12:02 AM, Nobo Akiya (nobo) wrote: > Hi MPLS WG Members, >=20 > First of all, thanks for many comments during WG session on Tuesday. >=20 > A. For new TLV processing by responder, we will review for further = error conditions and introduce new error code if we see the need. >=20 > B. For pre-defined preference Reply Mode: >=20 > Current proposed order: > 1. control-channel > 2. reverse-lsp > 3. IP path >=20 > That was what author felt as a reasonable order based on input from = some, at the time of writing the draft. However, we would like to seek = for further input from others in the WG, particularly from operators. = Thanks! >=20 > -Nobo >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobo@cisco.com Thu Nov 7 11:12:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8777D11E827D for ; Thu, 7 Nov 2013 11:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwUfrzBjnzIU for ; Thu, 7 Nov 2013 11:12:25 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81911E825B for ; Thu, 7 Nov 2013 11:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5205; q=dns/txt; s=iport; t=1383851544; x=1385061144; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ixSGu2xm9QTi2x0kPnTrFUIceoXUitdjBkd1zx9kjJ4=; b=QH5hmzX0VbGiyFJcuDrBNMOlD5yFyjjTuAxkYaPZSTw9rykt95qv6ER5 vVEF3OaaF8ivkfVtXE0Xq+uIUO2i9by0nJtk7Y5O1GCWdOGdHBaqxyncX mtZoheW1BednbKUlSl/Z1hEs85u5bNJ0sM2hjddeJsLySGQTCL+IxQQZv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABble1KtJXG9/2dsb2JhbABagmYhOFO/D4ElFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQEBChQJByEGCxQJCAEBBA4FCBOHVAMPAQyyZg2Ja4xngkExBwaDGoEQA5QsgXWDGosjhTiDJoIq X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="scan'208";a="279100748" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2013 19:12:22 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7JCMJD010481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 19:12:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 13:12:22 -0600 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac7bjm3cTBhLnI0pTpa7M681uYyPWwAjKsEAAAxJ8oA= Date: Thu, 7 Nov 2013 19:12:22 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> In-Reply-To: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.94.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:12:30 -0000 Hi Sam, Thanks for comments. Please see inline. > - Why do you need a new reply mode 6, when reply mode 4 and 5 (via > another draft) are already present? If you think reply mode 5 doesn't suf= fice > the need to support reverse LSP, then the > ping/?include_text=3D1> should be fixed rather than introduce another mod= e. Reply mode 4 and 5 has its own use, but those are not always available at r= esponder nodes. Whether responder node (transit-LSR, or LSR not part of the= LSP) has control-channel or reverse LSP is conditional. Instead of MPLS ec= ho request being dropped at those responder nodes which do not have return = path indicated by received Reply Mode, it's better for initiator to obtain = the error, as it's a diagnostic tool.=20 > - As others pointed out, IP is the best option available for all FEC type= s, > albeit TP LSP. There are two points. 1. "albeit TP LSP" is exactly one of the reasons. 2. IP path is indeed available in most cases, but I've also heard from some= that reply on control-channel/reverse-LSP is preferred over IP path in ord= er to a) preserve disjointness in networks, and b) deterministic reverse di= rection. > - Regarding the order of preference, my opinion is, the source should sel= ect > the preference of the reply mode. The existing reply modes does exactly > that. Receiver should not chose different reply mode to what was sent by > source. Agree with draft on that aspect and neither does the existing > RFC4379 does differently. > - Regarding multiple reply options and preference within a single request= , I > see it as more of optimization solution for the OAM workflow. The cost > incurred to support the new type is too high and do not support adding on= e > more mode. Would like to keep it simple as it is, without these new > changes required on the network device, while it could be achieved by the > application/user without any change. As much as I appreciate your comments, I disagree. Primary because words fr= om operators [2 from above], I believe, are valid. And if that's the case, = using control-channel, reverse-LSP or return path TLV simply won't work in = all cases. -Nobo > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Thursday, November 07, 2013 1:40 PM > To: Nobo Akiya (nobo) > Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode- > simple@tools.ietf.org > Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping- > reply-mode-simple >=20 > Hi Nobo and authors, >=20 > I have few comments about this draft, which I raised in the meeting as we= ll. >=20 > - Why do you need a new reply mode 6, when reply mode 4 and 5 (via > another draft) are already present? If you think reply mode 5 doesn't suf= fice > the need to support reverse LSP, then the > ping/?include_text=3D1> should be fixed rather than introduce another mod= e. > - As others pointed out, IP is the best option available for all FEC type= s, > albeit TP LSP. > - Regarding the order of preference, my opinion is, the source should sel= ect > the preference of the reply mode. The existing reply modes does exactly > that. Receiver should not chose different reply mode to what was sent by > source. Agree with draft on that aspect and neither does the existing > RFC4379 does differently. > - Regarding multiple reply options and preference within a single request= , I > see it as more of optimization solution for the OAM workflow. The cost > incurred to support the new type is too high and do not support adding on= e > more mode. Would like to keep it simple as it is, without these new > changes required on the network device, while it could be achieved by the > application/user without any change. >=20 > Draft specific comment (though I do not prefer multiple return types in t= he > first place :D) > - Sec 3.3 point #5 , is incorrect. TLV should allow this. Reason is, if t= he first > preferred return mode could not be supported, one could use reply mode 1 > as next preference, where it will not reply. >=20 > cheers > -sam > On Nov 7, 2013, at 12:02 AM, Nobo Akiya (nobo) wrote: >=20 > > Hi MPLS WG Members, > > > > First of all, thanks for many comments during WG session on Tuesday. > > > > A. For new TLV processing by responder, we will review for further erro= r > conditions and introduce new error code if we see the need. > > > > B. For pre-defined preference Reply Mode: > > > > Current proposed order: > > 1. control-channel > > 2. reverse-lsp > > 3. IP path > > > > That was what author felt as a reasonable order based on input from som= e, > at the time of writing the draft. However, we would like to seek for furt= her > input from others in the WG, particularly from operators. Thanks! > > > > -Nobo > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Thu Nov 7 11:32:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B628421E80DB for ; Thu, 7 Nov 2013 11:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulthHV8Q3mfY for ; Thu, 7 Nov 2013 11:31:55 -0800 (PST) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C3D7811E81B3 for ; Thu, 7 Nov 2013 11:31:54 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id v11so7892bkz.34 for ; Thu, 07 Nov 2013 11:31:53 -0800 (PST) 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=ZMtyvvb0+Jfz0lqyIA/Egx3lsuY9KAA9xZFYB6whJyk=; b=w3odr9qmyFnVSUwciTQLSB9vOndLPqQ8Ip/6mcZwtPKj+DSgcAzuWFKu1Ny7d3XWO4 tn1xlMGT4vP2f7adnD7pmFBkD1cj729KJyI/PwRFmVcdq63jTiVR6vkW07FSqk89OaeT +4nPQWD42SMj22dk/OLvvtXPKNt13+CF8P1Kzk4OuuIdpkP3v/sQwp/tsm/iXEbteRT+ ylQ6yC6KGpXAJ+CM5bmxV2aLT5hZVB+fTjaLaj994RNkDb74iDRMHoLUvo8Mk4bNvZQV gyJ+TB/8X9oaxux8/DVuh5k5pHdnBDZ+KoU65QMHIEJYPRBiJg2XLmwcnqusxlIBPbjk kFYA== X-Received: by 10.204.228.198 with SMTP id jf6mr3018683bkb.41.1383852713841; Thu, 07 Nov 2013 11:31:53 -0800 (PST) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:5cdd:e353:c670:b4d3]) by mx.google.com with ESMTPSA id qe6sm3353163bkb.5.2013.11.07.11.31.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 11:31:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sam Aldrin In-Reply-To: Date: Thu, 7 Nov 2013 11:31:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1816) Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:32:01 -0000 Hi Nobo, Thanks for the reply. Inline for my comments. On Nov 7, 2013, at 11:12 AM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 > Thanks for comments. Please see inline. >=20 >> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via >> another draft) are already present? If you think reply mode 5 doesn't = suffice >> the need to support reverse LSP, then the >> = > ping/?include_text=3D1> should be fixed rather than introduce another = mode. >=20 > Reply mode 4 and 5 has its own use, but those are not always available = at responder nodes. > Whether responder node (transit-LSR, or LSR not part of the LSP) has = control-channel or reverse LSP is conditional. Instead of MPLS echo = request being dropped at those responder nodes which do not have return = path indicated by received Reply Mode, it's better for initiator to = obtain the error, as it's a diagnostic tool.=20 %sam - Think I am missing something here. Could you provide details on = the scenarios why reply mode 6 will work where reply mode 5 cannot work. = If you can can clarify that, it would be clear.=20 Having said that, if there is really something missing by reply mode 5, = but is being solved by reply mode 6, I would rather have it fixed in = reply mode 5 itself, before it is published as RFC. >=20 >> - As others pointed out, IP is the best option available for all FEC = types, >> albeit TP LSP. >=20 > There are two points. > 1. "albeit TP LSP" is exactly one of the reasons. > 2. IP path is indeed available in most cases, but I've also heard from = some that reply on control-channel/reverse-LSP is preferred over IP path = in order to a) preserve disjointness in networks, and b) deterministic = reverse direction. %sam - I am not debating on why reverse path LSP is required or not. = Rather, I want to know why mode 5 is not solving it.=20 >=20 >> - Regarding the order of preference, my opinion is, the source should = select >> the preference of the reply mode. The existing reply modes does = exactly >> that. Receiver should not chose different reply mode to what was sent = by >> source. Agree with draft on that aspect and neither does the existing >> RFC4379 does differently. >> - Regarding multiple reply options and preference within a single = request, I >> see it as more of optimization solution for the OAM workflow. The = cost >> incurred to support the new type is too high and do not support = adding one >> more mode. Would like to keep it simple as it is, without these new >> changes required on the network device, while it could be achieved by = the >> application/user without any change. >=20 > As much as I appreciate your comments, I disagree. Primary because = words from operators [2 from above], I believe, are valid. And if that's = the case, using control-channel, reverse-LSP or return path TLV simply = won't work in all cases. %sam - The same case was made for return path ping too, if I remember = correctly. So, my disagreement is not about the need, but why mode 5 is = not solving it. But My point above is related to mode 7 TLV. Do you = disagree that it is not optimization, assuming you have return modes = 1-6? cheers -sam >=20 > -Nobo >=20 >> -----Original Message----- >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Thursday, November 07, 2013 1:40 PM >> To: Nobo Akiya (nobo) >> Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode- >> simple@tools.ietf.org >> Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping- >> reply-mode-simple >>=20 >> Hi Nobo and authors, >>=20 >> I have few comments about this draft, which I raised in the meeting = as well. >>=20 >> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via >> another draft) are already present? If you think reply mode 5 doesn't = suffice >> the need to support reverse LSP, then the >> = > ping/?include_text=3D1> should be fixed rather than introduce another = mode. >> - As others pointed out, IP is the best option available for all FEC = types, >> albeit TP LSP. >> - Regarding the order of preference, my opinion is, the source should = select >> the preference of the reply mode. The existing reply modes does = exactly >> that. Receiver should not chose different reply mode to what was sent = by >> source. Agree with draft on that aspect and neither does the existing >> RFC4379 does differently. >> - Regarding multiple reply options and preference within a single = request, I >> see it as more of optimization solution for the OAM workflow. The = cost >> incurred to support the new type is too high and do not support = adding one >> more mode. Would like to keep it simple as it is, without these new >> changes required on the network device, while it could be achieved by = the >> application/user without any change. >>=20 >> Draft specific comment (though I do not prefer multiple return types = in the >> first place :D) >> - Sec 3.3 point #5 , is incorrect. TLV should allow this. Reason is, = if the first >> preferred return mode could not be supported, one could use reply = mode 1 >> as next preference, where it will not reply. >>=20 >> cheers >> -sam >> On Nov 7, 2013, at 12:02 AM, Nobo Akiya (nobo) = wrote: >>=20 >>> Hi MPLS WG Members, >>>=20 >>> First of all, thanks for many comments during WG session on Tuesday. >>>=20 >>> A. For new TLV processing by responder, we will review for further = error >> conditions and introduce new error code if we see the need. >>>=20 >>> B. For pre-defined preference Reply Mode: >>>=20 >>> Current proposed order: >>> 1. control-channel >>> 2. reverse-lsp >>> 3. IP path >>>=20 >>> That was what author felt as a reasonable order based on input from = some, >> at the time of writing the draft. However, we would like to seek for = further >> input from others in the WG, particularly from operators. Thanks! >>>=20 >>> -Nobo >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 From nobo@cisco.com Thu Nov 7 11:38:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38611E815C for ; Thu, 7 Nov 2013 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yagLmAs5C0kL for ; Thu, 7 Nov 2013 11:38:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B111E8188 for ; Thu, 7 Nov 2013 11:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2623; q=dns/txt; s=iport; t=1383853104; x=1385062704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1D8BNudPBytjLuXNIGm/jaJPhQpgdsT98Q3jxacXvJI=; b=VJdNBPV8zsObfhvDy19RbEhh0RMba0rXBpLkDhx1oMiVzOlI/7EeZ6rO 6pyuuvQ7rJhpRCLD0Ma2srRctJ0mNFa/Mo8gS3gUDHBc4Ziu7hJ68KUpE TntA7QjJ1LhTIw8G2rfcs3LnTM5S4XT/s3XePszsV4ZvdTDamfjSN/j7f g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAObre1KtJXHA/2dsb2JhbABagmYhOFO/D4EmFnSCJQEBAQQBAQE3MQMLDAICAgEIEQQBAQEKFAkHGwwLFAkIAQEEAQ0FCId5AQy8ZQQEjgyBGDEHBoMagRADlCyVaoMmgXE5 X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="scan'208";a="282073912" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2013 19:38:11 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA7JcB5o026416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 19:38:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 13:38:10 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac7bjm3cTBhLnI0pTpa7M681uYyPWwAgax8AAAh8zTA= Date: Thu, 7 Nov 2013 19:38:10 +0000 Message-ID: References: <527BCC20.3070202@pi.nu> In-Reply-To: <527BCC20.3070202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.94.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:38:30 -0000 Hi Loa, Thanks for comments. > "If the IP path is there, use that! It will always work" Yes, that's a good comment from Curtis. There's one thing that I'd like to = point out. Multisegment-Pseudowire over TP was a scenario where I was scratching my he= ad few months ago. Initiating TP segment could have IP routes (TP in IP bas= ed domain), but next TP segment may not have IP routes (IP in IP-less domai= n). So the "If the IP path is there ..." is something which initiator does = not always have knowledge of. In this case, using Reply Mode of IP can caus= e responder to drop the request. Same problem as using Reply Mode 4/5 but n= ot having paths corresponding to Reply Mode 4/5 at responder. The question is whether standard should have pre-defined preference or not,= I'd like to wait for more comments. Thanks, Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, November 07, 2013 12:22 PM > To: Nobo Akiya (nobo); mpls@ietf.org > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping- > reply-mode-simple >=20 > Folks, >=20 > >=20 >=20 >=20 > On 2013-11-07 00:02, Nobo Akiya (nobo) wrote: >=20 > >=20 > > > > B. For pre-defined preference Reply Mode: > > > > Current proposed order: > > 1. control-channel > > 2. reverse-lsp > > 3. IP path > > > > That was what author felt as a reasonable order > based on input from some, at the time of writing the draft. > However, we would like to seek for further input from others in the WG, > particularly from operators. Thanks! >=20 > I can understand why we came up with with this order of preference; I can > also understand the logic behind what Curtis said "If the IP path is ther= e, use > that! It will always work" >=20 > However thinking about it I'm more and more convinced that the order of > preference need to established not as something that is once and for all > fixed by the standard. I think that the operator would benefit from be ab= le > to decide the order of preference at configuration time. >=20 > /Loa >=20 > >=20 > > > > -Nobo > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=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 nobo@cisco.com Thu Nov 7 13:39:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485B221E809F for ; Thu, 7 Nov 2013 13:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izoJLkU1XFm4 for ; Thu, 7 Nov 2013 13:39:02 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3885521E8169 for ; Thu, 7 Nov 2013 13:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7472; q=dns/txt; s=iport; t=1383860321; x=1385069921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ugAww1d2Lj5UoZe7qRgWf6Wy+dKVh8eMA4parh/9CGg=; b=MGM8ackaWBp3BUB5PW1X6vlbwmDFdB3guJ7h2GEsObMT/fCX/9KiFkTS vJnugfgiRDvgqDaKfFSYtVWt6TUJHfJ+67TwvOzeQ87EbvolWa4mQBhnh dsQjdqKsDZhq7U0xtofSB7GMG0i+jSq+1WZGJzDy7TYk50P67a7hfOGm9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANAHfFKtJV2Z/2dsb2JhbABagmYhOFO/DoEnFnSCJQEBAQMBAQEBNzQGBQUHBAIBCBEEAQEBChQJByEGCxQJCAEBBA4FCBOHVAMJBgEMsxMNiWuMZ4JBMQcGgxqBEAOULIF1gxqLI4U4gyaCKg X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="282180339" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2013 21:38:39 +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 rA7LcdGb011944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 21:38:39 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.0123.003; Thu, 7 Nov 2013 15:38:39 -0600 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple Thread-Index: Ac7bjm3cTBhLnI0pTpa7M681uYyPWwAjKsEAAAxJ8oD//6wQgIAAVouw Date: Thu, 7 Nov 2013 21:38:38 +0000 Message-ID: References: <660E124A-F814-469D-97A9-EF55CE9651C7@gmail.com> <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> In-Reply-To: <84A5DEF5-8FFB-4F04-BCEC-A8EEBD05A3BA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping-reply-mode-simple X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:39:12 -0000 Hi Sam, /pong :) Please see inline. > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Thursday, November 07, 2013 2:32 PM > To: Nobo Akiya (nobo) > Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode- > simple@tools.ietf.org > Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping- > reply-mode-simple >=20 > Hi Nobo, >=20 > Thanks for the reply. Inline for my comments. >=20 > On Nov 7, 2013, at 11:12 AM, Nobo Akiya (nobo) wrote: >=20 > > Hi Sam, > > > > Thanks for comments. Please see inline. > > > >> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via > >> another draft) are already present? If you think reply mode 5 doesn't > >> suffice the need to support reverse LSP, then the > >> >> d-lsp- ping/?include_text=3D1> should be fixed rather than introduce > >> another mode. > > > > Reply mode 4 and 5 has its own use, but those are not always available = at > responder nodes. > > Whether responder node (transit-LSR, or LSR not part of the LSP) has > control-channel or reverse LSP is conditional. Instead of MPLS echo reque= st > being dropped at those responder nodes which do not have return path > indicated by received Reply Mode, it's better for initiator to obtain the= error, > as it's a diagnostic tool. > %sam - Think I am missing something here. Could you provide details on th= e > scenarios why reply mode 6 will work where reply mode 5 cannot work. If > you can can clarify that, it would be clear. [NOBO] One example. Doing a traceroute on an associated RSVP LSP (i.e. bi-d= irectional) that is partially co-routed, reply mode 5 will not work but 6 w= ill.=20 > Having said that, if there is really something missing by reply mode 5, b= ut is > being solved by reply mode 6, I would rather have it fixed in reply mode = 5 > itself, before it is published as RFC. [NOBO] Considering return path TLV draft is very late in the stage (LC done= already), I would bet that authors/chairs would want to progress return pa= th TLV draft. > > > >> - As others pointed out, IP is the best option available for all FEC > >> types, albeit TP LSP. > > > > There are two points. > > 1. "albeit TP LSP" is exactly one of the reasons. > > 2. IP path is indeed available in most cases, but I've also heard from = some > that reply on control-channel/reverse-LSP is preferred over IP path in or= der > to a) preserve disjointness in networks, and b) deterministic reverse > direction. > %sam - I am not debating on why reverse path LSP is required or not. Rath= er, > I want to know why mode 5 is not solving it. [NOBO] See above. > > > >> - Regarding the order of preference, my opinion is, the source should > >> select the preference of the reply mode. The existing reply modes > >> does exactly that. Receiver should not chose different reply mode to > >> what was sent by source. Agree with draft on that aspect and neither > >> does the existing > >> RFC4379 does differently. > >> - Regarding multiple reply options and preference within a single > >> request, I see it as more of optimization solution for the OAM > >> workflow. The cost incurred to support the new type is too high and > >> do not support adding one more mode. Would like to keep it simple as > >> it is, without these new changes required on the network device, > >> while it could be achieved by the application/user without any change. > > > > As much as I appreciate your comments, I disagree. Primary because word= s > from operators [2 from above], I believe, are valid. And if that's the ca= se, > using control-channel, reverse-LSP or return path TLV simply won't work i= n > all cases. > %sam - The same case was made for return path ping too, if I remember > correctly. So, my disagreement is not about the need, but why mode 5 is n= ot > solving it. But My point above is related to mode 7 TLV. Do you disagree = that > it is not optimization, assuming you have return modes 1-6? [NOBO] Similar, yes. But return path TLV draft leaves traceroute as "outsid= e the scope", and that means problem described in this draft is not very re= levant and thus not discussed/solved. -Nobo >=20 > cheers > -sam > > > > -Nobo > > > >> -----Original Message----- > >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > >> Sent: Thursday, November 07, 2013 1:40 PM > >> To: Nobo Akiya (nobo) > >> Cc: mpls@ietf.org; draft-akiya-mpls-lsp-ping-reply-mode- > >> simple@tools.ietf.org > >> Subject: Re: [mpls] Thanks for comments on draft-akiya-mpls-lsp-ping- > >> reply-mode-simple > >> > >> Hi Nobo and authors, > >> > >> I have few comments about this draft, which I raised in the meeting as > well. > >> > >> - Why do you need a new reply mode 6, when reply mode 4 and 5 (via > >> another draft) are already present? If you think reply mode 5 doesn't > >> suffice the need to support reverse LSP, then the > >> >> d-lsp- ping/?include_text=3D1> should be fixed rather than introduce > >> another mode. > >> - As others pointed out, IP is the best option available for all FEC > >> types, albeit TP LSP. > >> - Regarding the order of preference, my opinion is, the source should > >> select the preference of the reply mode. The existing reply modes > >> does exactly that. Receiver should not chose different reply mode to > >> what was sent by source. Agree with draft on that aspect and neither > >> does the existing > >> RFC4379 does differently. > >> - Regarding multiple reply options and preference within a single > >> request, I see it as more of optimization solution for the OAM > >> workflow. The cost incurred to support the new type is too high and > >> do not support adding one more mode. Would like to keep it simple as > >> it is, without these new changes required on the network device, > >> while it could be achieved by the application/user without any change. > >> > >> Draft specific comment (though I do not prefer multiple return types > >> in the first place :D) > >> - Sec 3.3 point #5 , is incorrect. TLV should allow this. Reason is, > >> if the first preferred return mode could not be supported, one could > >> use reply mode 1 as next preference, where it will not reply. > >> > >> cheers > >> -sam > >> On Nov 7, 2013, at 12:02 AM, Nobo Akiya (nobo) > wrote: > >> > >>> Hi MPLS WG Members, > >>> > >>> First of all, thanks for many comments during WG session on Tuesday. > >>> > >>> A. For new TLV processing by responder, we will review for further > >>> error > >> conditions and introduce new error code if we see the need. > >>> > >>> B. For pre-defined preference Reply Mode: > >>> > >>> Current proposed order: > >>> 1. control-channel > >>> 2. reverse-lsp > >>> 3. IP path > >>> > >>> That was what author felt as a reasonable order based on input from > >>> some, > >> at the time of writing the draft. However, we would like to seek for > >> further input from others in the WG, particularly from operators. Than= ks! > >>> > >>> -Nobo > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > From martin.vigoureux@alcatel-lucent.com Thu Nov 7 14:01:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44621F9D98 for ; Thu, 7 Nov 2013 14:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flCibhU9FNRp for ; Thu, 7 Nov 2013 14:01:28 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 43B3621E816E for ; Thu, 7 Nov 2013 14:00:38 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rA7M0aX6003714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Nov 2013 16:00:37 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id rA7M0Zcw028129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Nov 2013 17:00:36 -0500 Received: from [135.244.23.131] (135.5.27.17) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 7 Nov 2013 17:00:35 -0500 Message-ID: <527C0D81.7010402@alcatel-lucent.com> Date: Thu, 7 Nov 2013 23:00:33 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [mpls] IETF88 - MPLS Sessions - Minutes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:01:34 -0000 All, the minutes of the MPLS sessions are available: http://www.ietf.org/proceedings/88/minutes/minutes-88-mpls Please read them and let me know if I have missed something. Thanks -m From lberger@labn.net Fri Nov 8 13:04:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257BC21E8082 for ; Fri, 8 Nov 2013 13:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.711 X-Spam-Level: X-Spam-Status: No, score=-101.711 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJhVz380Q3G7 for ; Fri, 8 Nov 2013 13:04:12 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 929CD21E8146 for ; Fri, 8 Nov 2013 13:04:12 -0800 (PST) Received: (qmail 30960 invoked by uid 0); 8 Nov 2013 21:03:51 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 8 Nov 2013 21:03:50 -0000 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=MnAsUZmhIe3+1iVLG5XqJ82t7tgyQT9BUxqJIHLc1Hg=; b=Tu20haBqmwolfM/GsUPCJyR8w1PTBOfo03Y/zoK767IVXDAyzZ0eCYqJfW3z4kz5zhZK2fYZTNdVKrpGc6ZJ6+sjE5Z1k8Ka4CIIIzJeJG0G+kaZ9v+V9RzGWHRo83Qk; Received: from box313.bluehost.com ([69.89.31.113]:39591 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VetDa-0004pD-Gw; Fri, 08 Nov 2013 14:03:50 -0700 Message-ID: <527D51B6.1060106@labn.net> Date: Fri, 08 Nov 2013 13:03:50 -0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Zhenlong Cui , mpls@ietf.org References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> In-Reply-To: <52794190.9060303@labn.net> X-Enigmail-Version: 1.6 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} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:04:17 -0000 Zhenlong, I understand you have an additional concern regarding supporting a MIP and MEP in a node that is both a branch and leaf node. I think this is supported, where MIPs are associated with the P2MP branch data plane function and MEPs are associated with the leaf data plane function. This holds for both for both per-node and per-interface MIPs. I certainly agree that it is reasonable for there to be a more in depth discussion on this topic, and suggest that such a discussion be added to draft-hmk-mpls-tp-p2mp-oam-framework. If you'd like, we can something like the following to our draft: It is worth noting that a MIP and MEP may be instantiated on a node when it is both a branch and leaf node. Please let us know if you still have concerns on our document. Thank you, Lou On 11/5/2013 11:05 AM, Lou Berger wrote: > Zhenlong, > > Perhaps the issue is in the slightly different language used in the > draft versus the section 3.7 of rfc6371. RFC6371 says: > > o To send an OAM packet to a single MIP, ... The OAM packet must > contain sufficient information to identify the target MIP and > therefore is processed only by the target MIP and can be silently > discarded by the others. > > To better align with this text, the draft should be revised to replace > "addressing information" with "additional information" > > Will this address your comment? If not, do you have some text/changes in > mind that would? > > Much thanks, > Lou > > On 11/4/2013 12:56 AM, Zhenlong Cui wrote: >> Hi Lou, >> >> Thank you for your reply. >> >> I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on a transit node. >> >> However, I think that this draft need further explanation for the OAM behavior on transit nodes. >> >> The P2MP OAM behaviors are described in section 4. >> All the traffic sent over a P2MP transport path, including OAM >> packets generated by a MEP, is sent (multicast) from the root to all >> the leaves, thus every OAM packet is sent to all leaves, and thus can >> impact all the MEs in a P2MP MEG. If an OAM packet is to be >> processed by only a specific leaf, it requires information to >> indicate to all other leaves that the packet must be discarded. To >> address a packet to an intermediate node in the tree, TTL based >> addressing is used to set the radius and addressing information in >> the OAM payload is used to identify the specific destination node. >> >> >> My comments: >> >> 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. >> The case of per-interface should also be described, if you like to mention about the per-node case in this draft. >> >> 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on a transit node. >> e.g.) >> When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed by a MIP functionality, before it identifies the addressing information. >> Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. >> >> >> Best reagrds, >> zhenlong >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Monday, November 04, 2013 1:17 PM >>> To: Zhenlong Cui; mpls@ietf.org >>> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework >>> >>> Zhenlong, >>> Thank you for the comments. Please see below for responses in-line. >>> >>> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: >>>> Dear authors, >>>> >>>> I have a comment/question on this draft. >>>> >>>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. >>>> In this case, the drop-and-continue node will become an intermediate point. >>> >>> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. >>> >>>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? >>> >>> I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit nodes. >>> Assuming you are asking about the case stated in the previous point, that a node is both egress and transit, then I think >>> it could have both MEP and MIP functionality separately instantiated. Section 3.7 already covers P2MP MIPs and MEPs. >>> >>>> As described in section 3.3 of RFC 6371, a MEP terminates all the OAM >>>> packets it receives from the MEG, may discards silently if addressing information in the OAM payload is different with >>> termination node. >>>> It means that the intermediate node must NOT be configured as a MEP >>>> when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. >>> >>> Why do you say this? If a node is both transit and egress, it will replicate OAM packets (just like the data) when performing >>> its transit role before then terminating the data/OAM packets as part of its egress role. >>> >>>> >>>> On the other hand, if the intermediate node can't be configured as a >>>> MEP, the path protection may not be able to work at this point. I think this is a serious problem. >>>> >>> >>> Perhaps I'm missing something, but I simply don't see an issue here that isn't already addressed in RFC6371 (and 4875.) >>> I guess 6371 could have shown this case as an example, or provided a related detailed walk through, but either way I don't >>> see any "serious problem" here. >>> >>> Perhaps the best way to proceed on this is to propose text to the already referenced "additional detail" draft >>> draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? >>> >>> Thanks, >>> Lou >>> >>>> Best regards, >>>> zhenlong >>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>> Of Loa Andersson >>>>> Sent: Friday, October 18, 2013 1:29 PM >>>>> To: mpls@ietf.org >>>>> Cc: mpls-chairs@tools.ietf.org; >>>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >>>>> Subject: [mpls] working group last call on >>>>> draft-ietf-mpls-tp-p2mp-framework >>>>> >>>>> Working Group, >>>>> >>>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. >>>>> >>>>> Please send your comment to working group mailing lists (mpls@ietf.org). >>>>> >>>>> We did an IPR poll on this document prior to starting the wglc. >>>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. >>>>> >>>>> There are no IPRs disclosed against this document. >>>>> >>>>> The working group last call will end Friday November 1, 2913. >>>>> >>>>> /Loa >>>>> 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 >>>>> _______________________________________________ >>>>> 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 internet-drafts@ietf.org Mon Nov 11 08:28:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C1921E81E8; Mon, 11 Nov 2013 08:28:26 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAR5q3fl06KX; Mon, 11 Nov 2013 08:28:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A890221E80BE; Mon, 11 Nov 2013 08:27:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131111162759.20298.95893.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2013 08:27:59 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 16:28:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-08.txt Pages : 40 Date : 2013-11-11 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mcast-08 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 wwwrun@rfc-editor.org Mon Nov 11 17:30:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E550011E8198; Mon, 11 Nov 2013 17:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoxZnkq28ojK; Mon, 11 Nov 2013 17:30:41 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0399311E80F9; Mon, 11 Nov 2013 17:30:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B7C3B75E016; Mon, 11 Nov 2013 17:20:42 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131112012042.B7C3B75E016@rfc-editor.org> Date: Mon, 11 Nov 2013 17:20:42 -0800 (PST) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7054 on Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:30:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7054 Title: Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) Author: A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul Status: Informational Stream: IETF Date: November 2013 Mailbox: adrian@olddog.co.uk, hideki.endo.es@hitachi.com, rolf.winter@neclab.eu, koike.yoshinori@lab.ntt.co.jp, Manuel.Paul@telekom.de Pages: 11 Characters: 25444 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-mip-mep-map-09.txt URL: http://www.rfc-editor.org/rfc/rfc7054.txt The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From pranjal.dutta@alcatel-lucent.com Tue Nov 12 11:57:58 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0739421E80A7 for ; Tue, 12 Nov 2013 11:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlvEyARa7KHS for ; Tue, 12 Nov 2013 11:57:52 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E4B4721F9EED for ; Tue, 12 Nov 2013 11:57:51 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rACJvTo6023267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 13:57:30 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id rACJvSHb031308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 14:57:29 -0500 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 12 Nov 2013 14:57:28 -0500 Received: from SG70YWXCHMBA08.zap.alcatel-lucent.com ([169.254.8.240]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 13 Nov 2013 03:57:24 +0800 From: "Dutta, Pranjal K (Pranjal)" To: Loa Andersson , Lizhong Jin , "vishwas.manral@hp.com" , Curtis Villamizar , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding Thread-Index: AQHO04+oR3C0tlrj8k6QHQNDMZKDZ5oh920g Date: Tue, 12 Nov 2013 19:57:24 +0000 Message-ID: References: <526DDCFE.6060403@pi.nu> In-Reply-To: <526DDCFE.6060403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:57:58 -0000 Hi All, I have reviewed the following version of the draft from MP-RT pers= pective and following are my inputs.=20 http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-wildcard-encodi= ng-01 1. The draft specifies procedures for=20 1.1 Mapping PIM ASM trees to MP-LSP=20 and, =20 1.2 Mapping multiple IP multicast trees into a single MP-LSP. =20 There is another draft in progress on item 1.1 that overlaps with the solut= ion in this draft. http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-07 I would suggest to merge the solutions for 1.1 from both the documents to a= dopt a single/unified approach. A key issue we have been seeing off late is= fragmentation - where solutions with same intent are fragmented across mul= tiple documents. This leads to lack of clarity for implementations and subs= equently opens inter-op worms. For e.g PIM BI-DIR mapping was addressed=20 in RFC 6826 but didn't address PIM ASM/unidirectional mapping in that doc. =20 I can see the need to address item 1.2 in this draft. This is certainly use= ful to reduce control + forwarding states since RFC 6826 makes us reach dat= a path scaling limits in core with 1:1 mapping to MP-LSP. This is more an i= ssue in vpn-in-band mapping wherein every VPN multicast tree is pushing one= MP-LSP into core. So I would like to see a solution for aggregation of VPN= in-band multicast trees over MP-LSP. 2. Using wildcard encoding for shared/ASM tree signaling is a paradigm shif= t from previous in-band encodings defined in RFC 6826 and vpn-in-band signa= ling. This draft avoids defining new MP opaque element types and re-uses/ov= erloads existing in-band opaque elements by introducing the notion of "wild= card" (zero values) in S and/or G. Section 3 states as follows: "if the IP Source Address sub-field contains the wildcard, and the IP Group Address sub-field contains an IP multicast group address, say G, that is NOT in the SSM address range (see Section 4.8 of [RFC4601]), the TLV identifies a PIM-SM shared tree." If the IP Source Address sub-field contains the wildcard, and the IP Group Address sub-field contains an IP multicast group address, say G, that is in the SSM address range, the TLV identifies the collection of PIM-SSM trees with the given group address. If the IP Source Address sub-field contains a non-zero IP address, and the IP Group Address sub-field contains the wildcard, the TLV identifies the collection of PIM-SSM trees that have the source address as their root." Adding newer interpretation to Group Address sub-field opens up backward= =20 compatibility issues with existing implementations of RFC 6826. The=20 defined Transit IPV4/IPV6 Source TLVs in RFC 6826 are explicitly=20 for "SSM" - the contract between PIM and mLdp had been locked for that=20 purpose in Root LSR. For e.g it is possible that in an existing RFC 6826 implementation - PIM= =20 at mLdp root LSR may be rejecting (or handling as no-op) Transit=20 IPv4/IPV6 Source TLV mapping if its opaque element is received with=20 non-SSM Range in Group Address.=20 On a similar note in Aggregation of multiple SSM trees with wildcard source address in Transit IPV4/IPV6 Source TLV - it is possible that=20 PIM at mLdp root LSR in RFC 6826 may be handling source address 0.0.0.0 as no-op (do nothing) or at best ending up as RPF lookup failure. 3. Section "4.1 PIM Shared Tree Forwarding" states below: "To efficiently use mLDP in-band signaling in this scenario, it is necessary for the Egress LSRs to construct an Opaque Value TLV that identifies a (*, G) tree. This is done by using the wildcard in the IP Source Address sub-field, and setting the IP Group Address sub- field to G."=20 Let's say the Group is selected from non SSM range (ASM) and source=20 is wildcard here. No RP is explicitly encoded/specified in the opaque element in Transit IPV4/IPV6 Source TLV, then does that means that=20 mLdp root is always the RP? What happens if RP is not co-located with=20 mLdp Root LSR? If so then this solution is not generic and has imposed=20 a limitation for collocation of RP and mLdp root for various PIM ASM=20 applications. A generic solution would be to encode an explicit RP in opaque value element. Such approach would satisfy both cases - whether RP is=20 collocated with mLdp root LSR or is disjoint. The encoding of Transit IPV4/V6 Shared Tree TLV defined in draft-rekhter-mpls-pim-sm-over-mldp=20 for same purpose carries an explicit RP.=20 Section "4.2 IGP/MLD proxying" is the case where it is possible that mLdp root node and RP are collocated in same node, since multicast=20 senders and receivers are directly connected to MPLS domain. It's not clear from overall Section 4 on how the draft addresses RP=20 and mLdp Root LSR being disjoint.=20 4. In section "5/ Procedures for Wildcard Source Usage" "The IP multicast component on an Egress LSR determines when a wildcard is to be used in the IP Source Address sub-field of an mLDP Opaque Value TLV. How the IP multicast component determines this is a local matter, and may need to be explicitly configured. It MAY however use the following rules (with or without explicit configuration); 1. Suppose that PIM is enabled, and an Egress LSR needs to join a non-bidirectional ASM group G, and the RP for G is reachable via a BGP route. The Egress LSR MAY choose the BGP Next Hop of the route to the RP to be the Ingress LSR (root node) of the MP-LSP corresponding to the (*,G) tree. (See also Section 7.) The Egress LSR MAY identify the (*,G) tree by using an mLDP Opaque Value TLV whose IP Source Address sub-field contains a wildcard, and whose IP Group Address sub-field contains G."=20 By reading this section the draft seems to re-assert that RP for (*, G) tre= e is collocated to mLdp Root Node. There would be newer applications to be = defined in future where RP and mLdp Root functionality need not be collocat= ed. 5. "Section 7. Determining the MP-LSP Root (Ingress LSR)" "Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] describe procedures by which an Egress LSR may determine the MP-LSP root node address corresponding to a given IP multicast stream, based upon the IP address of the source of the IP multicast stream. When a wildcard source encoding is used, PIM is enabled, and the group is a non-bidirectional ASM group, a similar procedure is applied. The only difference from the above mentioned procedures is that the Proxy device or RP address is used instead of the Source to discover the mLDP root node address. In all other cases some sort of manual configuration is applied in order to find the root node. Note, finding the root node is a local implementation matter and not limited to the solutions mentioned in this document." This section seems to imply that MP-LSP root and RP may be disjoint=20 nodes when wildcard source encoding is used for non-bidirectional=20 ASM Group. If so then it is required for MP-LSP root node to hand off=20 the (*,G) to local PIM and further progress (*, G) join upstream in=20 PIM domain towards the RP. Overloading existing Transit IPV4/IPV6 Source= =20 TLVs with wildcard source won't work. Summary: 1. Is it likely to be actually useful in operational Networks?=20 =20 - Yes. The solutions are desirable. 2. Is the document technically sound? - Concerned with Wildcard Encoding for PIM-ASM. By reading the draft it=20 does not look like encoding is generic + may lead to backward=20 compatibility issues with RFC 6826. This item has overlap with=20 draft-rekhter-mpls-pim-sm-over-mldp-07 and single approach should be = =20 adopted by WG. IMO, the encoding defined in draft-rekhter is more generic + no backward compatibility issues. - Aggregation of SSM trees with wildcard encoding may lead to backward=20 Compatibility issues with RFC 6826. A better approach is to define new MP Opaque Value elements exclusively for mapping PIM-ASM and Aggregate SSM(in similar lines with RFC 6826 and= =20 in-band-vpn draft).=20 Note that we have mapped PIM BI-DIR explicitly to Transit IPV4/IPV6=20 Bi-Dir TLVs in RFC 6826.=20 Thanks, Pranjal -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Sunday, October 27, 2013 8:42 PM To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.manral@hp.com; Curtis = Villamizar; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.o= rg; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encodi= ng Lizhong, Pranjal, Vishwas and Curtis, You have been selected as an MPLS Review team reviewers for draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01. 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 secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. Are you able to review this draft by November 11, 2013? Thanks, Loa (as MPLS WG chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Tue Nov 12 13:59:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248E311E810B; Tue, 12 Nov 2013 13:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qn+RDHoi6yV; Tue, 12 Nov 2013 13:59:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B611E80E6; Tue, 12 Nov 2013 13:59:39 -0800 (PST) Received: from [192.168.252.96] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 93B2B1802038; Tue, 12 Nov 2013 22:59:37 +0100 (CET) Message-ID: <5282A4C9.4080603@pi.nu> Date: Tue, 12 Nov 2013 13:59:37 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , "nvo3@ietf.org" , l2vpn@ietf.org, L3VPN , Vero Zheng , Adrian Farrel , "stbryant@cisco.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] MPLS VPN Scaling Bof in London X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:59:48 -0000 Working Groups, We will run a non-Working Group forming BoF in London to discuss issues around Scaling of MPLS VPNs. Lou Berger and i have accepted to chair this BoF, Vero Zheng will take on the role as list admin and secretary. We plan to kick-off the discussion on a problem statement as soon as we have enough participants on the mailing list We gave a heads up for this BoF in Vancouver - these slides were presented in the RTG Area Open Meeting. http://www.ietf.org/proceedings/88/slides/slides-88-rtgarea-5.pptx We have started to prepare the BoF, and the discussion on how we set it up will take place on a new mailing list: scale-request@ietf.org Please subscribe to this list through: https://www.ietf.org/mailman/listinfo/scale /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ice@cisco.com Tue Nov 12 15:19:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7121E8089 for ; Tue, 12 Nov 2013 15:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JPR9L4Pj0zX for ; Tue, 12 Nov 2013 15:19:29 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65911E814D for ; Tue, 12 Nov 2013 15:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13794; q=dns/txt; s=iport; t=1384298369; x=1385507969; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=byuRSmfdLh15h9BPr7vaHBfqOrsYHHa2R7bd0dDqjiA=; b=bh2O22hT60R1wn02Mx3OGdZk8QqLCplY1Zsj6ZoNLYwc6Cfthn67f3/i BjqK6TUbKc82QqdhEUmyAVe7Z8c+YQG/imYh2M/hwdl7M+FcSZrYHpEoQ 5z6XjvqPWZAKRRK64TDEzBYDki0e/dYuUp6hcvov8VmWmOBMeqaaEFj+W k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYKAEG2glKrRDoG/2dsb2JhbABQAgiDBzirFJRkgSsWdIIlAQEBAwEBAQE3LQQDCwUHAgILEQQBASgHGwwfCQgGEQIbh2AFDr8xBI4SBgQCgQozBwaDGoERA4lCimyDYYEvhQ6LTYNHGwSBKAkX X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="scan'208";a="94175391" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Nov 2013 23:19:27 +0000 Received: from [10.154.212.56] ([10.154.212.56]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACNJQFO009085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 23:19:26 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: IJsbrand Wijnands In-Reply-To: Date: Tue, 12 Nov 2013 15:19:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <608E97B8-C768-476C-87B7-26D79B08F674@cisco.com> References: <526DDCFE.6060403@pi.nu> To: "Dutta, Pranjal K (Pranjal)" X-Mailer: Apple Mail (2.1499) Cc: "vishwas.manral@hp.com" , "mpls@ietf.org" , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , Lizhong Jin , "mpls-chairs@tools.ietf.org" , Curtis Villamizar Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:19:33 -0000 Hi Dutta, Thanks for the review, a few comments; > I would suggest to merge the solutions for 1.1 from both the documents = to adopt a single/unified approach. A key issue we have been seeing off = late is fragmentation - where solutions with same intent are fragmented = across multiple documents. This leads to lack of clarity for = implementations and subsequently opens inter-op worms. For e.g PIM = BI-DIR mapping was addressed=20 > in RFC 6826 but didn't address PIM ASM/unidirectional mapping in that = doc. The overlap in the two drafts got introduced by; = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-rekhter-mpl= s-pim-sm-over-mldp-03.txt Its really a very minimal overlap looking at the procedures defined. = Both solutions provide an option to do shared tree only forwarding. = draft-rekhter does it by making the Source discovery optional. The = intend of draft-rekhter has always been towards source discovery, that = is what most of his draft is about. Merging the drafts seems a very bad = way to resolve the conflict. Is better to keep both drafts, one with a = focus on source discovery, the other on shared tree forwarding. > I can see the need to address item 1.2 in this draft. This is = certainly useful to reduce control + forwarding states since RFC 6826 = makes us reach data path scaling limits in core with 1:1 mapping to = MP-LSP. This is more an issue in vpn-in-band mapping wherein every VPN = multicast tree is pushing one MP-LSP into core. So I would like to see a = solution for aggregation of VPN in-band multicast trees over MP-LSP. Please note that this is not a solution intended for VPN support. Its = used for solutions where the service is implemented in a VRF context. = This is a fine lined, but important difference. The reason for Thomsson = Reuters to go with shared tree only forwarding is not necessarily due to = aggregation, but mostly that source discovery is avoid all together. For = example, in many cases there is a single sender per Group, so you really = don't have any less state. But this solution can certainly be used for = reduce state if there are multiple senders for a given group. > 2. Using wildcard encoding for shared/ASM tree signaling is a paradigm = shift from previous in-band encodings defined in RFC 6826 and = vpn-in-band signaling. This draft avoids defining new MP opaque element = types and re-uses/overloads existing in-band opaque elements by = introducing the notion of "wildcard" (zero values) in S and/or G. This is not a paradigm shift. > Section 3 states as follows: >=20 > > "if the IP Source Address sub-field contains the wildcard, and the IP > Group Address sub-field contains an IP multicast group address, say > G, that is NOT in the SSM address range (see Section 4.8 of > [RFC4601]), the TLV identifies a PIM-SM shared tree." >=20 > If the IP Source Address sub-field contains the wildcard, and the IP > Group Address sub-field contains an IP multicast group address, say > G, that is in the SSM address range, the TLV identifies the > collection of PIM-SSM trees with the given group address. >=20 > If the IP Source Address sub-field contains a non-zero IP address, > and the IP Group Address sub-field contains the wildcard, the TLV > identifies the collection of PIM-SSM trees that have the source > address as their root." > >=20 > Adding newer interpretation to Group Address sub-field opens up = backward=20 > compatibility issues with existing implementations of RFC 6826. The=20= > defined Transit IPV4/IPV6 Source TLVs in RFC 6826 are explicitly=20 > for "SSM" - the contract between PIM and mLdp had been locked for = that=20 > purpose in Root LSR. That is not the case, section 2.2 in RFC6826 clearly explains the Source = can be either SM or ASM. Since a source/group field of 0.0.0.0 is = undefined behaviour, this does not cause any backwards compatibility = issue.=20 > For e.g it is possible that in an existing RFC 6826 implementation - = PIM=20 > at mLdp root LSR may be rejecting (or handling as no-op) Transit=20 > IPv4/IPV6 Source TLV mapping if its opaque element is received with=20= > non-SSM Range in Group Address.=20 That does not mean there is a interop issue. How is this different from = receiving a opaque value that is unknown? > On a similar note in Aggregation of multiple SSM trees with wildcard > source address in Transit IPV4/IPV6 Source TLV - it is possible that=20= > PIM at mLdp root LSR in RFC 6826 may be handling source address = 0.0.0.0 > as no-op (do nothing) or at best ending up as RPF lookup failure. That is expect if the value is undefined, I don't see the issue. >=20 > 3. Section "4.1 PIM Shared Tree Forwarding" states below: >=20 > >=20 > "To efficiently use mLDP in-band signaling in this scenario, it is > necessary for the Egress LSRs to construct an Opaque Value TLV that > identifies a (*, G) tree. This is done by using the wildcard in the > IP Source Address sub-field, and setting the IP Group Address sub- > field to G."=20 >=20 > >=20 > Let's say the Group is selected from non SSM range (ASM) and source=20= > is wildcard here. No RP is explicitly encoded/specified in the = opaque > element in Transit IPV4/IPV6 Source TLV, then does that means that=20= > mLdp root is always the RP? What happens if RP is not co-located = with=20 > mLdp Root LSR? If so then this solution is not generic and has = imposed=20 > a limitation for collocation of RP and mLdp root for various PIM ASM=20= > applications. The mLDP Root will treat this as having received a IGMP (*,G) report, = and do what ever PIM procedure it has to do based on that. This solution = is explicitly targeted to deployments where the RP is behind the mLDP = root. This is not a limitation of the solution. >=20 > A generic solution would be to encode an explicit RP in opaque value > element. Such approach would satisfy both cases - whether RP is=20 > collocated with mLdp root LSR or is disjoint. The encoding of = Transit > IPV4/V6 Shared Tree TLV defined in = draft-rekhter-mpls-pim-sm-over-mldp=20 > for same purpose carries an explicit RP. This is not true and something we want to explicitly avoid. The mLDP = root will look at its own RP mapping table to determine the RP for the = group it is processing. The RP that is carried in the PIM Join messages = is NOT used for RP discovery, its only used to detect conflicts. This is = really an historical artefact. Decoupling the RP on the egress and = ingress and NOT having to have the same RP on both provides a lot of = flexibility. Also, when IGMP proxy is done, there is no RP what so ever = on the egress. >=20 >=20 > Section "4.2 IGP/MLD proxying" is the case where it is possible that > mLdp root node and RP are collocated in same node, since multicast=20= > senders and receivers are directly connected to MPLS domain. >=20 > It's not clear from overall Section 4 on how the draft addresses RP=20= > and mLdp Root LSR being disjoint.=20 That is the point, we don't. We don't intend to address disjointness. Shared tree only forwarding is = used by many financials and they have engineered the network to be this = way.=20 >=20 > 4. In section "5/ Procedures for Wildcard Source Usage" >=20 > >=20 > "The IP multicast component on an Egress LSR determines when a > wildcard is to be used in the IP Source Address sub-field of an mLDP > Opaque Value TLV. How the IP multicast component determines this is > a local matter, and may need to be explicitly configured. It MAY > however use the following rules (with or without explicit > configuration); >=20 > 1. Suppose that PIM is enabled, and an Egress LSR needs to join a > non-bidirectional ASM group G, and the RP for G is reachable = via > a BGP route. The Egress LSR MAY choose the BGP Next Hop of the > route to the RP to be the Ingress LSR (root node) of the MP-LSP > corresponding to the (*,G) tree. (See also Section 7.) The > Egress LSR MAY identify the (*,G) tree by using an mLDP Opaque > Value TLV whose IP Source Address sub-field contains a = wildcard, > and whose IP Group Address sub-field contains G."=20 >=20 > >=20 > By reading this section the draft seems to re-assert that RP for (*, = G) tree is collocated to mLdp Root Node. There would be newer = applications to be defined in future where RP and mLdp Root = functionality need not be collocated. As I said before, this is the sweet-spot for this proposal. But even if = the RP/Source are not co-located with the mLDP root, nothing is broken, = it still works using the basic PIM procedures. Its just that you don't = have optimal forwarding. >=20 > 5. "Section 7. Determining the MP-LSP Root (Ingress LSR)" >=20 > >=20 > "Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] > describe procedures by which an Egress LSR may determine the MP-LSP > root node address corresponding to a given IP multicast stream, = based > upon the IP address of the source of the IP multicast stream. When = a > wildcard source encoding is used, PIM is enabled, and the group is a > non-bidirectional ASM group, a similar procedure is applied. The > only difference from the above mentioned procedures is that the = Proxy > device or RP address is used instead of the Source to discover the > mLDP root node address. >=20 > In all other cases some sort of manual configuration is applied in > order to find the root node. Note, finding the root node is a local > implementation matter and not limited to the solutions mentioned in > this document." > >=20 > This section seems to imply that MP-LSP root and RP may be disjoint=20= It does not imply this. > nodes when wildcard source encoding is used for non-bidirectional=20 > ASM Group. If so then it is required for MP-LSP root node to hand = off=20 > the (*,G) to local PIM and further progress (*, G) join upstream in=20= > PIM domain towards the RP. Overloading existing Transit IPV4/IPV6 = Source=20 > TLVs with wildcard source won't work. >=20 >=20 > Summary: >=20 > 1. Is it likely to be actually useful in operational > Networks?=20 >=20 > - Yes. The solutions are desirable. >=20 > 2. Is the document technically sound? >=20 > - Concerned with Wildcard Encoding for PIM-ASM. By reading the draft = it=20 > does not look like encoding is generic + may lead to backward=20 > compatibility issues with RFC 6826. This item has overlap with=20 > draft-rekhter-mpls-pim-sm-over-mldp-07 and single approach should be = =20 > adopted by WG. IMO, the encoding defined in draft-rekhter is more > generic + no backward compatibility issues. I disagree, there is no backwards compatibility issue. Also, if the = overlap is a concern, its better to remove the overlap then to merge the = draft. Both drafts have a totally different focus. >=20 > - Aggregation of SSM trees with wildcard encoding may lead to backward=20= > Compatibility issues with RFC 6826. I disagree. By using the wildcard encoding, we don't have to redefine existing = behaviour as already defined in RFC6826 and more imporantly = draft-ietf-l3vpn-mldp-vrf-in-band-signaling. Thx, Ice. >=20 > A better approach is to define new MP Opaque Value elements = exclusively > for mapping PIM-ASM and Aggregate SSM(in similar lines with RFC 6826 = and=20 > in-band-vpn draft).=20 >=20 > Note that we have mapped PIM BI-DIR explicitly to Transit IPV4/IPV6=20= > Bi-Dir TLVs in RFC 6826.=20 >=20 >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu]=20 > Sent: Sunday, October 27, 2013 8:42 PM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.manral@hp.com; = Curtis Villamizar; = draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org; = mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: MPLS-RT review of = draft-wijnands-mpls-mldp-in-band-wildcard-encoding >=20 > Lizhong, Pranjal, Vishwas and Curtis, >=20 > You have been selected as an MPLS Review team reviewers for > draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01. >=20 > 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. >=20 > 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). >=20 > Reviews should be sent to the document authors, WG co-chairs and > secretary, and CC'd to the MPLS WG email list. If necessary, comments > may be sent privately to only the WG chairs. >=20 > Are you able to review this draft by November 11, 2013? >=20 >=20 > Thanks, Loa > (as MPLS WG chair) > --=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Nov 13 12:15:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324B321E813A for ; Wed, 13 Nov 2013 12:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzgI4giEg6aE for ; Wed, 13 Nov 2013 12:15:46 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4995321E8127 for ; Wed, 13 Nov 2013 12:15:39 -0800 (PST) Received: from [192.168.252.96] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7311018014F6; Wed, 13 Nov 2013 21:15:25 +0100 (CET) Message-ID: <5283DDCD.6030501@pi.nu> Date: Wed, 13 Nov 2013 12:15:09 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201311121641.rACGf9jl093561@gateway1.ipv6.occnc.com> In-Reply-To: <201311121641.rACGf9jl093561@gateway1.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-multipath-use@tools.ietf.org Subject: Re: [mpls] Closed - Working group last call on draft-ietf-mpls-multipath-use X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:15:57 -0000 Curtis, the working group last is not a door that is shut and no more comments allowed after closing. It is rather a door that is opened to notify that now is an excellent time to comment on a specific draft since he authors will be focused on updating the draft. Please go ahead and make the changes you have indicated below; once all updates are down, re-post and let me know and I will go ahead with the publication request procedures. /Loa On 2013-11-12 08:41, Curtis Villamizar wrote: > Loa, > > Although WGLC is over I reread draft-ietf-mpls-multipath-use and found > three editorial changes that should be made. > > OLD SENTENCE > > Alternately, the need for requirement MP#1 can be eliminated if > every MPLS-TP LSP can be created by the MPLS-TP ingress makes use > of an Entropy Label Indicator (ELI) and Entropy Label (EL) below > the MPLS-TP label [RFC6790]. > > NEW SENTENCE > > Alternately, the need for requirement MP#1 can be eliminated if > every MPLS-TP LSP created by an MPLS-TP ingress makes use of an > Entropy Label Indicator (ELI) and Entropy Label (EL) below the > MPLS-TP label [RFC6790]. > > The above change is s/can be created by the/created by an/. The > original sentence was understandable but grammatically wrong. > > OLD SENTENCE > > For those LSP that are larger than component link capacity, their > capacity are not increments of convenient capacity increments such > as 10Gb/s. > > NEW SENTENCE > > For those LSP that are larger than component link capacity, their > capacity are not integer multiples of convenient capacity > increments such as 10Gb/s. > > The above change is s/increments of/integer multiples of/. Again the > intent was clear in the original sentence but the wording was wrong. > > In the implementation section (which will be removed by IESG) the one > change is s/mpls mailing list/MPLS mailing list/. > > I was unable to submit immediately after last call ended due to the > IETF-88 submission blackout period. Hence the delay in submitting. > > If the above editorial changes are OK with the WG chairs, I will > submit the draft with the changes from the WGLC (define acronyms > before use) and with these changes. > > Curtis > > > In message <526B3C00.1020104@pi.nu> > Loa Andersson writes: >> >> Working Group, >> >> This working group last call has been closed. >> >> We have seen very few comments (1), and that comment is editorial. >> However we believe that it is nevertheless reason to go ahead and >> start the process to have the draft published as an RFC. >> >> Can the authors please address the comments, make sure the commenter >> is comfortable with how the comments been addressed, and if necessary >> post a new version of the draft. >> >> /Loa >> for the mpls wg chairs >> >> >> On 2013-10-12 20:02, Loa Andersson wrote: >>> Working Group, >>> >>> this is to start a two week working group last call on >>> draft-ietf-mpls-multipath-use-02. >>> >>> Please send your comment to working group mailing lists (mpls@ietf.org). >>> >>> We did an IPR poll on this document prior to starting the wglc. >>> The authors responded to the IPR poll that he is not aware of >>> any IPR's relating to this document. >>> >>> There are no IPRs disclosed against this document. >>> >>> However, the data-tracker identifies one IPR disclosure (# 1593), but >>> this IPR was disclosed against an earlier document that this document >>> replaces; the author has indicated that one reason why the earlier >>> document were replaced was to avoid the IPR. >>> This happens because we mark the documents with a replaced by info, >>> the IPR tracker tool uses this link to find IPR disclosures, but >>> IPR is not always continued over a link that indicate replacement. >>> >>> The working group last call will end Friday October 25, 2913. >>> >>> /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Wed Nov 13 13:13:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0021E80B3; Wed, 13 Nov 2013 13:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYpU2JR5dvZg; Wed, 13 Nov 2013 13:13:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD1C21F9D8E; Wed, 13 Nov 2013 13:13:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131113211333.30560.14489.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 13:13:33 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-multipath-use-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:13:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Use of Multipath with MPLS and MPLS-TP Author(s) : Curtis Villamizar Filename : draft-ietf-mpls-multipath-use-03.txt Pages : 12 Date : 2013-11-13 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-multipath-use-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-multipath-use-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Wed Nov 13 13:29:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8521E8104 for ; Wed, 13 Nov 2013 13:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSqZqqHe1uzC for ; Wed, 13 Nov 2013 13:28:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id EFCFD11E8107 for ; Wed, 13 Nov 2013 13:28:53 -0800 (PST) Received: from [192.168.252.96] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6153C18014F6; Wed, 13 Nov 2013 22:28:52 +0100 (CET) Message-ID: <5283EF14.60206@pi.nu> Date: Wed, 13 Nov 2013 13:28:52 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201311132114.rADLEsVt042926@gateway1.ipv6.occnc.com> In-Reply-To: <201311132114.rADLEsVt042926@gateway1.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-multipath-use@tools.ietf.org Subject: Re: [mpls] Closed - Working group last call on draft-ietf-mpls-multipath-use X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:29:01 -0000 Curtis, You are right! But there are also differences between comments. Sometimes there are things that changes the draft dramatically, in such cases the chairs will return that issue to the working group, independent if that comment came in as part of the the wglc or not. Some comment proposes clarification, most of the time working group chairs will nod and say "go ahead". Some comments are purely editorial, these could be addressed among the authors or by the author. Of course the wg chairs could come back ans lap your fingers for any change you made :). And you are correct a working group document is under the version control by the wg. /Loa On 2013-11-13 13:14, Curtis Villamizar wrote: > Loa, > > Thanks for the clarification on WGLC. My impression was that any > changes after WGLC should be brought to the WG and inclusion was at > the discression of the chairs so I sent the email below. > > The -03 version has been submitted. The WGLC comment from Vero Zheng > that acronyms should be expanded before use > has been addressed in addition to the changes identified below. > > Curtis > > > In message <5283DDCD.6030501@pi.nu> > Loa Andersson writes: > > Curtis, > > the working group last is not a door that is shut and no more comments > allowed after closing. > > It is rather a door that is opened to notify that now is an excellent > time to comment on a specific draft since he authors will be focused > on updating the draft. > > Please go ahead and make the changes you have indicated below; once all > updates are down, re-post and let me know and I will go ahead with the > publication request procedures. > > /Loa > > On 2013-11-12 08:41, Curtis Villamizar wrote: >> Loa, >> >> Although WGLC is over I reread draft-ietf-mpls-multipath-use and found >> three editorial changes that should be made. >> >> OLD SENTENCE >> >> Alternately, the need for requirement MP#1 can be eliminated if >> every MPLS-TP LSP can be created by the MPLS-TP ingress makes use >> of an Entropy Label Indicator (ELI) and Entropy Label (EL) below >> the MPLS-TP label [RFC6790]. >> >> NEW SENTENCE >> >> Alternately, the need for requirement MP#1 can be eliminated if >> every MPLS-TP LSP created by an MPLS-TP ingress makes use of an >> Entropy Label Indicator (ELI) and Entropy Label (EL) below the >> MPLS-TP label [RFC6790]. >> >> The above change is s/can be created by the/created by an/. The >> original sentence was understandable but grammatically wrong. >> >> OLD SENTENCE >> >> For those LSP that are larger than component link capacity, their >> capacity are not increments of convenient capacity increments such >> as 10Gb/s. >> >> NEW SENTENCE >> >> For those LSP that are larger than component link capacity, their >> capacity are not integer multiples of convenient capacity >> increments such as 10Gb/s. >> >> The above change is s/increments of/integer multiples of/. Again the >> intent was clear in the original sentence but the wording was wrong. >> >> In the implementation section (which will be removed by IESG) the one >> change is s/mpls mailing list/MPLS mailing list/. >> >> I was unable to submit immediately after last call ended due to the >> IETF-88 submission blackout period. Hence the delay in submitting. >> >> If the above editorial changes are OK with the WG chairs, I will >> submit the draft with the changes from the WGLC (define acronyms >> before use) and with these changes. >> >> Curtis >> >> >> In message <526B3C00.1020104@pi.nu> >> Loa Andersson writes: >>> >>> Working Group, >>> >>> This working group last call has been closed. >>> >>> We have seen very few comments (1), and that comment is editorial. >>> However we believe that it is nevertheless reason to go ahead and >>> start the process to have the draft published as an RFC. >>> >>> Can the authors please address the comments, make sure the commenter >>> is comfortable with how the comments been addressed, and if necessary >>> post a new version of the draft. >>> >>> /Loa >>> for the mpls wg chairs >>> >>> >>> On 2013-10-12 20:02, Loa Andersson wrote: >>>> Working Group, >>>> >>>> this is to start a two week working group last call on >>>> draft-ietf-mpls-multipath-use-02. >>>> >>>> Please send your comment to working group mailing lists (mpls@ietf.org). >>>> >>>> We did an IPR poll on this document prior to starting the wglc. >>>> The authors responded to the IPR poll that he is not aware of >>>> any IPR's relating to this document. >>>> >>>> There are no IPRs disclosed against this document. >>>> >>>> However, the data-tracker identifies one IPR disclosure (# 1593), but >>>> this IPR was disclosed against an earlier document that this document >>>> replaces; the author has indicated that one reason why the earlier >>>> document were replaced was to avoid the IPR. >>>> This happens because we mark the documents with a replaced by info, >>>> the IPR tracker tool uses this link to find IPR disclosures, but >>>> IPR is not always continued over a link that indicate replacement. >>>> >>>> The working group last call will end Friday October 25, 2913. >>>> >>>> /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Wed Nov 13 18:28:25 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1379921E813C for ; Wed, 13 Nov 2013 18:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHoM0-ub81X7 for ; Wed, 13 Nov 2013 18:28:19 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 291F821E811C for ; Wed, 13 Nov 2013 18:27:38 -0800 (PST) Received: from [172.20.4.125] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6598618014F6; Thu, 14 Nov 2013 03:27:36 +0100 (CET) Message-ID: <52843518.6010202@pi.nu> Date: Wed, 13 Nov 2013 18:27:36 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: [mpls] wglc on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 02:28:25 -0000 Working Group, this is to start a 2 week working group last call on draft-ietf-mpls-forwarding-02. Please review the document and send comments to the mpls@ietf.org mailing list. There are no IPR claims against this document. However, we know that some of the author contact information for this document is changing; this will be updated together with the of the last call comments. The working group last call ends November 29 - 2013. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jeff.tantsura@ericsson.com Wed Nov 13 20:17:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E168F21E80D4 for ; Wed, 13 Nov 2013 20:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k4kRA2V1gpi for ; Wed, 13 Nov 2013 20:17:32 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB821E8192 for ; Wed, 13 Nov 2013 20:17:25 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-df-52844ed246fe Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C4.5D.23183.2DE44825; Thu, 14 Nov 2013 05:17:22 +0100 (CET) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 23:17:21 -0500 From: Jeff Tantsura To: Loa Andersson Thread-Topic: [mpls] wglc on draft-ietf-mpls-forwarding Thread-Index: AQHO4OE24QcIals1pEOTw5GUXxYMZpokHxBl Date: Thu, 14 Nov 2013 04:17:20 +0000 Message-ID: References: <52843518.6010202@pi.nu> In-Reply-To: <52843518.6010202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXSPt+4lv5Ygg7Z5phYb7t5lt/g3dw6z xfdLS1gsbi1dyerA4rFkyU8mj1nT29g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsWTzfbaCC+wV a7/+ZmtgfM7axcjBISFgIjHpfWkXIyeQKSZx4d56ti5GLg4hgSOMEks6jzBBOMsZJdZNf88O UsUmYCDx/9txFhBbREBW4tq2n0wgNrPAKkaJF9PyQWxhATOJzxNvQdWYS/w718QOYRtJ3P3y GizOIqAq8ffkJDCbV8Be4u3f82C2kICKxKMJ11hBbE6gmn8LuxlBbEag676fWgO1S1zi1pP5 TBBXC0gs2XOeGcIWlXj5+B8rRI2OxILdn9ggbG2JZQtfM0PsEpQ4OfMJywRG0VlIRs1C0jIL ScssJC0LGFlWMXKUFqeW5aYbGWxiBMbKMQk23R2Me15aHmKU5mBREuf98tY5SEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANj5uTpt59UXTu6e3PS8jihW95ZSoK/fZUkVcoj5LZm+jw/o9pT aRu9eYZDzM9tMzL2HvN5l3FYpWuBhqvrAccqjkcXPwforZ8dNq/om3n2xvO2XKmXdyo6z60y XLVirVXtmeQ1wsfc2bun/tz9tjNULYXtvKXnq8uJPUH3tmWF7c74ev6056RSJZbijERDLeai 4kQArnK6GmMCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 04:17:38 -0000 Yes/ support Regards, Jeff > On Nov 13, 2013, at 6:28 PM, "Loa Andersson" wrote: >=20 > Working Group, >=20 >=20 > this is to start a 2 week working group last call on > draft-ietf-mpls-forwarding-02. >=20 > Please review the document and send comments to the > mpls@ietf.org mailing list. >=20 > There are no IPR claims against this document. >=20 > However, we know that some of the author contact information for this > document is changing; this will be updated together with the of > the last call comments. >=20 > The working group last call ends November 29 - 2013. >=20 > /Loa >=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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From shane@castlepoint.net Wed Nov 13 22:43:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35D611E8172 for ; Wed, 13 Nov 2013 22:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbs+IgXX5bUJ for ; Wed, 13 Nov 2013 22:43:24 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 25C4011E816F for ; Wed, 13 Nov 2013 22:43:24 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id C442A300049 for ; Thu, 14 Nov 2013 06:43:23 +0000 (UTC) Received: from [10.0.1.8] (c-67-188-218-56.hsd1.ca.comcast.net [67.188.218.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 366AE300047; Wed, 13 Nov 2013 23:43:20 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Shane Amante In-Reply-To: <52843518.6010202@pi.nu> Date: Wed, 13 Nov 2013 22:43:19 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <52843518.6010202@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1812) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 13 23:43:23 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5284710b42071687320985 X-DSPAM-Factors: 27, 2013+at, 0.40000, 739+81, 0.40000, this+#+#+#+together, 0.40000, mail01+#+com, 0.40000, call+#+#+#+mpls, 0.40000, against+#+#+#+we, 0.40000, Loa+#+loa, 0.40000, and+#+#+#+the, 0.40000, for+#+#+is, 0.40000, 2+#+working, 0.40000, nu+#+Technologies, 0.40000, PM+#+#+loa, 0.40000, However+#+#+#+some, 0.40000, loa+#+#+Huawei, 0.40000, pi+#+#+Working, 0.40000, pi+#+wrote, 0.40000, nu+wrote, 0.40000, 2013+#+#+27, 0.40000, To*Andersson+loa, 0.40000, Mime-Version*OS+X, 0.40000, Technologies+#+#+46, 0.40000, are+#+#+#+against, 0.40000, as+#+#+#+On, 0.40000, Loa+#+Andersson, 0.40000, group+#+call, 0.40000, group+#+call, 0.40000, working+group, 0.40000 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 06:43:28 -0000 Support, (as co-author). -shane On Nov 13, 2013, at 6:27 PM, Loa Andersson wrote: > Working Group, > > > this is to start a 2 week working group last call on > draft-ietf-mpls-forwarding-02. > > Please review the document and send comments to the > mpls@ietf.org mailing list. > > There are no IPR claims against this document. > > However, we know that some of the author contact information for this > document is changing; this will be updated together with the of > the last call comments. > > The working group last call ends November 29 - 2013. > > /Loa > > -- > > > 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 c-sai@bx.jp.nec.com Thu Nov 14 03:51:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A821E80B6 for ; Thu, 14 Nov 2013 03:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJfvwQcrJOKY for ; Thu, 14 Nov 2013 03:51:53 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F721E8090 for ; Thu, 14 Nov 2013 03:51:52 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAEBpoeu018643; Thu, 14 Nov 2013 20:51:50 +0900 (JST) Received: from mailsv4.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id rAEBpnh22675; Thu, 14 Nov 2013 20:51:49 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAEBpnL1029230; Thu, 14 Nov 2013 20:51:49 +0900 (JST) Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-28040; Thu, 14 Nov 2013 20:51:14 +0900 Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Thu, 14 Nov 2013 20:51:13 +0900 From: "Zhenlong Cui" To: "'Lou Berger'" , References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> In-Reply-To: <527D51B6.1060106@labn.net> Date: Thu, 14 Nov 2013 20:51:13 +0900 Message-ID: <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_097C_01CEE17B.4143EA40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq0BaI8zcAJ+CQwLArAVKgmYLBl8sA== Content-Language: ja Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:51:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_097C_01CEE17B.4143EA40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lou, I agree your opinion. I looked through the draft, there are few comments as an attached file. I hope you will find it informative before you post a new version of the draft. Best reagrds, zhenlong > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Saturday, November 09, 2013 6:04 AM > To: Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework > > > Zhenlong, > > I understand you have an additional concern regarding supporting a MIP and MEP in a node that is both a branch and leaf > node. I think this is supported, where MIPs are associated with the P2MP branch data plane function and MEPs are associated > with the leaf data plane function. > This holds for both for both per-node and per-interface MIPs. I certainly agree that it is reasonable for there to be > a more in depth discussion on this topic, and suggest that such a discussion be added to draft-hmk-mpls-tp-p2mp-oam-framework. > > If you'd like, we can something like the following to our draft: > > It is worth noting that a MIP and MEP may be instantiated on a node > when it is both a branch and leaf node. > > Please let us know if you still have concerns on our document. > > Thank you, > Lou > > On 11/5/2013 11:05 AM, Lou Berger wrote: > > Zhenlong, > > > > Perhaps the issue is in the slightly different language used in the > > draft versus the section 3.7 of rfc6371. RFC6371 says: > > > > o To send an OAM packet to a single MIP, ... The OAM packet must > > contain sufficient information to identify the target MIP and > > therefore is processed only by the target MIP and can be silently > > discarded by the others. > > > > To better align with this text, the draft should be revised to replace > > "addressing information" with "additional information" > > > > Will this address your comment? If not, do you have some text/changes > > in mind that would? > > > > Much thanks, > > Lou > > > > On 11/4/2013 12:56 AM, Zhenlong Cui wrote: > >> Hi Lou, > >> > >> Thank you for your reply. > >> > >> I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on > a transit node. > >> > >> However, I think that this draft need further explanation for the OAM behavior on transit nodes. > >> > >> The P2MP OAM behaviors are described in section 4. > >> All the traffic sent over a P2MP transport path, including OAM > >> packets generated by a MEP, is sent (multicast) from the root to all > >> the leaves, thus every OAM packet is sent to all leaves, and thus can > >> impact all the MEs in a P2MP MEG. If an OAM packet is to be > >> processed by only a specific leaf, it requires information to > >> indicate to all other leaves that the packet must be discarded. To > >> address a packet to an intermediate node in the tree, TTL based > >> addressing is used to set the radius and addressing information in > >> the OAM payload is used to identify the specific destination node. > >> > >> > >> My comments: > >> > >> 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. > >> The case of per-interface should also be described, if you like to mention about the per-node case in this draft. > >> > >> 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on > a transit node. > >> e.g.) > >> When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed > by a MIP functionality, before it identifies the addressing information. > >> Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. > >> > >> > >> Best reagrds, > >> zhenlong > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Monday, November 04, 2013 1:17 PM > >>> To: Zhenlong Cui; mpls@ietf.org > >>> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>> Subject: Re: [mpls] working group last call on > >>> draft-ietf-mpls-tp-p2mp-framework > >>> > >>> Zhenlong, > >>> Thank you for the comments. Please see below for responses in-line. > >>> > >>> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: > >>>> Dear authors, > >>>> > >>>> I have a comment/question on this draft. > >>>> > >>>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. > >>>> In this case, the drop-and-continue node will become an intermediate point. > >>> > >>> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. > >>> > >>>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? > >>> > >>> I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit > nodes. > >>> Assuming you are asking about the case stated in the previous point, > >>> that a node is both egress and transit, then I think it could have both MEP and MIP functionality separately instantiated. > Section 3.7 already covers P2MP MIPs and MEPs. > >>> > >>>> As described in section 3.3 of RFC 6371, a MEP terminates all the > >>>> OAM packets it receives from the MEG, may discards silently if > >>>> addressing information in the OAM payload is different with > >>> termination node. > >>>> It means that the intermediate node must NOT be configured as a MEP > >>>> when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. > >>> > >>> Why do you say this? If a node is both transit and egress, it will > >>> replicate OAM packets (just like the data) when performing its transit role before then terminating the data/OAM packets > as part of its egress role. > >>> > >>>> > >>>> On the other hand, if the intermediate node can't be configured as > >>>> a MEP, the path protection may not be able to work at this point. I think this is a serious problem. > >>>> > >>> > >>> Perhaps I'm missing something, but I simply don't see an issue here > >>> that isn't already addressed in RFC6371 (and 4875.) I guess 6371 > >>> could have shown this case as an example, or provided a related detailed walk through, but either way I don't see > any "serious problem" here. > >>> > >>> Perhaps the best way to proceed on this is to propose text to the > >>> already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? > >>> > >>> Thanks, > >>> Lou > >>> > >>>> Best regards, > >>>> zhenlong > >>>> > >>>>> -----Original Message----- > >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>>> Behalf Of Loa Andersson > >>>>> Sent: Friday, October 18, 2013 1:29 PM > >>>>> To: mpls@ietf.org > >>>>> Cc: mpls-chairs@tools.ietf.org; > >>>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>>>> Subject: [mpls] working group last call on > >>>>> draft-ietf-mpls-tp-p2mp-framework > >>>>> > >>>>> Working Group, > >>>>> > >>>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. > >>>>> > >>>>> Please send your comment to working group mailing lists (mpls@ietf.org). > >>>>> > >>>>> We did an IPR poll on this document prior to starting the wglc. > >>>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. > >>>>> > >>>>> There are no IPRs disclosed against this document. > >>>>> > >>>>> The working group last call will end Friday November 1, 2913. > >>>>> > >>>>> /Loa > >>>>> 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 > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > >> > >> > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > ------=_NextPart_000_097C_01CEE17B.4143EA40 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-mpls-tp-p2mp-framework-04-r1.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mpls-tp-p2mp-framework-04-r1.docx" UEsDBBQABgAIAAAAIQAChWeXqgEAAJUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 Vctu2zAQvAfIPwi8FhKdHoKisJxDmh6bAHGQXhlqZRPlC9x1Ev99l7ItOK1quTFyESCROzOc1Q6n V6/OFs+Q0ARfi4tqIgrwOjTGL2rxMP9efhEFkvKNssFDLdaA4mp2fjadryNgwdUea7Ekil+lRL0E p7AKETyvtCE5RfyaFjIq/UstQH6eTC6lDp7AU0kZQ8ym36BVK0vFzSt/3ihJYFEU15uNmasWKkZr tCJWKp998wdLuWWouLLbg0sT8RPLEHKQIa/8m2Bbd8vWJNNAcacS/VCOZciXkBrZBL1yfIbqMMyA ztC2RkNfn9FiChoQ2XNnq37FKeN3+od06BVScD+dlYbA3aUQ8eJkOT1oxoNEBnoPhzR0XiCtLeDJ 1H85scE9ZMEe/aOh5U3bguYfbrwnDstcW20o9mrH2YCIG3UMydsxKMcaj1vkUQkv8HT/YSr2wEeF 6ODyDHyAFzvkUQktJ8RcPVk4oun/2Y8eelQEceyB7J6nT2AHc4iSA6Ibdo7R9I5j73IyV5ecPEdM ec/IEXyyz5BDvoFmgFt2l8rsNwAAAP//AwBQSwMEFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsACAJf cmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5IoXci6wOEmewBdw7MpNq+vaMg ulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeLB1BZyFuagmcNR86waW5v1i88kZShPIwx q6Lis4ZBJD4iZjOwo1yFyL5UupAcSQlTj5HMG/WMq7q+x/RXA5qZptpZDWln70C1x1g2X9YOXTca fgpm79jLiRXIB2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi1fVE/1+LjoUsCaEJic/zfHWc A1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAGAAgAAAAhAJj3d8RTBQAANToA ABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAvFtNk6M2EL2nKv/BRVVyA8yHAW+WcQ7ZVO0hl2RS2auMhU2MgEjyeObfR5IH j11je9wsrctUgT2iaXW/97rV/rx4ZvXkiXJRtU3uBN7UmdCmaFdVs86dvx9/dzNnIiRpVqRuG5o7 L1Q4i4cff/j8J62JVP8kNlUnJmqVRuTORsruk++LYkMZEV7b0UZ9UracEaku+drvSLEla+qH02ni 89M1nIezNSdfV7nDv66CyJk8vnTq0R8v3pZlVdDf2mLHaCMvPMPfqJV4XTVbtSjhaypzx+dlsarK cqH/SP0k193s9cXPhHW/7Hgd5itOSulWVJYu62rhys7tQta5JSeM7lu+daexJ59lv+of7UoZ/OVZ Ut6Q2vGvvJryLeqref4dhgcwo8ME2ejXbZZ8JySlnna6iZxabW0jqFs1ZQszOZojm+zpGJpFUQiz K9Suxwztu/Y/hhkd6e/jGq2dmcyAdsXa+eh2JVEKtSu1YVecpTPYPs4U0uP7a4Bd+j1s7CMwWRNs HjIgovwFtQufRHQ+zg1YGcq8j9xSbJ54D26GkiV1WbV0pxrzAeZmdmAtS3TaQeyywl1JYjgSYBc2 qvndqrxHvQyQXSk+7aqMUUwBROT5qAwmlQSnfazljrn0zd/AU5r8miYd1QYhX2pVLxyl9uH61uMD W6hRLpdXpHxv7n0wF1rJTzj8BuhB7vn7ta+rIaDDsIH2tX5YEUkkV9Um5W81hCmHhF/sONcFIsxy I+/RlQlcMUXYWHwob8AKILaiMBXOAivY2JbC1IoRQKkzKwpT+QuoMGdWFGYcpTqOAf5K8LliUFlv KkRcnDhp69ThU9e4Tx0TqhvF9luX0/92FVfk30jhToEaJMWns2XRBcAaOrOCcAMyQwXsaBu9p8u/ qJSq8Xpk1Nw5uXlLNiXobG86XGAKyEaVkxeat4eiGQwdc2xq6puYbVuLN/kh9aX2JCN8u+uA+iPA z80TXLnW5waSh0n10XLkQgQc2/eIjfoQP4wVKqaaZwH8F1pBRXgnNsJOroF6NBpV9xUtMxTb71nu 9HduAXVsS+MBeT+2ovEUw0I1sR2NBya2BLuK7bvBQH8l+BwxrBuMj1Un3NXtaXQ4oO3236eHsdPC r1b3dTl1yw7EDjMrkhB+XmGqT0xB0J8LbNj2vMPXEnZ6YA8UMpkVVgsDo/IAKiAbldUuCKxXtjXx BLDrGtGxquCtaEvpKb70DxMbelIjPZ8G8Q+94n8quflSlrSQog//3Hn30S3GDbC1GyNVLdtPJ/Bz WTr/atT/sRhYiN3yX/VeH8+W/BTq0AO4PrAKtpff1p0CjQ7x43iAxo6uhfGF0aZB00eH7AKPjkTY xNTrD6iOtKLXBuhIO7oIfLyb4Keq1mvgaRoDOTZY+uZMHVD8xlYkD/wszowy4TpTbXIcxzqYADyR YFPjQBBJrUgtBSLANrQ50MfdxxMVMW5jP7NCZPAYzKwQGZww5qNiSdk28pEsa9onaO4cb90Ur+r7 owVcoQZqW/btrZDMHc9TZ+Gvd/1KUnZzNgSd2z1/I1kNbYtjC0dVozeVFAvVYM4v9/XvLeLBE+Ih ftZqUazFEYA3Qis5C+fZCD1A9WEDvESPrYhPOMbN7IjPObR1EGDzv85ioX6ncnlGqC0+bsnBEiYa lUyu9mjAKj+20sUeEJi2hCmwwDDDu6Px8dV9BCdMgk2BQ4U8Pn0dBPPIvV5zEou7zwe7OVmvCd8T 9+zEQv0Aj3RqdkejBoCWMysoA5/TyqzQskIZoL9GBT/xbnSnv3NL32MLg7uPl7Tuvh5t/tmPPR/+ BwAA//8DAFBLAwQUAAYACAAAACEArlp+AaFbAACFNAQAEQAAAHdvcmQvZG9jdW1lbnQueG1s7H3d cttIlub9Ruw7ZOhi144xZZGS/KMZaUK25WrH2FUMS121O911AZJJEWMSYAOgZHXsVdWL7At0dEd0 R/RNXe2r1APUK+x3TgIgEkRCIARQgojqiJYsUUDmyZPn/3zn3/7962wqrqTn265zvNPd3dsR0hm6 I9u5PN75/cX7zqsd4QeWM7KmriOPd26kv/PvJ//9v/3b9dHIHS5m0gkEHuH4R9fz4fHOJAjmR8+f +8OJnFn+7sweeq7vjoPdoTt77o7H9lA+v3a90fPeXnePv5t77lD6Pt731nKuLH8nfNxs9WnuXDp4 19j1Zlbg77re5fOZ5X1ZzDt4+twK7IE9tYMbPHvvRfQY93hn4TlH4YI68YLoT47UgsIv0V94K7vI eK/6y3chBfiNzz05xRpcx5/Y8+U2yj4NW5xES7rK28TVbBp97nrePVh5X7zlImfwzrOucRTLB648 LoMYI/VHs6miA53v8lTTT+zu5W0mPBF6RLyGIkvQ3xmtZGbZTvyYcqRJEhc34i78/Y3nLubxcub2 3Z72wfkSP4su5hor23vBNy+5NX+tB6xc3fOJNZc7YjY8+nDpuJ41mGJF190DQRy5cwJhMXBHN/R1 Lq6PIGxGn4939vZ6bw7fHHR3oh+9k2NrMQ0Sv+G/6Hv0xZ9bQ3AmPjuQkAB4PkRV9I/TReCGHwh/ bo0DiZvMn+HvUx95Ts8c2VcfRnjIlTU93nn54sXhq4Ne79UO/85Tr/Xeu07g4zOWP7RxZG/dhWdL T3wrr+n1k1PHT/2U/3pq8VL5wdKhJz7HvumR+DoPH01LqOs110csl5lsoNXck770ruTOiajoP9pI oLalNsVnBZI8zNPtvtp7dfBy71VvTz/e8+BmKiMWAJW66tdrn9/azyHq/UEjIrjpZi69qe18Ed6R PTre8T6MoMjwSdedBvb8eCdSOMKXljecCOhl4ckAHAlOE3PrEpcQj7H9wPVuoM756vH1ifhMW6e1 HxKjaianzWGtvrY/MEy8QWb9JP9r6ypyDvSKH0WagtA77vjM84hoIObxjj+X0+l5YHlBuNU7vnQ8 Hb2dWPT88LsLfs1AXkLVhNe8is3Zjh94F/Kr6Rb/7n/3zz5//PDtf4hI8hOT+Lu2DMZsGdmj59DL 46BDP+nM5lO/E8w7895s3hl71kxCY37p7B3sBl+DHfFHV+z0p9CWAb0xNAeFOxYBeElEht6OoPOM VxZdflz5eojqy7nlWYFM0nXlgC+xmULnWyuzg4oar0PIpzmRFnrmjGplQ6mej1NSR3LHcwlO/k9q V/EFXkqol5qE6r97n8M/D0U2zUdjbWPVi6YChINnlRDt/+vTR+HDuBhKAfMmffEeCuHgft0/4V5r hPvdBShnElnPxNhzZwLE7X1+/5b+7mEox0mQImSGwGDVFUqM6hl0VXdm3O0u28+x+fHh7Pwb8c4K rMCzhl9gBduOcsbh9T5krr1Qy62Zc4tRlN2dmKIXExif0MTk2VySfygmsOlgAl4+VAnwwzcPgow9 TQacQ/EJRJzsqQhcUE7GNouwFsHE9RCPeShX/4yW+SBouK/R8IMDtgPh7PFYPLmmL08fDtHeYTnd B0G0A41o5/ZIdgY3HUQ0FOkeFsl6D4JkhxrJPi8c+K3CHjk2AisIFA+/ZHgaD+W2fotF1ktEinev hml+ZF8rDrBEBr2KHJmjEwiIeRV6oSbvs44Y0n1t8eR7lf3wj8QT7aTBgqvxmK4ekOl7crjwfNd7 OPdeef3jwcDg9Gt7rNyuzObmp3kMk17QnLzWhxsnNkQSzXcSNM6K+JaJeGVTd0lcjZTZ/Mvu+sNw gvb2tPVuiBfTgjXrkrNr/kCIVLPZY2Ap7WSyOYnd8AdCpJoNndJEQrrhwTgee/vaoT6c69Zjn/iB cNLBvRBpKcILfaet8b4MJ8OlKLSB2z+kbZFU6J2sgrmmbSlkqOLwWga4tGZ/4MsrziDByaf+x3Px QxiR4oqF248q+Yl3u+I9Sn70bMgjos8HpMg8Rwadd5RcS+680Pfnu+KNd2M5j5o+zkiOqGgsWMCn +rAMESNFnfffW9sfuuL8xg/kbMXnfsjXf437lS0zz77ObRRoHInTuYcQZvfgmUB93EEesbTffdpN G7Ur2ce8PLjZdaEk+xt3OLQ1aXx7ruJRn5ZG+rX+cTodIp097XxcDFE3qdH08YjIbBZfi06rH/4I uSm9S+m1RFslzupPNCqZrquhaiJfGny0Bt8WenpmqUPusw2M8xYVtagKREpMe297YVaPnX7y3TBw B0jNhkpkxed7yKL5gZ/pA1/enc0QZijtkumP9DQnatK9tVaSzIdT+ANhuRmXCPRdVJl1ArfziS71 nP4l2OmwHYE8vePPXS9AeW1AafHtMgNXL3TqMFasusLFbwUPS+UO8isGi6xpWbXSipvSUQX98uWq zpPTAcpFrWGjbMotEKdU3qPknOcG7tCdCthPcirOr+1gOKEqn6XI63vu2EYtOgpuqYAF/UkzVFX5 slFnugbPGsw9casrmyP08i+Jqxd9ZtjFxhrd3AcbdsJaDSJbHfx44Qy5O0yM5BiFNiOqVJIOtcqE 500V3wv+DNX1a2J2C66Ktl/D0ZTyWNCwhiJyVCgWeUNlXgtq59Gw9EUGAnI5NGoQNmSjZlcIFgwI tXYu+sJfzMnm8cXADSbaIttj3yl92dmyJDuTv9HIauCuys6eunLi18+WZu6SE9CsOvGZDeytM3GL HEWpix61qRR5QWVnrYS5UtlyKqkf2ue2rKW85zYa2AHqumuray94+QtODXB2IIfBwpMaUWu/3vP5 1B6y4kZUfWijqd2aTm9In4einAy7WABoa2sPvPyBLyWpRtK6jzsttbWXP/DzfODLW8NbOIFKQD6R KoUvUCkiPsmZ255Euod9E7EGg7dDNi3OJZUfx0/8xWBmBwEcHkT4xovpFK6tygk76HWDIzwh/6dJ Z7kG2xqJpe3XIMJKWUFwOK9sQnPRDUvDKyqzg3AvU1vKqKvscdfO2oVeuc73yZu3ffHylfZyiL34 7dwCm+iDzX2Y4bjIoNdekHj+shG2x/00dezutfby0rs72U0/p43O3qvE1IUl/AZv2Q0YeTOs8igg GH1YnDnAGpDS28KM6IXlfxHvXWqSfvLh7OL9U/jQ37oBRdCsQCB8gsQnt1H6YmbdCGvqu2hoQ1zN HiyCVseksDFKx1bCjlVNmtStYJb3wUpbGSqSIsUUJ00GIjpyPMIli25MR1vo47GJDdqqxgj6Oyp6 9JGi0Cha99HjaqfeF2v3hPblxsyKtW8IqjVatrwvAVZGTIvnIbM911bYqmhqe2AkqFxQr3rLsquw 02MZErI+qWg++bjD3BfAXrJHXNxgQe18tWeLGYkh3/4qkMJDpDfNGw/Z7KqCaNp+DdKhlHOTzosZ nl2ZV0NGxECKxRwSQI6eAWtrPrWG9B0gWtyB704lObaDm9D2SCipAFHgG40QreIpH/sL7JluvlV2 8icwIT8ElHW3HWsO7xkl2DhsiuYu/KXVrer9YaL7YIKxhH0x1BfUnm750wXWKdwZS0fFqOyEDWYS gSy5YogUAsWfILHZe4AjAXgCX+yQjUsRK3DEJWrz/d2dJl3mLeDGrHDjtY3wouRuCoHiGb2doo1+ UBismo63NayEk7fu/MazLyeo6nQDAEC39+g+jsEgBYVYHs+T4VPqO9oXFFpBZdoC7jSFPin6hCIa HzFlwLbAs0bKE1YPpCR+06TTXINrjeTS9mvQUaVs28h2LPKCygzcEB0LNtApJCffUjJwGCt41ArM exGYRtZjjRexCVmsSK39FwogyI5JcU1WgIRhmCoOkGwo+UISaCmU/qcvPsrLlLm4BRZPP07tic88 a4BQAl1FmHfhKIKtizUUwGzqMWZTxZwfhgZRsot+ZbkMC6I0SDq+7BA0pnYpwaDxrVwrKXnylPwQ OR7TVYdVS5eB4hGIMaVf8JADSw/8grbLwwyEO2RD4SfryOs52SW9kQzu9Y1C48jNzZ8wrsQzgZJq a6qbJgYzLNNKKvVuo0qOW7bCFv6Uyxn/OvrmD31g9Ivuj5kXd+C6X2igDZuPiJ/TCADGD3LQQIcZ DvjTTk9RqjQ8miniTg9/40nryxuersFDLDbtKpbB1s9jmRip3nB8CQx9QOBPRURhNqbiPz6hs1qB U897r2EfWXD2ZuT8CK4eTUOIVIUzSt7zf4oFFtEPHQxmKnB/DETQODHa6O0wk4Y9Sh2APuJo3MSY nxU8ZT2aalNcXEqInOi5JBIJ3CJ0ETeIwMDjFrB+71M/0TZLn4zausk/146sNr1VHy3bJS8BqOqj cvG7bEZ51TjNoGVLBTvmiwHV0N9HW1YARyBO3iLw0Z9KC4keT17Z8pqMa/wjcrI35E1tKRMMkUyn gmA9TWpgs0xjLk8LByfPwhDlDVou/SFqwKS4wYSNKMxFoU2EulAcFjZmci0yfoKmjg013W7pwQe6 Z1zZiRtMnPSNf+uOJMLeszkMJ2rXwswj6p1HSJuHhWgfFzP495oYbKD2etCqwHaG08VIzyPUzRHn NgZiqSzGm/N34qOK2QiefoW0RiQuuGVBO/xEDAcGreUMMVsCQ8YgMFBx36mjBO1cPVscaOsAE5YM Ju1uLm60rdItlRSrm5lVoo4j4iIRIib1RtVqCMxcIWsHBwytNu4iENeWB48jQHl0a97As9LuleGs Stm4sRQp8ob1zRuDskOomALE2RJOD5s1UJM1cMlrKN+TC+4qRu0oQO8Csk001mng5hu45DXOy3AF V2RKrKozbIZy2Of5jk/xkQG5z8neHtVLOoHnjhYKq0bsrvm/QuQh2wHBbhCs4rxd3qSALeXWQgcS 2bjd3Vo4drdunj0fAghoTU5VnF2IPC2/Uk7bLE7oaq2OPTd/HtCR2eKHguFpmy1Xvu7WIUW6u3ly 5M4qBDL2Qnoz20Hy5/JmTa4tRB7m1zoalleyE/HhcCKt2Xmfsvxa6EiWErZXk4zFc9MGZeJ0quDa 09HIplAIoP7R+GVjxB8hEXAVaZKhUxxdiDwtxz5YCVuHHOnu5kmSSng1xHGypzaCIetYsS2/3kt9 iNki0KRaIjSa4W/VYQ3UbQuYygQyoLQ/yz8tMEtE4dCta7/WEb/Oi1tvqb+1BrfWIVlrl6sJYD6x llwlfi0uW1tutVAAHlaGSYdKwHChPPKy7s3b2q/FcsVTtTuD7VVst4bgnMDWGVpzjBvhyhQ2W4E2 g4TJiCAdM3m5OL/W0X9xmEOXVrqSwRwzSoYtsGkJUoXV+l0EZ+0/E6cjhAgI3mjJrp8smzIHyEzL LH5tubW5luum5UcV3Ep5LA9jD/qInKwffS3OrXV0+LxoZSt1HYTdoDsn60ZeD2uxBfDUnHOpgmf7 GW7Vx/M+52Tzebnl1wcmXQsdSBR3PawlU4Cn3gO/9n9IsesdbdeXNWRiX+bQpbVdb7NdN63xqpCs 5wvvyr6yButHXNeLDLTcupHIgHZ/8z2tTZ9IFdwaziAUnywHxSgUUc3yqEx5g0Kqh3Nam6ZNK1tv k62vatB2tSKUI2yKOvGFR4ksuFw+6n1VTMDP1PurPFucWzdNm5Zbb+PW1zVwa0WI89klPODWD6ff npbj1PUsgZZbH5ol0GVEg4qLOrt7mi0CmRGHfen2JLvsS5Tw7AJuJ4T89NcxASIx2wrXJocFunu1 xLHosfUyLeAWPSCr2lcyyb8RU+Z9bRm24QxbR5ELGLbuSNYHNRdqfZYtzrCbNpYaaL5GS47AW5Jw RFz7r+CIorBpt+GIRDqWy6QX7mfVTrg+ImSA7y1kXCdR2cVesuri+siAijOQmNgTfTJtkBR+P86F izsADEWjoi/Qtp5tX4sVYKPlWRXBNiq8ovIUKYeF5L1HOtGnRL4/tO3jnbdAc7Ax8udbec0+0Ck8 X/2nLMcH6v/f+vxVA1Ta4/8UB68LqHSi62/dzCxMw+WpGpjnVkilkGGTRm6JtwcMhJ9o7EobJ02r 3I/E2KOESjPdfJrCiFHDPHM6mjz/0RrIqThH+zcG5qKMaRVvCoA41DM8dGeYVyJ82QJerJYhroNv uKo7lrc8OEnBdhpazitrCOfiYaw+cCH5MIDTCdFu1ORqoHu7YiZpTj04wEtWD4fDjeWo6ZJAl8y5 h2NQqCv2ZXXcYDsaeevmhj+k3hbHSRKTtDghEbjuNLDnxzv/408LN/hXra4cDeqYkpFdla4+XkNI 8vP7t4cvDvPKydc455MfEYRkUammsifQ9opQiMOKKQqdJp4xBmQjkwdoDEtxGyaU/FpJ9LqnmyWQ PPEZp03P3Ktw8mMEHUL9W8K9Qkphqo9o2VIVm7pCVcqCZV99kZdUpiOgA0j8R1XQBB2j1IMyDC6l Q4cPOBlYEAEAiRbAlUmpsZYX6HZVxws4j42ywFJM9RUKKaPnXUuMheBBHy5gES2GxsPcAfjBQM8a ku0wj6rltNW23FAtNzCVNQobeK06kRCj0s4tjDAM1eV84c2JE2AB6DB55EJg1i71/PI8LW2tLTdU yw1yqhr8NCLXzRCkFJbeAzNAQmMkNQPG6BG462CqS7CWC6rlgkgKwyqrCUHV4A3hovuL+dz1Agon xApgxlEHUgcCHSmOTx8QSnhojNpAPoiWnBUS51xLKiSOjCHHGhsbe0oFEPfvOShufj9O5s5Bccrv EofGYXXVSEm3NSeoal7TtofFU4ntklRcnmzZwHg4K6PUGS7fzoFxRo96LFKssVIpN15hUFYU5kkA vmt+bWRHcaOvybZp+qnr168cCTUaGAzNUhipyYhCkZdU5t54NEANoLhr2DLa+iAfmpYQe9CMwHai RmEDm63PAZTYpFAvphuhLJrmJvIEb0+dfpFwLxeNPP5wL0WtARGdCPQoL087li1l/Dg0mnR0NcIY +LWUWMQUckw583T/2fCC9S+EQVNylNcePhNgg6ELAAHPwRVJepkMIa5teku5QaOB4VxKHXzsTN9/ wE/bYwPPuV3yJqZMtVTeBJXXEzF68Gb7xmv2io/XZHy1xHjN/YbH7fLcO0MYJbc4Ne95cbjMYE+s VKFGCK6kWeI/zo615b3XsI9yJaVaNWjzx2sy/zZQJuu+aTkB1o7XVBDrDTz+aMlZ+RUGaUvnV5o+ Blnn8EkduYRcuV74/TiZu+dXkCIrIPMLr2nr8yt6H1ae7MzhrOXJGhSqvG2W84EylqrIryTA4Vu/ 8zy4mcqow2gz7kXyDPNsr5y+A8yrIIS4Jex/0w9Sv1flqNJR/4nw6zpfWvIJ8faMQQfFWwxhdWcI 3p+NLvWgaGQ5bFlO8xuuLhfiG1WZa/8ZkVr6Ucs0Qnx812euUX1P7wgf1x4saBAJjcfkNpiWTCAT IC3pv2R7GLioj2rPljxEns8r5KFyt88YoSq9lkJCfDrrM4WSkNNIRok+lQC2BAKBIJCJQrntmC2h FKE6F2eKYGhEGFNvwZmDpnkpPVy6lkYRjfoxjcL62rBZo6WQEN+dfmJ5VBwhv6UaqHbxbUi1ADX7 09V2xZZIQvR7n/pEJVZtncDtLGvdW/KALD8wC3GQL1gmdFaa4VBLMp2Wqovo+3Ixcq8x2Uqjd0Ze lN8R1sRsqXP4+fz7PqnTz9IHQAoGgeAb6V2pISGRCyQ6dNVbTWsN00MOzt/9jtn5/MYZTjzXcRe+ eGdf2gGk4+8AN0M1q3rDzZby2UVHudoXlncpqZgW/9SuZwPp0uAlZyXPeGbMSvLssbUnHdxze5L5 /WCnCtJn5RqUzKtqE2jrtCiZ6bg83bIptMNbU2hF3s4tSsVGL7fyuZHZtXcysOwpVCx32CemalvL gdsIS8YT42fWjRhIMXYXCMilIIYaqOKqSMVpnJ/hOFx61qyUb1Kgg2SfQa8ffwcJYQQUIQfDiKbI 8fgQpopwXHM91UiMZJmdPJwobXY2vbZ2A/VJD6hmC5XRxL+31OlugCbl6nofGlTsrj51W1dohal4 d4Pzxa0Gp7kWcfl2ZXCGMC88zUuTdZFoaFBRRgOXrPNQufok6ouNe86WQW3q/3OA82Zf0UQhxHGv MFFoJAY3Ee5j56IvHBlcu96Xpp98FWTUaFClbWn7RR4dGhF338nA8nHMKJQhNMC1+KItPpI8IbfI cZXyMsLbVhM/UI88J7m4ZuHirEPVQSHIE3XMj2x/uPCJOYBoWsTCZ1SklIV/9hWTyX3UYTFWXIns hHgSpjaewrP1ltk4VWDByFNIe2QUNPniCTbkP60TefXg1ctD7fShUkojr8KRSj9rG+EminAat/Cl OI25mLliaPkBSkmG1txfAPGDmK9OJjjc39eL8+/ABADgpGoqSj0jwZq4jANJhWgjeSWn7pzUcii1 W44RObIJUyOQz3O94x3Af3Q+dN7t2jIYd+bXcr8z783m+K6TxD+vAcL69pemj7AVIFH+pJx9axYg BnaY9q7mTudqPvM7Y292/WXJEnXyg/mtmHdSFU9oz6nSSIXtsGL+GZ6/vqV6Qq5GbIpqe9hSn02j gYHOpUzMpf9X5BXrH6WhT1zzNWFrYtzy1L2kqguAczESTtIBBbToiPMfVotFjzKVIidVihliCNci b6iMFwAuP3FcHL8tATO+GE4IfPy7uaE0sZULHld21ex63pNcKKq7v9l9+TprIMfbieVZQ2RF0QFk D33CLHdDToqZOwpiiUlU2CVoBM6cp71HiJCo+xpM3eGX+jwH3oJ20e7gN7DbMPLceQf+QwfSFTDN C1nYMsZaXmWlK6lFl4SznoMmP9xPFMqNwkK5JT2foJ7uaUTnWkn4aq8qEirXK5hAB4V+14oVto3u uEbeKi2PTQ+78K0Zxp1NLZ+lQsKkECF2PQcKngm5e7n7TFDwG7MNEo2EuxolGmiHNnDJd49uMwwo JtfAxnTCWRVsSXIwMSvwCY2x1H1U9t/0Y6+ChhoNqhQCS1IXeUVlJqfmfpB6c1yMMGE/BGaDDWBa OWrv+3zjZXMNFFHtkjeBVtJSuaVyPE27D+QaYojoK4/YAXaO59ujz8c7e3u9N4dvUEMd/QjwNBbm 1CR+w39Bf46ntELOHGaPqLyeytdLm7YPi3S/OBYpj11NYJGG8FoNKqIqbl4a+iVy6x/NrJkoUzTE mLOxSAEtSMLjlhrHvPca9lGuZvGRYZG+pFLDBiprnYvLCbAWi7TxKjmrrp3DzHpd+yNDIu3dcyul +f2QJHdtpSyFQ2pe0Za3UeqFTnlSc2Km4fJUDapU3oZC+urWivYib+eKdhUDjGdXAiphjKa7zDrD ZLeSFq5qoMIrsOR3ckou0+mLw17vLMeZCt2sfuLDNfpXIznFC+3R8Q5PaLIWmF6E+q4/D2mFIwTu jnd6e939Trfb6R5cdF8d9V4c7e39p2IYs1lH9FAOYQWwqDx4CilFT43sjWPNVNaCCT/RfJ3ilbWM h52qd0xyI+U5LceAE1Vr7eOLw4P0VShbv6Y95/po6M4oI/vZci4lVzOEx97dU2e5ZIQuu/qFOYGY 0wuZVudx/o3iAjOngMvk9EJ+DU6eqfxq9E9av2KeuzzcIBJXvaS7vARL/uAAI5O2cbv3tPvcGw8P X71AhviPrtj5447GepQNNsNvqaxqEi7wCTC7nlJJeUryfqtaS/w/7igPLblG9ilqo22m53YbeXUf wQobHYuwzef3b4mYxC4bYZ2UNq2E9X98lrF8taGy/l9I8A2pEfNBLTUBTgeLIlXT5daGjUsYw9UU XJHBpTIbYaD7lz2vDyHilewJxYT4hJLBS9avgLrK0rWqQv4ituy2Sr6AYBkX9I56z6CaapEvGauP xItuGiAnHF3S0DCIBBynAkLrNaHZU4KbI1YgzHvUTPl4kuUPbft457df/vLbL38Xv/3yt19/+sev P/3z159//vWnv5KNKdFdcurbVt5nJqfoecr7wNA3/lYF0EK3NzKC5Fh6EuMZta2CIEonJnZnlmvX R+zv8GRkn/o80fIXFtmixEsMPFuOUfk0m1neDdmTbf31I66zXBZDeknhicJbXwYCcNdkoKm5sCN3 uCBD3P9X6hClexnDPZKqJN57lOkKk2FcY/21mlaskdiQeYPUWw2B5N59gy2BmpfkZGTqAY4PnM57 5svpFeqy1Zxg/FKObQcVVFeSjBBtqS038F3wXHd85pESCm7miEaUxhiC7J9PgbGoEblufpii4pGk f1Is8CxtMEqkHEYuGMJxSUYMp4uRbOWCKsY3F6977EV4H0b7jJKTiuT8h7wRQFUYqVu2wCxuCF94 idwM88EZAaM5IEDX2MoVH6kPtL66ary71+2+1hgPt7tsYIeQJSA/ZujFlIKE1AKWu8A+ubPc9VA+ jvafhNyBGgomKRiEVrpUK10iKa8dct3ShatwMeWcg7YA1yU9squtoIHH3MAlR47D7bHOe7CC3Npb S2cYLRU1eYiFY48QqWeHCFIodnuWpckitpabzqpVnHudDYgovJ7oXTeVSaSTVs5svtSxCn7T7pyB HUp1u25YzkCIEPJ+R4YzbmD9ZMgabbdbqlnqlDDZotzAVpV52SzXWgHUCiC63mFoNzjZkAACJjSg kKwBqlrg2C98AhJihCEaEIL5mk/8xeDp1LppJ9yd8AyQ+vAV+BgIOhNIB5qgr1v+wKG+xhgeAlbo 9wDylj54xSDhysT1RDra8lo9FBoyyJdUFNwLW8zTg+7qZoQY749KkWJdKFr9xIm0Vj+l9dNFKuNT N39STRCxJiFYeC68cYQLJRqyE/669APoMtufkB6zINTarBSjkNZpNSf7pTXNUDc/QDABzAXgoZx3 gssU5aEiRkHFpxVyyRN7V+5yXdK2JyjrZAU9XLZRZoDpgnJC33eHNjXoi4EWuOPfDt2OR8Oa28xk zaasRvvNc4HOhezOUE0ppSNJLVDCyb5ceGr8oTvWFthas5Vbs7CLgeJGJUUapevWDhFYl4KoshxA 1S+lw8zCSHLpcNIx/mAbg2ltXGLRZAzmsxy6iIPo4z3rZl0GPbT/tEAlBSfCya4h15zAaFRwZuIu ptBxKAYYofqK5zQHrna9WkFWuSDzbdTc2OPN8gK9kyuZlboiFgDGt1JercBqBVZaYP1ey1hrIqFu sdX9ly6LqO4RFw+HSp+9MpZaSUeR3XZtda3AqlxgDTZbHhiGLVt0NFy0jQMHhcwT2i5lqn1rrF2u P5mFGh2206g60hIe+XkcGAydj3QhD8mjVvpwGEAjg0FFlCqhiDMIRd7QZtP55pISpLq7SBlmYY50 ecCNDjryyEZpmgEaykNsrDYqJjqj9L6vQvAUMUiUoXliBWEq7KvqlBqkWQdFMlubjUSJupjTzXBv 3QW6wzzxrbymDriwuy35UzStXR8N1P+/9fmrhmy1x/+plpUFHnFlAVuCQFfVj3J12cl+SrqoprcQ rUHTwoVOtVgbY3QtE/2F4Q284+vVHE1vOLHJel54ugEXSYUGtVQ1cMlVWFJIjQqyRygFaSWOk4ps kJJMwxv0Q2AZlMBHuax2RjsV3BTpmmGYxFTXzKl4j+ntksaRxgArZBperHR81wqA8rrHndbJlGPZ Phnus0JfXZKZKC6YUSbK3IVEuSYZt/QiajSo0rqlBjwMEtlwrRbJjrE7nbrXXOAwiiYfCamChCrZ EWc0jrTtN5AFGrjkKtSHdmxVci0c8XsMEGbJKhrDqm23gUfewCW3XHpk6l7L4tL+Dy2TtjFNklPJ 5DDNoXPRnazJL4O4ri7ARWOtafZMogeRhnNzcvgHvTiyZdrNM20DlUG75HaARuYADYMsM6QD9CDq 9o12OCg+2qHLoK2J2Q6HKtbZoMhecQvSEFPNDcjnBX3XjrzPASnSOWxnOxRIDhvOSt4Gug2GVth0 zcb8KifC2uEOetayQVKsgaZPccFr8nDrrfQ4X3hX9pU1oI7Rmmolga7tKERoAeCoEOpVoUmb0aY1 L21Lz73O5p805J/BeKzMEU7ihscRb872GCI47CK38cZ7mWtXhdCipOoy+QFggrCiwr+1Kd+fo8Hd 4LXkWZrBiYI1RJ5Hkx4ZrM2vqIy3Kc8DSF9r7i+my8Jv5PuuLY+amLTVbKks02iQcSKlsTVTLWGG R1d21lnSCrVzhAckrm1gHaKiUQ1EoObnUO8pZQc20ajQckK1OIjaFdQoXTdTuBxaVqCfwPEHFKIC 3o4YI3BZm409dxal+8XbM22JLTNUywwjeWUPN5zvJ7QVLhiKzF1UCKGk+QrNzQRwAGyO4Rdgcsel tozeglU+ms6gqNKOlXcEcI9QzvVRqgB2N5xT1yDfU7eJ9NDDZP+e5+6Z3w+5EgaS1g7ExSWwOC02 2uIncMmzKp40VqDWQpPHUQS7q9eZleSs5cmWDgOGceycMtgijBUP3yOL52zFDn7/aOzgLdXRfaW2 NPNK2TPxycZlm8QCGSZya+rUGMWjIIlIYazXbfEmO9lh8lhBggPOsjhA0Cobb+joojo3GGFoNFGI 2J0LM5GA74fBkigb8dzRYqiQ9YtUVvN041Rl9dlX4Gb4KHvhAQSfpY/2DyD34xvgBqpQBarZAxcd HqJD9dbsx56FuLZktT75fP59H8t9ygfcj8pZPi2mgc0XXWArH60BBqydw/8dTrDgPmE/iyd04k/r rNg+ePXyMC1ZylZss0BrPXTGH9NoapAkpeJznkR8LIXoZHh+ZQEbghXrKPC52/ZVPvA4kBPrysbl KvSKyvZ2DRTQ8cID23piOLU8e2wXlxc8dDclL3iQJ9/toQWgPs2Yq3VIyeH+vj6QGrZW2avcahkk jiJUPfQ0udcqMjVwg4lYzDEsVlqzDvCV7EsH7EKliCP3mobIJn+ucfKWWr4aDQyCqpQgnJLC1Os9 DY+vTFZQ+xENJKIg9eM10LaUUYu6aBmumUC1vJhYOjNuKRlru+8DmcLhrvu2j2x/uPBpLleYlKIc Zf+Hs33xA7osybD/Buiac23DW3roZt8KI2Sd4cT1jncwWLHzofNu17MuLy2kdTvza7nfmfdmc3yH OSCU++V+eszcc70bjJne4cCoMToa9efnupAnt70yfXxlLaZnYoA5of5iOImnQmKkLLIXUBrpdzS7 ZDCX3kaXXaOB4eqWsgNC473I8yszBPxgMbppvI0cCavMlBOPZtRTTlzxiqNDLsrz7RFPlO69OXxz gNxG+KN3cmwhrHG8s7cX/oZTkgqdYvOtKXqsKZVwqgNhJLfEu/D7cTB3TTih3J5uxHrppjoo8ijS TQcp6ZKT7THTcHmqpZNNL1TTxB1fz8kmc9koe7OJWkNt75HMaJAQyFzy6YvDXu/sfuQWLmWU2Gco DzUA9Hjnz0NaD4JtmJPc2+vud7rdTvfgovvqaP/gaG/vP29DB6KNhjhACaOpEnWdWDLHyAsvmRcS aQdSCyHhEwuM8ZVQ+AXNIRE1O/Vt67bd0uT1C1jkydnMiQxKX3x3+gnoIVIgJDk0RvWAakHj3D9j Dq/USi5eh1ettrVjrPDhqxd76dsFShNtkuuC2RLxS7iq5XH09ohnChzHK+aglePoHuwfvHilLO0s DCnrZUiH95hBQmxr+UPbPt757Ze//PbL38Vvv/zt15/+8etP//z1559//emvtJbo/PI+E2JmmR8y 9I1/rrpuQv0YkUmOkfChgcpQeSO4DkwnErhcZhHSNEE1tlgKUE3duxWqVcrEP64YkrzeTLHVJHMr V/Dw1Y0Ao9RNXWKAaddYg4gqgo90wFciFZU3qztVWJrQdxlISp03FsUBkNxz/LnrBcB+CwhqqdZ4 /ov9l3qRCziivHeablZ43OxldEMZl5n4bSQpdk/oAXBlQnhxgAlBX+A3Q88eqCyQJp51sZxUF71e KCYTei2P/w0WYK77kPc8SIzAu5BfTQ1QZmzGXZggtMn4CSwxlYV5t82Us/zzdhmcnKu5GmJ/92Xq ZJI2cd4zDJSXer9npFfILFiq3/iUoWZiDzhDF2gojM3UoGqr4Iu1OMHEfgwCaAXakW2pANJoUGUc DPakbkgYHh4GwRpI/gYuObo/yrTOk0umqyPEqZrqRzXvXFrkw19hrE2Uw7M6WxbD0+TKZ4nJT1B0 Gr9tKQU1GhiuRanYs+pG0PN+hueH1+7uDHEpHTJXYJ4MMOFJfDrDGDjYyMwVTxgiiepOUGtGnTKU svJcFw0TaJ+Z6rhNBZjhnQQwceyzR1pvNcgb/qaf+DDZDmE0ouq4L9qDQj+vx8jgt/txvdf3HD9B C0tFo3JxokXYuTJ2m0rrSvrPwEmLlbbThEPN8C6FD8LkUEcc1ke+cG/vxcFe9+Bgp6AVGpyQWa+y +FTLq26E4nuhdsGRTRwFmprInRvozfq4D+x451j5YbF/ggE5TVJq3/rdKrhJvJms/BPJ7XG0YSWC iCWi39H3sNrUT+i5BmM26lyIiJ66vGGERU9aNNSY5a0qsjCdIvFRMPwaio8k197l9AzOaSbLRm2v uHxDy8k5ZuyuRFo5PPsNCW6z/UOrVzYSuDg6nYKR5s2cjhAYTGYN2Ycx3rSiTqjJ2KPzjbGzDYZE KUMlrfsNz65Ma5Dd8ekMYpiG07CR+unsGyB6fxhDBnNkXsktktMQ0am5TeV4ma5nTRZHEca969nX 2N0Sq7wi/FUZD8A8dZ0p2ahhBmZIangMazWIkjbEIKiPmak2inagI00AKHJGpWSA7YwwNzPYrPkY 2l8om0Z9fWiFca8TSYhQBvDcKoz2pII7oH1gnJoQF+1wzzp5wRqNPBjBRXitMnmwbN4nKAfqzpLe TI5oerlw3BH1a7G/ihp6+UxcXHwUA8q6aGsspxmSVk4i4dkqC2TbNRhUsj5C1khj7tRtMcAQ4NG/ EBg+ATxQ4MIa2bB7qblCYwLdo9HSMGF+fGlE7hfMjx/0VvLjoYmfYJjQJTJbA7ETlm3iL0nLGzKa kQaHLdycF7Iz19+tru5ROGyJ/D175aFLgFZ6fHe7u51xmiZqRXUN6xef4DTtTDj0Ww4oj30KOQYQ gmGgorDNeZK0syqZtJSUqS9fHBy87e20Bria5LYqUyHNUhIsMyBYmapVgaGbqWuNyMOKBKvqOB/f sHSNjXLkuwPbYRM8tcikHEqK2f0w250Qs4UCsa+PzL56gofuKmbZmqCtrClgo21p93d1XY9BwKqt gkRKgnBkq0CO6iSdYVxGgPcLRYBfHx0erihaFs2vXvdeqcodzqyrCHD4Q1peIclotgz2s6Kdt72z ACMGJx8CumKoBkJPoOPiJl3iegHMAamZD2pIBVI0QG29QZQDJq4fWE5ANi/G2lNwhC1fRr2CW4wH cYepJQYoNUIrCdk+5DTzx3TiL7VA8ppChES6Mtxx4ogKBatxRC9yjyjBLI/iKiSCwxFN8bVEMPVe 9V8DlxxJnwKCJ9uehofMsUVKe6varYUDoDiMxlZ22b+SokPfmevBobScG4SdMGLUQdwBd5UiExxQ jwOuW0rClNLPtExKBZxcz75kwyIF31q3K0nyllq1XaczkoDLHim4QATvGcXl2kZBBWSxuwg67rgz wAcQcPpu0ZYn1Rlx2jDGLJ1q8rqHpZ1xSy9iTSm+j0trhcc15N6HkWpsixpYl1h+nJiaVNunGlY2 /r//u7/7iobm/oH6AzBOdWXESrxO1sMJZZzrV6YstwaKugYuOcccjdoqip6fWQEqZLmPrq8iZYha wdT8hC4MDNOm1pa4mD4uWi9URN+jSEuqiL6//rvqxK5CgfyBdonBIiVvx4+ojgJ0y2ilIqRpZmAV NpVGU4OyLmUQRMX2m807UCiZzUTUxWGeNPSC44rhhEq7yeFypETKicxB+mCI+aORoJGSp3Bo0ChZ NBpUyQawMMf2dLMRMdKoqQ3FoiKh8DmMlZJ6p2FRmciRsf1wnj2ZncxC99QwdKjt8Q7yUI816Ios EWOI1FgYDeZIzuNsiNjnrYKiuFgNFAgNXHIVquxUzOD8o6UrsCBxANKmHAD4gWRjs1agWHmkmDgI zpV25CCO3QWURSXZknsNDVVBSE2uVKkMzFJ5FTpoMvvSmc2nficAZhABB7kA4Rt71kxSMyYZrBU7 ZQQelP9SjS4VytvMKEyYH2rgXW6X3A7c1SpNiCFU3DeT0w3uhZ5v2L6Bu4cr0SD2T7MAnPY5SJUY uBtixzQIuKW43jI09W6unZoH7iK9RuqAcnzci82G4loJVsM+ynVSA5Ac3si1qkl4z/+pJvVF9EPH daT6UW7s0OAhaqrvzmcl9QbsiKUTvsYrWmoDFYlOmnIirB24q9RFA48/WnLE0azacAMJp2afAcR1 lL0wbd9YOa0z+MSMh3Z9RCVI31uO7U8iibQX3vGw8sIgD3PleuH342DC18QS2yDpjOgZxUasF15R eYqU0xAx8lYI6vQW6Ps26vS/ldfsTJ0CG+V4J/lTSODro4H6/7c+f9XUzB7/p3TKumrmRA9e5YnN HK5anqqBeW5XNFGdbSI3U/gIl69nlL23QM3yMBikDwWrBzwjsdCge97AJetMVMbKQSsK0gJxkIGz aYlEAYWO+ITVeAzkE+DPYFohYk1IMZuDG8scM9fNpULOPENiiTYVRZefhNmJp0LjqyVgVc3Ztn3N 5AM7xCF0viqJ+5JL6ZNVxLNtTLNdIFiFqRHDBWdpPQzblJgyER5xiq80kENMLLnGeGfRAs7X2i8X XuTNJitVpNqn2tCJe51MSaY4wkes2sesGvTPTjCKKn0zt/FCaTSoMkadvH1FXhLGaddQPieoQPvk YlwQI2WlQE3Dsv3ic4kOeF7slukUYc3n07Z+o84aPvmnBYAEdBob7tn6V8Dge6Euo99TdfScrtPB rnxqFYZ99kXeqGxe1NWiXdMtNVw1GhjOyRBoz7ffQpu3yPMr4wNlXyclMYF1HmlraOA5N3DJa6g1 w52uEeTAFRG2BFnVGncYbkBlHPpCPMmSUE+faato4IE3cMktj36dTRFftYaYJTAH1ANm1UoMJt0/ EE/QDcoq1V8MOqgVlp7fsuhR1RiFZgVKt0llvh9wieY9itGD1+IJdTTCA0YjF0HE3wjfnS5U8w4V WCbtwZZ1W9ZVeXZ1p4KTe2TdQ7Bu91+6FAIOVA9iy54tez4Y9nzRA3seof21Zc8WKvDKArTzKlIJ pCc6ZDSPpW6/KeHTixeHikX9CZz7kZhJlAZEVsDTXW1ZDfRKGrjkKhwpamVFr97+j2oyqkpZpNIZ CN56rgXEiwirxl/MedJOmA9r+tFXQUeNBoZbWSqeF8dUi7yhsngJozYgfksAKiMEa2hGmy++4dw3 UpyUZNeT63FzlbbMLb1UF33x8bzvi4vOx3cIj5vohcnklFrqfzzv4C8QvXeRYyZ8mpaGNUYhpQ3u 1cc+G+7r+rfp5JmAD0wwQc8UB1BHKw2gR6YETUuctfbR4AT16QdIEg8pZUN/cmVbwmqPvcZjv7e8 CK74KTqZ4XUWLjtiLKgtSxG32aJmhjkpw9v/gVv3ofN0qwCjSVCBOqVwy5Wc3jwTjCatqmMU0GFr QYbB//olX4eztJqOqUzvGXKJCe+RLB2IwWsoX5XgwL5tzHp5JhhfT2FATO10XnBLDcgip1TKm6Bc E5G9yAvWN38MbECDO9n0ocpbBQEHq4dMHrKSgf6Geskkqygx0c6dOKmzXiiqUdxsPAlzJ8h3XNEU kA4/TCRGvrIIAMq4YlMqI9FYtZUHVMiNy1TRxLLoWmpENrygMnlANx9OEc0ty7EdaKaScOc8T68F ekB9QK0mwmyQDTOdyWrrcwIcY3KFfXeGfo2FE6I9hsC7sShinRAyRZa/1t7+im8/KiF0+Vr31b+e AOpF8MQZhfoYCSCKkFCgxKggNAm1pYzAXSnUxmR5iB0tppYHO4oiC4xwfcP9T2xJR2mZR5OVyWrQ VYjkqQbd3a5qcGxQ656efkh1M2KqBndyrtYslW9IXadF1/x+3ME7t+jitIrAMmyAJo+jSXe3q4nJ kpy1PNmybbq4msy1ySq6woe4fD236fZdTKPqBG7n02Ia2HP6F/sPb9v2XbYGQqSe8+AGmjVEFNkE oJHOXKvyKXGMhriAag+J8l+r+UQ+azp5npwdnzzPTImTkamCCLy1ba+r0EG0Nxsq4qly1GD5+fz7 fufijE0aIx8gszqSY5vSaS0SIDmIRXraea5yKrl09jWQwJNwHc5UfpY+wCaGUuAbBGIYeFH0UZjm IpovOgLN7+OxPRRnDkYISOnRWJUn4YFhtj1VAWfIbBzmR2uACcLnCAIPJzizPo+GeEJBwKd1dscf vHp5qOlFCInS3fEIYy8hK6fAmafdozOUOoJVfUTkzq70i6fX0AqqCgXV/WY3CKw6dmULgkswCFzq InKBTQsuoYY78LCpd3JswfA73tnb6705fIPf3KvVs6X2RR/IQ0WUC2NmbRlPqzg2GyI8cxIAEQq+ +FkRkh3yENQUyVp9HAcXch2Lkx9VXJkVb6tea8wQRBFFjciVRYuRHiggXQ55wmzqqkSOQuLKQP+e hxXKuIlIVpAPiS/iG+kgnTS1/wzjk6MJnaVZm7RN2aBlnnoKG1j1udVsoPY0wt7BQOU8SxFiZg2R UQbsubxk2KMNbb0y5KpnQGyicLiQX+dTe2gHiI7z4VGi0dZLPrdUj2tcZri+pQpLeGJ8OMWtyEtK pBBRIxDFisJqEaSQyN2cWVMVB2D1S9o3U1q1R15t9hBtlBPH/tNiw9VEqsv4kyqxB0+cL2gWawYf RLMEo5iSxpYtM1TLDPKrCoVoRDYImPXvviGAjN4lNViNCglI8IdyAToQ/5bX5JKroNUMvEpgtjNk mBdBi/qx+VrjBl64Bi7ZcOMMKl1PyW3fyIYXxUc2qIhUYmRDOF2rsXUGeX61Ie2bWzeQ97y1Mbx5 ZAMSFaRN4j9WvfqktpJp5bz3GvZRLtevYWk3f2QDGBop+kaKuOTxlxNh7ciGxo9seJSCNzAYujUG 9mjODMIjU+nXlOlHbM+fuIvpiDpgI0htSWPdKaWsoHiiiLlqmkUuzZr6ruZKNF5Q5empezj2cNii 3Gz7R6HJ7oc86DU92f1g9+Uu/6LiMYIhAEbvRxFPeedXpbmvZMHA467A5RhyugK311bgxtkrgwWa a0nrJs2k5gpcHGEBK7vwmspXJZezyh/amJxdPZGj+yqFqQhtlz9lSd42ke0gvIVmW7kQYxkrcNHy 3Rbg3m8pis5b5eyLC3TgRUmVYgW41KSztOc4tp5WlW1dW4V1ba6jkdcQ4KsspE7ddwRaFDNDFEFn 7C/KvcTVuKogm/ihSLo5a5RS35eLkXttoz/8XAaLOeeuP1mUS3Rg/0nxe59S8bwmLh19hySDZyOC T0PC44rUJ1hwvQWkBwcvtVOAfC5pD/7Y+NxDFWJHI6aBpQ0x61w5d0L4EkUeXtl9WcxHVgBoNJSi h8mnkaqA7iFDSVNPgPHE6Mjwd5eFw9oSW9e22lRkNGaE6a5R2sBplTEDKg9IVsWyE7yKdmeqhydu IEmJ0Ab9e7zw8EEPIGCL0c3jdhHZZ9ddxKZPu06Z8Y96imqxudkboMijcA9fpMRRjndm5qoKnMP9 W9szi7yencPzBaBarqyBPbUDffpUA/VaA5dchTl2AaVFwxwIiMlPnifwd4YTm4L0C9jopLkiZxGK rG29W85uKdR6d7j26D9x0X+KArfEDdvYPFk9joWLUc7hyU5ohWX7KWlIk0UAAPfZci4lW//hJPaD g1Bc4d/cE8TNQPvdN3v7HIEpHGQ1/H1cYZC9WLEcMf7HqdjxVcqqEyYkaA/xAzihroS64V2GtZbT bvm+ULhQsZrOABkNywujjro+t0J1kfc6w75SccrkCcPqxiLs0fHObeebvaiwACcdAP7tl7/89svf xW+//O3Xn/7x60///PXnn3/96a80Ml1afnDq29bxjvkzEzVW3fyBoW/8c1VOES422qkcS09SKCO5 VbCMYhIuZlEN/HnENeUHkU5bQsFAHvtDBEdCCPeE76ldsy1VcRoNDH5gqYiDOy7y6MpczCk6ri0E 4ZapcwAnLRxbwSoiLIZaePY2CbQ9IND2BcfQaPRNenhEywrVBh66R8nxQprtpPv4Bv6rjEnEe1hq OHHVmRiPbwiDDxSiAIBgizJfJ6LehsUCnSlf+8CTktHmPXt0ie/wc0TuPYExEozZQED0gF/jXwA1 7AvF11u5UC+64v9n71qb2ka27V9R+csldbFj8zTUjWsgIQmZkFCBZCr31vkg2wLrYks+kgzD/Pqz drde3ZZkSZZIZHc+zDgE69G9ez/XXjtS1i9qKgILgMzzBU1vgR14eD019LswiLPssQGuVSLo5jMq fCkRHlNZiWqtxJ1jz4QFrtsaAOCnMVl41vTRyHbGrKZmczLOOUY5GZ7hzBiLDvxHfDZ1iAwzIac9 Va6q00pAPb+oKHBen9dk/UUlABqfMeP+8af9cJpm1tTFohdUNqoYT+JHndcUwJ8dHe7tXbAAft5k DrM8G1gqsmC8J3muXpnfiMLV2O+htVgPnV/Qkh4iiG2X8jSHPE8zBsmTH+6ySSb6wpvYzpvWPyMK w6le+qa11+3tt3u9du/gttc/3d8/7Xb/l8lCkJl4Z2AGniAlfmSdFSjjzrfG3ynh8tAhTCkiInod /zeDhA3/CSn6+MvFUhT+q/GwnYurlCRpZj6CvRfenr0Y8ljBxjGWsFIb9y1528I8zQTwDkw39JMx XGKy9tQbwGd5XGoyDuQk5XaZV0zJ8wlijjXBcrAEDftPjizNwD8uANSTa01GlKiL5MsqeFSF8Ch0 /WI2HcdYCAtdt1c1QVgNzjyN3DkWTTFnOjCfAWyJ6XCKxyoMuuNG9HegxAqSmTlOSMrBq7W9Zfyy LpYkhHFzItQ0+ku2knFnrVK5J6d7B2m2MiYM+W3lwI/+ixpE//k3ziCy9woMIhbFN4icpuvFdyfl wJCQpW5YZMU5YVKxh44ZuzVMti2y7ayvIoRjVcY2h3qaexNxncynL2LYyMKjRrQhTaqgAagw4JeW fGNlvSu03nXO4kw5OiPd5WlRFgTDLFtCBizK1VHK1HLZnGMSBkI/KFmo0VIn5R7rduLYFqNCi5N+ ZQPh4tpzai8kfxIUcRIUZg7ZQB4VAaQLyiElCzXKgl5TL3KKTmBFdBROWfEkpgHIEPROUWSPqq00 y45wUJuJ4N2ypvpbVMcuL27faxPA9y2beAOR/eZwDT6oksG2ZUXgas+Gx4hHlRKoUQnANjsGztrL xm8mJt4zLu+57cIG0Dh2Frz7EH5JFohjTglBjUJgWkhI05R0YZXr9gscTCumKRSUtaFZlYInQHk9 v3+D0nwkLlQ+gbBIvXoIU1S0UGG04ME3e1ExcBfD/0dtfDeGsoNcmKiFBc1ejCfXmBnOPcHubPIU HpEDFJ5SiQHlFLAyFc0sFQ6jsNIpd6msPkaOX9TKRSWysIpKPV+oPIk4rwbufPDIQ9t+mOnOQzxn eZhA99F0GjyxiDdJb3spT2xRhOwj/f7YGD+pG6LNU6KZCK7eamlxxHo+Qr0XWJFyaPcwHam7I9N8 03qLIUUmoG1fjCeqK/vQ7fhP2Qy6If/vW5f9X2Dx67I/PBG/wCUeddSciRArT1VS7AgXM5y51zDa 1XwA+uBYRpVpHEr2YumJ+Ayhjm7Perm+8MKldqVb+j2smtX42mWgzrYssD1DMhv9XI8mOJCR0fYL 0tos3FfqUXbhqDi8OV1o7aK520PlwtSJ+7qzF9Lcwrpdl2XmtbTKJOjXuELx68wMYLH3q7ut9js9 MIiQtxeavwC7A9Vb7FHLmZ9MRMnAJ4/T6DklnzTt6XxzLtqKunutVu1u8kM1EtvEX5VMXCEUT4pX BTXaeu/oM5q1/RDqS8ydpHGIfp3It59uS5CALbVBeUiBGDxQGuhzFrW4rljmOkfyHJ7sibOUsYvl OmAH/0LCiDLNfm5g7DfqzRmJEWvTQ+7A+PeCslyUQ6AIUwlQjTnFsLArrHLdFpiKyO7G5Ae2zKGm 85vgRQv0CFQt9DmgKHTiTD8BXwLqhoK0balRENYg5cSVAsv7pE8vz2ecx8wxMLVk5pZjbYya+/cC XHiS8PDxRctORr3W77Bi6/cMq+eYjyieB3jZexrGhynSAl2XmN9Xh6TazHnAEDDOcwwry5rDRb68 /d6+1T50jo973dc/O73jbi+DNPLpNCD/Rv23zb9FGT7pBL0FXQhqdHRo5qwOE0tv3C2sEfOv4gq5 thPDH1FY1DXcReb1hj6Kxsas2VP7Hs38jXcfgmBsHaw4bDE6GTEgAMEX2hmB0ANai5Vqv55dJVtg 5IhZS4ZSL8hq5bFYSbPJvwIc46cLydWJksTaDhaeJqXK5gvNL2b7OmCQjU9YRbF8h1yjV+HO1HY4 MSTuYP9YzNavczrZu+PR27fX4cPnWtOk2dhLaxYt8q52NkZXLjHeslXnk47j7Lh82aFeaSUT0hB1 Lulh/6hbmcKjJQX2iv7HQBdA3sjXVkCKCivocaMoLHSKR16ZK4DsRjiQV5vZ47B1iyA0I4yg0Z1n Zv5Y35TqPa+zBoEK0J15v+DKpR4pwOgf2AygJuCZjQyuwMBKhrKtBxgN8BMxjL0fXSsPJ5+FPuom eMRbE1NyLUJjoqZxBA50CHP6vee54e6SezhdMLYLSqk2XrIaGA2rR/54e/WZ11NppuW5Y+gP5wzU zGqsY/PxklgQGfCk1+/2D467/b2uX4BdFSTR6vLfKQKuE+uN2zf09Tj/0FdO2Bob+uo3vW5k8jsF gJSJXsuqiYd1+pSC6hJMjQ19ReBJvkj45QH9rVABN+U9yhX9BbhY84e+QqChdxqolQMZ4OqunApT Q1/V0FduaV/GKMcRmVmKMoWuiOIA5K6OjvZP/hVgBzhL39XleZtXhYT6I6HT/XIjda43Hrspnvly K5gnri1Vb3QMAleK+eTasycoQtNsLAftSTwROzHnLrCa3pOBNnZkUxjZtIdWxqgxISivCSvReAtQ ThpwcCjrtMCwY97Yx6Gu2tQAWBbuOR/dFJTs/YxEDDWrej4fjXqpUn3+JJS6BHmt+2QBnYEO4Cdq ONX0MefAQz94XF7wK0FtiWZX/zUxpypJXWd+Er2XLyoDwWhyzCiHegCvWIiRD5iVA5gnQ3IhveTx X/VxfcLDbqmCFdYg5dCWMrci+WjKlSsrUzB4PrOwrBiBfgg0TkyfXXT6AgYcVxaRhhDKGcI6KFmo FsWCMqGwvnVLQ2AQ4Ag8w9kKmr1Ry7pbEGTXXcwZSxDrDI1wG5uB96zCCQdgA8aTODYYamNIzirv nOcd9qx8TT8g1sR7x8YgWDiwOle7yn8FfX/dbhfU2G4GhkEEZF2233VMw7trz+ZTtz3fm83bntGe mUOqSBF9ku08v2n1WnLXhZi1ydPo4g1S7yVoAGjY0th84ULZqqSBijx45KBvVGjnZt0X4mjOpie4 RRnL6HzdgHbufKnyF1iRcqn136yduy8pgnj2Lvca4rj5DXQpVQjDGvsZeHb94FjCc4XupFloh/5w 3DVvz0dzBlCLt0Kzr/CigYJoUEmrgY9chRf1gfDySEqEAJqMFm5KVjCgFVJawNnkQHwe9RLwJBvY itd04a9Cks6iDFeWMM1tJJvbnt2eEY6X/Y3IsODFq16mQZ2Zr6BRVJDVbNd0fbHIqSYYBZDUiHHx twcmfMweZBRY3ww+ZUbDB0QuPI0SgsDbhFNmk8gurHvMHEILEIK+nW83P67btxevWL7lOhC8q0jw bi80CT9+Tf2U2g5J5Ks6kc4H/eNDYSdgf0pHGxo6gZFFCnONOGEOChKAvhL/pAW6juBEyrdUAOgK AdCi6RSWuu5zNjSeMWUH5SeA3OM2mv8gEIzmd/oEXlrg4gqRJ2uIFCPPEx8lBz84mvF8fnh+wBwT 9qN3BoOF03yZ2KiDAAJ34z1Pacwuw9K9fIU/d4ywAZEnOlnozKwAab3AimxE5Hki6Z81Q7/SkWdA 8sLydklAq4x0CqTBD3xZ5Hl59uVMU1Enz4H+JgqqHGSC5+4pnoR/Qn1DhuszG7A91hng3qUgk9hZ Q8dmY8D2ieaLdUeK5qvng7YblEcRY4YX0NaZUOLc949UTWh/8iKM4VtTf0gbm6UMmABtXosJsyd2 gpaUq2hfS1uwlTOp8luwbwbD0iEwE6wzHrJpgVjwyImajPUky5qs09ssX3zff59lC/gyvnj6/SOZ X0OXYbtKaLP0hyq/KBvhjve6HZH7JlOfpS9jtLel9ZkfE2cEBHluz6l9qQnXIwKezdNsjfW5lhVS JDQZXQGCRXo6TVLsvD2YK3Yi0SESjP5xAlV05iMM/K+l3DCqWuJ2SyTUmVdO9tj+pSHJa93vap86 u0yleVH711KLI4BB02kpMOE342ECFL30Vsk3KI4pRNP7Tzw+kVm862jX+lwfmzPTc0x7sau1/ES3 cO/AQm+ZHKOEEvyJVRAQSd74gDpgLbH8VIEiSfPrn+Y/qGmywkBbLWKwfuz/YY0lXihh1ZUPhLAj gh5WE35uLR2usJ6hOQyF4FyOj/ZrgHNBn2ikh+SdC+8vY8YylQhO2pUuDgZSR2mv2z3emOzLlmlE GaeRaNlZPUS27AFneyx3m310uGXfFw5i5ErELLsfO8V90Mwrp1r2cxqS5Oxqn2u17efOswscsfRe Vdn25Jfb1S7xTpKlf+f7AGedGj2Z9zr1Atb0sgPFvyTYV63F7Kh2Y9wzusli5hTTCypHR/vmVDzF MIHrmFNNGRBSovNfXE4uoWMhrLkMSGyKVxQaMmIIMdOR+Qh+aCgiYxINSNGgM1nHIjTMpeZKBYRn 9/e686TXp0i1b+kG4qaj/dTdxYP+pCuFKyncWFyIdqucyDJBTlRAUA5npxZREMWbJ9PD6PcxvLwI dZgvjj6sz/CL2lcZfgQpW3recxl+ltERIsfD/f2i5pkMP31NUBCJhr9oTJpq+C9GD4aDKby3MKLf AJu0drULfJSeIDnG+x39geQXxbvhpSht/LPOkLH25HeLko3C3mzpmYwZEJavHumuh4T2SJ+7C5+/ J58FYX2aFTfWUui4dIzXsSBni/sF3g/RY1+lHzc4emR5DNGIHB0eFCz/MSOCrwlqItGIFL1ysm4t ET0umZN7DP8rZU2+oOr+sgnJ9ifDQhIUFMjntdrJc2dhIXJeScfBSrXFK6nJe7mLsipezPA8vN9V re93M3cMeP01Voq/dMSYP7v7RBlSSWFUd0hfmlQGWZ/vhmUTIiA+NoXohZbmeVw79h3YxlqiqChh kIQhzHrHitis0agO10k2Xuu4TjfG3DNmQ4yyh/d0orynDfaeWDJI9J4waLaM9yTPp030nopm9ZMt bgnvKXe5eHBuj0amdJKX1HrFDgR5DSgU6xaSCjf4/N6xXXwkvyLXk5RyAz8bj46+yHX94q7SgNfV KXvwufEKpEAZKllgY5E3PgbAg1Z+Oot8cTlrA6reuAgiItoVZfOFxYlVumM2n/U0VLwtFY4DB7p1 AdbAvS6A5sLbNHBz1SO/RKN5A1c5JY5NMZxi79/2jaTp5x9JcxQj7WMDU5rOm5CFMklpnMnsI826 XuEmK3+FmVcYfnlAWps7uDnhlinvUa5dSujbbP5IGgi0GknTfgdSJI/cVsaFC4oky+Wcwjz1w6lw 3yMDbTDiXPrNryPP5jmD3hIAsKk9qg3CezfSKOcOy1PjqlxAgxi9j48wPNo/LlrJoRoRfU3wkROz HAnEJVlWwBsgoRGG/KzijmxskA9oXeuAG3jaZ9sF0x01cWHYimoyIY0T/bnCuIyFYzAYdDB2KByG nSt4PmbzSyuO0qiovSQyOKhhZrhoe1E8M9vrqXBtgzOzMU6XSGcVzZ/6OkvE5SXqrASqijV01hlw iUprnbpzfWS8aaFqG3HmR0pLi2stv6bG+CbJ52qf6y7gnZHn5c9SdlXVjbhOY38kexzq1igDd8xa 1OrR7eLRUrqddoMRjAX+aGLPYDLNiw/9bJDTHcTdiex06VwY5RlNMlMNYtpqkn5/7I3PjhcmEVIc 7KWhuBFlVQd9O7Tb4SWS8xC5H6r8opTLW/xmfP/IvssY5nh0lHsZo71NyfIYqyj/jyqkebm04I4r ohdGG8va+Pz56BvbzcfjqAhR8KFzfBxwEcblOdu55N+SLHtgSaJmcNysGM0LRdra5e339i0jn5gh YBxzQnB+x9c/O73jbk/b6R6/pr7TV8BDvbVnM9sSniWwbY21VJmrn2IKYi7X6t7H0uBUAp/NKY4X FjylfFMcl5DybjPM07v30wcLi5EyBsM16VngdKs2ZHZ6Nzfg5kGCoLj6hdULtEi/K0lugtoqDLAi tZWqt/rd16S39g8DvdXrkt66NZwZyxgKz6NUl7AcKYolpS6cqTYHY+POtEwidHXz3KMy5UUJT/fZ Gk0c27IX4Dw2700Pg3kmJubzOKPJs7Zz8+7jK+GZlBgIy1GlGPhjumuSgQEzRQqqgx3bXB9aYsSA VTkpnJ9lX5KEPMEUFW63zTRFJ31tp9eF68xN0NuJ7oCRHTN1XM8c0bBi4YGUEhKWo0olZM+x4KsJ RMhNr8wOeSFKwFeBMQsUuvWYUcz9a+nhlCzUJgvDqT16UOYoGMVjWD7Ah6VASe4oJ7Ol8pcHPnEs 8TTQDOTJ7IGPW/bmfOKyrc/adwEeqGhWZvUVpcORYMiKsjsMkjGO25vS+dM2HwzOFfxRR0IEvYBE cEGQk6uO9kWfmQ8mwsoI9IW4Q9iWLT1CsbxY0qBAVsy9vda+nl3lA6Iw56/iYuWY4HztpUMrb19Y O91afRjbTGFxYpidWF05iZJ4qVcsIxUqFnXyTaAXFG27K9eMEm/vu3g4oLEdFmuXmamNlKzpDsN+ giAbNwVI3nWRdnpvDJ2F7rB+kv2OsIYN1A8NfOT1tzUfbSPwk/Coonwp2XDT8O7a073HudV+nM9c OASzp4c2TekyGTivjF+w6pqe7Nkm+AaFoZ7KN4gpQnwUznFCnCrPPkjUQqWSqn/C7/CMXPevKpDl PtCnr9+/nP2EQqu1CVdxsZRspUaDMdqjV8lFLL+xpao8do7zLFapM/rSXCWfO9on0xJiEYpSBOIS Kor8MB1vofJMEl7y2jExBN3gM0sYB9wNxqKbI0Pb+XF9dfMqX5RSB304j1Jkgy+IrejCqjMtLE7M vY8FKUl8r0Xsc5kgRXb8PLfdFZGyCU6EqKxrj1Ri/Wp7KlDZ4GqaxHETBiqz+dTlyUvPaM/MYeno RL6QdCgTApLCfRwqIIk5MiUCkvzQw5pHmGhniCdCfn3G9kO+yy1lWMeGTiPZwiyiIEfK1jHS2rlt Wh73XWDEPBvd55jRNzSmGqdEZ/PFKOf6inpn7u7MkVpF4egI9Pu3F68wsizEPoZobdvSqP9I27m6 PFfAIWH9VuZCMvK9mUnWwcweL6YrUx0xL2ntVF8+V78OuueYqy9bz3b3RD6ytfiC8k2axlGw9u6/ kFgHxQFhvbPd/wKvNkDN4WzumFPFVbnpAO0Y0xB1RId+/PzJ2Od+/PwpVmwAar9gc8jqK0oynODZ M/aYIvKrPPtiekguNeT37H8Vs+dHA8DsXe0DHH9y9WudplFruWSA4ERIssqJXxWjCOgYLYzkYqGL pEKWMnHl5fvaNRZj+wmlVrkkmnyTquplmv0IqmiKuYR3U8JwffOFOseEVUnO0dZBCx5zsVMtpJyV xZ4pX5vTvwno0AIGPQUrIxg5SSKWjmfpELJ+X1sxEB30WtvRyS2xppF37Oh8Mmlb0CgGmyFVxtvO up50SBJ87eI8a8I1lYESliMhJC/vi7zEBFvmTb8HFsBH6kSJ85i7xZ2itvCmauP/gpMojn7L56fU wTDP/ZQsTdDu9uT9i3kpajd3hNVJOMel/QkC+Oa5eGWhhAgmvqL2ZcVM/4sSew08WA185GLHVQTj bB8z/UlyujRwDhl8EbB0c/ymdRxj0GS86QEN0Ua2eKWQfWXyxWWVI0NWt5R4dokYLlhilu4Iv80a iXiKVnHTI4vA6b9SNstYxcwGkVbc9Iqb/rRppepGmuXchaUUDZmzjSpGherzPO/1egkMjFnK2iOe Z/qa5KsHZhHueWAUi145+eVAAiLdaimHWT53cO7oY6vOIbc0Yq/1p/GsIbwZu4xyeQGwE2IPLKOr ebZ2aY1BnyH1HW2pFMcy17Hin4bxgcY0Z3mjjglo52+vtZ44jAEbFMsLrJ2zz1O5AUUcTlbF3do0 NmDpNJd+OVRteRzdOzk5VkD3zQW6c1mMOnIhRgf7x4WT5P7XJP2+bEoKsyOmmpIA+Ux0E1e249hP +D8+S4+wZGJKp7VunvTpFHfJc4PKUluE/zibwozzwa4EBblp/HFcW8nGrAs+Xumeu3An5kyHhf46 B38ho1PkJCQRTnkHZBqvhH4/YSeVoRaWo1iGKdvPlDlfUq5d2aFhlZz2dRLSH9MxdjjQPxqNIauM 0B2I+uH6NQ2DEJZcNNZKHoXFiXlpsW2pg/aGzJ9wa3FfCiivgcBs0j1qvOLeUpnMw3fGNYToRx0c lPKj8DVB/pJGL+F2xXDKqX6UdKvq/CXEDx6ojflM92+2a8CHuYA7czEVC+sJ1qB8GuBMf9JFgrG0 yxe3NjjOX/D8N+AWmUQ0Zx/EU51wu1jzzZYeoJi/5uOaW6vErrwIRIjWXPcoLgfJR0m7MbzF3Hc6 0W5oWLoFeoTvLjUXehODNxwKj6Sk4R04fh1zuCCHXQsdtp3P767zMUr0k8jU4jlYsfSZjyyNMikH shJexwkIW42UB7DBBNx9iYAbYnTYPyo8DcL/mqAoEj2AMiTcP8x7GyNPF3/zXMlfujOOEgsg7Dw3 PM+VGzbk8E2prSjJgOzMeAYvB2qMZR186lM9MgA87YAygep1MFoSq9BtSP5dLBqvg0eItD6dV+Hg raP1r3TGZ9kV/cMGHp4GPnKBID3Fm8tXiOX+hxD1HZ4cFo3NqBBLXxNEL1HnF+er1uB3zna1PxG4 gLPBvTONKVQ+FTMpl3zR0T44+jM0vn8AY8QOwtNsqQzEApdYGZNXf0mft4epA3fzZBWTWLaq8F6X hGkNPabEICYEGqK8uWfMhuhdpHklSrdvcGVU4iqGkj7ax8C3Ynk3f5h6Dt1elG842XDVC7JZuKag DxKyXSxxUzypguTaZYfZpHedoOIZK+Yl+tnCoygLdRWLOsSWcmaq1Gz4p1Mv+dAIGj6P4a6D3YgC EFIwslSH5UiGhc4JiPZwngRT1VOmaoNNlcRWyU1V4QSR/zVBABPDkKJMlMmnrlZTdTN3jNGkNkBo 8htRgYjZsLOOrEWW6mrlCxx1k022yFwQEaLlzm3Ho7z8nTklXj+KeATpUEb39vqVdrMAFfajPjSn pveshaY3V3dsvw4WD9+UiGNe1ogBlSk53xYCh75EmMZtQuG8k/81QVkkmpKi1GfJireEKVlSyKWB oWfW2HBc17akt126Q8nQKPmVOa7i3HDuDYd/fq9b9/xTrgcpNbXhHEOia8ZX8LzkqldQoIpY0OLn cDPtNhmqt7blOeA+vgZeU+SMVYa8oNmug9TCN9v7guwrs03LMVfjVmkZWHEg6KqI961zN1IoRB0d 7Rft22PJSnxNEMBEs10U2Jhsw2C2/wQ8iiAIHDhVZ9j0w7Ae0J3n6nXZaaRcWpxEKAl5jvcUllVp 3LQIkywVKOTbPGEZMc2r5YuZfE37CgLNR9N4yhdm1tFNyeyVrC7WsVefFpZBdTU1Wuf3xskNzhbe xHbc/wL6aUwzXCXy2AbqtgY+chUgl3e6hYSV7XpKuWraW9Md2drNs4sKv8iG3EDpaOAjVyHQghyn ladLpT4uUF+d5rp8ier3qTbWrTs6iH+MSAo7I3sm3KuB26ke+ePt1WeOFyGiq3PH0B/ODcCpDYYh GZuPl0Sx8qhP37R6/W7/4Ljb3wsA45z0Kb2xllaX/04cMZb++1nF7xvPQNuUp507z7qlTAHcbGUK Wo3nqxb0Z5NMgesN2UFUpiDUcS+P3VDW6yWsVwNXOUGTZJQOxQbELeJe/b9ruDxar5ufe7W/xL3q g20V96pPAZrl3YXsqcmpdi2FexXEJmQnw28P6G/co8wJNUzhJXWNuY6eOMMnH126pHgwgs5cTGa1 ncAnfs/+cAd6EfzQsi12zafTrNVIA3pKPkFe1znlHY1V3KsQacW9qrhXFfdqM+JgMImBqeGpRuxm 4XGCjXSQ8qrVNC2toQOEmFSn7c+LkaEyEtQ2/cN+hkPlEHZnZKymOSwPL76Z2PO5YU2AJgOsTTKY 9WLatG+2PhbuuKXij1TzGFtg6OjVFdajWPCR6SENgB18cNHR+Pkozy2KJ7VTHNG960/C/bZ0i79b pgc2QsK/jFWu//eud6dIcp185jVXm2bc0+kM7dHI/EP3re2UWVtVe/ofqNkb7xk9L351RqXCrCCO D4CYVdWePtsL0A4Ril1ZhToVymd9+EVY4QRXotIGBUKbu4spOCAbD3zcUhfleoJc26n23732frfX Pjjqt0/29vqCEG3pyghrkHaQfkeUyRTMJVC1f0z1odWxjMbX+hsof+qRlTeV6E0pwVCCoQTDB7Wp +CujvkmaIojDGEwLcarjmuNvb1rd7t75IXWrBz96Z9zp8MJj//JLgV1KySklp5ScUnLBVNv0EoVS cir76KdfDaUxlMZQGkN5cmv2yijnUzmfypQoU6JMiTIlypQ0IFuUUFrL6LVJjyXR/DpgNAe7muFp +rSzqoAXo5cL2iE44CHzHqk4oZC45eLvuQnCDO1s7phTjKLfJbqTg/Cf/Q9+70wvuXemQe0waztc 7lwfAUCASHjIGqeRxqTMJv8LWEhs/xf8n+t3nuHEP0u/8kv6rocO7wFZ0QJj2ZAJy+PtLu4/QfDf 88mW3X/euvLPSgjjR2821Wa684BZhQDzjoH4GmvD55Uo0yw8sdjKU/V7DJy7EX/gVYc2Hb5S7xOm HPtep9fFAdcfwRuhDwEmA7/DTF7okN09mmp8wkR8gplitvMMZoAWa8SKdWOJbxO0TlUgMoOJ581P X7/2bHvqdkzDu+vYzj3/6+twG14L+4AjHr5D9oNWLRgpyy4/3ZyeyjVG3jU1lsllEvrH+f0NHbcn rHXvpMu5/fH5qL/P2rfoFzDMFr/h2XP8/KTP6NYd836CskrvuMuKLUPb8+xZ9PepcRf7V4Jyk2bq YzgULnRn20xRnZywoYH3C8/XW0xBoQmOjjqpNuNN62DP1wBje/TBMYkxYmpaxrXpjSZvWvt8wiB2 gb8i698b2uNn9gFfWczQQDH4jwAAAAD//wMAUEsDBBQABgAIAAAAIQAe/WabKgYAACUqAAARAAAA d29yZC9jb21tZW50cy54bWzsWl9v2zYQfx+w70DopS+xLTu20wq1irRpigDLFjQZBuxlYKRTRFgi NZKy6z7tg2xfbp9kR+pPYltupSTdltZPUSzqeH9/d7zjy1cf0oQsQCom+MwZ9l2HAA9EyPjNzPn5 6rT33CFKUx7SRHCYOStQziv/++9eLr1ApClwrQiS4MpbZsHMibXOvMFABTGkVPVTFkihRKT7uHgg oogFMFgKGQ5G7tC1T5kUASiF+72hfEGVU5JLt6mJDDjuFQmZUq36Qt4MUirnedZD6hnV7JolTK+Q tjutyIiZk0vulQz1aobMJ17BUPmn+kJuSdGwb/HliQhyowK740BCgjwIrmKW3YpxX2ooYlyxtPiU EIs0qdYts+F4a79a5DY2OJF0iaa4JbhFrkEZYfFRmhR6MPa9teomxaH7KWFKixgSNQ9tWFjfs+Ik pYzXZO6nmrvKxYh4iH+/kyLPanYy9jBqZ3xe0zKB2YEzd2oj765oqhOBrdC9jGkGDkkD7+yGC0mv E+RoORwT45GOfwsWZOmxEHEGYWbp0VzHAsPtY2D+C6nGjxAXDnvDYW84vhq5njvyXPdX85ZxphlN kE9cbQhm+COiVvh+5rju+PVocoQxX/50AhHNE33njf3iQto/l3qVAC5d0GTm0OfOwH85QHrFW7tE ls/rK4/KleVbyrnQNuDfQ1TQKD42m1QUToUByKUXM47sAFX6WDG6Tkj770/fTJ5PXYIwS8zzi8mQ xHQBBHcg1wCcqDxFqGMfISSMEx0zRRQEBm365Mywr60QBQOVGi5Qt657PJ2MRm8dw5U22OqpjAao 6UyCArkAx38WkoTNgWhBJBSoHpJNop2lat5Lx1STVKBsVggJEUhMONC4n/aRpVLOL8QPGVutl5uQ o/7aPsYvrGILraCS67SHSrae/KKdJx+OvwVPbrb5OZo7JJEUaWVMMkK3jXbYnIMpCKhcrZkCY6qz C/oHhIYhAofghJYxtCIiIj8dn6Or/54zCUUJQxUROgZZM4gBluZBjNGnNciuXjEatfOKJ4tv2j9/ uHWYLfsQe/h8jdjno240aaff8beRP84MmPI50WtqxIhZzwTTsTscF+lY+4jDz5RNMFW8sWRFtMxh k0jnsGtGgf5WuFfc2Tw9Ho2mZZbyX2+ysGNltywLAc0VELVJ/JHkEykQwXshHnwwjRuEwTw7B0z/ mxs+ijQpXSE4bZJ+JFm2WDZ0tR9KkWUQbm76GPI0+wy5XmG9gwCcQsiwPkR/DaGDI119CVZN6JAU KLfRA3h4Xt0xN7GlGdemmkoAizjVOXm0LCnGh0+0pND+L5t26ey3PhQVMr2RgMUFJnhbTwYx5TfQ VeOHX3u67gSUzaF4ZjQMJAPZsxEZ4SGCBFTBwQ6wqCovmjzY2M0cITIUrSBT3qlY5EmIiEgQ40MT fCzEzgyLMKch2yqDgGH3qUATyzuWgeZNCEozbs9xJbq8wRYOfiyxD1KLbHDHHhSa5K/SbwgJIEY1 iav9v//4s+lFJ8v4ho0mKob8X00vOpHfpeZPlMKtq3Jz3OZMxeVBuThga98JYgUNqi49ixUuVp95 sdMU6QNy9kzCrcWsXWqfNIYSPFmtY8DD+MxufszT7kf8Rpn3tHa2RPb6qty0XTrc62uvr8224t4n 9j6x94my7Nnn2n2u3aw5vz2f+Hw79bBlO/UJt6uPH3w68k2ngSyZjslK5JKIDGeSOH9bI9xC10ft Wtf31PXazK9qzP1/5qH/1kT1/OKHy97VBfaI8PBKedGgi3JuR6YKh0+EprZ9p3KJRo1XJGShsSs2 9rBrYNtJQC7OSfWNPVPW59Bq9trR9th8R5O0GHs/1WHhfzwWGn/9OLY1Gml3VERcKmuiHXcAJOU4 7WQ8SHJsoGz13G2PBdvZ0Y4OfDEfeASQxWg0UWjD0jwsadFKVzjusHcHaJKYCa5p3W1zybEXrNaa f/YiCAkEL8bAr7pGLF5/axWxT3XQqP2t6yOdPcrXZugRCIm3R3RXDU8OW2p4+mSnHV9wVL70roWY m1uQl5pKjb5qLqVMbJ7hNMVrPr+9E69xDmmuHN0ufosTynpp0djcuOeCgFHeeVH+PwAAAP//AwBQ SwMEFAAGAAgAAAAhAAzkc5qzBgAArBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU1vG0UY viPxH0Z7b2MndhpHdarYsRto00axW9TjeD3enWZ2ZzUzTupb1UhcKiEhCuJAETcOCKjUSlzKnyFQ BEXqX+Cdmd31TrxWktaCChpFiXf2mff7febDl6/cixg6IEJSHje96sWKh0js8yGNg6Z3q9+9sOYh qXA8xIzHpOlNiPSubLz/3mW8rkISEQTzY7mOm16oVLK+tCR9GMbyIk9IDO9GXERYwaMIloYCH4Lc iC0tVyqrSxGmsYdiHIHYm6MR9Qn65f5D+D0++vj46Pnx0dfeRqamw0BXrKQe8JnoaSXEmWuww/2q RsiJbDOBDjBreqBxyA/75J7yEMNSwYumVzE/3tLG5SW8nk5ias7cwryu+UnnpROG+8tGpwgGudJq t9a4tJXLNwCmZnGdTqfdqebyDAD7PnhqbSnKrHXXqq1MZgFkP87KblfqlZqLL8hfmbG50Wq16o3U FivUgOzH2gx+rbJa21x28AZk8fUZfK212W6vOngDsvjVGXz3UmO15uINKGQ03p9B64R2u6n0HDLi bLsUvgbwtUoKn6KgGvLq0ipGPFbzai3Cd7noAkADGVY0RmqSkBH2oZ43BcVMi8frBBfG7ZAvZ4a0 JiR9QRPV9D5MMHTGVNqr59+/ev4UHT94dvzgp+Ojo+MHP1pBzqxtHAfFWS+//fSvx/fRn0+/efno 83K8LOJ/++Hhrz9/Vg6E5pma8+KLJ78/e/Liy0/++O5RCXxT4EER3qcRkegGOUR7PALHTFRcy8lA nG9GP8S0OGMzDiSOsdZSIr+jQgd9Y4IZLsG1iBvB2wLIowx4dXzXMbgXirGiJRKvhZED3OGctbgo jcI1rasQ5v44DsqVi3ERt4fxQZnuNo6d/HbGCbAmLRPZDolj5i7DscIBiYlC+h3fJ6TEuzuUOnHd ob7gko8UukNRC9PSkPTpwKmm6aRtGkFeJmUGQr6d2OzcRi3OyrzeIgcuEroia0Wn6PqEOWG8iscK R2Ui+zhixYBfxyosM7I3EX4R15EKMh0QxlFnSKQsm3NTgL+FpF/DwFelad9hk8hFCkX3y2Rex5wX kVt8vx3iKCnD9mgcFrEfyH0oUYx2uSqD73C3Q/Qz5AHHc9N9mxIn3aezwS0aOCZNC0S/GYuSQrxK uFO/vQkbYWKoBijdYeqIxvNpuw0r71hMrIbFETdQ5YuvHpfY/bZSdmH5cnpm+wRRz8OdpOc2F0P6 9rPzFh7HuwQaYnaJekfO78jZ+8+T87x+XjwlT1kYCFpzjN1mm013NHfPPaKM9dSEkevSbLslrD3D LgzqeebkSfIzWBLCR93JoMDBBQKbOUhw9RFVYS/ECWzZq54WEshUdCBRwiUcFc1wqWyNh22/sgfN uj6CWOaQWO3woR1e0cPZSSMXY6wKzHE2U7SiBZxV2cqlVCj49jrKqtqoM2urGtMMKTracpd1iM2R HEKeuwaDeTRhU4NgKwRRXoWzv1YNhx3MyFDH3eYoS4vJwiJTJEM8JGmOtN+zOaqaJGW1MuOI9sMW gz42nhK1graGFvsG2s6SpKK62hx1WfbeJEtZBU+zBNJOtiOLi83JYnTY9Br15bqHfJw0vRGckuFj lEDWpd5HYhbApZOvhC37U5vZdPk0m43MMbcJqnDxYeM+47DDA4mQagvL0JaGeZWWAIu1Jmv/ch3C uigHStjobFasrEEx/GtWQBzd1JLRiPiqmOzCiI6dfUyplI8VEb1weIgGbCz2MKRflyr4M6QSrjsM I+gHuJnT0TavXHJOm654H2ZwdhyzJMQp3eoWzTrZwg0h5TaYp4J54Fup7ca587tiWn5BrhTL+H/m il5P4PZhZagz4MMVscBId0rT40KFHFgoCanfFbBxMNwB1QK3u/Aaigouqs1/QQ70f9tzVoZpazhE qj0aIEFhPVKhIGQXaMlU3ynCqunaZUWyVJCpqIK5MrFmD8gBYX3Ngat6bfdQCKVu2CSlAYM7WX/u c9pBg0Bvcor95jBZvvbaHvindz62mcEpl4fNhiaLf25ivj2Yrqp2vpmerb1FR/SL6TarlnUFKCss BY207V/ThHMutZaxZjxermfGQRZnPYbBfEOUwB0S0n9g/aPCZ8SUsV5Q+3wPuBXBVxdaGJQNVPUF u/FAmiDt4AA2TnbQFpMWZUObbp101LLFesE73VzviWBry86S73MGO9+cueqcXlxksNMIO7G2Y3ND DZk92aIwNMoOMiYx5uuy4vdYfHAXEr0F3xiMmZKmmOBbKoFhD90zfQDNbzWaqRt/AwAA//8DAFBL AwQUAAYACAAAACEA9tH6Mg0BAACLAQAAHAAAAHdvcmQvX3JlbHMvc2V0dGluZ3MueG1sLnJlbHOE kE1KxEAQhfeCdwi973RmEAlDktk4A1m4kbiRbIp0dRIm/UN3qZk7uB7wBp7B+zjnsBEEAwNuCop6 9b1XVWxnPSUv6MNoTclWacYSNJ2Vo+lL9tjsec6SQGAkTNZgyY4Y2La6vioecAKKS2EYXUgixYSS DURuI0ToBtQQUuvQxImyXgPF1vfCQXeAHsU6y26F/8tg1YKZ1LJkvpYrljRHF53/Z1ulxg7vbPes 0dAFCwFEELPJBrWL8TGywfdIJVPjhDG5eNq054/38+fp6+3U1rtm/1PyvHVr7bjyoPHV+kMrPSji I5LiERU4Ob5U8OwmlZbmX4t7K+MRu5nQG5iYqAqxeGH1DQAA//8DAFBLAwQUAAYACAAAACEARn/c WEYEAADECQAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFZbb9s2FH4fsP8g6Lm2JVl2MiFKETtx6y7Z gihFnymRtrnwIpCUlfTX75CUrKTRimIvNnk+nvvHQ118fOYsOBKlqRR5GE+jMCCikpiKfR5+fdxM zsNAGyQwYlKQPHwhOvx4+ftvF22miTFwTAdgQuiMV3l4MKbOZjNdHQhHeiprIgDcScWRga3azzhS T009qSSvkaElZdS8zJIoWoadGZmHjRJZZ2LCaaWkljtjVTK529GKdH+9hvoVv17zWlYNJ8I4jzNF GMQghT7QWvfW+P+1BikeeiPHnyVx5Kw/18bRz0526bZS4ZPGr4RnFWolK6I1NIgzny5HVJzMxOk7 Q6dST6HUM+97Zk2Behy51RC5Zu/0R7rtu3hLS4WUbzMQwEbBq2y7F1KhkgGp2jgNL4FRR0raAP4Q GG9JGc6s8LuUHIQ1URV0DjgaRR4oITQg7rX8S5qiUUo2An8mCGRObwzeSGk6GOojd4VBhoBxXRPG HOUrRhDE12Z7hTiQNQ+9xJlExiCgNn4kvAbqkEBlFOeh2uLYh2QUqp4eyJHa66SdDiY71DDziMrC yLrP7jztkhDyvhGVaRwR/yRKQBROrzogMAbRFjWqQLiWwijJegPYZr2GW6Sgyd65v1O2ZA4sBKof 5SdF8VasIT0fjVX7pgAhz+YbNQfnfYC+anKDtLnSFImVIujpoWHEJ7JXsr1qjNxR4843mmxubtGL bPzeuy/8UIAwBeLQWi/tLvqdxMTWtlH0HXv+k31WwTECSAKOZ202JApjC2ubsV08QHP7s1G0WaaL ZOkrY9EBiZZRerYYQ+J0ni7Px5BkHq+i+SiyWqzSrv1v/aRpkixvxnTSVbI4G40NQluszsZ0zpZp uk7GkPM/khOd3kZwtVwkyWgEq/lyfTXqZ6gbVNqag/ryzA63e9WvNsDFgPuurBEvFUXBnR1/0B+e leppRUWPlwTGP3mNFE3Zg5OJBzRHjG2A7z3gbgfPMNX1Ndk5s+wOqf1gtzuhRqVw6b6cbNmxQdQn mA+199YC/7cCg7h3F6f+PvKMCnNLeS/XTVn0WgJG2CsIhs3fR2UNzobytJmBl4/Y+twise85R8Tk a2F5TLq7lYf/oMmXe6sNdGaqsA8muUN1DTcdzpX7OA8Z3R9MbNUM7DA8nG5T7pMOSxwGO4u5Daps snC6W9gDfgmnusUgm/ey+SCDZ8GfSwfZopctBtmyl8HD3WaHFxjPMECf4Fr3SyvfScZkS/DnXpiH 70S+CG5kbUXFGkyAIFhWeivsePbDRx9QTYAJdpQCIWXmBN1s1cExg3GWhwRTA58rNcUcPduXAgbA 5cUxM4CW8jmgAr5Z8nAxPV/U5sP0DH5erV0vf7B8csXcoHvjyGLWU/1GGmBkEPh+bc0ru9n1QyIw q0lFgf3FCy+H6T71RWFUm4LU8BAYqaCcbgx+cJaHz6/LfwEAAP//AwBQSwMEFAAGAAgAAAAhAIMe WBfGDQAA4m4AABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbOxdTW/cxhm+F+h/IPbUHmTt l1YfyDqQZStWITuKJbfnWe5IpMUlWZKrtXJqLLQJUBTtqQ7QUy+9pS2QAm1a/5utgt78F/rOB7lc kkO+s6Rkx7YPlnZ2Zp55P+Z535nhUB99/HziGBc0CG3PHbY6d9otg7qmN7bds2Hr6cn+2lbLCCPi jonjuXTYuqRh6+O7P/7RR7OdMLp0aGhAB264M/PNYcuKIn9nfT00LToh4Z2JbQZe6J1Gd0xvsu6d ntomXZ95wXi92+60+W9+4Jk0DAFtj7gXJGzJ7ib53jyfuoB16gUTEoV3vOBsfUKC86m/Br37JLJH tmNHl9B3exB34w1b08DdkQNaSwbEmuyIAckfcYsgJ0UBrmh53zOnE+pGHHE9oA6MwXNDy/YXYqza G4hoxUO6KBPiYuLE9WZ+p5/DS0TG2OB+QGZgikWHue4KlDEWjSaO0AOz78Kq2R477TJhpEVYF8kY MENYxoxHMiG2m3SzmmrSyoX5UMe/Pwm8qZ8Mx7fr9Xbgnid9sWmpMbL2gM+8tGihVge5qXtsEZ+2 jIm5c3DmegEZOTCiWadvMI9s3QWqGHvmfXpKpk4Uso/BUSA/yk/8x77nRqEx2yGhaYN6TuwJsMtj OjOeeBMClpztUBJGu6FNToBfAGJiA9oDWca+t3bdsLilCSJmO1xnqA5xz6DlBXGGLequPT1O4wxb z8jaz45Y0cgeQ88kWDvebUHDdS5E/DMljJ+IJmplJAeOAMY4FswJeqGnh555TsfHEXwxbAH78sKn B0eB7QVAZ8PW9rYsPKYT+6E9HlNG1HFF17LH9BcWdZ+GdLwo/2yf06Ts0fSmbjRsdQeb3BpOOH7w 3KQ+oyvAcwlT5mPWALgEeD2Fwwc0tRejEQUZVF74yxiywxQEmi1CsShhocXg4y8F4lJPawN1KyVq CKh3W0D92wLauC0gCNcVXteQjTYZUNqbeb9ajgvpUN0uhDCpOYUfReSZYuqkhehtl0w41oLPAa0W 3Jm1WnCv1GrB3UurBfcTrRY5g1fqKmffyhY5c5a2MAmn3awX9bg2UJ54YkcORNuKGdOpSdQypBlH JCBnAfEtg4Xn7LDLqP54OopwQ+XBYHWqP44CjyWtFRrpimmwckR5MPEtEtqQ21cB1VT9CUugjE8C G5LgCqgN4Xw5mdQB+MghJrU8Z0wD44Q+FxbVaP/YM459YvJVQsXgapr10D6zIgNyS5YwVGpioFC6 WhOi/0M75DoozUUGClGqOkfZcKDwS3Xnj+jYnk5i1SByqYHgcw0zZyCqs6hBn5koP4krpWAGwIgg woW+CLx/xPhFcNHvn9kYM34RilbsHzF+EbhW7L86eR1oM8192JwxUNNrU3vu7nmOF5xOnXgOVNLD pvYMTiBwImhP4qR/FElsas/gJfo0dk0T1p0YP9W2xYJHNVC0zSFQ+GTDy6JtlAztdTQk0jZQBqur gVWPazWAtEn3Cb2w2VaybjDgLJ3kmpXTuafQAIQgVA792dSLqnPoroLzsCgHLmz2hNTAofUUMw+L Jv1JxDsNG9cLfBpA9SKgBlC9UKgBpPAPdc6TxEQ8SP3gqIGlTctJFONuh2bmTW1mToD0QkBDcROR fylmr9oX8nETgaJtoHzcRKBoWycTy5K4icBqLG4isBRRQ22jNKfqCKUdN9NASSaAkKgZ8kYANUPe CKBmyBsBVJ+8q0GaI28EljY3JJyaJm8EEK+is9RPgNLkjQDS5gbBdnLPKI57vJfy/Z0GyBuBom2g PHkjULStoyJvBBavouMJGayE6hBYzZA3AqgZ8kYANUPeCKBmyBsB1Ax5I4Dqk3c1SHPkjcDS5oaE U9PkjQDSpocEKE3eCCBeRYcbCsmbz/obJ28EiraB8uSNQNG2ToZQkyQVgaVtoAxWQt4ILF5Fxxkk FnduHaGaIW+ERM2QNwKoGfJGADVD3gig+uRdDdIceSOwtLkh4dQ0eSOAtOkhAUqTNwJImxsKyZtP xhsnbwSKtoHy5I1A0bZOhlATnkNgaRsog5WQNwKL+0tt8kYA8SqrAulI1Ax5IyRqhrwRQM2QNwKo PnlXgzRH3ggsbW5IODVN3gggbXpIgNLkjQDS5oZC8uZz5MbJG4GibaA8eSNQtK2TIdSEvBFY2gbK YCVUh8BqhrwRQNwxa5M3AohXWQGIzyIdMzVD3giJmiFvBFB98q4GaY68EVja3JBwapq8EUDa9JAA pckbAaTNDew5W3heFP14akfhBNjnDOKnGtCAXYWRsIBSwCf0lAZwN5FWPx1SEzCWUANR4R5YEe95 3rmBe7C7p3AQNJQ9cmyPP9J9yZ/SSV1E6G2W3CQ4+XTPeCiu7+TacZdafvIGbkilLzuxG0H8wiiM M7r04cKRHz9ZznqDi1Dsdpi8wMQrHsB1JsLvK7ELSlCH39GS15T4ka0E5L/DvSsOIZ5NhtojCjdF AabT5oc74uPuNPJCUUVCkdOIwp1PWYt/ylSC7kEW2T/cXGMwQeau2utX37x+9a3x+tXf5y/+MX/x z/nV1fzF35hg8ZW1YUtdR15bU1dgt9cU33Lhw89j9XT7woLh53vsKh1XmShL3Vjj6q0wSGKCTs4E iztcHHxE4ObZp+wiGUcj0oVs9zwugrsIvObi6kb8jby5UmpIx2YXHLkR2a9Ppux2IYkOmWZFv940 Yt8cXjhxvxyw0mp73jSw4Tl4uGPITCXNkC4VAor/90L+85wGiay9ARvAqprtKjXbFXJVa7Z765rl Nz5uQrOrarGn1GIPq0V48o6b9vb8kxv4bdKiuKabJtp4lktCqfbF/q1rkRv4bdLihtIXN7C+uHHr WuQGfpu0OFBqkdMthPbKiAO3gW55RnMDvxktmhZkUiakMWWJVDunVMUNP4Xe5E2/xX6QqLd03wSK QAOK7CJit9rKRphPNESuZ/D7cEp7yhSiamCQdY4ckbzBLwfuGAL+TKYVIh8dP5epC3y/Rx3nEQlY jhR5vrqqQ08j8W2nzRfxma5GXhR5E3X7gN9x4yMp6gC0mR6M+MiEUKvZnU5GNJA35lRZdT7zgGt9 bEFcV8vqcS05aZJcknz0fgiLgwDSufNixlRPbLQjyBzeZHeIwDQ8a23Dv/19KX5cyF5LAz4r3Jq3 0pYvH1f3PcfxZnT8ZuTcAjm3Yh3WltOchuDex+xtFtmVG+T8bPakM4r//eW311/+e/7FS6Nj/OT7 P355/c3Ln5YamXlBPEbJP8oUrXBhFr8nhDzzgofs3SCMf+IVWfrL3EtE0l8mLc0wki8eYR3egzeC iOE3s/xamiElmoWcX63Zrr5m5WJDqdkMs74/ioZlgVrRPX1Fy/XIB0VnuQJWDmpF9/UVLZcstRSt 3HBJMUhZndp7OiOeYI3krsPtUgwsQtQG2dA3iFz91DJIISP/0Lkc1ilqRQ/0FS0XSLUUXebVsb7L 6ryVnr+02Zyknw9PHh3mDMAKjaOAbR/DW/giOi7OUURpOkVhDePUKtlUj/MXeItX8Yop2VqGBRJ/ ORr8jBux5QVLWXwPNoC3O9K6qgqdrZ6M5aoa3c3+lhiGqkZvAC9y4ANV1ehvxPmjqsZGf7tipIN+ p2Kkm71uxUi3uv2KkYLCpDlUI4Vd/82KoXba29sVY+10tmHxV6q0TheGW1GltxnvoCmH2x9s8OGy haD0FnmaAU4SH3iojjt4uTzuWPy+dNjB1QWdow47Kk86shWWiSH7beqMY+kr0CuMSGf1VZI7iyma pVw+47//07+uX/3+v//5ev7F7/SJl3Uh7FvAvXLqF2bOw1b6vAHMqEGxmZYpDWYPolBKXOLIEiVa +Z0aKOL+X7wzlzubY6c1ZUc6lS6YkVx6VrpUDEf8z3OoaidCy5/fPrEkRbwf8uc3bazSs5Z3zf75 TR1Lkvv7Yf+CY47S8413zf4FBxQyi3gv7O8HNJc0s7KSCIALfcU03hxxd/KBa371NXtW4+pX86tX pTFMSjC6kYji0plPzvJajctLNCvnFmt+L6Dk/B5/7AUaxDEUfipOZLDxznbZO33Y6U02cVp8UzJC qbml7fZ9/o95TLV1sfui4IJ5+/LCwsHJpcHKngmpmmWztyrLQ5ZmhbEKfJWV3ZoosJ4QWHID6oK4 dmiB0OK4RAxkRkfihdSZcsxuFbilT82f57ttziPOAnqZ81leqFajerpg/dCC5x2zE4WVqTHl8ib/ WFk6oWX+Jl5vni3NeuG7YDqrV6BEKPugRFg4oT2xX6BEKPugRA0lup4Px+lRbkrH5WplqqlkKfIm u5Ekn1ffI3BYDC/p52/qLUQSxkxvQxKZi6o3IjInestXKTgK/DkY9oCEPBrfHWx0uw8EUi6XX9p2 SraXoBcQX1YujLG3vp/fkXt06UdjRVlzEQd0n6X+6z98BztK8uBb+9gbfIIbBG1MteXeMSsspo34 oxbpJw2I63rwBzXYn7eAfXx5a6Bw+lTu19eZK1Lji2yojgsqOGMr53Ap4SP2gu9CuQtoIz6gUB5d rK4KNRNiQxnZzsk5f/Ht/OrP8yv4/yvxNMn1Vy/1d26JpIWbmmFlR2Uae72Kx/+BpMu3fSHNvsHL AYTkzJJyv3A6ekZNhQdKtbvgonGkiU2xFM1GmgSoFc3kDB2JOYLcJ0b77CinnLTPXv/m19d//a7C YeWkXNII0dSIZkh44w6btsaq7hszTnj3/wAAAP//AwBQSwMEFAAGAAgAAAAhANbOGQ7hAAAAVQEA ABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAnJDBasMwDIbvg71D0N21k7ZpKXGKSxbodWywq+soiSG2g+2MjbF3n8NO3XEn 8UlI34+q84eZsnf0QTvLId8wyNAq12k7cHh9ackRshCl7eTkLHKwDs7140PVhVMnowzRebxGNFlq 6FSvDYevpi3YU8n2RFzyguyOrSAXsWXkUDZ7wfJylx/EN2RJbdOZwGGMcT5RGtSIRoaNm9GmYe+8 kTGhH6jre62wcWoxaCMtGCupWpLevJkJ6jXP7/Yz9uEe12iL1/+13PRt0m7wch4/gdYV/aNa+e4V 9Q8AAAD//wMAUEsDBBQABgAIAAAAIQCBBSFkQQ0AAPFrAAAPAAAAd29yZC9zdHlsZXMueG1s7F3N b9y4Fb8X6P8gzKk9JPZ8ePyBnSwcb9ykcLLe2GnPHA3tUayRppImjvfUjdHuAkXRnpoFeuqlt20L bIF22/w3Uy96y7/Qx0dK1kii9DiSJ2mSHGIPh+SP74M/PpJ68kcfP5+41jMehI7vDVrt2+sti3u2 P3K800HryfH+ra2WFUbMGzHX9/igdcHD1sd3fviDj853wujC5aEFHXjhzsQetMZRNN1ZWwvtMZ+w 8LY/5R58eeIHExbBx+B0bcKCs9n0lu1Ppixyho7rRBdrnfX1fkt1E1B68U9OHJt/4tuzCfcibL8W cBd69L1w7EzDuLdzSm/nfjCaBr7NwxCEnriyvwlzvKSbdi/X0cSxAz/0T6LbIMyaHNGa6Aqat9fx t4nbsib2zoNTzw/Y0AXlnbd7rTuguZFvf8JP2MyNQvExOAzUR/UJf+z7XhRa5zsstB1n0Dp2JqDs R/zceuxPGIztfIezMNoNHXYM+obeJw4A3VNl4vvxrhcWt7TDfIdrAtVl3im0fMbcQYt7t54cpXEG rafs1k8PRdHQGUHPLLh1tNuChmsoRPwzJcw0EU3WykgONgMLHklHAr3wkwPfPuOjowi+GLTAGbHw yYPDwPEDcJZBa3tbFR7xiXPfGY248Nu4ojd2RvznY+49CfnouvyzfXRC1aPtz7xo0Or0N9Eabji6 99zmU+E+gOcxocxHogEYENw8hYMDmjnXo5EFGVQs/EUM2RYKAs0WoYw5EzPNwvGXAqHUs9pAnUqJ GgLqrgqotyqgjVUBARlWeF1DNtoUQGlvxn6NHBdWh7pdSGFSc4o+isi35dRJC9HdLplwogXOAaMW 6MxGLdArjVqgexm1QD8xapEzeKWucvatbJEzZ2kLmyHtZr2oi9ogeeKxE7m8csa0axK1WtKsQxaw 04BNx5ZYnrPDLqP6o9kwog0VF4Plqf4oCnzvtFIjHTkNll5R7k2mYxY6EGtVkFWnpuqPRexk/SRw RpVQG9L5cjLpF+BDl9l87LsjHljH/Lm0qEH7R751NGU2rOGVg6tp1gPndBxZR2MMGCrB+hql6zUh +z9wQtRBaSzS14hS1TnJhn2NX+o7f8hHzmwSq4YQS/UlnxuYOQNRHUX1e8JE+UlcKYUwAEUEuVyY i4D9E8YvFxfz/oWNKeOXS9GS/RPGLxeuJfuvDl77xkzzCWx9LdL02jSeu3u+6wcnMzeeA5X0sGk8 gxMImgjGkzjpn0QSm8YzeIE+rV3bhn0nxU+NbXHNowYoxuaQKDjZ6LIYGyVDe20DiYwNlMHqGGDV 41oDIGPSfcyfOeJkzXQxQJZOYs3K6dzVaACWIFIM/dnMj6pj6I6G86goDzw47Am5RUPramYeFU35 k1zvDGxcb+EzAKq3AhoA1VsKDYA0/qGPeZI1kQ5Sf3E0wDKm5WQVQ7cjM/OmMTMnQGZLQEPrJiH+ 0sxevS/k100CirGB8usmAcXYOpm1LFk3CViNrZsELM2qobdRmlNNhDJeN9NASSRAkKgZ8iYANUPe BKBmyJsAVJ+8q0GaI28CljE3JJyaJm8CEFYx2eonQGnyJgAZc4NkO3VmFK972Ev5+U4D5E1AMTZQ nrwJKMbW0ZE3AQurmHhCBiuhOgJWM+RNAGqGvAlAzZA3AagZ8iYANUPeBKD65F0N0hx5E7CMuSHh 1DR5E4CM6SEBSpM3AQirmHBDIXnjrL9x8iagGBsoT94EFGPrZAg1CVIJWMYGymAl5E3AwiomzqCw 0LlNhGqGvAkSNUPeBKBmyJsA1Ax5E4Dqk3c1SHPkTcAy5oaEU9PkTQAypocEKE3eBCBjbigkb5yM N07eBBRjA+XJm4BibJ0MoSY8R8AyNlAGKyFvAhb6S23yJgBhlWWBTCRqhrwJEjVD3gSgZsibAFSf vKtBmiNvApYxNyScmiZvApAxPSRAafImABlzQyF54xy5cfImoBgbKE/eBBRj62QINSFvApaxgTJY CdURsJohbwIQOmZt8iYAYZUlgHAWmZipGfImSNQMeROA6pN3NUhz5E3AMuaGhFPT5E0AMqaHBChN 3gQgY24Qz9nC86Lkx1PbGiegPmcQP9VABuxojEQFVAI+5ic8gFQtXv10SE3AWEIDRI17UEW86/tn Fu3B7q7GQchQztB1fHyk+wKf0kklInQ3SzIJjj/ds+7L9J1cO3SpxSdvIEMqnewkMoIwfw7GGV1M IeFoGj9ZLnqDRCiRHaYSmLDiA0hnYpivJBKUoA7maKk0JbyyVYD4O+RdIYR8NhlqDznk4QFMex0v d+TH3Vnkh7KKgmInEYccPFULP2UqQfcgi+ofMtcETJDJVXv96pvXr761Xr/62/zF3+cv/jG/vJy/ +KsQLE5ZG7T0dVTamr6CyF7TfIvCh5/H6un0pAXDz/dEKh2qTJalMtZQvRUGSUzQzpngOocLwYcM Ms8+FYlkiMaUCzneWVwEuQhY8zp1I/5GZa6UGtJ1RBomGlH8+ngmEgtZdCA0K/v1Z5H45uCZG/eL gJVW2/NngQPPwUOOoTCVMkO6VAoo/98L8ecZDxJZu30xgGU129FqtiPlqtYspBrgoFanWcz4uAnN LqvFrlaLXaoW4cm7FWsRDfw2aVGm6aaJNp7lilCqfbG3ci2igd8mLW5ofXGD6osbK9ciGvht0mJf q0WkW1jaK1ccyAZa8YxGA78ZLdpjiKRsCGPKAqn1nFI1GX4avalMv+vzIFlvId8EikADmugiEllt ZSPMBxoy1rMwH05rTxVCVA0Mos6hK4M3+OWBN4IFH96WgGGFjEdHz1XoAt/vcdd9yAIRI0X+VF/V 5SeR/La9jpv4TFdDP4r8ib59gDluOJKiDkCb6cHIj0IIvZq92WTIA5Wep4uq85EHpPWJDXFdLevH teCkSXDJ8qv3fdgcBBDOnRUzpn5ikx1BxfC2yCEC02DUug7/9veV+HGheD0G+Kx0a2xlLF9+Xd33 Xdc/56M3I+cWyLkV67C2nPYsBPc+Em+zyO7cIOYXsycdUfz3z7+5+vJf8y9eWm3rR9//4curb17+ uNTIwgviMSr+0Qa6hRuz+D0h7Kkf3BfvBhH8E+/I0l/mXiKS/jJpaYeRevGI6PAuvBFEDr+Z7dfC DCnRLMT8es12zDWrNhtazWaY9f1RNGwL9Irumita7Uc+KDrLFbBz0Cu6Z65otWWppWjtgUuKQcrq 1D7TGWKANVSnDqulGNiE6A2yYW4QtfupZZBCRv5/53LYp+gV3TdXtNog1VJ0mVfH+i6r81Z6/sJh cxJ+3j9+eJAzgCi0DgNxfAyvcYv4qDhGkaXpEEU0jEOr5FA9jl/gLV7FO6bkaBk2SPhyNPgZNxLb CxGyTH04AN5uK+vqKrS3umot19XobPa25DB0Nbp9eJEDDlRXo7cRx4+6Ghu97YqR9nvtipFudjsV I93q9CpGCgpT5tCNFE79NyuG2l7f3q4Ya7u9DZu/UqW1OzDciirdzfgETTvcXn8Dhys2gspb1G0G OEl84aG77sBydd1x/fvCZQeqCzonXXZU3nRkKywSQ/bb1B3HwlegVxiRye6rJHaWUzRLuTjjv//j P69e/e4///56/sVvzYlXdCHtW8C9auoXRs6DVvq+AcxoQLGZlikNZi+iSEpc4MgSJY7zJzVQhP5f fDKXu5sTtzVlVzqVLpiRXHlWulQOR/6PMVS1E5Hlzx+fjBVFvB/y5w9txqV3Le+a/fOHOmNF7u+H /QuuOUrvN941+xdcUKgo4r2w/zTguaBZlJWsALSlr5jGmyPudn7hml9+LZ7VuPzl/PJV6RqmJBje yIri8fMpO81rNS4v0ayaW6L53YCzs7v42As0iNdQ+Km5kaGud44n3ukjbm+ygdP1NyUjVJpbOG7f x3/CY6qtSz0XBRfM2xcLCwentgZLeyaEamNHvFVZXbI0K8y4wFdF2cpEgf2ExFIHUM+Y54RjEFpe l8iBnPOhfCF1ppxyWgVuOeX2z/LdNucRpwG/yPksFurVqJ8uVD8cw/OO2YkiyvSYanuTf6wsHdAK f5OvN8+WZr3wXTDduFugRCj7oETYOJE9sVegRCj7oEQDJXr+FK7To9yUjsv1ytRTycLKm5xGsnxc fZfBZTG8pB/f1FuIJI2ZPoZkKhbVH0RkbvQWUykQBf46hnhAQl2N7/Y3Op17EikXyy8cOyXHS9AL iK8qF66xKz/Pb6szuvSjsbKsuRUHdJ+l/qvffwcnSuri2/jaG3wCDUI2pt5y75gVrqeN/KMW6ScN mOf58Ac1xJ+3gHN8lTVQOH0qz+vrzBWl8etoqI4LajhjK+dwKeEj8YLvQrkLaCO+oNBeXSyvCj0T Upcytp2Tc/7i2/nln+aX8P9X8mmSq69emp/cMkULNzXDyq7KDM56NY//A0mXH/tCmH2DyQGM5cyS cr9wNnzKbY0HKrV74KLxShObYmE1GxoSoNFqpmboUM4R4jkx2WeHOeWkffbq17+6+st3FQ6rJuWC RpihRgyXhDfusGlrLOu+MeOEd/4HAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgB Y3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAhM/BigIxDAbgu+A7lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k 3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwm DJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3Vgo XMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhAKJDqiOUAQAA6wIA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIySTY/bIBCG75X6HxB3gkncqrIcr/qhnDZVpE3VqjcE4yxa8yGYXW/66wtO4iZqDz3OzMszLy+0 d692IC8Qk/FuTcWiogSc8tq4w5p+22/YB0oSSqfl4B2s6RESvevevmlVaJSPsIs+QEQDiWSSS40K a/qIGBrOk3oEK9MiK1we9j5aibmMBx6kepIH4Muqes8toNQSJS9AFmYiPSO1mpHhOQ4TQCsOA1hw mLhYCP5HixBt+ueBaXKltAaPId/pbPeardVpOKtfk5mF4zguxtVkI/sX/Mf2/mG6KjOuZKWAdq1W DRocoNNR9sgMYM9sGBLDwMLSBtZHaWH08YlVNWHkI9lcGiQnRXbeOGTo2fZ5QBNKRba7+wdiHNlH 6VLwEclXwIJILZ/3lc0qgkQfu19qGlzK8miDTLjN79sb0J+Ok+LvbhFGeDHlV3R1y6/LzJ+CPC0B TXI0zSnIy+T76vOX/YZ2y0qsmBBM1HtRNe+qpqp+FkM350tUp4Y92/pPomjq+pZ4AXST49vv2f0G AAD//wMAUEsDBBQABgAIAAAAIQCpyFyqjAAAANoAAAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCi JAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACySbIKzi8tSk4tVghOzUlNLklN CS6pzEm1VYpxDHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2ShklJQVW+vrFyRmpuYnFevkFqXlA ubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMyknMz+9KLEgoxJqGFWMsrPRh3vGjpcL AAAA//8DAFBLAwQUAAYACAAAACEADICkjIcCAAAjCQAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbMSV vW7bMBSF9wJ9B4F7IkpR4h9EDvJTFx2SoU0fgKYpi6hICiQdxWuyd+7QPkLRAi3QxW9jIKtfoVeU 7AaxldhA21gwIF+RB1efz+E9PLoWmXfFtOFKxijYxchjkqohl6MYvb/s77SRZyyRQ5IpyWI0YQYd 9V6+OCy6iZLWeLBfmq6gMUqtzbu+b2jKBDG7KmcSHiZKC2Lhpx75gugP43yHKpETywc843bihxgf oFpGb6KikoRTdqboWDBp3X5fswwUlTQpz81CrdhErVB6mGtFmTHwziKr9AThcikTRCtCglOtjErs LryMX3Xkl1KwPcDuTmTIE7T7ZiSVJoMM2BVBhHo1OK/oSiKgeMkFM94FK7y3ShDpFuREKsMCWHNF shjhEK4DvIf3cQTfEO4i5JdKNCXaMLtciKtyQgTPJouqdrpufc4tTRf1K6J52Vi1x/ARPBibAY7R K4xxeNzvo6oSxOgUKq12FNSVEJqqPp26sresgIOgMafjlgSVDlRAp97l+vQrC60QmU+/zqc/vLtP H+8+f3E8SGYvANai8fN33jmXNFVV5+tpdYBVCLTajbTaW9FK+DUbrkeFw/uoDo5PW/2z/slDVEH4 BCoIQsch3xrVfPp9dvNzdvNrdns7u/nW4KET8BD8izWVsMFD66kINWRa1rw3N9HzkTlVY82ZLoPV gKMFxugAjNIkAKMBB15rkkYcj7hkbaD2HroE/4NAHUPOswYKpSnKoCyubQ4WU3BjtvbE83GoD5aV qKweL6+VTTltOl5KZp2/HaRHnPOMKYIBO9aTBu9Ezjv7kJ//MZTc6AjbrTox94dJNab+DCU3gmCU NQ+lp0/aejqZ3m8AAAD//wMAUEsDBBQABgAIAAAAIQAMaBnZ0QEAAJYGAAAUAAAAd29yZC93ZWJT ZXR0aW5ncy54bWzsVV1r2zAUfR/sPxi9N7K9LHFNnEJWOgZjjK77AbIsx6KSrpCUeOmv37UdN0m7 QQJ97JOk+3F07zn6WNz80SraCuclmIIkk5hEwnCopFkX5PfD3VVGIh+YqZgCIwqyE57cLD9+WLR5 K8pfIgSM9BGiGJ9rXpAmBJtT6nkjNPMTsMKgswanWcClW1PN3OPGXnHQlgVZSiXDjqZxPCN7GHcO CtS15OIW+EYLE/p86oRCRDC+kdaPaO05aC24yjrgwnvsR6sBTzNpnmGS6SsgLbkDD3WYYDN0qIh2 UJiexP1MKxJpnn9bG3CsVMhgm0zJEumr5Nbvx6jNZYXsZ3E2ncdZGvcBJVS7W7lF55Yp9BLahSN7 30Udnq0YPNrv5br5p+MB7Bh/iF5BCKBf2LGoVeW6fcIhx6DyBAP9U0HwfODEMo6d9HMOClAwtgkw FKKOqrssszyp6LJcd9z7Jam0V2LfdKfJl0aq6lSYdH4dz64/JYMuLxQ4MHrC/8H8zv7/j8s57M9n s8/ZNE2z/la8s//qxr3F2R+EWC6GcbwEZ1m7uzL+GeNzsjESPxExvAhgg9TySdyBWzlovXD9i8WU gvbnj6+4wH2OfpPlXwAAAP//AwBQSwMEFAAGAAgAAAAhAJfI0Q1MAgAAcgQAABAACAFkb2NQcm9w cy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJRLbtswEIb3BXoH QnuZ8iNpatAMAqdBFnkYsJKsWWlkE5FIghy7cZfJJgfprofoYXyRjqTYUZouino188949HP4SeL4 oSrZGnzQ1kyifi+JGJjM5tosJtFNehYfRSygMrkqrYFJtIEQHcuPH8TMWwceNQRGI0yYREtEN+Y8 ZEuoVOhR2VClsL5SSKlfcFsUOoNTm60qMMgHSXLI4QHB5JDHbj8waieO1/i/Q3Ob1f7CbbpxZFiK FCpXKgSZe1VgrAGLmJQQo4vdoHJx4VUF36y/j5NRL7f4IPj+PyK1qMpUVyCHh6TvMzFTCwjySPA2 EHfW50EO+0cjwdtYTJfKqwxpw3KYjJKB4B1FnDhX6kwhbV9e6szbYAtk182eWD1B8G6LoN3NIVt5 jRuZCN5NxYU2ZGZwMBS8DcmeVwuv3DLIw0+1yX0q5pkqYUo7koUqAwj+KohzUPX9z5Qm02KN4zVk aD0L+jsRMIjYVxWg3uwkWiuvlUHacN3WJk1cuoBebh9/bR9/bJ+et08/BaeWVm7Cbnc31iPZbxoo eNtYD2itUOGtyVRjCeG6oCPiXzz3u54bD63j1s6/MMFidsLOdpAwoprNrDYYo40vVyVqV2fscnYx Z9qw1CsTnPXIrgBrrMK74zc7pYP8YX1qK6fMRl59mRIqL0l9t/fhxqX2tIb45creih3S7jQu505l hMNweND/3GWuUxNzYhNygmg38VUQ53S/vqwfS7yaBeS7nveFmuLb9hMi+6NeQr8G251G5O3fbfkb AAD//wMAUEsBAi0AFAAGAAgAAAAhAAKFZ5eqAQAAlQYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAADj AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAmPd3xFMFAAA1OgAAHAAAAAAAAAAAAAAAAAAH BwAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQCuWn4BoVsAAIU0 BAARAAAAAAAAAAAAAAAAAJwNAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQAe/Wab KgYAACUqAAARAAAAAAAAAAAAAAAAAGxpAAB3b3JkL2NvbW1lbnRzLnhtbFBLAQItABQABgAIAAAA IQAM5HOaswYAAKwbAAAVAAAAAAAAAAAAAAAAAMVvAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEA9tH6Mg0BAACLAQAAHAAAAAAAAAAAAAAAAACrdgAAd29yZC9fcmVscy9zZXR0 aW5ncy54bWwucmVsc1BLAQItABQABgAIAAAAIQBGf9xYRgQAAMQJAAARAAAAAAAAAAAAAAAAAPJ3 AAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCDHlgXxg0AAOJuAAAaAAAAAAAAAAAA AAAAAGd8AAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQDWzhkO4QAA AFUBAAAYAAAAAAAAAAAAAAAAAGWKAABjdXN0b21YbWwvaXRlbVByb3BzMS54bWxQSwECLQAUAAYA CAAAACEAgQUhZEENAADxawAADwAAAAAAAAAAAAAAAACkiwAAd29yZC9zdHlsZXMueG1sUEsBAi0A FAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAAAAAAAAAAAAAAEpkAAGN1c3RvbVhtbC9fcmVscy9p dGVtMS54bWwucmVsc1BLAQItABQABgAIAAAAIQCiQ6ojlAEAAOsCAAARAAAAAAAAAAAAAAAAABib AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCpyFyqjAAAANoAAAATAAAAAAAAAAAA AAAAAOOdAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgAAAAhAAyApIyHAgAAIwkAABIA AAAAAAAAAAAAAAAAyJ4AAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQAMaBnZ0QEA AJYGAAAUAAAAAAAAAAAAAAAAAH+hAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAA IQCXyNENTAIAAHIEAAAQAAAAAAAAAAAAAAAAAIKjAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAR ABEAZQQAAASnAAAAAA== ------=_NextPart_000_097C_01CEE17B.4143EA40-- From agmalis@gmail.com Thu Nov 14 04:11:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7916621E80D2 for ; Thu, 14 Nov 2013 04:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2aYQ8D9bUYY for ; Thu, 14 Nov 2013 04:11:13 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E43B21E8090 for ; Thu, 14 Nov 2013 04:11:13 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id i19so2273228wiw.15 for ; Thu, 14 Nov 2013 04:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nBy8CHfPPGHLMy3xsDPliiwZLWtcl9mWUv7LdpRj16U=; b=cCpw3NVy0xl1kTE1U9Ir14qZbmSZyEWS5jmoUpRPJ2IKS3uZ5Ju9qUFv3NnoHTEPMD jSm9Lu5ti1HNjLJs7USG/pZ0wflDYtGuwwyP7y/9wEhzhZv8xWDY813dcGCPKWaPT6Sc iLTKH8jV/nzkyLwIUOd7XOQ2b467fWFxG7WSldZ9ZCPiBhL4U6rZ9pQXJ0PlSuFkIVOD zbM7jLU4iqbZPePNMJNOWiaPjmlqdzyUbik6dEatWYBVrTvLTdFzC5WqDMAwTWVV0uwL CNs39tf16HjIhlm/ESRNNxNXWqQvgzudTgoGbQ1krURgnJnKoUxuWv8UHjOv7PhGWbqk G3Zg== X-Received: by 10.195.12.52 with SMTP id en20mr1303817wjd.55.1384431072465; Thu, 14 Nov 2013 04:11:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.79.135 with HTTP; Thu, 14 Nov 2013 04:10:52 -0800 (PST) In-Reply-To: References: <52843518.6010202@pi.nu> From: "Andrew G. Malis" Date: Thu, 14 Nov 2013 07:10:52 -0500 Message-ID: To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 12:11:14 -0000 As I'm a co-author and have no last-call comments other than an update on my contact information, I'll also add my name to the list of supporters for sending the draft to the IESG for publication. My new contact information is: Andrew G. Malis Consultant Email: agmalis@gmail.com I also haven't seen an IPR call for the draft, but just for the public record, I am not aware of any IPR regarding this draft. Cheers, Andy On Thu, Nov 14, 2013 at 1:43 AM, Shane Amante wrote: > Support, (as co-author). > > -shane > > > On Nov 13, 2013, at 6:27 PM, Loa Andersson wrote: > >> Working Group, >> >> >> this is to start a 2 week working group last call on >> draft-ietf-mpls-forwarding-02. >> >> Please review the document and send comments to the >> mpls@ietf.org mailing list. >> >> There are no IPR claims against this document. >> >> However, we know that some of the author contact information for this >> document is changing; this will be updated together with the of >> the last call comments. >> >> The working group last call ends November 29 - 2013. >> >> /Loa >> >> -- >> >> >> 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 prvs=8030856f84=hshah@ciena.com Thu Nov 14 06:20:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6721E809D for ; Thu, 14 Nov 2013 06:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgApupwroHFk for ; Thu, 14 Nov 2013 06:19:57 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id E920A11E80F2 for ; Thu, 14 Nov 2013 06:19:57 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id rAEEEjTX027641; Thu, 14 Nov 2013 09:19:56 -0500 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 1g4b0u3x2r-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Nov 2013 09:19:56 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 14 Nov 2013 09:19:55 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Thu, 14 Nov 2013 09:19:54 -0500 From: "Shah, Himanshu" To: Loa Andersson , "mpls@ietf.org" Date: Thu, 14 Nov 2013 09:19:54 -0500 Thread-Topic: [mpls] wglc on draft-ietf-mpls-forwarding Thread-Index: Ac7g4TUtcCxd192ZRv+wLEHojyvTMQAY1E1A Message-ID: <40746B2300A8FC4AB04EE722A593182B6A0DF4C2@ONWVEXCHMB04.ciena.com> References: <52843518.6010202@pi.nu> In-Reply-To: <52843518.6010202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20290.007 X-TM-AS-Result: No--12.551300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_03:2013-11-13, 2013-11-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311140072 Cc: "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 14:20:02 -0000 Support. /himanshu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, November 13, 2013 9:28 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; mpls-forwarding co-authors Subject: [mpls] wglc on draft-ietf-mpls-forwarding Working Group, this is to start a 2 week working group last call on draft-ietf-mpls-forwar= ding-02. Please review the document and send comments to the mpls@ietf.org mailing l= ist. There are no IPR claims against this document. However, we know that some of the author contact information for this docum= ent is changing; this will be updated together with the of the last call co= mments. The working group last call ends November 29 - 2013. /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lberger@labn.net Thu Nov 14 08:11:23 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BC721E80B2 for ; Thu, 14 Nov 2013 08:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.951 X-Spam-Level: X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fykz49ejudNT for ; Thu, 14 Nov 2013 08:11:16 -0800 (PST) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 0796721E8056 for ; Thu, 14 Nov 2013 08:11:15 -0800 (PST) Received: (qmail 18551 invoked by uid 0); 14 Nov 2013 16:10:50 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 14 Nov 2013 16:10:50 -0000 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=PMT17pkq1M3wPljHoV/h/59JxyPA+MwMQx6cazm8vfY=; b=HBRO4GYdVlbgXzrfisQUWCWpnKwtLjMCd4XZmqgvxcNURswA1I4KWkjjPb4vxo5p6uu+WkOq1f1/ONSWrHR5WSDn4KcojVCZEDja5Gcjous6TmdpZpP/SwbpBQ3x3Ehl; Received: from box313.bluehost.com ([69.89.31.113]:45893 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1VgzVK-00036e-9D; Thu, 14 Nov 2013 09:10:50 -0700 Message-ID: <5284F610.6050807@labn.net> Date: Thu, 14 Nov 2013 11:10:56 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Zhenlong Cui , mpls@ietf.org References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> In-Reply-To: <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:11:23 -0000 Zhenlong, Thank you for the comments. Here are your comments, as extracted from word, and my responses. (Clearly the page numbers are wrong.) > Page 120: Deleted zc 11/14/2013 6:26:00 PM > , [RFC5860], > and [RFC5951] > Page 121: Comment [zc1] zc 11/14/2013 8:02:00 PM > RFC5860 and RFC5951 have not been summarized in this section. You are correct. To fix, I propose to add the following: From [RFC5860]: o The protocol solution(s) developed to perform the following OAM functions must also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point- to-multipoint LSPs: * Continuity Check * Connectivity Verification, proactive * Lock Instruct * Lock Reporting * Alarm Reporting * Client Failure Indication * Packet Loss Measurement * Packet Delay Measurement o The protocol solution(s) developed to perform the following OAM functions may also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point- to-multipoint LSPs: * Connectivity Verification, on-demand * Route Tracing * Diagnostic Tests * Remote Defect Indication From [RFC5951]: o For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is required. o For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is required. > Page 197: Inserted zc 11/14/2013 6:34:00 PM > The requirements for MPLS-TP OAM are specified in [RFC5860]. Sure. > Page 197: Comment [zc2] zc 11/14/2013 8:34:00 PM > Moved from section 2. If necessary, addition a summary of OAM requirements as other > section is much better. See response above. > Page 199: Comment [zc3] zc 11/14/2013 8:02:00 PM > Missing link [Multiple places] Links come from the html tools page, not the source XML. > Page 203: Inserted zc 11/14/2013 6:29:00 PM > OAM Packets is sent to all leaves and processed by > Page 203: Deleted zc 11/14/2013 6:29:00 PM > every OAM packet > Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM > I think that's not necessarily true. Because some on-demand OAM packets may be dropped > by intermediate node. That mean not every OAM packet is sent to leaves. > Page 203: Deleted zc 11/14/2013 6:29:00 PM > is sent to all leaves, and thus can > impact So your point is that an intermediate node may drop an OAM packet? If so, yes, this is true for P2P case too. How about: DROP (redundant statement): thus every OAM packet is sent to all leaves, s/can impact/may be processed by > Page 208: Deleted zc 11/14/2013 6:42:00 PM > addressing > Page 208: Comment [zc5] zc 11/14/2013 8:43:00 PM > We have agreed on this change. > Page 208: Inserted zc 11/14/2013 6:42:00 PM > additional Agreed. > Page 209: Deleted zc 11/14/2013 7:29:00 PM > node > Page 209: Comment [zc6] zc 11/14/2013 8:02:00 PM > In the per-interface case, additional information should be used to identify the specific > interface of the destination node. Considering the per-node and per-interface case, I think > delete “node” is much better. Sure. > Page 209: Inserted zc 11/14/2013 7:55:00 PM > It is worth noting that a MIP and MEP may be instantiated on a node when it > is both a branch and leaf node. Slightly rephrased: It is worth noting that a MIP and MEP may be instantiated on a single node when it is both a branch and leaf node.< > Page 217: Comment [zc8] zc 11/14/2013 8:02:00 PM > MPLS-TP has many OAM functions. Agreed. > I am not sure why did you mention the PM function only > in this section. I suspect that this text was added to align with the two requirements from RFC5951. I have no problem just dropping this sentence and leaving the more detailed discussion of requirements to hmk-mpls-tp-p2mp-oam-framework > Page 305: Comment [zc10] zc 11/14/2013 8:02:00 PM > Branch include intermediate node and leaf node. Are you sure you want to say that all of the > intermediate node needs to identify fault condition? > Page 305: Deleted zc 11/14/2013 6:33:00 PM > branches > Page 305: Inserted zc 11/14/2013 6:33:00 PM > leaves I don't think any specific solution guidance was intended. How about: OLD For 1:1, the source/root MPLS-TP node needs to identify the existence of a fault condition on any of the branches of the network. NEW For 1:1, the source/root MPLS-TP node needs to identify the existence of a fault condition impacting delivery to any of the leaves. > Page 307: Deleted zc 11/14/2013 7:24:00 PM > and > Page 307: Inserted zc 11/14/2013 7:24:00 PM > or > Page 307: Comment [zc11] zc 11/14/2013 8:02:00 PM > It is correct? How about: s/and/and, perhaps, I think that's it. Thank you again for your comments. Lou On 11/14/2013 6:51 AM, Zhenlong Cui wrote: > Lou, > > I agree your opinion. > > I looked through the draft, there are few comments as an attached file. > I hope you will find it informative before you post a new version of the draft. > > Best reagrds, > zhenlong > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Saturday, November 09, 2013 6:04 AM >> To: Zhenlong Cui; mpls@ietf.org >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework >> >> >> Zhenlong, >> >> I understand you have an additional concern regarding supporting a MIP and MEP in a node that is both a branch and leaf >> node. I think this is supported, where MIPs are associated with the P2MP branch data plane function and MEPs are associated >> with the leaf data plane function. >> This holds for both for both per-node and per-interface MIPs. I certainly agree that it is reasonable for there to be >> a more in depth discussion on this topic, and suggest that such a discussion be added to draft-hmk-mpls-tp-p2mp-oam-framework. >> >> If you'd like, we can something like the following to our draft: >> >> It is worth noting that a MIP and MEP may be instantiated on a node >> when it is both a branch and leaf node. >> >> Please let us know if you still have concerns on our document. >> >> Thank you, >> Lou >> >> On 11/5/2013 11:05 AM, Lou Berger wrote: >>> Zhenlong, >>> >>> Perhaps the issue is in the slightly different language used in the >>> draft versus the section 3.7 of rfc6371. RFC6371 says: >>> >>> o To send an OAM packet to a single MIP, ... The OAM packet must >>> contain sufficient information to identify the target MIP and >>> therefore is processed only by the target MIP and can be silently >>> discarded by the others. >>> >>> To better align with this text, the draft should be revised to replace >>> "addressing information" with "additional information" >>> >>> Will this address your comment? If not, do you have some text/changes >>> in mind that would? >>> >>> Much thanks, >>> Lou >>> >>> On 11/4/2013 12:56 AM, Zhenlong Cui wrote: >>>> Hi Lou, >>>> >>>> Thank you for your reply. >>>> >>>> I was relieved to know that you already considered the case that both MEP and MIP functionality are configured on >> a transit node. >>>> >>>> However, I think that this draft need further explanation for the OAM behavior on transit nodes. >>>> >>>> The P2MP OAM behaviors are described in section 4. >>>> All the traffic sent over a P2MP transport path, including OAM >>>> packets generated by a MEP, is sent (multicast) from the root to all >>>> the leaves, thus every OAM packet is sent to all leaves, and thus can >>>> impact all the MEs in a P2MP MEG. If an OAM packet is to be >>>> processed by only a specific leaf, it requires information to >>>> indicate to all other leaves that the packet must be discarded. To >>>> address a packet to an intermediate node in the tree, TTL based >>>> addressing is used to set the radius and addressing information in >>>> the OAM payload is used to identify the specific destination node. >>>> >>>> >>>> My comments: >>>> >>>> 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. >>>> The case of per-interface should also be described, if you like to mention about the per-node case in this draft. >>>> >>>> 2)May need further explanation for the OAM behavior in case that both MEP and MIP functionality are configured on >> a transit node. >>>> e.g.) >>>> When a transit node receive a OAM packet, the transit node has to determine whether the OAM packets should be processed >> by a MIP functionality, before it identifies the addressing information. >>>> Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. >>>> >>>> >>>> Best reagrds, >>>> zhenlong >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Monday, November 04, 2013 1:17 PM >>>>> To: Zhenlong Cui; mpls@ietf.org >>>>> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >>>>> Subject: Re: [mpls] working group last call on >>>>> draft-ietf-mpls-tp-p2mp-framework >>>>> >>>>> Zhenlong, >>>>> Thank you for the comments. Please see below for responses in-line. >>>>> >>>>> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: >>>>>> Dear authors, >>>>>> >>>>>> I have a comment/question on this draft. >>>>>> >>>>>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. >>>>>> In this case, the drop-and-continue node will become an intermediate point. >>>>> >>>>> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. >>>>> >>>>>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? >>>>> >>>>> I think this is a matter of semantics. By definition a MEP is only on egress (leaf) nodes and a MIP only on transit >> nodes. >>>>> Assuming you are asking about the case stated in the previous point, >>>>> that a node is both egress and transit, then I think it could have both MEP and MIP functionality separately instantiated. >> Section 3.7 already covers P2MP MIPs and MEPs. >>>>> >>>>>> As described in section 3.3 of RFC 6371, a MEP terminates all the >>>>>> OAM packets it receives from the MEG, may discards silently if >>>>>> addressing information in the OAM payload is different with >>>>> termination node. >>>>>> It means that the intermediate node must NOT be configured as a MEP >>>>>> when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. >>>>> >>>>> Why do you say this? If a node is both transit and egress, it will >>>>> replicate OAM packets (just like the data) when performing its transit role before then terminating the data/OAM packets >> as part of its egress role. >>>>> >>>>>> >>>>>> On the other hand, if the intermediate node can't be configured as >>>>>> a MEP, the path protection may not be able to work at this point. I think this is a serious problem. >>>>>> >>>>> >>>>> Perhaps I'm missing something, but I simply don't see an issue here >>>>> that isn't already addressed in RFC6371 (and 4875.) I guess 6371 >>>>> could have shown this case as an example, or provided a related detailed walk through, but either way I don't see >> any "serious problem" here. >>>>> >>>>> Perhaps the best way to proceed on this is to propose text to the >>>>> already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>>> Best regards, >>>>>> zhenlong >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>> Behalf Of Loa Andersson >>>>>>> Sent: Friday, October 18, 2013 1:29 PM >>>>>>> To: mpls@ietf.org >>>>>>> Cc: mpls-chairs@tools.ietf.org; >>>>>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >>>>>>> Subject: [mpls] working group last call on >>>>>>> draft-ietf-mpls-tp-p2mp-framework >>>>>>> >>>>>>> Working Group, >>>>>>> >>>>>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. >>>>>>> >>>>>>> Please send your comment to working group mailing lists (mpls@ietf.org). >>>>>>> >>>>>>> We did an IPR poll on this document prior to starting the wglc. >>>>>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. >>>>>>> >>>>>>> There are no IPRs disclosed against this document. >>>>>>> >>>>>>> The working group last call will end Friday November 1, 2913. >>>>>>> >>>>>>> /Loa >>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> From loa@pi.nu Thu Nov 14 12:57:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98611E810D for ; Thu, 14 Nov 2013 12:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynA3g8caq41o for ; Thu, 14 Nov 2013 12:57:27 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC911E80FA for ; Thu, 14 Nov 2013 12:57:27 -0800 (PST) Received: from [192.168.252.96] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D8DC31802039; Thu, 14 Nov 2013 21:57:24 +0100 (CET) Message-ID: <52853934.7020905@pi.nu> Date: Thu, 14 Nov 2013 12:57:24 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Dutta, Pranjal K (Pranjal)" , Lizhong Jin , "vishwas.manral@hp.com" , Curtis Villamizar , "draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "mpls@ietf.org" References: <526DDCFE.6060403@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 20:57:32 -0000 Folks, We now have three (of four) MPLS-RT reviews. This is the point where we normally ask the authors to update the draft. Authors, Please do so for this draft also, but when it comes the overlap that the reviewers (as many others) have noticed, please do the necessary technical updates, but leave it in place for the time being. When you have addressed the comments, verify with the reviewers that they are comfortable with how their comments has been addressed. Reviewers, Please try to respond to the authors on how they propose to address your comments in a timely manner. /Loa for the mpls wg co-chairs On 2013-11-12 11:57, Dutta, Pranjal K (Pranjal) wrote: > Hi All, > I have reviewed the following version of the draft from MP-RT perspective and following are my inputs. > > http://tools.ietf.org/html/draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01 > > 1. The draft specifies procedures for > 1.1 Mapping PIM ASM trees to MP-LSP > and, > 1.2 Mapping multiple IP multicast trees into a single MP-LSP. > > There is another draft in progress on item 1.1 that overlaps with the solution in this draft. > > http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-07 > > I would suggest to merge the solutions for 1.1 from both the documents to adopt a single/unified approach. A key issue we have been seeing off late is fragmentation - where solutions with same intent are fragmented across multiple documents. This leads to lack of clarity for implementations and subsequently opens inter-op worms. For e.g PIM BI-DIR mapping was addressed > in RFC 6826 but didn't address PIM ASM/unidirectional mapping in that doc. > > I can see the need to address item 1.2 in this draft. This is certainly useful to reduce control + forwarding states since RFC 6826 makes us reach data path scaling limits in core with 1:1 mapping to MP-LSP. This is more an issue in vpn-in-band mapping wherein every VPN multicast tree is pushing one MP-LSP into core. So I would like to see a solution for aggregation of VPN in-band multicast trees over MP-LSP. > > 2. Using wildcard encoding for shared/ASM tree signaling is a paradigm shift from previous in-band encodings defined in RFC 6826 and vpn-in-band signaling. This draft avoids defining new MP opaque element types and re-uses/overloads existing in-band opaque elements by introducing the notion of "wildcard" (zero values) in S and/or G. > > Section 3 states as follows: > > > "if the IP Source Address sub-field contains the wildcard, and the IP > Group Address sub-field contains an IP multicast group address, say > G, that is NOT in the SSM address range (see Section 4.8 of > [RFC4601]), the TLV identifies a PIM-SM shared tree." > > If the IP Source Address sub-field contains the wildcard, and the IP > Group Address sub-field contains an IP multicast group address, say > G, that is in the SSM address range, the TLV identifies the > collection of PIM-SSM trees with the given group address. > > If the IP Source Address sub-field contains a non-zero IP address, > and the IP Group Address sub-field contains the wildcard, the TLV > identifies the collection of PIM-SSM trees that have the source > address as their root." > > > Adding newer interpretation to Group Address sub-field opens up backward > compatibility issues with existing implementations of RFC 6826. The > defined Transit IPV4/IPV6 Source TLVs in RFC 6826 are explicitly > for "SSM" - the contract between PIM and mLdp had been locked for that > purpose in Root LSR. > > For e.g it is possible that in an existing RFC 6826 implementation - PIM > at mLdp root LSR may be rejecting (or handling as no-op) Transit > IPv4/IPV6 Source TLV mapping if its opaque element is received with > non-SSM Range in Group Address. > > On a similar note in Aggregation of multiple SSM trees with wildcard > source address in Transit IPV4/IPV6 Source TLV - it is possible that > PIM at mLdp root LSR in RFC 6826 may be handling source address 0.0.0.0 > as no-op (do nothing) or at best ending up as RPF lookup failure. > > 3. Section "4.1 PIM Shared Tree Forwarding" states below: > > > > "To efficiently use mLDP in-band signaling in this scenario, it is > necessary for the Egress LSRs to construct an Opaque Value TLV that > identifies a (*, G) tree. This is done by using the wildcard in the > IP Source Address sub-field, and setting the IP Group Address sub- > field to G." > > > > Let's say the Group is selected from non SSM range (ASM) and source > is wildcard here. No RP is explicitly encoded/specified in the opaque > element in Transit IPV4/IPV6 Source TLV, then does that means that > mLdp root is always the RP? What happens if RP is not co-located with > mLdp Root LSR? If so then this solution is not generic and has imposed > a limitation for collocation of RP and mLdp root for various PIM ASM > applications. > > A generic solution would be to encode an explicit RP in opaque value > element. Such approach would satisfy both cases - whether RP is > collocated with mLdp root LSR or is disjoint. The encoding of Transit > IPV4/V6 Shared Tree TLV defined in draft-rekhter-mpls-pim-sm-over-mldp > for same purpose carries an explicit RP. > > Section "4.2 IGP/MLD proxying" is the case where it is possible that > mLdp root node and RP are collocated in same node, since multicast > senders and receivers are directly connected to MPLS domain. > > It's not clear from overall Section 4 on how the draft addresses RP > and mLdp Root LSR being disjoint. > > 4. In section "5/ Procedures for Wildcard Source Usage" > > > > "The IP multicast component on an Egress LSR determines when a > wildcard is to be used in the IP Source Address sub-field of an mLDP > Opaque Value TLV. How the IP multicast component determines this is > a local matter, and may need to be explicitly configured. It MAY > however use the following rules (with or without explicit > configuration); > > 1. Suppose that PIM is enabled, and an Egress LSR needs to join a > non-bidirectional ASM group G, and the RP for G is reachable via > a BGP route. The Egress LSR MAY choose the BGP Next Hop of the > route to the RP to be the Ingress LSR (root node) of the MP-LSP > corresponding to the (*,G) tree. (See also Section 7.) The > Egress LSR MAY identify the (*,G) tree by using an mLDP Opaque > Value TLV whose IP Source Address sub-field contains a wildcard, > and whose IP Group Address sub-field contains G." > > > > By reading this section the draft seems to re-assert that RP for (*, G) tree is collocated to mLdp Root Node. There would be newer applications to be defined in future where RP and mLdp Root functionality need not be collocated. > > 5. "Section 7. Determining the MP-LSP Root (Ingress LSR)" > > > > "Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] > describe procedures by which an Egress LSR may determine the MP-LSP > root node address corresponding to a given IP multicast stream, based > upon the IP address of the source of the IP multicast stream. When a > wildcard source encoding is used, PIM is enabled, and the group is a > non-bidirectional ASM group, a similar procedure is applied. The > only difference from the above mentioned procedures is that the Proxy > device or RP address is used instead of the Source to discover the > mLDP root node address. > > In all other cases some sort of manual configuration is applied in > order to find the root node. Note, finding the root node is a local > implementation matter and not limited to the solutions mentioned in > this document." > > > This section seems to imply that MP-LSP root and RP may be disjoint > nodes when wildcard source encoding is used for non-bidirectional > ASM Group. If so then it is required for MP-LSP root node to hand off > the (*,G) to local PIM and further progress (*, G) join upstream in > PIM domain towards the RP. Overloading existing Transit IPV4/IPV6 Source > TLVs with wildcard source won't work. > > > Summary: > > 1. Is it likely to be actually useful in operational > Networks? > > - Yes. The solutions are desirable. > > 2. Is the document technically sound? > > - Concerned with Wildcard Encoding for PIM-ASM. By reading the draft it > does not look like encoding is generic + may lead to backward > compatibility issues with RFC 6826. This item has overlap with > draft-rekhter-mpls-pim-sm-over-mldp-07 and single approach should be > adopted by WG. IMO, the encoding defined in draft-rekhter is more > generic + no backward compatibility issues. > > - Aggregation of SSM trees with wildcard encoding may lead to backward > Compatibility issues with RFC 6826. > > A better approach is to define new MP Opaque Value elements exclusively > for mapping PIM-ASM and Aggregate SSM(in similar lines with RFC 6826 and > in-band-vpn draft). > > Note that we have mapped PIM BI-DIR explicitly to Transit IPV4/IPV6 > Bi-Dir TLVs in RFC 6826. > > > Thanks, > Pranjal > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Sunday, October 27, 2013 8:42 PM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.manral@hp.com; Curtis Villamizar; draft-wijnands-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > Subject: MPLS-RT review of draft-wijnands-mpls-mldp-in-band-wildcard-encoding > > Lizhong, Pranjal, Vishwas and Curtis, > > You have been selected as an MPLS Review team reviewers for > draft-wijnands-mpls-mldp-in-band-wildcard-encoding-01. > > 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 > secretary, and CC'd to the MPLS WG email list. If necessary, comments > may be sent privately to only the WG chairs. > > Are you able to review this draft by November 11, 2013? > > > Thanks, Loa > (as MPLS WG chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobo@cisco.com Thu Nov 14 16:06:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5718F11E8165 for ; Thu, 14 Nov 2013 16:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiffX6b7fkD2 for ; Thu, 14 Nov 2013 16:06:34 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5121B11E814D for ; Thu, 14 Nov 2013 16:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4177; q=dns/txt; s=iport; t=1384473994; x=1385683594; h=from:to:cc:subject:date:message-id:mime-version; bh=zhPB6BcUHGXET/kfpeT6GQushHfov/a4E3fZtp+YAXY=; b=izEpPX7sce+N9EXRWrdxRRewADwZB2JVi6q/p4zqyvXbjl+4079ClQLI n89nn4tPVTGbLJ//PrFEYPc01+JEk6u2Dpjdp0j45OLam1kw8Zish/3vT mhgeAOhh/nyoewi9ONOzZAk/va5knK0mh9CjWZ7JuaHOSJSWGmqDOOkbc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGAPlkhVKtJXG9/2dsb2JhbABagkMjIThTtlmIRYEgFnSCJwEELUwSAQweViYBBAENDYd5AQzAdY8uMYMngREDmT+JJIc5gyiCKg X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208,217";a="284991308" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 15 Nov 2013 00:06:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAF06SrH010222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 00:06:28 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.0123.003; Thu, 14 Nov 2013 18:06:28 -0600 From: "Nobo Akiya (nobo)" To: "kireeti@juniper.net" , "George Swallow (swallow)" , Nitin Bahadur Thread-Topic: LSP Ping DS Flags and Multipath Info Types Thread-Index: Ac7hlUCbc7xBFLF4QUya0kvMF4LXlQ== Date: Fri, 15 Nov 2013 00:06:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.64] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DEE5FF0xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] LSP Ping DS Flags and Multipath Info Types X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 00:06:44 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE5FF0xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kireeti, George, Nitin, I'm reaching out to authors of RFC4379/RFC6424 as part of follow up to comm= ents received for LSP ping for entropy label draft. http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-00 Authors would like to extend DS Flags (add 2 flags) and extend Multipath In= formation Type (add 1 new type). However, IANA does not maintain DS Flags nor Multipath Information Type, an= d wanted to check on background/thoughts with original authors of the LSP p= ing mechanism. Should DS Flags and Multipath Information Types be maintained by IANA? Thank you. -Nobo --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE5FF0xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kireeti, George, Nitin,

 

I’m reaching out to authors of RFC4379/RFC6424= as part of follow up to comments received for LSP ping for entropy label d= raft.

 

http://tools.ietf.org/html/draft-akiya-mpls-entropy= -lsp-ping-00

 

Authors would like to extend DS Flags (add 2 flags) = and extend Multipath Information Type (add 1 new type).

 

However, IANA does not maintain DS Flags nor Multipa= th Information Type, and wanted to check on background/thoughts with origin= al authors of the LSP ping mechanism.

 

Should DS Flags and Multipath Information Types be m= aintained by IANA?

 

Thank you.

 

-Nobo

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DEE5FF0xmbalnx01ciscoc_-- From internet-drafts@ietf.org Thu Nov 14 17:33:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B421E8117; Thu, 14 Nov 2013 17:33:48 -0800 (PST) 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=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk75B8X0a6kq; Thu, 14 Nov 2013 17:33:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B9621E80F2; Thu, 14 Nov 2013 17:33:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131115013348.16529.64443.idtracker@ietfa.amsl.com> Date: Thu, 14 Nov 2013 17:33:48 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 01:33:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Forwarding Compliance and Performance Requirements Author(s) : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-03.txt Pages : 52 Date : 2013-11-14 Abstract: This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-forwarding-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From c-sai@bx.jp.nec.com Thu Nov 14 18:42:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02E11E8176 for ; Thu, 14 Nov 2013 18:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc4ISnJnQGv6 for ; Thu, 14 Nov 2013 18:42:31 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 368A711E8170 for ; Thu, 14 Nov 2013 18:42:28 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAF2gQPi021042; Fri, 15 Nov 2013 11:42:26 +0900 (JST) Received: from mailsv.nec.co.jp (imss63.nec.co.jp [10.7.69.158]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id rAF2gQh13019; Fri, 15 Nov 2013 11:42:26 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAF2gPTW001434; Fri, 15 Nov 2013 11:42:25 +0900 (JST) Received: from kaishu.jp.nec.com ([10.26.220.5] [10.26.220.5]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-645312; Fri, 15 Nov 2013 11:41:50 +0900 Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Fri, 15 Nov 2013 11:41:50 +0900 From: "Zhenlong Cui" To: "'Lou Berger'" , References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> In-Reply-To: <5284F610.6050807@labn.net> Date: Fri, 15 Nov 2013 11:41:49 +0900 Message-ID: <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq0BaI8zcAJ+CQwLArAVKgkDj+8ESQHLim8TmAI2cfA= Content-Language: ja Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 02:42:35 -0000 Loa, Thank you for your reply. Please see below for responses in-line. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, November 15, 2013 1:11 AM > To: Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework > > Zhenlong, > > Thank you for the comments. > > Here are your comments, as extracted from word, and my responses. > (Clearly the page numbers are wrong.) > > > Page 120: Deleted zc 11/14/2013 6:26:00 PM , [RFC5860], and [RFC5951] > > Page 121: Comment [zc1] zc 11/14/2013 8:02:00 PM > > RFC5860 and RFC5951 have not been summarized in this section. > > You are correct. To fix, I propose to add the following: > > From [RFC5860]: > > o The protocol solution(s) developed to perform the following OAM > functions must also apply to point-to-point associated > bidirectional LSPs, point-to-point unidirectional LSPs, and point- > to-multipoint LSPs: > > * Continuity Check > > * Connectivity Verification, proactive > > * Lock Instruct > > * Lock Reporting > > * Alarm Reporting > > * Client Failure Indication > > * Packet Loss Measurement > > * Packet Delay Measurement > > o The protocol solution(s) developed to perform the following OAM > functions may also apply to point-to-point associated > bidirectional LSPs, point-to-point unidirectional LSPs, and point- > to-multipoint LSPs: > > * Connectivity Verification, on-demand > > * Route Tracing > > * Diagnostic Tests > > * Remote Defect Indication > > From [RFC5951]: > > o For unidirectional (P2P and point-to-multipoint (P2MP)) > connection, proactive measurement of packet loss and loss ratio is > required. > > o For a unidirectional (P2P and P2MP) connection, on-demand > measurement of delay measurement is required. Agree. > > > > Page 197: Inserted zc 11/14/2013 6:34:00 PM The requirements for > > MPLS-TP OAM are specified in [RFC5860]. > Sure. > > > Page 197: Comment [zc2] zc 11/14/2013 8:34:00 PM Moved from section 2. > > If necessary, addition a summary of OAM > requirements as other > > section is much better. > See response above. Agree. > > > Page 199: Comment [zc3] zc 11/14/2013 8:02:00 PM Missing link > > [Multiple places] > Links come from the html tools page, not the source XML. Ok, I understand. > > > Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to all > > leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00 PM > > every OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM I > > think that's not necessarily true. Because some on-demand OAM > packets may be dropped > > by intermediate node. That mean not every OAM packet is sent to leaves. > > Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, and > > thus can impact > > So your point is that an intermediate node may drop an OAM packet? If so, yes, this is true for P2P case too. > > How about: > DROP (redundant statement): > thus every OAM packet is sent to all leaves, s/can impact/may be processed by My primary concern: I think there is a discrepancy between "every OAM packet is sent to all leaves" and "To address a packet to an intermediate node in the tree, TTL based ..." My understanding: "every OAM packet is sent to all leaves" is equal to "no OAM packet is sent to branches". On the other hand, "To address a packet to an intermediate node in the tree, TTL based ...", it seems meaning that "the root may send OAM packet to branches". Is my understanding correct? > > > Page 208: Deleted zc 11/14/2013 6:42:00 PM addressing Page 208: > > Comment [zc5] zc 11/14/2013 8:43:00 PM We have agreed on this change. > > Page 208: Inserted zc 11/14/2013 6:42:00 PM additional > Agreed. > > > Page 209: Deleted zc 11/14/2013 7:29:00 PM node Page 209: Comment > > [zc6] zc 11/14/2013 8:02:00 PM In the per-interface case, additional > > information should be used to > identify the specific > > interface of the destination node. Considering the per-node and > per-interface case, I think > > delete "node" is much better. > Sure. > > > Page 209: Inserted zc 11/14/2013 7:55:00 PM It is worth noting that a > > MIP and MEP may be instantiated on a node > when it > > is both a branch and leaf node. > Slightly rephrased: > It is worth > noting that a MIP and MEP may be instantiated on a single node > when it is both a branch and leaf node.< No problem. > > > Page 217: Comment [zc8] zc 11/14/2013 8:02:00 PM MPLS-TP has many OAM > > functions. > Agreed. > > > I am not sure why did you mention the PM function only in this > > section. > > I suspect that this text was added to align with the two requirements from RFC5951. > > I have no problem just dropping this sentence and leaving the more detailed discussion of requirements to > hmk-mpls-tp-p2mp-oam-framework I agree with your opinion that dropping this sentence and leaving the more detailed discussion of requirements to hmk-mpls-tp-p2mp-oam-framework. > > > Page 305: Comment [zc10] zc 11/14/2013 8:02:00 PM Branch include > > intermediate node and leaf node. Are you sure you want > to say that all of the > > intermediate node needs to identify fault condition? > > Page 305: Deleted zc 11/14/2013 6:33:00 PM branches Page 305: Inserted > > zc 11/14/2013 6:33:00 PM leaves > > I don't think any specific solution guidance was intended. How about: > OLD > For 1:1, the source/root MPLS-TP node needs to identify the > existence of a fault condition on any of the branches of the > network. > NEW > For 1:1, the source/root MPLS-TP node needs to identify the > existence of a fault condition impacting delivery to any of > the leaves. Agree. > > > Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted zc > > 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013 > > 8:02:00 PM It is correct? > How about: > s/and/and, perhaps, s/and/and? Is this a mistake? My propose is s/and/or. Best regards, zhenlong > > I think that's it. > > Thank you again for your comments. > > Lou > > On 11/14/2013 6:51 AM, Zhenlong Cui wrote: > > Lou, > > > > I agree your opinion. > > > > I looked through the draft, there are few comments as an attached file. > > I hope you will find it informative before you post a new version of the draft. > > > > Best reagrds, > > zhenlong > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Saturday, November 09, 2013 6:04 AM > >> To: Zhenlong Cui; mpls@ietf.org > >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-p2mp-framework > >> > >> > >> Zhenlong, > >> > >> I understand you have an additional concern regarding supporting a > >> MIP and MEP in a node that is both a branch and leaf node. I think > >> this is supported, where MIPs are associated with the P2MP branch data plane function and MEPs are associated with > the leaf data plane function. > >> This holds for both for both per-node and per-interface MIPs. I > >> certainly agree that it is reasonable for there to be a more in depth discussion on this topic, and suggest that such > a discussion be added to draft-hmk-mpls-tp-p2mp-oam-framework. > >> > >> If you'd like, we can something like the following to our draft: > >> > >> It is worth noting that a MIP and MEP may be instantiated on a node > >> when it is both a branch and leaf node. > >> > >> Please let us know if you still have concerns on our document. > >> > >> Thank you, > >> Lou > >> > >> On 11/5/2013 11:05 AM, Lou Berger wrote: > >>> Zhenlong, > >>> > >>> Perhaps the issue is in the slightly different language used in the > >>> draft versus the section 3.7 of rfc6371. RFC6371 says: > >>> > >>> o To send an OAM packet to a single MIP, ... The OAM packet must > >>> contain sufficient information to identify the target MIP and > >>> therefore is processed only by the target MIP and can be silently > >>> discarded by the others. > >>> > >>> To better align with this text, the draft should be revised to > >>> replace "addressing information" with "additional information" > >>> > >>> Will this address your comment? If not, do you have some > >>> text/changes in mind that would? > >>> > >>> Much thanks, > >>> Lou > >>> > >>> On 11/4/2013 12:56 AM, Zhenlong Cui wrote: > >>>> Hi Lou, > >>>> > >>>> Thank you for your reply. > >>>> > >>>> I was relieved to know that you already considered the case that > >>>> both MEP and MIP functionality are configured on > >> a transit node. > >>>> > >>>> However, I think that this draft need further explanation for the OAM behavior on transit nodes. > >>>> > >>>> The P2MP OAM behaviors are described in section 4. > >>>> All the traffic sent over a P2MP transport path, including OAM > >>>> packets generated by a MEP, is sent (multicast) from the root to all > >>>> the leaves, thus every OAM packet is sent to all leaves, and thus can > >>>> impact all the MEs in a P2MP MEG. If an OAM packet is to be > >>>> processed by only a specific leaf, it requires information to > >>>> indicate to all other leaves that the packet must be discarded. To > >>>> address a packet to an intermediate node in the tree, TTL based > >>>> addressing is used to set the radius and addressing information in > >>>> the OAM payload is used to identify the specific destination node. > >>>> > >>>> > >>>> My comments: > >>>> > >>>> 1)As defined in RFC 6426, the IF_Num is used to identify the specific destination node and interface. > >>>> The case of per-interface should also be described, if you like to mention about the per-node case in this draft. > >>>> > >>>> 2)May need further explanation for the OAM behavior in case that > >>>> both MEP and MIP functionality are configured on > >> a transit node. > >>>> e.g.) > >>>> When a transit node receive a OAM packet, the transit node has > >>>> to determine whether the OAM packets should be processed > >> by a MIP functionality, before it identifies the addressing information. > >>>> Because MIP functionality is usually implemented by software. This behavior will be help to block the DDOS attack. > >>>> > >>>> > >>>> Best reagrds, > >>>> zhenlong > >>>> > >>>>> -----Original Message----- > >>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>> Sent: Monday, November 04, 2013 1:17 PM > >>>>> To: Zhenlong Cui; mpls@ietf.org > >>>>> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>>>> Subject: Re: [mpls] working group last call on > >>>>> draft-ietf-mpls-tp-p2mp-framework > >>>>> > >>>>> Zhenlong, > >>>>> Thank you for the comments. Please see below for responses in-line. > >>>>> > >>>>> On 10/22/2013 2:18 AM, Zhenlong Cui wrote: > >>>>>> Dear authors, > >>>>>> > >>>>>> I have a comment/question on this draft. > >>>>>> > >>>>>> As described in section 1.3, in the ring topology, we have to consider the drop-and-continue node case. > >>>>>> In this case, the drop-and-continue node will become an intermediate point. > >>>>> > >>>>> Agreed. This node will be both a transit node and an egress/leaf. This case is covered in RFC4875. > >>>>> > >>>>>> So, can we configure a MEP on an intermediate node(= drop-and-continue node)? > >>>>> > >>>>> I think this is a matter of semantics. By definition a MEP is > >>>>> only on egress (leaf) nodes and a MIP only on transit > >> nodes. > >>>>> Assuming you are asking about the case stated in the previous > >>>>> point, that a node is both egress and transit, then I think it could have both MEP and MIP functionality separately > instantiated. > >> Section 3.7 already covers P2MP MIPs and MEPs. > >>>>> > >>>>>> As described in section 3.3 of RFC 6371, a MEP terminates all the > >>>>>> OAM packets it receives from the MEG, may discards silently if > >>>>>> addressing information in the OAM payload is different with > >>>>> termination node. > >>>>>> It means that the intermediate node must NOT be configured as a > >>>>>> MEP when per-node OAM configuration is used, because downstream nodes can't receive the OAM packets from root node. > >>>>> > >>>>> Why do you say this? If a node is both transit and egress, it > >>>>> will replicate OAM packets (just like the data) when performing > >>>>> its transit role before then terminating the data/OAM packets > >> as part of its egress role. > >>>>> > >>>>>> > >>>>>> On the other hand, if the intermediate node can't be configured > >>>>>> as a MEP, the path protection may not be able to work at this point. I think this is a serious problem. > >>>>>> > >>>>> > >>>>> Perhaps I'm missing something, but I simply don't see an issue > >>>>> here that isn't already addressed in RFC6371 (and 4875.) I guess > >>>>> 6371 could have shown this case as an example, or provided a > >>>>> related detailed walk through, but either way I don't see > >> any "serious problem" here. > >>>>> > >>>>> Perhaps the best way to proceed on this is to propose text to the > >>>>> already referenced "additional detail" draft draft-hmk-mpls-tp-p2mp-oam-framework. Does this work for you? > >>>>> > >>>>> Thanks, > >>>>> Lou > >>>>> > >>>>>> Best regards, > >>>>>> zhenlong > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>>>>> Behalf Of Loa Andersson > >>>>>>> Sent: Friday, October 18, 2013 1:29 PM > >>>>>>> To: mpls@ietf.org > >>>>>>> Cc: mpls-chairs@tools.ietf.org; > >>>>>>> draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >>>>>>> Subject: [mpls] working group last call on > >>>>>>> draft-ietf-mpls-tp-p2mp-framework > >>>>>>> > >>>>>>> Working Group, > >>>>>>> > >>>>>>> this is to start a two week working group last call on draft-ietf-mpls-tp-p2mp-framework-04. > >>>>>>> > >>>>>>> Please send your comment to working group mailing lists (mpls@ietf.org). > >>>>>>> > >>>>>>> We did an IPR poll on this document prior to starting the wglc. > >>>>>>> The each authors responded to the IPR poll that they not aware of any IPR's relating to this document. > >>>>>>> > >>>>>>> There are no IPRs disclosed against this document. > >>>>>>> > >>>>>>> The working group last call will end Friday November 1, 2913. > >>>>>>> > >>>>>>> /Loa > >>>>>>> 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 > >>>>>>> _______________________________________________ > >>>>>>> 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 lberger@labn.net Fri Nov 15 07:39:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0411E8171 for ; Fri, 15 Nov 2013 07:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwQT3ZgClu07 for ; Fri, 15 Nov 2013 07:39:23 -0800 (PST) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 1AFB111E81A9 for ; Fri, 15 Nov 2013 07:37:09 -0800 (PST) Received: (qmail 10789 invoked by uid 0); 15 Nov 2013 15:37:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 15 Nov 2013 15:37:00 -0000 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=RsQJwjZ1j7t3X2MDK4EIgR1evlEAMwedX6xBg4RG+vE=; b=z/wNWnAV1isvVTnQrELKD8zDpYeDvrc5q/6otM6dDQbBCnZayrsSKizTy5VpZBaoMMlNsmJu0Md+QVv2bOqZ13pl0t+KMs42Kj/OHhABsjMKZ9KHBji6KqxCi86rktL8; Received: from box313.bluehost.com ([69.89.31.113]:37419 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1VhLS7-0007yo-Ti; Fri, 15 Nov 2013 08:37:00 -0700 Message-ID: <52863FA2.1070604@labn.net> Date: Fri, 15 Nov 2013 10:37:06 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Zhenlong Cui , mpls@ietf.org References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> In-Reply-To: <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> X-Enigmail-Version: 1.6 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} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:39:28 -0000 Zhenlong, See below. I've cut topics with resolutions/agreements. On 11/14/2013 9:41 PM, Zhenlong Cui wrote: > Loa, > > Thank you for your reply. Please see below for responses in-line. > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, November 15, 2013 1:11 AM >> To: Zhenlong Cui; mpls@ietf.org >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework >> >> Zhenlong, >> >> Thank you for the comments. >> >> Here are your comments, as extracted from word, and my responses. >> (Clearly the page numbers are wrong.) >> [...] >> >>> Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to all >>> leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00 PM >>> every OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM I >>> think that's not necessarily true. Because some on-demand OAM >> packets may be dropped >>> by intermediate node. That mean not every OAM packet is sent to leaves. >>> Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, and >>> thus can impact >> >> So your point is that an intermediate node may drop an OAM packet? If so, yes, this is true for P2P case too. >> >> How about: >> DROP (redundant statement): >> thus every OAM packet is sent to all leaves, s/can impact/may be processed by > > My primary concern: > I think there is a discrepancy between "every OAM packet is sent to > all leaves" and "To address a packet to an intermediate node in the > tree, TTL based ..." > > My understanding: > "every OAM packet is sent to all leaves" is equal to "no OAM packet is sent to branches". > On the other hand, "To address a packet to an intermediate node in the tree, TTL based ...", it seems meaning that "the root may send OAM packet to branches". > > Is my understanding correct? > Okay, I understand your point. I think your reading / the text does not match our intent. (Which is certainly to allow for both MIP and MEP processing.) How about: s/to all leaves/towards all leaves Which will result in: All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root towards all the leaves, and thus may be processed by all the MEs in a P2MP MEG. [...] > >> >>> Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted zc >>> 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013 >>> 8:02:00 PM It is correct? >> How about: >> s/and/and, perhaps, > > s/and/and? Is this a mistake? > My propose is s/and/or. > > Sorry for not being clear. I was proposing the following final text: Fault notification happens from the node identifying the fault to the root node and, perhaps, from the leaves to the root via an out of band path. Now rereading the sentence I think I'd prefer just dropping the reference to leaves as it really doesn't add anything. How about: Fault notification happens from the node identifying the fault to the root node via an out of band path. And also dropping "In either case" immediately following to align the next sentence. That's it. Thank you again for your comments. Lou > Best regards, > zhenlong > [...] From gregory.mirsky@ericsson.com Fri Nov 15 13:25:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75B21F9F03 for ; Fri, 15 Nov 2013 13:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+55PsbXEzAD for ; Fri, 15 Nov 2013 13:25:26 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1621F9E50 for ; Fri, 15 Nov 2013 13:25:22 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-f0-5286913efdaf Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id ED.7C.04556.E3196825; Fri, 15 Nov 2013 22:25:18 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 15 Nov 2013 16:25:18 -0500 From: Gregory Mirsky To: Lou Berger , Zhenlong Cui , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework Thread-Index: AQHOzwfaIG3lunalsUq9rl/3+CCjF5oU30CAgABOIYCAAjx4AIAE1/QAgAjTl4CAAEiQAIAAsEWAgADYnACAAAtfwA== Date: Fri, 15 Nov 2013 21:25:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B713560@eusaamb103.ericsson.se> References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> In-Reply-To: <52863FA2.1070604@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPoK7dxLYggwX/rCzeHvrHaLFvywc2 i47mtywWt5auZHVg8ejd+4PRY8mSn0weHzY1s3l8ufyZLYAlissmJTUnsyy1SN8ugStjx45u 9oI1LBXTF21ma2BcxNzFyMkhIWAi8ab1DwuELSZx4d56NhBbSOAIo8T6Rp0uRi4gezmjxNyF L8GK2ASMJF5s7GEHsUUEMiQm3DgDNohZIFviW89TsLiwQJDE9lN3WCBqgiVePn8CVMMBZGdJ /PprBxJmEVCV2LZ1LtguXgFfiTs9W5ghdv1ikpjfeRsswSmgIXGveTcriM0IdNz3U2uYIHaJ S9x6Mp8J4mgBiSV7zkM9Iyrx8vE/VghbWeL7nEcsEPU6Egt2f2KDsLUlli18zQyxWFDi5Mwn LBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhNxyTYHHcwLvhkeYhRmoNFSZz3 y1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mm9L/iif95P8kt0f86DeNBbOltBo3LRF5 ttykKGGRSqeSaIqXnWZt187cG1cmn+77ob9VWKXy77SULR7Z3IE9p4QL5DJbnm2c8OpiyaPJ a9Jn9L6fsCxo0+PEyZMC5K4u4bjO0VjEFGdT+ehY3RffL3OS+SdeO8vg/m5P94LTz0pvOPUu 2/52kxJLcUaioRZzUXEiAIMFWvB0AgAA Cc: "draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 21:25:32 -0000 Hi Lou, I've got confused with use of ME in=20 Which will result in: All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root towards all the leaves, and thus may be processed by all the MEs in a P2MP MEG. Maintenance Entity (ME) is association of two or more MEPs. Perhaps it shou= ld be "by all Maintenance Points (MPs) in a P2MP MEG" since in MPLS-TP MEG = consists of only one ME and thus both terms can be used interchangeably. Regards, Greg From gregory.mirsky@ericsson.com Fri Nov 15 13:50:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6B411E80E4 for ; Fri, 15 Nov 2013 13:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM5OR7PLrX7i for ; Fri, 15 Nov 2013 13:50:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8FE21F9F80 for ; Fri, 15 Nov 2013 13:50:39 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-b1-5286972e9a33 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1B.BD.04556.E2796825; Fri, 15 Nov 2013 22:50:38 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 15 Nov 2013 16:50:38 -0500 From: Gregory Mirsky To: Lou Berger , Zhenlong Cui , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework Thread-Index: AQHOzwfaIG3lunalsUq9rl/3+CCjF5oU30CAgABOIYCAAjx4AIAE1/QAgAjTl4CAAEiQAIAAsEWAgADYnACAABNssA== Date: Fri, 15 Nov 2013 21:50:37 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B713587@eusaamb103.ericsson.se> References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> In-Reply-To: <52863FA2.1070604@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPoK7e9LYgg59fzS3eHvrHaLFvywc2 i47mtywWt5auZHVg8ejd+4PRY8mSn0weHzY1s3l8ufyZLYAlissmJTUnsyy1SN8ugStj37QW loLP8hVb51xkbWCcJdnFyMEhIWAisa4puYuRE8gUk7hwbz1bFyMXh5DAEUaJWUu/s4MkhASW M0rMXJ0BYrMJGEm82NgDFhcRyJCYcOMMM4jNLJAt8a3nKVhcWCBIYvupOywQNcESL58/YYaw syRezH0FVsMioCpx9MUhVpAbeAV8JY6scYbY+4tJYn7nbTaQGk4BDYl7zbtZQWxGoOO+n1rD BLFLXOLWk/lMEEcLSCzZc54ZwhaVePn4HyuErSzxfc4jFoh6HYkFuz+xQdjaEssWvgar5xUQ lDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbmIExtIxCTbHHYwLPlkeYpTm YFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+NExZdO7jys6x/vF4/kftwusO7W o0erzAJVFqiJzbYwc/c2jvoZaf7akMHykxHjH5fMLRLy4ee/NhVyLQxL6xVkf39MI9jtnVLT FxvpJYufR147std32o7oLI1kjqTiG0W8R7x7+w9ZNRfqcaponvLc9ENrjvP962dDFjJeVtZh ktzrZqZYpcRSnJFoqMVcVJwIAFCDz/hzAgAA Cc: "draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 21:50:44 -0000 Hi Lou, et. al, though it might be not canonical but often "node that is both leaf and bran= ch node" referred as "bud node". Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lou= Berger Sent: Friday, November 15, 2013 7:37 AM To: Zhenlong Cui; mpls@ietf.org Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-fram= ework Zhenlong, See below. I've cut topics with resolutions/agreements. On 11/14/2013 9:41 PM, Zhenlong Cui wrote: > Loa, >=20 > Thank you for your reply. Please see below for responses in-line. >=20 >=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, November 15, 2013 1:11 AM >> To: Zhenlong Cui; mpls@ietf.org >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org >> Subject: Re: [mpls] working group last call on=20 >> draft-ietf-mpls-tp-p2mp-framework >> >> Zhenlong, >> >> Thank you for the comments. >> >> Here are your comments, as extracted from word, and my responses. >> (Clearly the page numbers are wrong.) >> [...] >> >>> Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to=20 >>> all leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00=20 >>> PM every OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM=20 >>> I think that's not necessarily true. Because some on-demand OAM >> packets may be dropped >>> by intermediate node. That mean not every OAM packet is sent to leaves. >>> Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves,=20 >>> and thus can impact >> >> So your point is that an intermediate node may drop an OAM packet? If s= o, yes, this is true for P2P case too. >> >> How about: >> DROP (redundant statement): >> thus every OAM packet is sent to all leaves, s/can impact/may be=20 >> processed by >=20 > My primary concern: > I think there is a discrepancy between "every OAM packet is sent to=20 > all leaves" and "To address a packet to an intermediate node in the=20 > tree, TTL based ..." >=20 > My understanding: > "every OAM packet is sent to all leaves" is equal to "no OAM packet is s= ent to branches". > On the other hand, "To address a packet to an intermediate node in the t= ree, TTL based ...", it seems meaning that "the root may send OAM packet to= branches". >=20 > Is my understanding correct? >=20 Okay, I understand your point. I think your reading / the text does not ma= tch our intent. (Which is certainly to allow for both MIP and MEP processing.) How about: s/to all leaves/towards all leaves Which will result in: All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root towards all the leaves, and thus may be processed by all the MEs in a P2MP MEG. [...] >=20 >> >>> Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted zc >>> 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013 >>> 8:02:00 PM It is correct? >> How about: >> s/and/and, perhaps, >=20 > s/and/and? Is this a mistake? > My propose is s/and/or. >=20 >=20 Sorry for not being clear. I was proposing the following final text: Fault notification happens from the node identifying the fault to the root node and, perhaps, from the leaves to the root via an out of band path. Now rereading the sentence I think I'd prefer just dropping the reference t= o leaves as it really doesn't add anything. How about: Fault notification happens from the node identifying the fault to the root node via an out of band path. And also dropping "In either case" immediately following to align the next = sentence. That's it. Thank you again for your comments. Lou > Best regards, > zhenlong >=20 [...] _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lberger@labn.net Sun Nov 17 06:51:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881A11E8D96 for ; Sun, 17 Nov 2013 06:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILAS3-l+snEK for ; Sun, 17 Nov 2013 06:51:10 -0800 (PST) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2927111E8D3F for ; Sun, 17 Nov 2013 06:50:54 -0800 (PST) Received: (qmail 11837 invoked by uid 0); 17 Nov 2013 14:50:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 17 Nov 2013 14:50:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=i6qcWo0pOb4taaTdz0BtkfQuAq0fQuT/PBidlzPhzu0=; b=UwXR/5BIGOKocoSxH8GW4KAOo5ZBfILrdPsbmdk0ZkTS8v4eLrpd2PbdKq24jQW22E/h8BeZ+Kp57IbZIEFLhHGxGITPiokRn/pRhrWFfjZot9PMUchMWLetsLzl/t90; Received: from box313.bluehost.com ([69.89.31.113]:46249 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Vi3gA-00030m-H8; Sun, 17 Nov 2013 07:50:26 -0700 From: Lou Berger To: Gregory Mirsky , Zhenlong Cui , Date: Sun, 17 Nov 2013 09:50:25 -0500 Message-ID: <142668a5c88.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B713587@eusaamb103.ericsson.se> References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> <7347100B5761DC41A166AC17F22DF1121B713587@eusaamb103.ericsson.se> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.5.10 (build: 2100360) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 14:51:15 -0000 I always found this term a bit counterintuitive so am happy that it has received limited use.... Lou On November 15, 2013 4:50:37 PM Gregory Mirsky wrote: > Hi Lou, et. al, > though it might be not canonical but often "node that is both leaf and > branch node" referred as "bud node". > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lou > Berger > Sent: Friday, November 15, 2013 7:37 AM > To: Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: Re: [mpls] working group last call on > draft-ietf-mpls-tp-p2mp-framework > > > Zhenlong, > > See below. I've cut topics with resolutions/agreements. > > On 11/14/2013 9:41 PM, Zhenlong Cui wrote: > > Loa, > > Thank you for your reply. Please see below for responses in-line. > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, November 15, 2013 1:11 AM > >> To: Zhenlong Cui; mpls@ietf.org > >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > >> Subject: Re: [mpls] working group last call on > draft-ietf-mpls-tp-p2mp-framework > >> > >> Zhenlong, > >> > >> Thank you for the comments. > >> > >> Here are your comments, as extracted from word, and my responses. > >> (Clearly the page numbers are wrong.) > >> > > [...] > > >> > >>> Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to all > leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00 PM every > OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM I think that's > not necessarily true. Because some on-demand OAM > >> packets may be dropped > >>> by intermediate node. That mean not every OAM packet is sent to leaves. > >>> Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, and > thus can impact > >> > >> So your point is that an intermediate node may drop an OAM packet? If > so, yes, this is true for P2P case too. > >> > >> How about: > >> DROP (redundant statement): > >> thus every OAM packet is sent to all leaves, s/can impact/may be >> > processed by > > My primary concern: > > I think there is a discrepancy between "every OAM packet is sent to all > leaves" and "To address a packet to an intermediate node in the tree, TTL > based ..." > > My understanding: > > "every OAM packet is sent to all leaves" is equal to "no OAM packet is > sent to branches". > > On the other hand, "To address a packet to an intermediate node in the > tree, TTL based ...", it seems meaning that "the root may send OAM packet > to branches". > > Is my understanding correct? > > > Okay, I understand your point. I think your reading / the text does not > match our intent. (Which is certainly to allow for both MIP and MEP > processing.) > > How about: > s/to all leaves/towards all leaves > > Which will result in: > All the traffic sent over a P2MP transport path, including > OAM packets generated by a MEP, is sent (multicast) from the > root towards all the leaves, and thus may be processed by all > the MEs in a P2MP MEG. > > [...] > > > >> > >>> Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted zc > >>> 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013 > >>> 8:02:00 PM It is correct? > >> How about: > >> s/and/and, perhaps, > > s/and/and? Is this a mistake? > > My propose is s/and/or. > > > > Sorry for not being clear. I was proposing the following final text: > Fault notification happens from the node > identifying the fault to the root node and, perhaps, from the > leaves to the root via an out of band path. > > Now rereading the sentence I think I'd prefer just dropping the reference > to leaves as it really doesn't add anything. How about: > Fault notification happens from the node > identifying the fault to the root node via an out of band path. > > And also dropping "In either case" immediately following to align the next > sentence. > > That's it. Thank you again for your comments. > > Lou > > > Best regards, > > zhenlong > > [...] > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From lberger@labn.net Sun Nov 17 06:55:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F88711E8DB6 for ; Sun, 17 Nov 2013 06:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.215 X-Spam-Level: X-Spam-Status: No, score=-101.215 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyDajyxhyITm for ; Sun, 17 Nov 2013 06:55:26 -0800 (PST) Received: from alt-proxy6.mail.unifiedlayer.com (alt-proxy6.mail.unifiedlayer.com [66.147.245.65]) by ietfa.amsl.com (Postfix) with SMTP id EFB2B11E8194 for ; Sun, 17 Nov 2013 06:55:25 -0800 (PST) Received: (qmail 4245 invoked by uid 0); 17 Nov 2013 14:55:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy19.mail.unifiedlayer.com with SMTP; 17 Nov 2013 14:55:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=krVBo3fp3gZ6W+OJsEfhFnIj1F1qqQtotHb9l1BHx9M=; b=hqFQzMXU8eXuGMYaQlTaAzBs3xjD/Y1r5PSYHblrwImYeOVrAKaIDA2Lkc4l/tTEdmn11rm3H6A9a4S7FY1m1nxTKDPOWoVNhCjxkHsKBGOyH+jKo4V9HeshMvMSKqJ4; Received: from box313.bluehost.com ([69.89.31.113]:46982 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Vi3kz-0004Wj-4j; Sun, 17 Nov 2013 07:55:25 -0700 From: Lou Berger To: Gregory Mirsky , Zhenlong Cui , Date: Sun, 17 Nov 2013 09:55:23 -0500 Message-ID: <142668f1390.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B713560@eusaamb103.ericsson.se> References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> <7347100B5761DC41A166AC17F22DF1121B713560@eusaamb103.ericsson.se> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.5.10 (build: 2100360) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 14:55:39 -0000 Greg, Thanks for the comment. See below. On November 15, 2013 4:25:17 PM Gregory Mirsky wrote: > Hi Lou, > I've got confused with use of ME in > Which will result in: > All the traffic sent over a P2MP transport path, including > OAM packets generated by a MEP, is sent (multicast) from the > root towards all the leaves, and thus may be processed by all > the MEs in a P2MP MEG. > > Maintenance Entity (ME) is association of two or more MEPs. Perhaps it > should be "by all Maintenance Points (MPs) in a P2MP MEG" since in MPLS-TP > MEG consists of only one ME and thus both terms can be used interchangeably. > How about being completely explicit: ...by all MIPs and MEPs associated with a P2MP MEG". Lou > Regards, > Greg > From gregory.mirsky@ericsson.com Sun Nov 17 07:43:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1758211E8E4B for ; Sun, 17 Nov 2013 07:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAcwEKZLRHCW for ; Sun, 17 Nov 2013 07:42:54 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2811E8E6E for ; Sun, 17 Nov 2013 07:41:45 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-2b-5288e3b72e4d Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FF.AF.04556.8B3E8825; Sun, 17 Nov 2013 16:41:44 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Sun, 17 Nov 2013 10:41:43 -0500 From: Gregory Mirsky To: Lou Berger , Zhenlong Cui , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework Thread-Index: AQHO46UOa6gwesUr20yDhqbGwI/ZuJopj0UA Date: Sun, 17 Nov 2013 15:41:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B719E2A@eusaamb103.ericsson.se> References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> <7347100B5761DC41A166AC17F22DF1121B713560@eusaamb103.ericsson.se> <142668f1390.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <142668f1390.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPt+6Oxx1BBoc3iFi8PfSP0WLflg9s Fh3Nb1ksbi1dyerA4tG79wejx5IlP5k8PmxqZvP4cvkzWwBLFJdNSmpOZllqkb5dAlfGkRWH mArOcVYs/zqbsYFxJ3sXIyeHhICJxJTnH1kgbDGJC/fWs3UxcnEICRxhlOi7eIwNJCEksJxR YtdJMRCbTcBI4sXGHrBmEYEMiQk3zjCD2MwC2RLfep6CxYUFgiTWnehnhqgJlmg8Pxuq3kji 3uc9YDNZBFQlfk29xwpi8wr4Stw8PYUFYvFfZomd+8+BNXAKeEr8a78HNogR6Lrvp9YwQSwT l7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0t8n/OIBaJeR2LB7k9sELa2xLKFr5khFgtKnJz5 hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3MQLj6ZgEm+MOxgWfLA8xSnOwKInz fnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUSyztCXH4i5frXRto81UYb30a8n2n5TD k1Z5vz3dfWP+wevtU6yDvPtvvPq+5WPPnLNbW3vFJp7n45kgbPDy9Wfxi+Eibo4F345ymEik Hl+lqHts4yLvzXdXOTQtC1fOnlPYciJi92N274m+cm8fFT7R1fYxOtO+9CrL08V3Jxg5KInw 5+etUWIpzkg01GIuKk4EAETLUYh1AgAA Cc: "draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 15:43:01 -0000 Hi Lou, yes, being explicit is the clearest way to express idea. Regards, Greg -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Sunday, November 17, 2013 6:55 AM To: Gregory Mirsky; Zhenlong Cui; mpls@ietf.org Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-fram= ework Greg, Thanks for the comment. See below. On November 15, 2013 4:25:17 PM Gregory Mirsky wrote: > Hi Lou, > I've got confused with use of ME in > Which will result in: > All the traffic sent over a P2MP transport path, including > OAM packets generated by a MEP, is sent (multicast) from the > root towards all the leaves, and thus may be processed by all > the MEs in a P2MP MEG. > > Maintenance Entity (ME) is association of two or more MEPs. Perhaps it=20 > should be "by all Maintenance Points (MPs) in a P2MP MEG" since in=20 > MPLS-TP MEG consists of only one ME and thus both terms can be used inter= changeably. > How about being completely explicit: ...by all MIPs and MEPs associated with a P2MP MEG". Lou > Regards, > Greg > From adrian@olddog.co.uk Sun Nov 17 12:24:23 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEC11E8EE1 for ; Sun, 17 Nov 2013 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGf92WeH8nqf for ; Sun, 17 Nov 2013 12:24:15 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8889911E81EC for ; Sun, 17 Nov 2013 12:23:53 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAHKNpZh025585; Sun, 17 Nov 2013 20:23:51 GMT Received: from 950129200 (unsi-72-29-212-251.unsi.net [72.29.212.251] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAHKNn0n025565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Nov 2013 20:23:50 GMT From: "Adrian Farrel" To: Date: Sun, 17 Nov 2013 20:23:48 -0000 Message-ID: <013a01cee3d2$ed3c4370$c7b4ca50$@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: Ac7j0ulIFPV3NWw1SyO2h/jAMWiQcA== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 20:24:23 -0000 Hi, I have done my usual AD review of your document having received the publication request from the working group. The purpose of the review is to catch and clean up any issues before the document goes to IETF last call and IESG evaluation. The WG chairs tell me that there is at least one implementation and a few planned implementations, so it is clear we should look at how to advance this work. At the same time I have a number of issues with the text that I believe need to be fixed or discussed before we can do that. Could you please work through the comments below and either produce a revised document or let me know why I am wrong. Thanks, Adrian =========== You will need to expand some acronyms on first use. You need to expand them in the Abstract and in the main text even if they are already expanded in the Abstract. I see: LSP P2MP OAM PW PE P2P VPMS IPTV FEC LSR LER --- Section 2 All good except would be good to actually expand the acronyms rather than just explaining them. Perhaps also give a reference for mLDP. --- Please read the comments on Sections 3.1 to 3.3, below, and then the meta-comment that follows. --- Section 3.1 I believe that the TicToc working group has agreed to change the status of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only describes an approach, and does not have consensus of the MPLS community. So I think you should OLD [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. NEW [I-D.ietf-tictoc-1588overmpls] describes a possible approach to carry [IEEE1588] over an MPLS network. END I do believe this use case in as much as timing synchronization benefits from the forward and reverse paths being identical. I am less sure that P2MP timing synchronization is a big requirement, but I am happy to believe you if you say it is needed. --- I think you need to do some rewriting in Section 3.2 [I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has made no progress for about 20 months. It appears to have been abandoned by the WG. I think that part of the reason was that the solutions offered provided too much complexity when the rend result could be achieved more simply. This leads to wonder whether your use case is making too many assumptions. You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your reference, but to be honest with you, that I-D is not in a good place either having been sent back to the WG by its AD. Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than six months ago meaning it has made no progress for a year. You could rewrite this section to establish the requirements in your text rather than by reference, but IMHO, the best thing is to remove the whole section. --- As far as I can tell, section 3.3. does not provide a motivating use case for this work. It is true that if you do have HSMP it would server the purpose, but I do not believe that the IGMP messages or the channel switch messages or whatever have to follow the reverse path of the P2MP distribution tree. This makes me think that you have two classes of use case (in the set of two use cases that remain after the removal of section 3.2). The first is the type of use case that motivates the invention of HSMP. The second is the type of use case that shows that HSMP could also be used for other things. Really, we need to separate these out to see whether there is real motivation for this work. Does this mean that the only reason for this work is time distribution in a multicast network? --- The comments on Sections 3.1 to 3.3, above, make me wonder about the value of Section 3. What does it add to the document? Was it intended to prove that there is a purpose to this work, or was it just trying to show some ways that HSMP might be used? If the latter, I recommend simply removing the whole section. If the former, I think you have failed! :-( If you *do* want show that there is value in the work (and I don't believe you need to *if* people are coding/deploying this function) then I suspect that the real motivation for this work is that it provides MP2MP functionality with the simplicity of a single hub compared to the multiple "distributed" hubs of MP2MP LSPs. If you feel the need to show a purpose, then I think *this* is the topic you need to discuss in Section 3. --- Section 4 HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the difference that the leaf LSRs can only send traffic to root node along the same path of traffic from root node to leaf node. This paragraph is very ambiguous. Is it that the LSRs can only send *traffic*? Is it that the LSRs can only send *to*the*root*? Or is it that the LSRs can only send *along*the*same*path* I think you need HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the difference that in HSMP, when the leaf LSRs send traffic on the LSP, the traffic is first delivered only to the root node and follows the reverse path of traffic sent from the root node to the leaf node. The root note then distributes the traffic on the P2MP tree to all of the leaf nodes. --- Section 4 The transmission of packets from the root node of an HSMP LSP to the receivers is identical to that of a P2MP LSP. Traffic from a leaf node follows the upstream path toward the root node, along a path that traverse the same nodes as the downstream node, but in reverse order. I believe this says that traffic is delivered back to the sender in all cases. Is that the intent? This makes for a significant difference between HSMP and MP2MP, doesn't it? Shouldn't the document make this clearer? --- Although Figure 1 shows the settings of the U and F bits, I think you should mention them explicitly. This seems to be important because it impacts what happens if there is an LSR in the path that does not support HSMP. --- Somewhat to my surprise, the use of the HSMP capability TLV is not described anywhere. Reading between the lines in Section 4.1 I can see that the new TLV is carried on the Initialization message. I can also see that an implementation wishing to indicate it supports HSMP includes the TLV and follow the procedures for indicating capabilities as defined in RFC 5561. But I don't find anything saying MUST NOT use HSMP FEC is peer does not support HSMP. I also don't understand what happens if I am tying to build an HSMP LSP and discover that the next hop does not support HSMP. Can I have an HSMP LSP with a hole in it? Does an LSR finding it cannot advance an HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an assumption that all nodes that might be on an HSMP tree will support HSMP? I think you need to explain all this. You could look to RFC 6388 for some suitable wording. --- Throughout Section 4 the references to 6388 for process may be "obvious" but are broken. For example, in 4.3.1 you have Determining the upstream LSR for the HSMP LSP follows the procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. But Section 3.3.1.1 of RFC 6388 says: Determining the upstream LDP peer U for an MP2MP LSP follows the procedure for a P2MP LSP described in Section 2.4.1.1. This is a double indirection, so you should go direct to the source. For example, later in 4.3.1 you have Determining one's HSMP downstream LSR follows the procedure defined in [RFC6388] section 3.3.1.2. But Section 3.3.1.2 of RFC 6388 says An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer D will treat D as downstream MP2MP LSR. which is not helpful in the context of this I-D. I think the bottom line is that this document needs to be written to desribe the processes that apply for these extensions. Looking to the future, there is a strong case to be made that HSMP might get more traction than MP2MP (since it provides the same user service with a number of simplifications). If this turns out to be the case, you do not want this document to need to lean on RFC 6388. It should be independent. By all means reference 6388 for comparison, but do not use it to define your processes. --- I am unconvinced by Section 7. As I read the rest of the document, HSMP has a high reliance on being able to produce a tree where the leaf-to- root path is co-routed (in the opposite direction) with the root-to-leaf path for each leaf. But I don't see anything in the document that *makes* this happen. Section 7 seems to expose that the document assumes that co-routing will happen fortuitously. That is, when it doesn't occur, the network is requested to detect the fact and scream. If the main purpose of HSMP is the co-routing, shouldn't this be factored into the protocol? If detection and reporting of non-co-routed HSMP LSPs is so important, shouldn't the protocol enable it? And maybe the LSP shouldn't even come up? From loa@pi.nu Sun Nov 17 13:47:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A146F11E81F0 for ; Sun, 17 Nov 2013 13:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6DcmK9hEbuf for ; Sun, 17 Nov 2013 13:47:29 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 31BE411E8EAE for ; Sun, 17 Nov 2013 13:47:28 -0800 (PST) Received: from [172.16.0.127] (unknown [72.29.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 648D61802039; Sun, 17 Nov 2013 22:47:09 +0100 (CET) Message-ID: <5289395D.7060603@pi.nu> Date: Sun, 17 Nov 2013 16:47:09 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> In-Reply-To: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 21:47:35 -0000 Adrian, I understand the latter part of the comments, but I'm confused about the requirement that the (most of) acronyms should be expanded; almost all of the are in the RFC Editor acronym list. The RFC Editor says: "Some abbreviations are so well known that expansion is probably unnecessary. The RFC Editor exercises editorial judgment about whether a particular use of one of the "well-known" abbreviations requires expansion." That is why I left then unexpanded during my review, and since the RFC-Editor promise to use " editorial judgment" I think we can leave it at that. /Loa On 2013-11-17 15:23, Adrian Farrel wrote: > Hi, > > I have done my usual AD review of your document having received the > publication request from the working group. The purpose of the review is > to catch and clean up any issues before the document goes to IETF last > call and IESG evaluation. > > The WG chairs tell me that there is at least one implementation and a > few planned implementations, so it is clear we should look at how to > advance this work. At the same time I have a number of issues with the > text that I believe need to be fixed or discussed before we can do that. > > Could you please work through the comments below and either produce a > revised document or let me know why I am wrong. > > Thanks, > Adrian > > =========== > > You will need to expand some acronyms on first use. > You need to expand them in the Abstract and in the main text even if > they are already expanded in the Abstract. > I see: > LSP > P2MP > OAM > PW > PE > P2P > VPMS > IPTV > FEC > LSR > LER > > --- > > Section 2 > > All good except would be good to actually expand the acronyms rather > than just explaining them. > > Perhaps also give a reference for mLDP. > > --- > > Please read the comments on Sections 3.1 to 3.3, below, and then the > meta-comment that follows. > > --- > > Section 3.1 > > I believe that the TicToc working group has agreed to change the status > of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only > describes an approach, and does not have consensus of the MPLS > community. > > So I think you should > > OLD > [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. > NEW > [I-D.ietf-tictoc-1588overmpls] describes a possible approach to > carry [IEEE1588] over an MPLS network. > END > > I do believe this use case in as much as timing synchronization benefits > from the forward and reverse paths being identical. I am less sure that > P2MP timing synchronization is a big requirement, but I am happy to > believe you if you say it is needed. > > --- > > I think you need to do some rewriting in Section 3.2 > > [I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has made > no progress for about 20 months. It appears to have been abandoned by > the WG. I think that part of the reason was that the solutions offered > provided too much complexity when the rend result could be achieved more > simply. > > This leads to wonder whether your use case is making too many > assumptions. > > You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your > reference, but to be honest with you, that I-D is not in a good place > either having been sent back to the WG by its AD. > > Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than > six months ago meaning it has made no progress for a year. > > You could rewrite this section to establish the requirements in your > text rather than by reference, but IMHO, the best thing is to remove the > whole section. > > --- > > As far as I can tell, section 3.3. does not provide a motivating use > case for this work. It is true that if you do have HSMP it would server > the purpose, but I do not believe that the IGMP messages or the channel > switch messages or whatever have to follow the reverse path of the P2MP > distribution tree. > > This makes me think that you have two classes of use case (in the set of > two use cases that remain after the removal of section 3.2). The first > is the type of use case that motivates the invention of HSMP. The second > is the type of use case that shows that HSMP could also be used for > other things. Really, we need to separate these out to see whether there > is real motivation for this work. > > Does this mean that the only reason for this work is time distribution > in a multicast network? > > --- > > The comments on Sections 3.1 to 3.3, above, make me wonder about the > value of Section 3. What does it add to the document? Was it intended to > prove that there is a purpose to this work, or was it just trying to > show some ways that HSMP might be used? > > If the latter, I recommend simply removing the whole section. > > If the former, I think you have failed! :-( > If you *do* want show that there is value in the work (and I don't > believe you need to *if* people are coding/deploying this function) then > I suspect that the real motivation for this work is that it provides > MP2MP functionality with the simplicity of a single hub compared to the > multiple "distributed" hubs of MP2MP LSPs. If you feel the need to show > a purpose, then I think *this* is the topic you need to discuss in > Section 3. > > --- > > Section 4 > > HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the > difference that the leaf LSRs can only send traffic to root node > along the same path of traffic from root node to leaf node. > > This paragraph is very ambiguous. > Is it that the LSRs can only send *traffic*? > Is it that the LSRs can only send *to*the*root*? > Or is it that the LSRs can only send *along*the*same*path* > > I think you need > > HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the > difference that in HSMP, when the leaf LSRs send traffic on the LSP, > the traffic is first delivered only to the root node and follows the > reverse path of traffic sent from the root node to the leaf node. The > root note then distributes the traffic on the P2MP tree to all of the > leaf nodes. > > --- > > Section 4 > > The transmission of packets from the root node of an HSMP LSP > to the receivers is identical to that of a P2MP LSP. Traffic from a > leaf node follows the upstream path toward the root node, along a > path that traverse the same nodes as the downstream node, but in > reverse order. > > I believe this says that traffic is delivered back to the sender in all > cases. Is that the intent? > > This makes for a significant difference between HSMP and MP2MP, doesn't > it? Shouldn't the document make this clearer? > > --- > > Although Figure 1 shows the settings of the U and F bits, I think you > should mention them explicitly. This seems to be important because it > impacts what happens if there is an LSR in the path that does not > support HSMP. > > --- > > Somewhat to my surprise, the use of the HSMP capability TLV is not > described anywhere. Reading between the lines in Section 4.1 I can see > that the new TLV is carried on the Initialization message. I can also > see that an implementation wishing to indicate it supports HSMP includes > the TLV and follow the procedures for indicating capabilities as defined > in RFC 5561. > > But I don't find anything saying MUST NOT use HSMP FEC is peer does not > support HSMP. > > I also don't understand what happens if I am tying to build an HSMP LSP > and discover that the next hop does not support HSMP. Can I have an > HSMP LSP with a hole in it? Does an LSR finding it cannot advance an > HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an > assumption that all nodes that might be on an HSMP tree will support > HSMP? > > I think you need to explain all this. You could look to RFC 6388 for > some suitable wording. > > --- > > Throughout Section 4 the references to 6388 for process may be "obvious" > but are broken. > > For example, in 4.3.1 you have > > Determining the upstream LSR for the HSMP LSP follows the > procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. > > But Section 3.3.1.1 of RFC 6388 says: > > Determining the upstream LDP peer U for an MP2MP LSP follows > the procedure for a P2MP LSP described in Section 2.4.1.1. > > This is a double indirection, so you should go direct to the source. > > For example, later in 4.3.1 you have > > Determining one's HSMP downstream LSR follows the procedure defined > in [RFC6388] section 3.3.1.2. > > But Section 3.3.1.2 of RFC 6388 says > > An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer > D will treat D as downstream MP2MP LSR. > > which is not helpful in the context of this I-D. > > I think the bottom line is that this document needs to be written to > desribe the processes that apply for these extensions. > > Looking to the future, there is a strong case to be made that HSMP > might get more traction than MP2MP (since it provides the same user > service with a number of simplifications). If this turns out to be the > case, you do not want this document to need to lean on RFC 6388. It > should be independent. By all means reference 6388 for comparison, but > do not use it to define your processes. > > --- > > I am unconvinced by Section 7. As I read the rest of the document, HSMP > has a high reliance on being able to produce a tree where the leaf-to- > root path is co-routed (in the opposite direction) with the root-to-leaf > path for each leaf. But I don't see anything in the document that > *makes* this happen. > > Section 7 seems to expose that the document assumes that co-routing will > happen fortuitously. That is, when it doesn't occur, the network is > requested to detect the fact and scream. > > If the main purpose of HSMP is the co-routing, shouldn't this be > factored into the protocol? > > If detection and reporting of non-co-routed HSMP LSPs is so important, > shouldn't the protocol enable it? And maybe the LSP shouldn't even come > up? > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Sun Nov 17 14:16:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A56011E82DA for ; Sun, 17 Nov 2013 14:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVr7-4fAjZIH for ; Sun, 17 Nov 2013 14:16:26 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D5EBB11E82D9 for ; Sun, 17 Nov 2013 14:16:25 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAHMGO6M025720; Sun, 17 Nov 2013 22:16:24 GMT Received: from 950129200 (unsi-72-29-212-253.unsi.net [72.29.212.253] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAHMGLwa025679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Nov 2013 22:16:22 GMT From: "Adrian Farrel" To: "'Loa Andersson'" , References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> <5289395D.7060603@pi.nu> In-Reply-To: <5289395D.7060603@pi.nu> Date: Sun, 17 Nov 2013 22:16:19 -0000 Message-ID: <015b01cee3e2$a652a070$f2f7e150$@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: AQKA2ZT9n+urJ3by5MGg4ag7RJGDwAIVQ3RPmLVhoMA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 22:16:31 -0000 The very next line from the one you quote says... In the following list of abbreviations, those that are usually (but not necessarily) treated as "well known" are marked with asterisks. Thus, anything not marked with an asterisk in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt may be regarded as "not well known" and need expansion. In particular, it is not only the reader that you need to worry about, but also the RFC Editor. If you are asking that the RFC Editor should expand these acronyms for you, they need to know what you intend the expansion to be and they of, course, have no insight on the technology to guide them. The alternative to the authors expanding the acronyms now is a series of email exchanges during the edit process where the RFC Editor questions the authors about what they meant. There is also a risk here that the RFC Editor will use the wrong expansion and it will be missed in Auth48. Perhaps the best example in the Routing Area is "LSP". Cheers, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 17 November 2013 21:47 > To: adrian@olddog.co.uk; draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: AD review of draft-ietf-mpls-mldp-hsmp > > Adrian, > > I understand the latter part of the comments, but I'm confused about > the requirement that the (most of) acronyms should be expanded; almost > all of the are in the RFC Editor acronym list. The RFC Editor says: > > "Some abbreviations are so well known that expansion is probably > unnecessary. The RFC Editor exercises editorial judgment about whether > a particular use of one of the "well-known" abbreviations requires > expansion." > > That is why I left then unexpanded during my review, and since the > RFC-Editor promise to use " editorial judgment" I think we can leave it > at that. > > /Loa > > On 2013-11-17 15:23, Adrian Farrel wrote: > > Hi, > > > > I have done my usual AD review of your document having received the > > publication request from the working group. The purpose of the review is > > to catch and clean up any issues before the document goes to IETF last > > call and IESG evaluation. > > > > The WG chairs tell me that there is at least one implementation and a > > few planned implementations, so it is clear we should look at how to > > advance this work. At the same time I have a number of issues with the > > text that I believe need to be fixed or discussed before we can do that. > > > > Could you please work through the comments below and either produce a > > revised document or let me know why I am wrong. > > > > Thanks, > > Adrian > > > > =========== > > > > You will need to expand some acronyms on first use. > > You need to expand them in the Abstract and in the main text even if > > they are already expanded in the Abstract. > > I see: > > LSP > > P2MP > > OAM > > PW > > PE > > P2P > > VPMS > > IPTV > > FEC > > LSR > > LER > > > > --- > > > > Section 2 > > > > All good except would be good to actually expand the acronyms rather > > than just explaining them. > > > > Perhaps also give a reference for mLDP. > > > > --- > > > > Please read the comments on Sections 3.1 to 3.3, below, and then the > > meta-comment that follows. > > > > --- > > > > Section 3.1 > > > > I believe that the TicToc working group has agreed to change the status > > of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only > > describes an approach, and does not have consensus of the MPLS > > community. > > > > So I think you should > > > > OLD > > [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. > > NEW > > [I-D.ietf-tictoc-1588overmpls] describes a possible approach to > > carry [IEEE1588] over an MPLS network. > > END > > > > I do believe this use case in as much as timing synchronization benefits > > from the forward and reverse paths being identical. I am less sure that > > P2MP timing synchronization is a big requirement, but I am happy to > > believe you if you say it is needed. > > > > --- > > > > I think you need to do some rewriting in Section 3.2 > > > > [I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has made > > no progress for about 20 months. It appears to have been abandoned by > > the WG. I think that part of the reason was that the solutions offered > > provided too much complexity when the rend result could be achieved more > > simply. > > > > This leads to wonder whether your use case is making too many > > assumptions. > > > > You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your > > reference, but to be honest with you, that I-D is not in a good place > > either having been sent back to the WG by its AD. > > > > Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than > > six months ago meaning it has made no progress for a year. > > > > You could rewrite this section to establish the requirements in your > > text rather than by reference, but IMHO, the best thing is to remove the > > whole section. > > > > --- > > > > As far as I can tell, section 3.3. does not provide a motivating use > > case for this work. It is true that if you do have HSMP it would server > > the purpose, but I do not believe that the IGMP messages or the channel > > switch messages or whatever have to follow the reverse path of the P2MP > > distribution tree. > > > > This makes me think that you have two classes of use case (in the set of > > two use cases that remain after the removal of section 3.2). The first > > is the type of use case that motivates the invention of HSMP. The second > > is the type of use case that shows that HSMP could also be used for > > other things. Really, we need to separate these out to see whether there > > is real motivation for this work. > > > > Does this mean that the only reason for this work is time distribution > > in a multicast network? > > > > --- > > > > The comments on Sections 3.1 to 3.3, above, make me wonder about the > > value of Section 3. What does it add to the document? Was it intended to > > prove that there is a purpose to this work, or was it just trying to > > show some ways that HSMP might be used? > > > > If the latter, I recommend simply removing the whole section. > > > > If the former, I think you have failed! :-( > > If you *do* want show that there is value in the work (and I don't > > believe you need to *if* people are coding/deploying this function) then > > I suspect that the real motivation for this work is that it provides > > MP2MP functionality with the simplicity of a single hub compared to the > > multiple "distributed" hubs of MP2MP LSPs. If you feel the need to show > > a purpose, then I think *this* is the topic you need to discuss in > > Section 3. > > > > --- > > > > Section 4 > > > > HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the > > difference that the leaf LSRs can only send traffic to root node > > along the same path of traffic from root node to leaf node. > > > > This paragraph is very ambiguous. > > Is it that the LSRs can only send *traffic*? > > Is it that the LSRs can only send *to*the*root*? > > Or is it that the LSRs can only send *along*the*same*path* > > > > I think you need > > > > HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the > > difference that in HSMP, when the leaf LSRs send traffic on the LSP, > > the traffic is first delivered only to the root node and follows the > > reverse path of traffic sent from the root node to the leaf node. The > > root note then distributes the traffic on the P2MP tree to all of the > > leaf nodes. > > > > --- > > > > Section 4 > > > > The transmission of packets from the root node of an HSMP LSP > > to the receivers is identical to that of a P2MP LSP. Traffic from a > > leaf node follows the upstream path toward the root node, along a > > path that traverse the same nodes as the downstream node, but in > > reverse order. > > > > I believe this says that traffic is delivered back to the sender in all > > cases. Is that the intent? > > > > This makes for a significant difference between HSMP and MP2MP, doesn't > > it? Shouldn't the document make this clearer? > > > > --- > > > > Although Figure 1 shows the settings of the U and F bits, I think you > > should mention them explicitly. This seems to be important because it > > impacts what happens if there is an LSR in the path that does not > > support HSMP. > > > > --- > > > > Somewhat to my surprise, the use of the HSMP capability TLV is not > > described anywhere. Reading between the lines in Section 4.1 I can see > > that the new TLV is carried on the Initialization message. I can also > > see that an implementation wishing to indicate it supports HSMP includes > > the TLV and follow the procedures for indicating capabilities as defined > > in RFC 5561. > > > > But I don't find anything saying MUST NOT use HSMP FEC is peer does not > > support HSMP. > > > > I also don't understand what happens if I am tying to build an HSMP LSP > > and discover that the next hop does not support HSMP. Can I have an > > HSMP LSP with a hole in it? Does an LSR finding it cannot advance an > > HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an > > assumption that all nodes that might be on an HSMP tree will support > > HSMP? > > > > I think you need to explain all this. You could look to RFC 6388 for > > some suitable wording. > > > > --- > > > > Throughout Section 4 the references to 6388 for process may be "obvious" > > but are broken. > > > > For example, in 4.3.1 you have > > > > Determining the upstream LSR for the HSMP LSP follows the > > procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. > > > > But Section 3.3.1.1 of RFC 6388 says: > > > > Determining the upstream LDP peer U for an MP2MP LSP follows > > the procedure for a P2MP LSP described in Section 2.4.1.1. > > > > This is a double indirection, so you should go direct to the source. > > > > For example, later in 4.3.1 you have > > > > Determining one's HSMP downstream LSR follows the procedure defined > > in [RFC6388] section 3.3.1.2. > > > > But Section 3.3.1.2 of RFC 6388 says > > > > An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer > > D will treat D as downstream MP2MP LSR. > > > > which is not helpful in the context of this I-D. > > > > I think the bottom line is that this document needs to be written to > > desribe the processes that apply for these extensions. > > > > Looking to the future, there is a strong case to be made that HSMP > > might get more traction than MP2MP (since it provides the same user > > service with a number of simplifications). If this turns out to be the > > case, you do not want this document to need to lean on RFC 6388. It > > should be independent. By all means reference 6388 for comparison, but > > do not use it to define your processes. > > > > --- > > > > I am unconvinced by Section 7. As I read the rest of the document, HSMP > > has a high reliance on being able to produce a tree where the leaf-to- > > root path is co-routed (in the opposite direction) with the root-to-leaf > > path for each leaf. But I don't see anything in the document that > > *makes* this happen. > > > > Section 7 seems to expose that the document assumes that co-routing will > > happen fortuitously. That is, when it doesn't occur, the network is > > requested to detect the fact and scream. > > > > If the main purpose of HSMP is the co-routing, shouldn't this be > > factored into the protocol? > > > > If detection and reporting of non-co-routed HSMP LSPs is so important, > > shouldn't the protocol enable it? And maybe the LSP shouldn't even come > > up? > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From c-sai@bx.jp.nec.com Sun Nov 17 16:44:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48F11E819B for ; Sun, 17 Nov 2013 16:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVrhDCWAsNav for ; Sun, 17 Nov 2013 16:44:36 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id EB89D11E80E6 for ; Sun, 17 Nov 2013 16:44:35 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAI0iUVp000593; Mon, 18 Nov 2013 09:44:31 +0900 (JST) Received: from mailsv.nec.co.jp (imss61.nec.co.jp [10.7.69.156]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id rAI0iUZ07309; Mon, 18 Nov 2013 09:44:30 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id rAI0hDeZ020686; Mon, 18 Nov 2013 09:44:30 +0900 (JST) Received: from kaishu.jp.nec.com ([10.26.220.5] [10.26.220.5]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-11226; Mon, 18 Nov 2013 09:44:00 +0900 Received: from VPCS7083 ([10.38.126.83] [10.38.126.83]) by mail.jp.nec.com with ESMTP; Mon, 18 Nov 2013 09:43:59 +0900 From: "Zhenlong Cui" To: "'Lou Berger'" , "'Gregory Mirsky'" , References: <5260B904.2090802@pi.nu> <015a01cecf07$abeefcd0$03ccf670$@bx.jp.nec.com> <52771FCD.1030406@labn.net> <00c701ced93b$d04fed80$70efc880$@bx.jp.nec.com> <52794190.9060303@labn.net> <527D51B6.1060106@labn.net> <097b01cee12f$d1590df0$740b29d0$@bx.jp.nec.com> <5284F610.6050807@labn.net> <00a201cee1ac$3c2efd20$b48cf760$@bx.jp.nec.com> <52863FA2.1070604@labn.net> <7347100B5761DC41A166AC17F22DF1121B713587@eusaamb103.ericsson.se> <142668a5c88.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <142668a5c88.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Mon, 18 Nov 2013 09:43:58 +0900 Message-ID: <016601cee3f7$44cbd780$ce638680$@bx.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKjcmuX2mpL/9O/4vEBAfSw2EoiNQI1xyzEAR+Coq0BaI8zcAJ+CQwLArAVKgkDj+8ESQHLim8TAkLFt4wBKnliYADwBSfCAVO87qOX2T20wA== Content-Language: ja Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 00:44:40 -0000 Lou, Thank you for your reply, this resolves all my comments. Best regards, zhenlong > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Sunday, November 17, 2013 11:50 PM > To: Gregory Mirsky; Zhenlong Cui; mpls@ietf.org > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-p2mp-framework > > I always found this term a bit counterintuitive so am happy that it has received limited use.... > > Lou > > > On November 15, 2013 4:50:37 PM Gregory Mirsky wrote: > > Hi Lou, et. al, > > though it might be not canonical but often "node that is both leaf and > > branch node" referred as "bud node". > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Lou Berger > > Sent: Friday, November 15, 2013 7:37 AM > > To: Zhenlong Cui; mpls@ietf.org > > Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > > Subject: Re: [mpls] working group last call on > > draft-ietf-mpls-tp-p2mp-framework > > > > > > Zhenlong, > > > > See below. I've cut topics with resolutions/agreements. > > > > On 11/14/2013 9:41 PM, Zhenlong Cui wrote: > > > Loa, > > > Thank you for your reply. Please see below for responses in-line. > > > > > >> -----Original Message----- > > >> From: Lou Berger [mailto:lberger@labn.net] > > >> Sent: Friday, November 15, 2013 1:11 AM > > >> To: Zhenlong Cui; mpls@ietf.org > > >> Cc: draft-ietf-mpls-tp-p2mp-framework@tools.ietf.org > > >> Subject: Re: [mpls] working group last call on > > draft-ietf-mpls-tp-p2mp-framework > > >> > > >> Zhenlong, > > >> > > >> Thank you for the comments. > > >> > > >> Here are your comments, as extracted from word, and my responses. > > >> (Clearly the page numbers are wrong.) > > >> > > > > [...] > > > > >> > > >>> Page 203: Inserted zc 11/14/2013 6:29:00 PM OAM Packets is sent to > > >>> all > > leaves and processed by Page 203: Deleted zc 11/14/2013 6:29:00 PM > > every OAM packet Page 203: Comment [zc4] zc 11/14/2013 8:42:00 PM I > > think that's not necessarily true. Because some on-demand OAM > > >> packets may be dropped > > >>> by intermediate node. That mean not every OAM packet is sent to leaves. > > >>> Page 203: Deleted zc 11/14/2013 6:29:00 PM is sent to all leaves, > > >>> and > > thus can impact > > >> > > >> So your point is that an intermediate node may drop an OAM packet? > > >> If > > so, yes, this is true for P2P case too. > > >> > > >> How about: > > >> DROP (redundant statement): > > >> thus every OAM packet is sent to all leaves, s/can impact/may be > > >> >> > > processed by > > > My primary concern: > > > I think there is a discrepancy between "every OAM packet is sent to > > > all > > leaves" and "To address a packet to an intermediate node in the tree, > > TTL based ..." > > > My understanding: > > > "every OAM packet is sent to all leaves" is equal to "no OAM packet > > > is > > sent to branches". > > > On the other hand, "To address a packet to an intermediate node in > > > the > > tree, TTL based ...", it seems meaning that "the root may send OAM > > packet to branches". > > > Is my understanding correct? > > > > > Okay, I understand your point. I think your reading / the text does > > not match our intent. (Which is certainly to allow for both MIP and > > MEP > > processing.) > > > > How about: > > s/to all leaves/towards all leaves > > > > Which will result in: > > All the traffic sent over a P2MP transport path, including > > OAM packets generated by a MEP, is sent (multicast) from the > > root towards all the leaves, and thus may be processed by all > > the MEs in a P2MP MEG. > > > > [...] > > > > > >> > > >>> Page 307: Deleted zc 11/14/2013 7:24:00 PM and Page 307: Inserted > > >>> zc > > >>> 11/14/2013 7:24:00 PM or Page 307: Comment [zc11] zc 11/14/2013 > > >>> 8:02:00 PM It is correct? > > >> How about: > > >> s/and/and, perhaps, > > > s/and/and? Is this a mistake? > > > My propose is s/and/or. > > > > > > > Sorry for not being clear. I was proposing the following final text: > > Fault notification happens from the node > > identifying the fault to the root node and, perhaps, from the > > leaves to the root via an out of band path. > > > > Now rereading the sentence I think I'd prefer just dropping the > > reference to leaves as it really doesn't add anything. How about: > > Fault notification happens from the node > > identifying the fault to the root node via an out of band path. > > > > And also dropping "In either case" immediately following to align the > > next sentence. > > > > That's it. Thank you again for your comments. > > > > Lou > > > > > Best regards, > > > zhenlong > > > [...] > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > From loa@pi.nu Mon Nov 18 07:19:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E611E82CA for ; Mon, 18 Nov 2013 07:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkUA4UXHg+dE for ; Mon, 18 Nov 2013 07:18:54 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id AD95E11E818D for ; Mon, 18 Nov 2013 07:11:26 -0800 (PST) Received: from [172.20.9.41] (unknown [72.29.212.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 112901802038; Mon, 18 Nov 2013 16:11:23 +0100 (CET) Message-ID: <528A2E1B.6060302@pi.nu> Date: Mon, 18 Nov 2013 10:11:23 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> <5289395D.7060603@pi.nu> <015b01cee3e2$a652a070$f2f7e150$@olddog.co.uk> In-Reply-To: <015b01cee3e2$a652a070$f2f7e150$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:19:07 -0000 Adrian, OK - that is pretty clear; - expand acronyms when they first appear in the document - if they are in the MPLS RFC Editors acronym list with an asterisk we might consider the acronym The only problem we have now is that this is not how the working group has reviewed the last 100 RFC, what we have done is to look at the acronym list we have not required expansion of acronyms other than in special cases. Hope we don't need to roll back and re-review :). /Loa On 2013-11-17 17:16, Adrian Farrel wrote: > The very next line from the one you quote says... > > In the following list of > abbreviations, those that are usually (but not necessarily) treated as > "well known" are marked with asterisks. > > Thus, anything not marked with an asterisk in the list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt may be regarded > as "not well known" and need expansion. > > In particular, it is not only the reader that you need to worry about, but also > the RFC Editor. If you are asking that the RFC Editor should expand these > acronyms for you, they need to know what you intend the expansion to be and they > of, course, have no insight on the technology to guide them. The alternative to > the authors expanding the acronyms now is a series of email exchanges during the > edit process where the RFC Editor questions the authors about what they meant. > > There is also a risk here that the RFC Editor will use the wrong expansion and > it will be missed in Auth48. Perhaps the best example in the Routing Area is > "LSP". > > Cheers, > Adrian > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: 17 November 2013 21:47 >> To: adrian@olddog.co.uk; draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: Re: AD review of draft-ietf-mpls-mldp-hsmp >> >> Adrian, >> >> I understand the latter part of the comments, but I'm confused about >> the requirement that the (most of) acronyms should be expanded; almost >> all of the are in the RFC Editor acronym list. The RFC Editor says: >> >> "Some abbreviations are so well known that expansion is probably >> unnecessary. The RFC Editor exercises editorial judgment about whether >> a particular use of one of the "well-known" abbreviations requires >> expansion." >> >> That is why I left then unexpanded during my review, and since the >> RFC-Editor promise to use " editorial judgment" I think we can leave it >> at that. >> >> /Loa >> >> On 2013-11-17 15:23, Adrian Farrel wrote: >>> Hi, >>> >>> I have done my usual AD review of your document having received the >>> publication request from the working group. The purpose of the review is >>> to catch and clean up any issues before the document goes to IETF last >>> call and IESG evaluation. >>> >>> The WG chairs tell me that there is at least one implementation and a >>> few planned implementations, so it is clear we should look at how to >>> advance this work. At the same time I have a number of issues with the >>> text that I believe need to be fixed or discussed before we can do that. >>> >>> Could you please work through the comments below and either produce a >>> revised document or let me know why I am wrong. >>> >>> Thanks, >>> Adrian >>> >>> =========== >>> >>> You will need to expand some acronyms on first use. >>> You need to expand them in the Abstract and in the main text even if >>> they are already expanded in the Abstract. >>> I see: >>> LSP >>> P2MP >>> OAM >>> PW >>> PE >>> P2P >>> VPMS >>> IPTV >>> FEC >>> LSR >>> LER >>> >>> --- >>> >>> Section 2 >>> >>> All good except would be good to actually expand the acronyms rather >>> than just explaining them. >>> >>> Perhaps also give a reference for mLDP. >>> >>> --- >>> >>> Please read the comments on Sections 3.1 to 3.3, below, and then the >>> meta-comment that follows. >>> >>> --- >>> >>> Section 3.1 >>> >>> I believe that the TicToc working group has agreed to change the status >>> of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only >>> describes an approach, and does not have consensus of the MPLS >>> community. >>> >>> So I think you should >>> >>> OLD >>> [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. >>> NEW >>> [I-D.ietf-tictoc-1588overmpls] describes a possible approach to >>> carry [IEEE1588] over an MPLS network. >>> END >>> >>> I do believe this use case in as much as timing synchronization benefits >>> from the forward and reverse paths being identical. I am less sure that >>> P2MP timing synchronization is a big requirement, but I am happy to >>> believe you if you say it is needed. >>> >>> --- >>> >>> I think you need to do some rewriting in Section 3.2 >>> >>> [I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has made >>> no progress for about 20 months. It appears to have been abandoned by >>> the WG. I think that part of the reason was that the solutions offered >>> provided too much complexity when the rend result could be achieved more >>> simply. >>> >>> This leads to wonder whether your use case is making too many >>> assumptions. >>> >>> You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your >>> reference, but to be honest with you, that I-D is not in a good place >>> either having been sent back to the WG by its AD. >>> >>> Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than >>> six months ago meaning it has made no progress for a year. >>> >>> You could rewrite this section to establish the requirements in your >>> text rather than by reference, but IMHO, the best thing is to remove the >>> whole section. >>> >>> --- >>> >>> As far as I can tell, section 3.3. does not provide a motivating use >>> case for this work. It is true that if you do have HSMP it would server >>> the purpose, but I do not believe that the IGMP messages or the channel >>> switch messages or whatever have to follow the reverse path of the P2MP >>> distribution tree. >>> >>> This makes me think that you have two classes of use case (in the set of >>> two use cases that remain after the removal of section 3.2). The first >>> is the type of use case that motivates the invention of HSMP. The second >>> is the type of use case that shows that HSMP could also be used for >>> other things. Really, we need to separate these out to see whether there >>> is real motivation for this work. >>> >>> Does this mean that the only reason for this work is time distribution >>> in a multicast network? >>> >>> --- >>> >>> The comments on Sections 3.1 to 3.3, above, make me wonder about the >>> value of Section 3. What does it add to the document? Was it intended to >>> prove that there is a purpose to this work, or was it just trying to >>> show some ways that HSMP might be used? >>> >>> If the latter, I recommend simply removing the whole section. >>> >>> If the former, I think you have failed! :-( >>> If you *do* want show that there is value in the work (and I don't >>> believe you need to *if* people are coding/deploying this function) then >>> I suspect that the real motivation for this work is that it provides >>> MP2MP functionality with the simplicity of a single hub compared to the >>> multiple "distributed" hubs of MP2MP LSPs. If you feel the need to show >>> a purpose, then I think *this* is the topic you need to discuss in >>> Section 3. >>> >>> --- >>> >>> Section 4 >>> >>> HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the >>> difference that the leaf LSRs can only send traffic to root node >>> along the same path of traffic from root node to leaf node. >>> >>> This paragraph is very ambiguous. >>> Is it that the LSRs can only send *traffic*? >>> Is it that the LSRs can only send *to*the*root*? >>> Or is it that the LSRs can only send *along*the*same*path* >>> >>> I think you need >>> >>> HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the >>> difference that in HSMP, when the leaf LSRs send traffic on the LSP, >>> the traffic is first delivered only to the root node and follows the >>> reverse path of traffic sent from the root node to the leaf node. The >>> root note then distributes the traffic on the P2MP tree to all of the >>> leaf nodes. >>> >>> --- >>> >>> Section 4 >>> >>> The transmission of packets from the root node of an HSMP LSP >>> to the receivers is identical to that of a P2MP LSP. Traffic from a >>> leaf node follows the upstream path toward the root node, along a >>> path that traverse the same nodes as the downstream node, but in >>> reverse order. >>> >>> I believe this says that traffic is delivered back to the sender in all >>> cases. Is that the intent? >>> >>> This makes for a significant difference between HSMP and MP2MP, doesn't >>> it? Shouldn't the document make this clearer? >>> >>> --- >>> >>> Although Figure 1 shows the settings of the U and F bits, I think you >>> should mention them explicitly. This seems to be important because it >>> impacts what happens if there is an LSR in the path that does not >>> support HSMP. >>> >>> --- >>> >>> Somewhat to my surprise, the use of the HSMP capability TLV is not >>> described anywhere. Reading between the lines in Section 4.1 I can see >>> that the new TLV is carried on the Initialization message. I can also >>> see that an implementation wishing to indicate it supports HSMP includes >>> the TLV and follow the procedures for indicating capabilities as defined >>> in RFC 5561. >>> >>> But I don't find anything saying MUST NOT use HSMP FEC is peer does not >>> support HSMP. >>> >>> I also don't understand what happens if I am tying to build an HSMP LSP >>> and discover that the next hop does not support HSMP. Can I have an >>> HSMP LSP with a hole in it? Does an LSR finding it cannot advance an >>> HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an >>> assumption that all nodes that might be on an HSMP tree will support >>> HSMP? >>> >>> I think you need to explain all this. You could look to RFC 6388 for >>> some suitable wording. >>> >>> --- >>> >>> Throughout Section 4 the references to 6388 for process may be "obvious" >>> but are broken. >>> >>> For example, in 4.3.1 you have >>> >>> Determining the upstream LSR for the HSMP LSP follows the >>> procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. >>> >>> But Section 3.3.1.1 of RFC 6388 says: >>> >>> Determining the upstream LDP peer U for an MP2MP LSP follows >>> the procedure for a P2MP LSP described in Section 2.4.1.1. >>> >>> This is a double indirection, so you should go direct to the source. >>> >>> For example, later in 4.3.1 you have >>> >>> Determining one's HSMP downstream LSR follows the procedure defined >>> in [RFC6388] section 3.3.1.2. >>> >>> But Section 3.3.1.2 of RFC 6388 says >>> >>> An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer >>> D will treat D as downstream MP2MP LSR. >>> >>> which is not helpful in the context of this I-D. >>> >>> I think the bottom line is that this document needs to be written to >>> desribe the processes that apply for these extensions. >>> >>> Looking to the future, there is a strong case to be made that HSMP >>> might get more traction than MP2MP (since it provides the same user >>> service with a number of simplifications). If this turns out to be the >>> case, you do not want this document to need to lean on RFC 6388. It >>> should be independent. By all means reference 6388 for comparison, but >>> do not use it to define your processes. >>> >>> --- >>> >>> I am unconvinced by Section 7. As I read the rest of the document, HSMP >>> has a high reliance on being able to produce a tree where the leaf-to- >>> root path is co-routed (in the opposite direction) with the root-to-leaf >>> path for each leaf. But I don't see anything in the document that >>> *makes* this happen. >>> >>> Section 7 seems to expose that the document assumes that co-routing will >>> happen fortuitously. That is, when it doesn't occur, the network is >>> requested to detect the fact and scream. >>> >>> If the main purpose of HSMP is the co-routing, shouldn't this be >>> factored into the protocol? >>> >>> If detection and reporting of non-co-routed HSMP LSPs is so important, >>> shouldn't the protocol enable it? And maybe the LSP shouldn't even come >>> up? >>> >> >> -- >> >> >> 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 internet-drafts@ietf.org Mon Nov 18 09:33:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38BA11E8177; Mon, 18 Nov 2013 09:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adc8BGV7Jo-X; Mon, 18 Nov 2013 09:33:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D283711E819C; Mon, 18 Nov 2013 09:32:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131118173204.18312.77427.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 09:32:04 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-p2mp-framework-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : A Framework for Point-to-Multipoint MPLS in Transport Ne= tworks Author(s) : Dan Frost Stewart Bryant Matthew Bocci Lou Berger Filename : draft-ietf-mpls-tp-p2mp-framework-05.txt Pages : 12 Date : 2013-11-18 Abstract: The Multiprotocol Label Switching Transport Profile is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-p2mp-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-p2mp-framework-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Mon Nov 18 16:52:59 2013 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 D40FA1AE7F3 for ; Mon, 18 Nov 2013 16:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 hFJvRAx6tZAW for ; Mon, 18 Nov 2013 16:52:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21A471AE7FB for ; Mon, 18 Nov 2013 16:52:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAL11547; Tue, 19 Nov 2013 00:52:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 00:52:43 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 00:52:49 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 08:52:43 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] wglc on draft-ietf-mpls-forwarding Thread-Index: AQHO4OE6kCSxfHmSpEW8hvz5tTV8b5orwWcQ Date: Tue, 19 Nov 2013 00:52:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08234158@NKGEML512-MBS.china.huawei.com> References: <52843518.6010202@pi.nu> In-Reply-To: <52843518.6010202@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: [mpls] =?gb2312?b?tPC4tDogIHdnbGMgb24gZHJhZnQtaWV0Zi1tcGxzLWZv?= =?gb2312?b?cndhcmRpbmc=?= 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, 19 Nov 2013 00:53:00 -0000 U3VwcG9ydC4gDQoNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBM b2ENCj4gQW5kZXJzc29uDQo+ILeiy83KsbzkOiAyMDEzxOoxMdTCMTTI1SAxMDoyOA0KPiDK1bz+ yMs6IG1wbHNAaWV0Zi5vcmcNCj4gs63LzTogbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1w bHMtZm9yd2FyZGluZyBjby1hdXRob3JzDQo+INb3zOI6IFttcGxzXSB3Z2xjIG9uIGRyYWZ0LWll dGYtbXBscy1mb3J3YXJkaW5nDQo+IA0KPiBXb3JraW5nIEdyb3VwLA0KPiANCj4gDQo+IHRoaXMg aXMgdG8gc3RhcnQgYSAyIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0 Zi1tcGxzLWZvcndhcmRpbmctMDIuDQo+IA0KPiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBh bmQgc2VuZCBjb21tZW50cyB0byB0aGUgbXBsc0BpZXRmLm9yZyBtYWlsaW5nDQo+IGxpc3QuDQo+ IA0KPiBUaGVyZSBhcmUgbm8gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+IA0K PiBIb3dldmVyLCB3ZSBrbm93IHRoYXQgc29tZSBvZiB0aGUgYXV0aG9yIGNvbnRhY3QgaW5mb3Jt YXRpb24gZm9yIHRoaXMNCj4gZG9jdW1lbnQgaXMgY2hhbmdpbmc7IHRoaXMgd2lsbCBiZSB1cGRh dGVkIHRvZ2V0aGVyIHdpdGggdGhlIG9mIHRoZSBsYXN0IGNhbGwNCj4gY29tbWVudHMuDQo+IA0K PiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBOb3ZlbWJlciAyOSAtIDIwMTMuDQo+ IA0KPiAvTG9hDQo+IA0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExTIEV4 cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9s b2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcg bGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0K From loa@pi.nu Tue Nov 19 11:54:33 2013 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 9CE5F1AE1CC for ; Tue, 19 Nov 2013 11:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 yI_JHkiXhQ67 for ; Tue, 19 Nov 2013 11:54:32 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE01AE1BF for ; Tue, 19 Nov 2013 11:54:31 -0800 (PST) Received: from [172.20.9.41] (unknown [72.29.212.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0BABE180203F; Tue, 19 Nov 2013 20:54:24 +0100 (CET) Message-ID: <528BC1F3.2050208@pi.nu> Date: Tue, 19 Nov 2013 14:54:27 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "kireeti@juniper.net" , "George Swallow (swallow)" , Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types 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, 19 Nov 2013 19:54:33 -0000 Nobo, My take on this is that when we now see that the authors of new drafts will want to allocate code point from "name spaces" that are not maintained by IANA. When this is the case we need to move the earlier allocated code points under IANA control. There are two ways of doing this - we can include the "old" allocations in the IANA section draft-akiya-mpls-entropy-lsp-ping; You will have create the "new/old" registries populated with the code points of both the new draft and what is in the old RFC. - or we can write a new I-D that need be published as an RFC before draft-akiya-mpls-entropy-lsp-ping; the IANA section of this draft should only include the "old" allocations. An implication of choosing this alternative is that the IANA section of draft-akiya-mpls-entropy-lsp-ping will need to request code point allocation in the format "TBA1, TBA2, ..." /Loa On 2013-11-14 19:06, Nobo Akiya (nobo) wrote: > Hi Kireeti, George, Nitin, > > I’m reaching out to authors of RFC4379/RFC6424 as part of follow up to > comments received for LSP ping for entropy label draft. > > http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-00 > > Authors would like to extend DS Flags (add 2 flags) and extend Multipath > Information Type (add 1 new type). > > However, IANA does not maintain DS Flags nor Multipath Information Type, > and wanted to check on background/thoughts with original authors of the > LSP ping mechanism. > > Should DS Flags and Multipath Information Types be maintained by IANA? > > Thank you. > > -Nobo > > > > _______________________________________________ > 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 loa@pi.nu Tue Nov 19 14:08:13 2013 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 16AAA1AE15E for ; Tue, 19 Nov 2013 14:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 gpqRY2RML98Z for ; Tue, 19 Nov 2013 14:08:11 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2C31AE152 for ; Tue, 19 Nov 2013 14:08:11 -0800 (PST) Received: from [172.20.9.41] (unknown [72.29.212.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DD0921802038; Tue, 19 Nov 2013 23:08:03 +0100 (CET) Message-ID: <528BE146.1030108@pi.nu> Date: Tue, 19 Nov 2013 17:08:06 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mpls-rt review of draft-ryoogray-mpls-tp-psc-itu 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, 19 Nov 2013 22:08:13 -0000 Working Group, I've reviewed draft-ryoogray-mpls-tp-psc-itu as part of the mpls-rt review. Is the document coherent - yes I think so, there are some issues but nothing that would stop an adoption as a working group document, I will hold the issues until we start working on the document as a working group document Is the document useful - yes is it likely that it will be deployed in operational networks Is the document technically sound - yes it is technically sound, but still a bit raw, quite a bit of working group effort will need to go into it I recommend that we accept the document as a working group document, it is a good starting point for the working group! / -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jrjahangir@gmail.com Wed Nov 20 05:33:28 2013 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 156B91ADF6C for ; Wed, 20 Nov 2013 05:33:28 -0800 (PST) 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 RbLO5_h0LZB7 for ; Wed, 20 Nov 2013 05:33:26 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C209C1ADF69 for ; Wed, 20 Nov 2013 05:33:25 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id a1so9220943wgh.12 for ; Wed, 20 Nov 2013 05:33:19 -0800 (PST) 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=nNSz5ht5YILiKtmvoLVAFrw/cYHD3Y7gQdBcZrJEvi4=; b=sNPUVn9/V53zmbeglJv7o2g3IaeXPVObYZOjqMRW8Tae6iMxiR5umoJFOpeqw76i/a CLlHn/aUvpYfmS/S0tXfZfQJ09J9gzT5a653SutCSIcRZOA/Nf+66U8wB29OwrMcbmd2 irOkfZBAD20YTiKRc2jD0Da9sqSHsnen2jj1U9Hp4gzUAkn1L4gIkxLqzYmDzjUov+mn GejGtDnXe9QGYda2OrS0H25t10hdejmJCXD9KCkTHWWHVyGO9jdL53FG6F6PrwqCy0KH PJCvEI4qKY5z79gUgcyEn07p18aJmf8GSm1og/0oO7oUasFmKX5YqKdHDCJA3Al1KH8k 6QNQ== MIME-Version: 1.0 X-Received: by 10.180.99.99 with SMTP id ep3mr1313304wib.11.1384954398916; Wed, 20 Nov 2013 05:33:18 -0800 (PST) Received: by 10.195.13.101 with HTTP; Wed, 20 Nov 2013 05:33:18 -0800 (PST) In-Reply-To: <52843518.6010202@pi.nu> References: <52843518.6010202@pi.nu> Date: Wed, 20 Nov 2013 19:33:18 +0600 Message-ID: From: Jahangir Hossain To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d044283c0fa47b004eb9bd293 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding 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, 20 Nov 2013 13:33:28 -0000 --f46d044283c0fa47b004eb9bd293 Content-Type: text/plain; charset=ISO-8859-1 I support this draft based on my initial understanding. Regards // Jahangir Hossain Open Communication Bangladesh On Thu, Nov 14, 2013 at 8:27 AM, Loa Andersson wrote: > Working Group, > > > this is to start a 2 week working group last call on > draft-ietf-mpls-forwarding-02. > > Please review the document and send comments to the > mpls@ietf.org mailing list. > > There are no IPR claims against this document. > > However, we know that some of the author contact information for this > document is changing; this will be updated together with the of > the last call comments. > > The working group last call ends November 29 - 2013. > > /Loa > > -- > > > 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 > -- --f46d044283c0fa47b004eb9bd293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this draft based on my initial understanding.

<= br>


Regards=A0 // = =A0Jahangir Hossain
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Open Communication
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bangladesh

On Thu, Nov 14, 2013 at 8:27 AM, Loa Andersson = <loa@pi= .nu> wrote:
Working Group,


this is to start a 2 week working group last call on
draft-ietf-mpls-forwarding-02.

Please review the document and send comments to the
mpls@ietf.org mailin= g list.

There are no IPR claims against this document.

However, we know that some of the author contact information for this
document is changing; this will be updated together with the of
the last call comments.

The working group last call ends November 29 - 2013.

/Loa

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
<= br>
=A0

=A0 =A0 =A0

--f46d044283c0fa47b004eb9bd293-- From Alexander.Vainshtein@ecitele.com Wed Nov 20 06:19:45 2013 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 6F34D1ADF92 for ; Wed, 20 Nov 2013 06:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 hBmuHwP-V533 for ; Wed, 20 Nov 2013 06:19:43 -0800 (PST) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDF61ADFA3 for ; Wed, 20 Nov 2013 06:19:40 -0800 (PST) X-AuditID: 93eaf2e7-b7f088e00000131c-29-528cd3713bd5 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id A2.05.04892.173DC825; Wed, 20 Nov 2013 17:21:21 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 16:19:32 +0200 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [mpls] wglc on draft-ietf-mpls-forwarding Thread-Index: AQHO4OE19N7wnbmjoU2NPwiWLaT9upouNP8Q Date: Wed, 20 Nov 2013 14:19:32 +0000 Message-ID: References: <52843518.6010202@pi.nu> In-Reply-To: <52843518.6010202@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.216.148] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTb0gTYRzHee7O81xenSvboxRcl0VU1tYqJ7mMILJXygr798Ku7XG72m5j d6WL/piR0ZRQCqJRarX+i4WIFRnmqhcapGaFBGZUlimRmTQsGt11aEL0vPo89/3+/tzD70fh +s9kKiWIMvKLvJsjdcTJwZHRdH93hc14KgwssXNncUv0WZiwvLp0LW4NnhMOj2E5odNlZM5o 9zcyD99WArJ4UfTKvIxYB5LsVi7PL+zl7QGOFRxWzsSxPjdvRx4kylaO9/mQ6OBW69h/TpZi E0QWiXavQxCdVm7Dxtx0i2VFZrqJWz1/rsm8SrfJJUgsSvfwgpv1IEninYhVvuxoxF13I22k r0VX3Bcqw0rAaSoIKAoyy2FZNCMIEhScCTtf3ySDQEfpmVYAm2KDQLs8BnC0KhqvukjGChtu 9JIqz2Bmw5dNY5iaCGd2wK6RIhWnMythMLJFc2TA2NPSeI2XweiTyjiVCWYePPKmmlCZZvLg wIvWP6xn0uDbypd/PAmKJ3a+HKgMlN6i7XWYyjhjgK/e12BazwwMN3fgGifDT+9icRqzsO/i 13jNvxjW3hshNV4EL58fwrW6SbDtzHtC86fA1qs9RCUwhCaVCE0KD00KD00KrwXEdZAsuH3y To/TaFqC7IKM3GiJ3etpANqsfLwDftSkRQBDAS6Rzmwut+nj+L1SwBMBKRTGJdPMwwqbfupO ryPg4iVXgX+PG0kRACmcm0EH7ysa7eAD+5DfOy6tU16wCk+dYvcqUynKBWaj8f8XzkBfKdmc q2ecyvztRsiH/ON5ZlEUB+kHavkkP3Ki4kLBLf+VMSpBbSNRaaNH9dCSj/dIglPT28GcVAPd qwqMKrj2iBOx41syCAzKT0+nP6iuRGWHJqIHlcSYkjg+pVxNrOzGhJRaAlpk867ebnNuqffH UfPw9gNFyUNj+TUV9dXr35Redkbyr8Lr79J6GoqeZdyKYG2HO7/nL+8/mG0yZr99nlV4/MLZ llbws75r4HXjiezhvsxqW8fSzi0O+GtKl9F2iC68+XyBO2nataqtvrRooPTRi+JNa/rX3q5L TDm2iCL2UwbDF46QXLxpIe6X+N832VsrAAQAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] wglc on draft-ietf-mpls-forwarding 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, 20 Nov 2013 14:19:45 -0000 Loa and all, I support this draft for publication. I will post a minor technical clarification to this draft in a separate emai= l. Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lo= a > Andersson > Sent: Thursday, November 14, 2013 4:28 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; mpls-forwarding co-authors > Subject: [mpls] wglc on draft-ietf-mpls-forwarding > > Working Group, > > > this is to start a 2 week working group last call on > draft-ietf-mpls-forwarding-02. > > Please review the document and send comments to the > mpls@ietf.org mailing list. > > There are no IPR claims against this document. > > However, we know that some of the author contact information for this > document is changing; this will be updated together with the of > the last call comments. > > The working group last call ends November 29 - 2013. > > /Loa > > -- > > > 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 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From nobo@cisco.com Wed Nov 20 06:32:08 2013 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 415341ADFE2 for ; Wed, 20 Nov 2013 06:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, 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 DfDZt79MCztJ for ; Wed, 20 Nov 2013 06:32:06 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6625D1ADFDD for ; Wed, 20 Nov 2013 06:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2555; q=dns/txt; s=iport; t=1384957920; x=1386167520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EqYFZbMB74Glr5NasfUSYJwzyCmpt4Y8OaQAEU5IMlk=; b=dHLo7mv1EiCD0UXkEuf9ANizmGT3hRmwP6Q8t6XbxFhE+hm80oNQj4HS 0gVwo2UmSIuR68YNue8t8bExwMf+bF9Sy8TuBBpsn2PUSM6E7LDCqhD4D AmOYLynmOmnk1fc4kVzaP8yZzNr9ITMyn+pn3Q7C+rV8XC/VuwK9tGUl+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAAHHjFKtJXHB/2dsb2JhbABZgmYhOFO+aoEWFnSCJQEBAQQBAQE3MQMLDAICAgEIEQQBAQEKFAkHGwwLFAkIAQEEAQ0FCId5AQzALhcEjgcRAYEJMQcGgxqBEgOZQYklhzmDKIFxOQ X-IronPort-AV: E=Sophos;i="4.93,737,1378857600"; d="scan'208";a="918123" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 20 Nov 2013 14:31:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAKEVxTl009447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 14:31:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 08:31:59 -0600 From: "Nobo Akiya (nobo)" To: Loa Andersson , "kireeti@juniper.net" , "George Swallow (swallow)" , Nitin Bahadur Thread-Topic: [mpls] LSP Ping DS Flags and Multipath Info Types Thread-Index: Ac7hlUCbc7xBFLF4QUya0kvMF4LXlQD/jEKAABpb6cA= Date: Wed, 20 Nov 2013 14:31:59 +0000 Message-ID: References: <528BC1F3.2050208@pi.nu> In-Reply-To: <528BC1F3.2050208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types 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, 20 Nov 2013 14:32:08 -0000 Hi Loa, I appreciate your guidance on this. I prefer the first approach suggested, = and will plan to go with it unless I hear opposing comments. -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Tuesday, November 19, 2013 2:54 PM > To: Nobo Akiya (nobo); kireeti@juniper.net; George Swallow (swallow); > Nitin Bahadur > Cc: mpls@ietf.org > Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types >=20 > Nobo, >=20 > My take on this is that when we now see that the authors of new drafts wi= ll > want to allocate code point from "name spaces" that are not maintained by > IANA. >=20 > When this is the case we need to move the earlier allocated code points > under IANA control. >=20 > There are two ways of doing this >=20 > - we can include the "old" allocations in the IANA section > draft-akiya-mpls-entropy-lsp-ping; > You will have create the "new/old" registries populated with the > code points of both the new draft and what is in the old RFC. >=20 > - or we can write a new I-D that need be published as an RFC before > draft-akiya-mpls-entropy-lsp-ping; the IANA section of this draft > should only include the "old" allocations. > An implication of choosing this alternative is that the IANA section > of draft-akiya-mpls-entropy-lsp-ping will need to request code point > allocation in the format "TBA1, TBA2, ..." >=20 > /Loa >=20 > On 2013-11-14 19:06, Nobo Akiya (nobo) wrote: > > Hi Kireeti, George, Nitin, > > > > I'm reaching out to authors of RFC4379/RFC6424 as part of follow up to > > comments received for LSP ping for entropy label draft. > > > > http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-00 > > > > Authors would like to extend DS Flags (add 2 flags) and extend > > Multipath Information Type (add 1 new type). > > > > However, IANA does not maintain DS Flags nor Multipath Information > > Type, and wanted to check on background/thoughts with original authors > > of the LSP ping mechanism. > > > > Should DS Flags and Multipath Information Types be maintained by IANA? > > > > Thank you. > > > > -Nobo > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=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 Alexander.Vainshtein@ecitele.com Wed Nov 20 06:35:55 2013 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 B6B0A1AE35E; Wed, 20 Nov 2013 06:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, 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 LxhtWoFcRyVP; Wed, 20 Nov 2013 06:35:53 -0800 (PST) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9F11AE369; Wed, 20 Nov 2013 06:35:51 -0800 (PST) X-AuditID: 93eaf2e7-b7f088e00000131c-1e-528cd73bc5eb Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 3C.65.04892.B37DC825; Wed, 20 Nov 2013 17:37:31 +0200 (IST) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([::1]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 16:35:43 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" , "kireeti@juniper.net" , "samante@apple.com" , "agmalis@gmail.com" , "cpignata@cisco.com" Thread-Topic: Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: Ac7l/cfceKBnwYAgQmeoXy+M5Z0ABw== Date: Wed, 20 Nov 2013 14:35:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.216.148] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA025392F92FILPTWPVEXMB01ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLsWRmVeSWpSXmKPExsUy+dWnL7o213uCDE4tYbY4/fwUm8WndztY LA4fmM5u8WPHJnaLf3PnMFvcWrqS1aLv0xYWi+PvP7BZfOj6werA6bH15A82jym/N7J67Jx1 l91jyZKfTB7Xm66yeyz+4ucxa3obm8ektWkBHFENjDaJeXn5JYklqQopqcXJtkoBRZllicmV SgqZKbZKhkoKBTmJyam5qXkltkqJBQWpeSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC 1FLXUMlOTdnQ2JorJCOzWCFVNzcxM0chN7W4ODE9VQEokrCFOWPys50sBRt1KtrunmJpYFyh 1sXIySEhYCLR+3kmM4QtJnHh3nq2LkYuDiGBg4wSS1dMYoFw1jBKrFvynR2kik3AVmLT6rtg VSICNxkltj/pZQdxmAXWMUq07XrNClIlLBAisbXlAiOILSIQKbHy8wMmCFtPYs38p2A2i4Cq xN+OpWwgNq9AgMTSd6fBehmB7vh+ag1YDbOAuMStJ/OZIO4TkFiy5zzUraISLx//Y4WwFSTu L/4IdAQHUH2+xKHrLBAjBSVOznzCAlEiKXFwxQ2WCYwis5BMnYXQMQtJB0SJjsSC3Z/YIGxt iWULXzPD2GcOPGZCFl/AyL6KUTQzp6AkKTfdwFAvNTmzJDUnVS85P3cTIySNPd/B+Gu+yiFG AQ5GJR5eyz3dQUKsiWXFlbmHGCU5mJREeYOO9QQJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHt 2guU401JrKxKLcqHSQUBw28isxR3cj4wNeeVxBsbGBDJURLnXd4Q7i8kkA5Mj9mpqQWpRTBD ZTg4lCR49x8H2idYlJqeWpGWmVOCkGbi4AS5iQfoplsgNbzFBYm5xZnpEPlTjLoct35++sYo xJKXn5cqJc57F6RIAKQoozQPbg4s271iFAeGhjDvU5AqHmCmhJv0CmgJE9ASdslukCXAfAOX kmpgPFQ0VdBK7LPpUr68XvGJZufFv01pP7v+U/l6nrsz94fuzWtXEauecMf+bcYF24cqXSka 6oF79XaJ3J9Rzvg0781zo1L+Lx27BSomBXk4z/h+fuNLcY3FFpOagnZv5dh9VHefU3mt+Zwd jTMvvUgvWeFyQVJsjsiqT2d0vS7fPTuxMrtq++EdV5VYijMSDbWYi4oTATLGZPBRBAAA Cc: "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: [mpls] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment 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, 20 Nov 2013 14:35:55 -0000 --_000_F9336571731ADE42A5397FC831CEAA025392F92FILPTWPVEXMB01ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I would like to comment on the text in Section 2.1.8.1 "Pseudowire Sequence= Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding Compliance and Performance R= equirements. This section states, in short, that the main drive for using the sequence nu= mber in the PW Control Word is handling of packet reordering events. TDM PWs= are presented as a major example, with CBR ATM services as another example. In fact, this statement is not accurate. The main drive for mandating the use of sequence number in TM PWs is the nee= d to detect and count lost packets because the egress PE MUST compensate the= lost payload bit for bit. Ability to compensate reordering of PW packets at egress is a side effect of= (a) sequence number usage and (b) usage of the de-jitter buffer in the egre= ss PW. It is not mandatory and in any case is limited by the depth of the de= -jitter buffer: re-ordered packets that cannot be accommodated within this b= uffer are treated as lost. Additional details can be found, e.g., in section 6.2.2 of RFC 4553. Ability to re-order mis-ordered PW packets is d= efined there as OPTIONAL, while replacement of the payload of lost PW packet= s is defined as MANDATORY. Hopefully these notes will be useful. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA025392F92FILPTWPVEXMB01ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,

I would like to comment on the text in Section 2.1.8.= 1 “Pseudowire Sequence Number” in

draft-ietf-mpls-forwarding-03 - MPLS Forwarding Compliance a= nd Performance Requirements.

 

This section states, in short, that the main drive fo= r using the sequence number in the PW Control Word is handling of packet reo= rdering events. TDM PWs are presented as a major example, with CBR ATM servi= ces as another example.

 

In fact, this statement is not accurate.

 

The main drive for mandating the use of sequence numb= er in TM PWs is the need to detect and count lost packets because the egress= PE MUST compensate the lost payload bit for bit.

 

Ability to compensate reordering of PW packets at egr= ess is a side effect of (a) sequence number usage and (b) usage of the de-ji= tter buffer in the egress PW. It is not mandatory and in any case is limited= by the depth of the de-jitter buffer: re-ordered packets that cannot be accommodated within this buffer a= re treated as lost.

 

Additional details can be found, e.g., in section 6.2= .2 of RFC 4553. Ability to re-order mis-ordered PW packets is defined there as= OPTIONAL, while replacement of the payload of lost PW packets is defined as= MANDATORY.

 

Hopefully these notes will be useful.

 

 

Regards,

     Sasha

 

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

--_000_F9336571731ADE42A5397FC831CEAA025392F92FILPTWPVEXMB01ec_-- From loa@pi.nu Wed Nov 20 06:56:15 2013 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 BB1701AE3E2 for ; Wed, 20 Nov 2013 06:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 PkGef8b5v5EV for ; Wed, 20 Nov 2013 06:56:14 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id EB1EB1AE3E1 for ; Wed, 20 Nov 2013 06:56:13 -0800 (PST) Received: from [172.20.9.41] (unknown [72.29.212.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A9A401802039; Wed, 20 Nov 2013 15:56:06 +0100 (CET) Message-ID: <528CCD89.5020205@pi.nu> Date: Wed, 20 Nov 2013 09:56:09 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "kireeti@juniper.net" , "George Swallow (swallow)" , Nitin Bahadur References: <528BC1F3.2050208@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types 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, 20 Nov 2013 14:56:15 -0000 Nobo, that works for me. /Loa On 2013-11-20 09:31, Nobo Akiya (nobo) wrote: > Hi Loa, > > I appreciate your guidance on this. I prefer the first approach suggested, and will plan to go with it unless I hear opposing comments. > > -Nobo > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Tuesday, November 19, 2013 2:54 PM >> To: Nobo Akiya (nobo); kireeti@juniper.net; George Swallow (swallow); >> Nitin Bahadur >> Cc: mpls@ietf.org >> Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types >> >> Nobo, >> >> My take on this is that when we now see that the authors of new drafts will >> want to allocate code point from "name spaces" that are not maintained by >> IANA. >> >> When this is the case we need to move the earlier allocated code points >> under IANA control. >> >> There are two ways of doing this >> >> - we can include the "old" allocations in the IANA section >> draft-akiya-mpls-entropy-lsp-ping; >> You will have create the "new/old" registries populated with the >> code points of both the new draft and what is in the old RFC. >> >> - or we can write a new I-D that need be published as an RFC before >> draft-akiya-mpls-entropy-lsp-ping; the IANA section of this draft >> should only include the "old" allocations. >> An implication of choosing this alternative is that the IANA section >> of draft-akiya-mpls-entropy-lsp-ping will need to request code point >> allocation in the format "TBA1, TBA2, ..." >> >> /Loa >> >> On 2013-11-14 19:06, Nobo Akiya (nobo) wrote: >>> Hi Kireeti, George, Nitin, >>> >>> I'm reaching out to authors of RFC4379/RFC6424 as part of follow up to >>> comments received for LSP ping for entropy label draft. >>> >>> http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-00 >>> >>> Authors would like to extend DS Flags (add 2 flags) and extend >>> Multipath Information Type (add 1 new type). >>> >>> However, IANA does not maintain DS Flags nor Multipath Information >>> Type, and wanted to check on background/thoughts with original authors >>> of the LSP ping mechanism. >>> >>> Should DS Flags and Multipath Information Types be maintained by IANA? >>> >>> Thank you. >>> >>> -Nobo >>> >>> >>> >>> _______________________________________________ >>> 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 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Wed Nov 20 07:30:29 2013 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 926EF1AE00A for ; Wed, 20 Nov 2013 07:30:29 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 RXa9bglxHlC6 for ; Wed, 20 Nov 2013 07:30:27 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2241ADFF3 for ; Wed, 20 Nov 2013 07:30:27 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAKFUJg0004378 for ; Wed, 20 Nov 2013 15:30:20 GMT Received: from 950129200 (63-235-172-3.dia.static.qwest.net [63.235.172.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAKFUIJx004362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Nov 2013 15:30:19 GMT From: "Adrian Farrel" To: References: <20131118163233.18312.62888.idtracker@ietfa.amsl.com> In-Reply-To: <20131118163233.18312.62888.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 15:30:17 -0000 Message-ID: <05f701cee605$6b7b7100$42725300$@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: AQIohLqhum4MHB3EukS4gnSeCQ5eFZl7ALQQ Content-Language: en-gb Subject: [mpls] FW: I-D Action: draft-mahesh-karp-rsvp-te-analysis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:30:29 -0000 I guess some of you will want to look at this work. Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 18 November 2013 16:33 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mahesh-karp-rsvp-te-analysis-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Analysis of RSVP-TE Security According to KARP Design Guide > Author(s) : Mahesh Jethanandani > Dacheng Zhang > Filename : draft-mahesh-karp-rsvp-te-analysis-02.txt > Pages : 9 > Date : 2013-11-15 > > Abstract: > This document analyzes Resource reSerVation Protocol-Traffic > Engineering (RSVP-TE) according to guidelines set forth in section > 4.2 of KARP Design Guidelines (RFC 6518). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mahesh-karp-rsvp-te-analysis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-mahesh-karp-rsvp-te-analysis-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From lizho.jin@gmail.com Wed Nov 20 08:26:16 2013 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 98F591ADFB4 for ; Wed, 20 Nov 2013 08:26:16 -0800 (PST) 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 DQxTd8O14oLB for ; Wed, 20 Nov 2013 08:26:13 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B18A71ADF7F for ; Wed, 20 Nov 2013 08:26:13 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so3690559pbc.20 for ; Wed, 20 Nov 2013 08:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=+4wuQUVBn/AfgFVYf0s4fvlO52w5YK5+ENfPGfbdIls=; b=oVnOOdBZlDVJ8uezLbEWVNRJKDmmKT5chGLsqM/FcECub5hk71bmSguC/JSgaZ2onZ dQMxeDy8flnBp4mNDxj6zlpWE+f75VynPjsmtqSN6s78xaeQJArQlYHNNpNIqa4pOIf2 PJohtd6UOa+WJNkelXNm7R+uC/J8Ci6YIYxzce3cjP/Y2wE+8GJoJNGtarH+4ywrCilK tIOoIwZ8Vr48vva4OBzj3oEPOT+R0dZUiiYC+v43nzWly2lW9C9yVHsLNI5rPhNfrpgB s7uDdb9JGCBnCmMG5ZfSxhsdqnQISgVxMgQS8kHMBS3orcs0Vr8UzM7UuiuwUoQ4gokB p3vQ== X-Received: by 10.68.172.65 with SMTP id ba1mr1643192pbc.18.1384964767389; Wed, 20 Nov 2013 08:26:07 -0800 (PST) Received: from LizhongPC ([114.62.232.243]) by mx.google.com with ESMTPSA id py4sm38928064pbb.33.2013.11.20.08.26.04 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Nov 2013 08:26:06 -0800 (PST) From: "Lizhong Jin" To: , References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> In-Reply-To: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> Date: Thu, 21 Nov 2013 00:26:04 +0800 Message-ID: <528ce29e.4488440a.7edd.ffffed33@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7j0ulIFPV3NWw1SyO2h/jAMWiQcACJqKaw Content-Language: zh-cn Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp 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, 20 Nov 2013 16:26:16 -0000 Hi Adrian, Thank you for the AD review. Please see my reply inline below. Regards Lizhong > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, November 18, 2013 4:24 AM > To: draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: AD review of draft-ietf-mpls-mldp-hsmp >=20 > Hi, >=20 > I have done my usual AD review of your document having received the > publication request from the working group. The purpose of the review > is > to catch and clean up any issues before the document goes to IETF last > call and IESG evaluation. >=20 > The WG chairs tell me that there is at least one implementation and a > few planned implementations, so it is clear we should look at how to > advance this work. At the same time I have a number of issues with the > text that I believe need to be fixed or discussed before we can do = that. >=20 > Could you please work through the comments below and either produce a > revised document or let me know why I am wrong. >=20 > Thanks, > Adrian >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > You will need to expand some acronyms on first use. > You need to expand them in the Abstract and in the main text even if > they are already expanded in the Abstract. > I see: > LSP > P2MP > OAM > PW > PE > P2P > VPMS > IPTV > FEC > LSR > LER [Lizhong] OK, will expand the acronyms. >=20 > --- >=20 > Section 2 >=20 > All good except would be good to actually expand the acronyms rather > than just explaining them. >=20 > Perhaps also give a reference for mLDP. [Lizhong] OK, will expand the acronyms. >=20 > --- >=20 > Please read the comments on Sections 3.1 to 3.3, below, and then the > meta-comment that follows. >=20 > --- >=20 > Section 3.1 >=20 > I believe that the TicToc working group has agreed to change the = status > of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only > describes an approach, and does not have consensus of the MPLS > community. >=20 > So I think you should >=20 > OLD > [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. > NEW > [I-D.ietf-tictoc-1588overmpls] describes a possible approach to > carry [IEEE1588] over an MPLS network. > END >=20 > I do believe this use case in as much as timing synchronization > benefits > from the forward and reverse paths being identical. I am less sure > that > P2MP timing synchronization is a big requirement, but I am happy to > believe you if you say it is needed. >=20 > --- >=20 > I think you need to do some rewriting in Section 3.2 >=20 > [I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has > made > no progress for about 20 months. It appears to have been abandoned by > the WG. I think that part of the reason was that the solutions offered > provided too much complexity when the rend result could be achieved > more > simply. >=20 > This leads to wonder whether your use case is making too many > assumptions. >=20 > You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your > reference, but to be honest with you, that I-D is not in a good place > either having been sent back to the WG by its AD. >=20 > Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than > six months ago meaning it has made no progress for a year. >=20 > You could rewrite this section to establish the requirements in your > text rather than by reference, but IMHO, the best thing is to remove > the > whole section. >=20 > --- >=20 > As far as I can tell, section 3.3. does not provide a motivating use > case for this work. It is true that if you do have HSMP it would = server > the purpose, but I do not believe that the IGMP messages or the = channel > switch messages or whatever have to follow the reverse path of the = P2MP > distribution tree. >=20 > This makes me think that you have two classes of use case (in the set > of > two use cases that remain after the removal of section 3.2). The first > is the type of use case that motivates the invention of HSMP. The > second > is the type of use case that shows that HSMP could also be used for > other things. Really, we need to separate these out to see whether > there > is real motivation for this work. >=20 > Does this mean that the only reason for this work is time distribution > in a multicast network? >=20 > --- >=20 > The comments on Sections 3.1 to 3.3, above, make me wonder about the > value of Section 3. What does it add to the document? Was it intended > to > prove that there is a purpose to this work, or was it just trying to > show some ways that HSMP might be used? >=20 > If the latter, I recommend simply removing the whole section. >=20 > If the former, I think you have failed! :-( > If you *do* want show that there is value in the work (and I don't > believe you need to *if* people are coding/deploying this function) > then > I suspect that the real motivation for this work is that it provides > MP2MP functionality with the simplicity of a single hub compared to = the > multiple "distributed" hubs of MP2MP LSPs. If you feel the need to = show > a purpose, then I think *this* is the topic you need to discuss in > Section 3. [Lizhong] I tend to remove section 3. The original purpose of section 3 = is trying to show some use cases the HSMP LSP might be applied.=20 >=20 > --- >=20 > Section 4 >=20 > HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the > difference that the leaf LSRs can only send traffic to root node > along the same path of traffic from root node to leaf node. >=20 > This paragraph is very ambiguous. > Is it that the LSRs can only send *traffic*? > Is it that the LSRs can only send *to*the*root*? > Or is it that the LSRs can only send *along*the*same*path* >=20 > I think you need >=20 > HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the > difference that in HSMP, when the leaf LSRs send traffic on the = LSP, > the traffic is first delivered only to the root node and follows = the > reverse path of traffic sent from the root node to the leaf node. > The > root note then distributes the traffic on the P2MP tree to all of > the > leaf nodes. [Lizhong] accepted, thanks. >=20 > --- >=20 > Section 4 >=20 > The transmission of packets from the root node of an HSMP LSP > to the receivers is identical to that of a P2MP LSP. Traffic from = a > leaf node follows the upstream path toward the root node, along a > path that traverse the same nodes as the downstream node, but in > reverse order. >=20 > I believe this says that traffic is delivered back to the sender in = all > cases. Is that the intent? >=20 > This makes for a significant difference between HSMP and MP2MP, = doesn't > it? Shouldn't the document make this clearer? [Lizhong] How about the below: The transmission of packets from the root node of an HSMP LSP to the receivers is identical to that of a P2MP LSP. Traffic from a leaf node follows the upstream path toward the root node, and would=20 not be sent to any other leaf nodes. The upstream path is the reverse path of traffic sent from the root node to the leaf node. >=20 > --- >=20 > Although Figure 1 shows the settings of the U and F bits, I think you > should mention them explicitly. This seems to be important because it > impacts what happens if there is an LSR in the path that does not > support HSMP. [Lizhong] OK, will add explicit description. >=20 > --- >=20 > Somewhat to my surprise, the use of the HSMP capability TLV is not > described anywhere. Reading between the lines in Section 4.1 I can see > that the new TLV is carried on the Initialization message. I can also > see that an implementation wishing to indicate it supports HSMP > includes > the TLV and follow the procedures for indicating capabilities as > defined > in RFC 5561. >=20 > But I don't find anything saying MUST NOT use HSMP FEC is peer does = not > support HSMP. >=20 > I also don't understand what happens if I am tying to build an HSMP = LSP > and discover that the next hop does not support HSMP. Can I have an > HSMP LSP with a hole in it? Does an LSR finding it cannot advance an > HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an > assumption that all nodes that might be on an HSMP tree will support > HSMP? >=20 > I think you need to explain all this. You could look to RFC 6388 for > some suitable wording. [Lizhong] How about to add the following: If the peer has not advertised the corresponding capability, then label=20 messages using the HSMP FEC Element SHOULD NOT be sent to the peer. In = that case, the HSMP LSP has not been completely established, and leaf node is = unable=20 to send any traffic to root node (see section 4.3.1 for detail). >=20 > --- >=20 > Throughout Section 4 the references to 6388 for process may be > "obvious" > but are broken. >=20 > For example, in 4.3.1 you have >=20 > Determining the upstream LSR for the HSMP LSP follows the > procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. >=20 > But Section 3.3.1.1 of RFC 6388 says: >=20 > Determining the upstream LDP peer U for an MP2MP LSP follows > the procedure for a P2MP LSP described in Section 2.4.1.1. >=20 > This is a double indirection, so you should go direct to the source. >=20 > For example, later in 4.3.1 you have >=20 > Determining one's HSMP downstream LSR follows the procedure defined > in [RFC6388] section 3.3.1.2. >=20 > But Section 3.3.1.2 of RFC 6388 says >=20 > An LDP peer U that receives an MP2MP-D Label Mapping from an LDP > peer > D will treat D as downstream MP2MP LSR. >=20 > which is not helpful in the context of this I-D. >=20 > I think the bottom line is that this document needs to be written to > desribe the processes that apply for these extensions. >=20 > Looking to the future, there is a strong case to be made that HSMP > might get more traction than MP2MP (since it provides the same user > service with a number of simplifications). If this turns out to be the > case, you do not want this document to need to lean on RFC 6388. It > should be independent. By all means reference 6388 for comparison, but > do not use it to define your processes. [Lizhong] OK, thanks. I will rephrase these sections in the updated = version. >=20 > --- >=20 > I am unconvinced by Section 7. As I read the rest of the document, = HSMP > has a high reliance on being able to produce a tree where the leaf-to- > root path is co-routed (in the opposite direction) with the root-to- > leaf > path for each leaf. But I don't see anything in the document that > *makes* this happen. >=20 > Section 7 seems to expose that the document assumes that co-routing > will > happen fortuitously. That is, when it doesn't occur, the network is > requested to detect the fact and scream. >=20 > If the main purpose of HSMP is the co-routing, shouldn't this be > factored into the protocol? >=20 > If detection and reporting of non-co-routed HSMP LSPs is so important, > shouldn't the protocol enable it? And maybe the LSP shouldn't even = come > up? [Lizhong] the intention of HSMP is to provide a leaf to root LSP path = along the same node of downstream path. I tend to remove the co-routing word = in the draft, and replace with the following description in section 7. The co-routed path would be achieved for HSMP. Both LSR U and LSR D = would ensure the=20 same interface to send traffic by some procedures. For a network with = symmetric IGP cost configuration, the following procedure MAY be used. To = determine the=20 downstream interface, LSR U MUST do a lookup in the unicast routing = table to=20 find the best interface and next-hop to reach LSR D. If the next-hop and = interface are also advertised by LSR D via the LDP session, it can be = used=20 to transmit the packet to LSR D. Determine the upstream interface = mechanism is same as determine downstream interface by exchanging the role of LSR = U and LSR D. Static route table configuration on LSR U and D could also be a possible = way=20 to ensure co-routed path. If co-routed is not required for HSMP LSP, LSR U is free to transmit the = packet=20 on any of the interfaces to LSR D, and vice versa. Thanks Lizhong From curtis@occnc.com Wed Nov 20 16:22:50 2013 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 D02AC1AE0C1; Wed, 20 Nov 2013 16:22:50 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_FAIL=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 ToeVrAI63-dy; Wed, 20 Nov 2013 16:22:47 -0800 (PST) Received: from daor.pair.com (daor.pair.com [209.68.5.146]) by ietfa.amsl.com (Postfix) with ESMTP id A39571ADF5E; Wed, 20 Nov 2013 16:22:47 -0800 (PST) Received: from [173.9.106.154] (unknown [173.9.106.154]) by daor.pair.com (Postfix) with ESMTPSA id A9C7810E4A9; Wed, 20 Nov 2013 19:22:36 -0500 (EST) Date: Wed, 20 Nov 2013 19:22:20 -0500 Message-ID: From: Curtis Villamizar To: Alexander Vainshtein MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=--_com.android.email_335386853140080_alt Cc: samante@apple.com, mpls@ietf.org, "kireeti@juniper.net " , "pwe3 \(pwe3@ietf.org\) " Subject: Re: [mpls] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment 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, 21 Nov 2013 00:22:51 -0000 ----_com.android.email_335386853140080_alt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U2FzaGEsCgpUaGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0LiAgSSdsbCBwcm9wb3NlIHJlcGxh Y2VtZW50IHRleHQgc2hvcnRseS4KCkN1cnRpcwoKU2VudCBmcm9tIG15IFZlcml6b24gV2lyZWxl c3MgNEcgTFRFIERST0lECgpBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+IHdyb3RlOgoKPjwhLS0gLyogRm9udCBEZWZpbml0aW9ucyAqLyBAZm9u dC1mYWNlIAl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsgCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30gLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8gcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbCAJe21hcmdpbjowY207IAltYXJnaW4tYm90dG9tOi4wMDAxcHQ7IAlmb250 LXNpemU6MTEuMHB0OyAJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9IGE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsgCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7IAljb2xvcjpibHVl OyAJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9IGE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZCAJe21zby1zdHlsZS1wcmlvcml0eTo5OTsgCWNvbG9yOnB1cnBsZTsgCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fSBzcGFuLkVtYWlsU3R5bGUxNyAJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7IAlmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyAJ Y29sb3I6d2luZG93dGV4dDt9IC5Nc29DaHBEZWZhdWx0IAl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7IAlmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30gQHBhZ2UgV29yZFNl Y3Rpb24xIAl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7IAltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30gZGl2LldvcmRTZWN0aW9uMSAJe3BhZ2U6V29yZFNlY3Rpb24xO30gLS0+IAo+ Cj5IaSBhbGwsCj4KPkkgd291bGQgbGlrZSB0byBjb21tZW50IG9uIHRoZSB0ZXh0IGluIFNlY3Rp b24gMi4xLjguMSDigJxQc2V1ZG93aXJlIFNlcXVlbmNlIE51bWJlcuKAnSBpbiAKPgo+ZHJhZnQt aWV0Zi1tcGxzLWZvcndhcmRpbmctMDMgLSBNUExTIEZvcndhcmRpbmcgQ29tcGxpYW5jZSBhbmQg UGVyZm9ybWFuY2UgUmVxdWlyZW1lbnRzLgo+Cj7CoAo+Cj5UaGlzIHNlY3Rpb24gc3RhdGVzLCBp biBzaG9ydCwgdGhhdCB0aGUgbWFpbiBkcml2ZSBmb3IgdXNpbmcgdGhlIHNlcXVlbmNlIG51bWJl ciBpbiB0aGUgUFcgQ29udHJvbCBXb3JkIGlzIGhhbmRsaW5nIG9mIHBhY2tldCByZW9yZGVyaW5n IGV2ZW50cy4gVERNIFBXcyBhcmUgcHJlc2VudGVkIGFzIGEgbWFqb3IgZXhhbXBsZSwgd2l0aCBD QlIgQVRNIHNlcnZpY2VzIGFzIGFub3RoZXIgZXhhbXBsZS4KPgo+wqAKPgo+SW4gZmFjdCwgdGhp cyBzdGF0ZW1lbnQgaXMgbm90IGFjY3VyYXRlLgo+Cj7CoAo+Cj5UaGUgbWFpbiBkcml2ZSBmb3Ig bWFuZGF0aW5nIHRoZSB1c2Ugb2Ygc2VxdWVuY2UgbnVtYmVyIGluIFRNIFBXcyBpcyB0aGUgbmVl ZCB0byBkZXRlY3QgYW5kIGNvdW50IGxvc3QgcGFja2V0cyBiZWNhdXNlIHRoZSBlZ3Jlc3MgUEUg TVVTVCBjb21wZW5zYXRlIHRoZSBsb3N0IHBheWxvYWQgYml0IGZvciBiaXQuIAo+Cj7CoAo+Cj5B YmlsaXR5IHRvIGNvbXBlbnNhdGUgcmVvcmRlcmluZyBvZiBQVyBwYWNrZXRzIGF0IGVncmVzcyBp cyBhIHNpZGUgZWZmZWN0IG9mIChhKSBzZXF1ZW5jZSBudW1iZXIgdXNhZ2UgYW5kIChiKSB1c2Fn ZSBvZiB0aGUgZGUtaml0dGVyIGJ1ZmZlciBpbiB0aGUgZWdyZXNzIFBXLiBJdCBpcyBub3QgbWFu ZGF0b3J5IGFuZCBpbiBhbnkgY2FzZSBpcyBsaW1pdGVkIGJ5IHRoZSBkZXB0aCBvZiB0aGUgZGUt aml0dGVyIGJ1ZmZlcjogcmUtb3JkZXJlZCBwYWNrZXRzIHRoYXQgY2Fubm90IGJlIGFjY29tbW9k YXRlZCB3aXRoaW4gdGhpcyBidWZmZXIgYXJlIHRyZWF0ZWQgYXMgbG9zdC4KPgo+wqAKPgo+QWRk aXRpb25hbCBkZXRhaWxzIGNhbiBiZSBmb3VuZCwgZS5nLiwgaW4gc2VjdGlvbiA2LjIuMiBvZiBS RkMgNDU1My4gQWJpbGl0eSB0byByZS1vcmRlciBtaXMtb3JkZXJlZCBQVyBwYWNrZXRzIGlzIGRl ZmluZWQgdGhlcmUgYXMgT1BUSU9OQUwsIHdoaWxlIHJlcGxhY2VtZW50IG9mIHRoZSBwYXlsb2Fk IG9mIGxvc3QgUFcgcGFja2V0cyBpcyBkZWZpbmVkIGFzIE1BTkRBVE9SWS4KPgo+wqAKPgo+SG9w ZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNlZnVsLgo+Cj7CoAo+Cj7CoAo+Cj5SZWdhcmRz LAo+Cj7CoMKgwqDCoCBTYXNoYQo+Cj7CoAo+Cj5UaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVu ZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNo IGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxl Y29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLiAKPgo= ----_com.android.email_335386853140080_alt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj48ZGl2PlNhc2hhLDwvZGl2PjxkaXY+PGJyLz48L2Rpdj48ZGl2PlRoYW5rcyBmb3IgcG9p bnRpbmcgdGhpcyBvdXQuJiMxNjA7IEkmIzM5O2xsIHByb3Bvc2UgcmVwbGFjZW1lbnQgdGV4dCBz aG9ydGx5LjwvZGl2PjxkaXY+PGJyLz48L2Rpdj48ZGl2PkN1cnRpczwvZGl2PjxkaXY+PGJyLz48 L2Rpdj48ZGl2Pjxmb250IHN0eWxlPSJjb2xvcjojMzMzMzMzIj48aT5TZW50IGZyb20gbXkgVmVy aXpvbiBXaXJlbGVzcyA0RyBMVEUgRFJPSUQ8L2k+PC9mb250PjwvZGl2PjwvZGl2Pjxicj48YnI+ QWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t Jmd0OyB3cm90ZTo8YnI+PGJyPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgd291bGQgbGlrZSB0byBjb21tZW50IG9uIHRoZSB0ZXh0IGluIFNlY3Rpb24gMi4xLjguMSAm IzgyMjA7UHNldWRvd2lyZSBTZXF1ZW5jZSBOdW1iZXImIzgyMjE7IGluDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbXBscy1mb3J3YXJkaW5nLTAzIj5kcmFmdC1pZXRmLW1wbHMtZm9yd2Fy ZGluZy0wMyAtIE1QTFMgRm9yd2FyZGluZyBDb21wbGlhbmNlIGFuZCBQZXJmb3JtYW5jZSBSZXF1 aXJlbWVudHM8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlY3Rpb24gc3RhdGVz LCBpbiBzaG9ydCwgdGhhdCB0aGUgbWFpbiBkcml2ZSBmb3IgdXNpbmcgdGhlIHNlcXVlbmNlIG51 bWJlciBpbiB0aGUgUFcgQ29udHJvbCBXb3JkIGlzIGhhbmRsaW5nIG9mIHBhY2tldCByZW9yZGVy aW5nIGV2ZW50cy4gVERNIFBXcyBhcmUgcHJlc2VudGVkIGFzIGEgbWFqb3IgZXhhbXBsZSwgd2l0 aCBDQlIgQVRNIHNlcnZpY2VzIGFzIGFub3RoZXIgZXhhbXBsZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW4gZmFjdCwgdGhpcyBzdGF0ZW1lbnQgaXMgbm90IGFjY3VyYXRlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgbWFpbiBkcml2ZSBmb3IgbWFuZGF0aW5nIHRoZSB1c2Ugb2Ygc2Vx dWVuY2UgbnVtYmVyIGluIFRNIFBXcyBpcyB0aGUgbmVlZCB0byBkZXRlY3QgYW5kIGNvdW50IGxv c3QgcGFja2V0cyBiZWNhdXNlIHRoZSBlZ3Jlc3MgUEUgTVVTVCBjb21wZW5zYXRlIHRoZSBsb3N0 IHBheWxvYWQgYml0IGZvciBiaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWJpbGl0eSB0 byBjb21wZW5zYXRlIHJlb3JkZXJpbmcgb2YgUFcgcGFja2V0cyBhdCBlZ3Jlc3MgaXMgYSBzaWRl IGVmZmVjdCBvZiAoYSkgc2VxdWVuY2UgbnVtYmVyIHVzYWdlIGFuZCAoYikgdXNhZ2Ugb2YgdGhl IGRlLWppdHRlciBidWZmZXIgaW4gdGhlIGVncmVzcyBQVy4gSXQgaXMgbm90IG1hbmRhdG9yeSBh bmQgaW4gYW55IGNhc2UgaXMgbGltaXRlZCBieSB0aGUgZGVwdGggb2YgdGhlIGRlLWppdHRlcg0K IGJ1ZmZlcjogcmUtb3JkZXJlZCBwYWNrZXRzIHRoYXQgY2Fubm90IGJlIGFjY29tbW9kYXRlZCB3 aXRoaW4gdGhpcyBidWZmZXIgYXJlIHRyZWF0ZWQgYXMgbG9zdC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWRkaXRpb25hbCBkZXRhaWxzIGNhbiBiZSBmb3VuZCwgZS5nLiwgaW4gc2VjdGlvbiA2 LjIuMiBvZiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTUzIj4NClJG QyA0NTUzPC9hPi4gQWJpbGl0eSB0byByZS1vcmRlciBtaXMtb3JkZXJlZCBQVyBwYWNrZXRzIGlz IGRlZmluZWQgdGhlcmUgYXMgT1BUSU9OQUwsIHdoaWxlIHJlcGxhY2VtZW50IG9mIHRoZSBwYXls b2FkIG9mIGxvc3QgUFcgcGFja2V0cyBpcyBkZWZpbmVkIGFzIE1BTkRBVE9SWS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNlZnVsLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FzaGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD4NClRoaXMgZS1tYWlsIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRh cnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9u IGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQg dGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo8L3A+DQo= ----_com.android.email_335386853140080_alt-- From matthew.bocci@alcatel-lucent.com Thu Nov 21 17:15:43 2013 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 DBA361AE0E2; Thu, 21 Nov 2013 17:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-ontaDgs0W0; Thu, 21 Nov 2013 17:15:41 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A89441A1F77; Thu, 21 Nov 2013 17:15:41 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAM1FVu5026672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Nov 2013 19:15:33 -0600 (CST) 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 rAM1FUCU021525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 02:15:31 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 22 Nov 2013 02:15:30 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Thread-Topic: Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO5yBViXeYAQSEMkaxB6wA8sJs3w== Date: Fri, 22 Nov 2013 01:15:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CEB45EA6580D2matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mpls@ietf.org" Subject: [mpls] Response to Liaison on Clarifying P2MP Combinations 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, 22 Nov 2013 01:15:44 -0000 --_000_CEB45EA6580D2matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PWE3 and MPLS Working Groups Please find below a draft response to the liaison from ITU-T SG15 of July 2= 013 on clarifying combinations of point to multipoint pseudowires and LSPs. Please direct any discussion to the PWE3 list. We would like to reply to the ITU by Wednesday 27th November. Regards Matthew and Andy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Body: Thank you for your liaison of July 2013 inquiring on the valid use of p2mp = pseudowires and LSPs. A new version of the "Requirements and Framework for = Point-to-Multipoint Pseudowires over MPLS PSNs" is available (see draft-ie= tf-pwe3-p2mp-pw-requirements-06.txt) that should help to clarify some of th= e points in your liaison. In general, point-to-point PWs are not intended to be used in conjunction w= ith P2MP LSPs. There is currently no way for the PEs terminating all of th= e P2MP LSP leaves to establish the applicable PW/FEC label mappings. We do= not believe that this case is supported by the PWE3 architecture. The onl= y current valid case for P2MP PWs is when used with corresponding P2MP LSPs= , as described in the draft referenced above. Best regards, Matthew Bocci Andrew Malis IETF PWE3 Working Group Chairs --_000_CEB45EA6580D2matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <26F0E485C898B54CB160CEFFFE82C5D2@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
PWE3 and MPLS Working Groups

Please find below a draft response to the liaison from ITU-T SG15 of J= uly 2013 on clarifying combinations of point to multipoint pseudowires and = LSPs.

Please direct any discussion to the PWE3 list.

We would like to reply to the ITU by Wednesday 27th November.

Regards

Matthew and Andy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Body: =

Thank you for your liaison of July 2013 inquiring on the valid use of = p2mp pseudowires and LSPs. A new version of the "Requirements and Fram= ework for Point-to-Multipoint Pseudowires over MPLS PSNs" is available= (see  draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should help to clarify some of the points in your liaison.
  
In general, point-to-point PWs are not intended to be used in conjunct= ion with P2MP LSPs.  There is currently no way for the PEs terminating= all of the P2MP LSP leaves to establish the applicable PW/FEC label mappin= gs.  We do not believe that this case is supported by the PWE3 architecture.  The only current valid case f= or P2MP PWs is when used with corresponding P2MP LSPs, as described in the = draft referenced above.

Best regards,


Matthew Bocci
Andrew Malis

IETF PWE3 Working Group Chairs
--_000_CEB45EA6580D2matthewboccialcatellucentcom_-- From eosborne@cisco.com Fri Nov 22 08:04:11 2013 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 5A9521ADFA4 for ; Fri, 22 Nov 2013 08:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.512 X-Spam-Level: X-Spam-Status: No, score=-13.512 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.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 5nzxsTzkQytt for ; Fri, 22 Nov 2013 08:04:09 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E51331ADF77 for ; Fri, 22 Nov 2013 08:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5292; q=dns/txt; s=iport; t=1385136242; x=1386345842; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8H8hjOvFtzFUE/8ZEY0auA7VAf9uJdiIZqBhpQCj31k=; b=EO6u9/iqCWVOXFZ/V1oUIHXykw+wxBs0y0DoZJ+Icn4+7gm7y1VSwSzd bkEGWZQ0wAOSG3aBAQRdp/LbLREQLvqbm5MCH+L3uZtBxWE8FNXK8i2jW SvxDp3tiVN7iJgPgmSOIYfMtpRaJve70op9iR+Io+rXM7U+3+IA+/zUA/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAHd/j1KtJXG9/2dsb2JhbABZgweBC7wXgSIWdIInAQQ6UQEaEAsJQhcPAQQBGod5wTsXjlZCgxaBEgOqJoMogio X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="scan'208";a="286906302" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 22 Nov 2013 16:04:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAMG41QD027967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 16:04:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 10:04:01 -0600 From: "Eric Osborne (eosborne)" To: "draft-ietf-mpls-forwarding@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: Comments on draft-ietf-mpls-forwarding-03 Thread-Index: Ac7nlmoYwFc53xV1RtutErtRwN2gxA== Date: Fri, 22 Nov 2013 16:04:00 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721047001F@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Comments on draft-ietf-mpls-forwarding-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, 22 Nov 2013 16:04:11 -0000 Some overdue comments post-Vancouver: Overall =3D=3D=3D=3D=3D=3D=3D The document tries to walk a fine line between "here's things we've learned= over time and which will bite you if you ignore them" and "here's how you = MUST do things". The former is great; the latter is a trap. I think this = doc would go over well if it was something like "The Hitchhiker's Guide To = Not Getting Your MPLS Implementation Totally Wrong", but 'Forwarding and Pe= rformance Requirements' feels like too mcuh of an ITU-style mandatory equip= ment spec. Is there any IETF precedent for requirements docs like this? Also, I note that there's not much in the document talking about how you ha= ndle RA packets for MPLS-TE. I hate to open up Yet Another Can Of Worms, b= ut the ability to deal with RA at a reasonable rate, including some TE scal= e numbers, would be cool. This sort of straddles the line between forwardi= ng and control plane, so should at least be hinted at. Section 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D I appreciate section 1.2, but I'm not sure it'll hold. As a vendor who's g= otten RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifyi= ng paragraph will do much. In absence of that, I have two options: i) claim conformance when asked ii) ignore the question (ii) doesn't always work Section 1.2 says ' RFC 2119 keywords are used where explicitly noted that t= he keywords indicate that operator experiences indicate a requirement, but there are no existing RFC requirements.' and 'Advice provided by this document may be ignored by implementations.' I don't get that. I read it as "MUST means MUST if operators have a requir= ement and there are no existing requirements". This seems to be a huge bac= kdoor to set any requirements you want. Section 1.3, I think most of what's in there belongs there. The only thing= I don't agree with is the inclusion of ACK-compression. It's great stuff = to talk about, but is it MPLS-specific? If yes, that's not clear from the = text. If no, what is it doing in an MPLS-specific document? Point 7 in Sec. 1.3 is one of those huge backdoor things I'm talking about: " The implementer and system designer SHOULD support adding an MPLS entropy label [RFC6790]. Deployments MAY enable this feature. See Section 2.4.4." 'SHOULD' in uppercase means "really ought to unless you have a very good re= ason not to", and uppercase makes it normative. This is where that line be= tween "really ought to because we know people want it" and "mandatory per s= pec" gets blurred. What does it mean to have 'SHOULD' in the face of the e= xculpatory disclaimer in 1.2? If the intent is to provide good advice to n= aive implementors, why not just say 'should' and be done with it? The doc = has lots of places where I think s/SHOULD/should/ is appropriate. Contrast this with text from section 2.1.3: " hardware should allow a timestamp to be placed in an outgoing packet at any specified byte position." Why is the first normative and the second not? What's the difference for t= he audience? Section 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D In line with my previous comment, I don't think Section 2.3 belongs in this= documenet. If you can hit sawtooth in IP-only networks (are there any of = those left? :) ) then it's not MPLS-specific. Section 2.4.5.1 is another one of those non-normative uppercase things. =20 " If no ELI is encountered, and the first nibble of payload contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support the ability to interpret the payload as IPv4 or IPv6 and extract and use appropriate fields from the IP headers." Where does this SHOULD come from? I didn't see anything similar in rfc6790= . Is this a normative requirement imposed on forwarding hardware? Or is i= t intended as "here's something you ought to do if you want to ship a usefu= l product". The latter is good stuff, but I don't see why it warrants norm= ative language. Sections 3 and 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I understand the intent of sections 3 and 4, but they make me nervous. "he= re's a bunch of tests you ought to run" means that if someone fails the tes= t they're held to account, and if the operator doesn't understand the quest= ions they're asking or the impact on their network then you may end up with= unnecessary confusion all around. Could you add something to these sectio= ns along the lines of "Here are some common tings that operators may wish t= o verify with their network equipment. The impact of a particular question= or test on the network operator's architecture needs to be carefully consi= dered, as not all negative answers have a negative impact on the network". = What I'm basically going for here is that the operator needs to understand= _why_ they're asking the question and whether that question has any impact= on their design. My fear is that this becomes a pass/fail checklist regar= dless of impact to any particular network. Section 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D What's the overlap with rfc5695, particularly section 6? =20 eric From loa@pi.nu Fri Nov 22 20:14:13 2013 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 332641AD986; Fri, 22 Nov 2013 20:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 WBme8SHfTKSJ; Fri, 22 Nov 2013 20:14:10 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6011AD8F2; Fri, 22 Nov 2013 20:14:10 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.29.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D2A621802038; Sat, 23 Nov 2013 05:14:00 +0100 (CET) Message-ID: <52902B86.7040901@pi.nu> Date: Sat, 23 Nov 2013 12:13:58 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 23 Nov 2013 04:14:13 -0000 Mathew, working groups, Good response! I'm OK with sending this! Thanks for the all the work! One small question and one suggetion. Ouestion: Is this intended to be sent "For Information"? Suggestuion: Since this was sent in two identical liaisons to PWE# and MPLS can we send it from the chairs of both working groups? /Loa mpls wg co-chair On 2013-11-22 09:15, Bocci, Matthew (Matthew) wrote: > PWE3 and MPLS Working Groups > > Please find below a draft response to the liaison from ITU-T SG15 of > July 2013 on clarifying combinations of point to multipoint pseudowires > and LSPs. > > Please direct any discussion to the PWE3 list. > > We would like to reply to the ITU by Wednesday 27th November. > > Regards > > Matthew and Andy > > =============== > > Body: > > Thank you for your liaison of July 2013 inquiring on the valid use of > p2mp pseudowires and LSPs. A new version of the "Requirements and > Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is > available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should > help to clarify some of the points in your liaison. > In general, point-to-point PWs are not intended to be used in > conjunction with P2MP LSPs. There is currently no way for the PEs > terminating all of the P2MP LSP leaves to establish the applicable > PW/FEC label mappings. We do not believe that this case is supported by > the PWE3 architecture. The only current valid case for P2MP PWs is when > used with corresponding P2MP LSPs, as described in the draft referenced > above. > > Best regards, > > > Matthew Bocci > Andrew Malis > > IETF PWE3 Working Group Chairs > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Sat Nov 23 06:14:47 2013 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 546FC1AE2F4; Sat, 23 Nov 2013 06:14:47 -0800 (PST) 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 N3C0gaZeDcAy; Sat, 23 Nov 2013 06:14:45 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F33B11ADEB5; Sat, 23 Nov 2013 06:14:44 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hm4so1889841wib.0 for ; Sat, 23 Nov 2013 06:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OaM68BZbAW8ZvTRxUz6YkXHOD6kGhi8CY5ny7MWOjyw=; b=l6bxA8mXPa3iNZOH2cWaU2uF7Xj+aZdnDJ0gVkLSgbP0ubo9YVhpb5c+EBOSG8ASUU HKvSVkVVbLIe8vhWRHxfdvVjqtq9XRCWbVCdmxf8Xmp1Ym9fKjvquOrjoBFnRV17tJHp D77tkJofpYm3gFT33X1NajAt5c84hreAyNicDWQTEmEXH47vJESt/IdHJciM2XWMKIFP l47AaSgwnNeT/Cr/HogyENCazBoZR8i0jBUrZkWbAaCEBPysTTNGUJtmKny3djmoKlQ6 JokqVxZ/1vbv6jQc9DryNcLi58BnDZkVfijFmKDiUbd4DyyDWCvqueNd7TE60CfNo39v EfDQ== X-Received: by 10.180.91.11 with SMTP id ca11mr6823833wib.39.1385216077082; Sat, 23 Nov 2013 06:14:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.127.68 with HTTP; Sat, 23 Nov 2013 06:14:17 -0800 (PST) In-Reply-To: <52902B86.7040901@pi.nu> References: <52902B86.7040901@pi.nu> From: "Andrew G. Malis" Date: Sat, 23 Nov 2013 09:14:17 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 23 Nov 2013 14:14:47 -0000 Loa, Yes, this is meant for information, not for action, and it's a good idea for it to come from both WGs in one response. Cheers, Andy On Fri, Nov 22, 2013 at 11:13 PM, Loa Andersson wrote: > Mathew, working groups, > > Good response! I'm OK with sending this! > > Thanks for the all the work! One small question and one suggetion. > > Ouestion: > Is this intended to be sent "For Information"? > > Suggestuion: > Since this was sent in two identical liaisons to PWE# and MPLS can we > send it from the chairs of both working groups? > > /Loa > mpls wg co-chair > > > > On 2013-11-22 09:15, Bocci, Matthew (Matthew) wrote: >> >> PWE3 and MPLS Working Groups >> >> Please find below a draft response to the liaison from ITU-T SG15 of >> July 2013 on clarifying combinations of point to multipoint pseudowires >> and LSPs. >> >> Please direct any discussion to the PWE3 list. >> >> We would like to reply to the ITU by Wednesday 27th November. >> >> Regards >> >> Matthew and Andy >> >> =============== >> >> Body: >> >> Thank you for your liaison of July 2013 inquiring on the valid use of >> p2mp pseudowires and LSPs. A new version of the "Requirements and >> Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is >> available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should >> help to clarify some of the points in your liaison. >> In general, point-to-point PWs are not intended to be used in >> conjunction with P2MP LSPs. There is currently no way for the PEs >> terminating all of the P2MP LSP leaves to establish the applicable >> PW/FEC label mappings. We do not believe that this case is supported by >> the PWE3 architecture. The only current valid case for P2MP PWs is when >> used with corresponding P2MP LSPs, as described in the draft referenced >> above. >> >> Best regards, >> >> >> Matthew Bocci >> Andrew Malis >> >> IETF PWE3 Working Group Chairs >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From huubatwork@gmail.com Sat Nov 23 06:43:16 2013 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 B4A371ADF10; Sat, 23 Nov 2013 06:43:16 -0800 (PST) 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 CvFCkhJAnleP; Sat, 23 Nov 2013 06:43:15 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB021AE0A3; Sat, 23 Nov 2013 06:43:14 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so3785890wid.0 for ; Sat, 23 Nov 2013 06:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TceBZQJM4EcekVi9YiPgJFTZ6Wm0b8HRlr5yw1mFj3s=; b=GF7s6aOQbtN2rqQ6ByWvvU8bgq5XADF+zr1COPlCjQQfQPx19II1MeHS3QMVMgZng8 mvL3XAoXDeGM7E0WDJHnr4fLiE1g9/+/GWKHEQLazSDUvcYsWQ/8b6sa/uTIGfAMk7kg pItyEMc67w3PKG9oQg67YMMCU4KYi/iHnZHYGBkDs35gq/Op9jcKTTZq2bxNGKvtC1Gu ZGhr4D28Ju6/fLBweiC3L4mx9B+HagPBUBy6Vzw8Av4lnKovsIXvny0yOKO8/cIK/CH0 mmIyTImtt2IL3PM9cisybncrss9AP2OJV/2wYzg3NXr17mg+EIiGUFcjBFbI3bGSv1UV fgkg== X-Received: by 10.180.185.242 with SMTP id ff18mr6998649wic.44.1385217786724; Sat, 23 Nov 2013 06:43:06 -0800 (PST) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id f15sm135747wik.6.2013.11.23.06.43.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 06:43:06 -0800 (PST) Message-ID: <5290BEFC.20308@gmail.com> Date: Sat, 23 Nov 2013 15:43:08 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Response to Liaison on Clarifying P2MP Combinations X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 14:43:17 -0000 Hello Matthew, You wrote: > PWE3 and MPLS Working Groups > > Please find below a draft response to the liaison from ITU-T SG15 of > July 2013 on clarifying combinations of point to multipoint pseudowires > and LSPs. Please see in-line [hvh] Best regards, Huub. > =============== > Body: > > Thank you for your liaison of July 2013 inquiring on the valid use of > p2mp pseudowires and LSPs. A new version of the "Requirements and > Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is > available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should > help to clarify some of the points in your liaison. [hvh] you mention that some of the points are clarified, are the remaining points clarified by another liaison or by the text that follows? > In general, point-to-point PWs are not intended to be used in > conjunction with P2MP LSPs. There is currently no way for the PEs > terminating all of the P2MP LSP leaves to establish the applicable > PW/FEC label mappings. We do not believe that this case is supported by > the PWE3 architecture. The only current valid case for P2MP PWs is when > used with corresponding P2MP LSPs, as described in the draft referenced > above. > > Best regards, > > > Matthew Bocci > Andrew Malis > > IETF PWE3 Working Group Chairs > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From ietf-secretariat-reply@ietf.org Sat Nov 23 18:58:37 2013 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 085E91A1F78 for ; Sat, 23 Nov 2013 18:58:37 -0800 (PST) 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 9sJgHylefEFg for ; Sat, 23 Nov 2013 18:58:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9971AE346 for ; Sat, 23 Nov 2013 18:58:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131124025835.19823.79620.idtracker@ietfa.amsl.com> Date: Sat, 23 Nov 2013 18:58:35 -0800 From: IETF Secretariat 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: Sun, 24 Nov 2013 02:58:37 -0000 Changed milestone "Submit draft-ietf-mpls-tp-1ton-protection for publication", set due date to March 2014 from November 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From Alexander.Vainshtein@ecitele.com Sun Nov 24 00:46:45 2013 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 5ACAA1AE0F8 for ; Sun, 24 Nov 2013 00:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 v49QxQqLaR5W for ; Sun, 24 Nov 2013 00:46:42 -0800 (PST) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF431AE03C for ; Sun, 24 Nov 2013 00:46:39 -0800 (PST) X-AuditID: 93eaf2e7-b7fb88e0000048b4-4b-5291cb702d88 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 2E.66.18612.07BC1925; Sun, 24 Nov 2013 11:48:32 +0200 (IST) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA02.ecitele.com ([::1]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 10:46:28 +0200 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" Thread-Topic: Comments on draft-ietf-mpls-forwarding-03 Thread-Index: Ac7nlmoYwFc53xV1RtutErtRwN2gxABWmTYA Date: Sun, 24 Nov 2013 08:46:27 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A275721047001F@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721047001F@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.220.148] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTN60zLUBkditBHNWYcRdwgLShUpcgHJhg1ENSY+KEO7aMdbae1 U4gYPyrKD25UMGolblRURJGKcUFEqj/qh7jFLbiBEsAtSoJKAs50ApIY39d595xz730v9xKY 5qtKR3C8B7l51s6o1Hhl7/f+pM33ffn6Jz3AeLGjI8JYWn0JGF+eOqvMwnKqBhuVOYHAL0VO /+MfqjxsrRdksDzv9LAeRFuQYDYxeW6umDWXMDRnMTEGhnbZWTNyIN5jYliXC/EWJlNN/3My RBnH04g3Oy0cbzUxS1fmJhmN8xckGZjMGdMMqYvUq2ycQKMkB8vZaQcSBNaKaDGyoQmzNRx9 hLtqUrY8e+5TesGtxHJAEJCaB3fWaMpBpAjjYPvrBpWENVQbgC1t9nKgFnE9gIGem2FCRZlg 8FxHGE+kUuC+K60KSYRRXgDP912PkIgYKg1276jHZVE6DHX2R4wYbgxdU0gYpxLgx+5vSgmT VB4s//QQkysvh6HWk+F4JLUCtg1fDceB2N3AvfqwF6O08GXXMYXcNQUDNx5gMo6FPZ1DShnT cPudXkzWz4XHm7+rZDwH1p7ow+S60fDu4S5c1sfDtjPP8Qqg9Y8p4R9j94+x+8fYjwO8DsRy dpenwGHVG5KRmfMgO0o2Ox1BIE9L91Xw+9j0EKAIwESR9OeKfI2SLRZKHCEQTyiYWNLf7MvX jC9wWkpsrGBb7y6yIyEEIIExE8llZSJHWtiSrcjtHKGWiD/ow3TjzE5xLnnP+lS9/v8XRkue 9q7J1VBWcQI3IeRC7pE8kwmCgWSdVD7ajaxoSyFn9/ylFUSk1EaU2MZuSUMKLtYhcFaZvwem 6rRkrURQEmEr4ke9I3vSC7Tio2PIvZIqStyiUXevmFghJo6I3yUlFrdjlNJ5wYv5CW+5WYn6 LhRS7wouOlCGX4rTzXxTW7fx4uJZcZ15lSeZwjL3s7kNd1917W8aPNI+/C14NLtpwoV1LelP s4PvGs2Tt/kaV1elOQqIjblOZ3p23cChhZtuD095P2lrWl+0vlt3+6H6w7ovke2GRF92aENW oL6Ua/rxc0+ntfqg8jKDCzbWMBtzC+wfSqkoBQIEAAA= Cc: "mpls@ietf.org" , "draft-ietf-mpls-forwarding@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-forwarding-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: Sun, 24 Nov 2013 08:46:45 -0000 Eric, You've asked (in the "Overall" section of your comment): Is there any IETF precedent for requirements docs like this? IMHO and FWIW RFC 2544 comes pretty close. And, as for encountering questions about the April Fools' RFCs in RFPs - wel= l, people could do much worse, IMO, then referring to RFC 1925... Regards, Sasha > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne > (eosborne) > Sent: Friday, November 22, 2013 6:04 PM > To: draft-ietf-mpls-forwarding@tools.ietf.org; mpls@ietf.org > Subject: [mpls] Comments on draft-ietf-mpls-forwarding-03 > > Some overdue comments post-Vancouver: > > Overall > =3D=3D=3D=3D=3D=3D=3D > The document tries to walk a fine line between "here's things we've learne= d > over time and which will bite you if you ignore them" and "here's how you > MUST do things". The former is great; the latter is a trap. I think this= doc would > go over well if it was something like "The Hitchhiker's Guide To Not Getti= ng > Your MPLS Implementation Totally Wrong", but 'Forwarding and Performance > Requirements' feels like too mcuh of an ITU-style mandatory equipment spec= . > Is there any IETF precedent for requirements docs like this? > > Also, I note that there's not much in the document talking about how you > handle RA packets for MPLS-TE. I hate to open up Yet Another Can Of Worms= , > but the ability to deal with RA at a reasonable rate, including some TE sc= ale > numbers, would be cool. This sort of straddles the line between forwardin= g and > control plane, so should at least be hinted at. > > > Section 1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > I appreciate section 1.2, but I'm not sure it'll hold. As a vendor who's= gotten > RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifying pa= ragraph > will do much. In absence of that, I have two options: > i) claim conformance when asked > ii) ignore the question > > (ii) doesn't always work > > > Section 1.2 says ' RFC 2119 keywords are used where explicitly noted that= the > keywords indicate that operator experiences indicate a > requirement, but there are no existing RFC requirements.' > > and > > 'Advice provided by this document may be ignored by implementations.' > > I don't get that. I read it as "MUST means MUST if operators have a > requirement and there are no existing requirements". This seems to be a h= uge > backdoor to set any requirements you want. > > > Section 1.3, I think most of what's in there belongs there. The only thin= g I don't > agree with is the inclusion of ACK-compression. It's great stuff to talk= about, > but is it MPLS-specific? If yes, that's not clear from the text. If no,= what is it > doing in an MPLS-specific document? > > Point 7 in Sec. 1.3 is one of those huge backdoor things I'm talking about= : > > " The implementer and system designer SHOULD support adding an MPLS > entropy label [RFC6790]. Deployments MAY enable this feature. > See Section 2.4.4." > > 'SHOULD' in uppercase means "really ought to unless you have a very good > reason not to", and uppercase makes it normative. This is where that line > between "really ought to because we know people want it" and "mandatory pe= r > spec" gets blurred. What does it mean to have 'SHOULD' in the face of the > exculpatory disclaimer in 1.2? If the intent is to provide good advice to= naive > implementors, why not just say 'should' and be done with it? The doc has= lots > of places where I think s/SHOULD/should/ is appropriate. > > Contrast this with text from section 2.1.3: " hardware should allow a > timestamp to be placed in an outgoing packet at any specified byte > position." > > Why is the first normative and the second not? What's the difference for= the > audience? > > > > > Section 2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > In line with my previous comment, I don't think Section 2.3 belongs in thi= s > documenet. If you can hit sawtooth in IP-only networks (are there any of= those > left? :) ) then it's not MPLS-specific. > > Section 2.4.5.1 is another one of those non-normative uppercase things. > " If no ELI is encountered, and the first nibble of payload > contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support > the ability to interpret the payload as IPv4 or IPv6 and extract > and use appropriate fields from the IP headers." > > Where does this SHOULD come from? I didn't see anything similar in rfc679= 0. > Is this a normative requirement imposed on forwarding hardware? Or is it > intended as "here's something you ought to do if you want to ship a useful > product". The latter is good stuff, but I don't see why it warrants norma= tive > language. > > > > > > Sections 3 and 4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I understand the intent of sections 3 and 4, but they make me nervous. "h= ere's > a bunch of tests you ought to run" means that if someone fails the test th= ey're > held to account, and if the operator doesn't understand the questions they= 're > asking or the impact on their network then you may end up with unnecessary > confusion all around. Could you add something to these sections along the > lines of "Here are some common tings that operators may wish to verify wit= h > their network equipment. The impact of a particular question or test on t= he > network operator's architecture needs to be carefully considered, as not a= ll > negative answers have a negative impact on the network". What I'm basical= ly > going for here is that the operator needs to understand _why_ they're aski= ng > the question and whether that question has any impact on their design. My > fear is that this becomes a pass/fail checklist regardless of impact to an= y > particular network. > > > > Section 4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > What's the overlap with rfc5695, particularly section 6? > > > > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From stbryant@cisco.com Sun Nov 24 01:45:41 2013 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 B16471AE17B for ; Sun, 24 Nov 2013 01:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, 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 E-hBtw_nz-F2 for ; Sun, 24 Nov 2013 01:45:39 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6C31AE159 for ; Sun, 24 Nov 2013 01:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7392; q=dns/txt; s=iport; t=1385286331; x=1386495931; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OoDa3Ncqvv65hPUzdZIiYQEU/LyI93sj6Zg5lDEThtY=; b=j6C6iyJNfkx+ozMEMjecl05MbKGAf6DKgGO5bopFrCtmeaQ2In5Sbdtp d5qmRPms2bITXpTJ2sgcQ14JvDX/adNU/joSEJmQPflwLZn32nPwXtBXc VVxKJMljFBzIcpIoUM+bO7Tzz0J8qaqkOaHrUI711BKkAnvZRnCP6RsCR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPPJkVKtJV2d/2dsb2JhbABZgwc4vHGBHRZ0giUBAQEDAQEBATc0CwUHBAIBCBEBAwEBARUJCQcnCxQDBggCBA4Fh3sGDb5iEwSOVAgrBwIEBIMWgRMDmBSSEoMo X-IronPort-AV: E=Sophos;i="4.93,761,1378857600"; d="scan'208";a="1823941" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 24 Nov 2013 09:45:31 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAO9jVw9008598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Nov 2013 09:45:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Sun, 24 Nov 2013 03:45:30 -0600 From: "Stewart Bryant (stbryant)" To: Alexander Vainshtein Thread-Topic: [mpls] Comments on draft-ietf-mpls-forwarding-03 Thread-Index: AQHO6PnohDC8JWCFEEyPOCbX4Ur8jg== Date: Sun, 24 Nov 2013 09:45:29 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A275721047001F@xmb-rcd-x09.cisco.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-forwarding@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-forwarding-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: Sun, 24 Nov 2013 09:45:41 -0000 Sasha RFC1812 was a requirements document, but the IETF never maintained it. Indeed now I remember it, I should take a look and see if it needs to be re= commended be made obsolete. Stewart Sent from my iPad > On 24 Nov 2013, at 08:46, "Alexander Vainshtein" wrote: >=20 > Eric, > You've asked (in the "Overall" section of your comment):=20 > > Is there any IETF precedent for requirements docs like this? > >=20 > IMHO and FWIW RFC 2544 comes pretty close.=20 >=20 > And, as for encountering questions about the April Fools' RFCs in RFPs - = well, people could do much worse, IMO, then referring to RFC 1925... >=20 > Regards, > Sasha >=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne >> (eosborne) >> Sent: Friday, November 22, 2013 6:04 PM >> To: draft-ietf-mpls-forwarding@tools.ietf.org; mpls@ietf.org >> Subject: [mpls] Comments on draft-ietf-mpls-forwarding-03 >>=20 >> Some overdue comments post-Vancouver: >>=20 >> Overall >> =3D=3D=3D=3D=3D=3D=3D >> The document tries to walk a fine line between "here's things we've lear= ned >> over time and which will bite you if you ignore them" and "here's how yo= u >> MUST do things". The former is great; the latter is a trap. I think th= is doc would >> go over well if it was something like "The Hitchhiker's Guide To Not Get= ting >> Your MPLS Implementation Totally Wrong", but 'Forwarding and Performance >> Requirements' feels like too mcuh of an ITU-style mandatory equipment sp= ec. >> Is there any IETF precedent for requirements docs like this? >>=20 >> Also, I note that there's not much in the document talking about how you >> handle RA packets for MPLS-TE. I hate to open up Yet Another Can Of Wor= ms, >> but the ability to deal with RA at a reasonable rate, including some TE = scale >> numbers, would be cool. This sort of straddles the line between forward= ing and >> control plane, so should at least be hinted at. >>=20 >>=20 >> Section 1 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> I appreciate section 1.2, but I'm not sure it'll hold. As a vendor who'= s gotten >> RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifying = paragraph >> will do much. In absence of that, I have two options: >> i) claim conformance when asked >> ii) ignore the question >>=20 >> (ii) doesn't always work >>=20 >>=20 >> Section 1.2 says ' RFC 2119 keywords are used where explicitly noted tha= t the >> keywords indicate that operator experiences indicate a >> requirement, but there are no existing RFC requirements.' >>=20 >> and >>=20 >> 'Advice provided by this document may be ignored by implementations.' >>=20 >> I don't get that. I read it as "MUST means MUST if operators have a >> requirement and there are no existing requirements". This seems to be a= huge >> backdoor to set any requirements you want. >>=20 >>=20 >> Section 1.3, I think most of what's in there belongs there. The only th= ing I don't >> agree with is the inclusion of ACK-compression. It's great stuff to tal= k about, >> but is it MPLS-specific? If yes, that's not clear from the text. If no= , what is it >> doing in an MPLS-specific document? >>=20 >> Point 7 in Sec. 1.3 is one of those huge backdoor things I'm talking abo= ut: >>=20 >> " The implementer and system designer SHOULD support adding an MPLS >> entropy label [RFC6790]. Deployments MAY enable this feature. >> See Section 2.4.4." >>=20 >> 'SHOULD' in uppercase means "really ought to unless you have a very good >> reason not to", and uppercase makes it normative. This is where that li= ne >> between "really ought to because we know people want it" and "mandatory = per >> spec" gets blurred. What does it mean to have 'SHOULD' in the face of t= he >> exculpatory disclaimer in 1.2? If the intent is to provide good advice = to naive >> implementors, why not just say 'should' and be done with it? The doc ha= s lots >> of places where I think s/SHOULD/should/ is appropriate. >>=20 >> Contrast this with text from section 2.1.3: " hardware should allow a >> timestamp to be placed in an outgoing packet at any specified byte >> position." >>=20 >> Why is the first normative and the second not? What's the difference fo= r the >> audience? >>=20 >>=20 >>=20 >>=20 >> Section 2 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> In line with my previous comment, I don't think Section 2.3 belongs in t= his >> documenet. If you can hit sawtooth in IP-only networks (are there any o= f those >> left? :) ) then it's not MPLS-specific. >>=20 >> Section 2.4.5.1 is another one of those non-normative uppercase things. >> " If no ELI is encountered, and the first nibble of payload >> contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support >> the ability to interpret the payload as IPv4 or IPv6 and extract >> and use appropriate fields from the IP headers." >>=20 >> Where does this SHOULD come from? I didn't see anything similar in rfc6= 790. >> Is this a normative requirement imposed on forwarding hardware? Or is i= t >> intended as "here's something you ought to do if you want to ship a usef= ul >> product". The latter is good stuff, but I don't see why it warrants nor= mative >> language. >>=20 >>=20 >>=20 >>=20 >>=20 >> Sections 3 and 4 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I understand the intent of sections 3 and 4, but they make me nervous. = "here's >> a bunch of tests you ought to run" means that if someone fails the test = they're >> held to account, and if the operator doesn't understand the questions th= ey're >> asking or the impact on their network then you may end up with unnecessa= ry >> confusion all around. Could you add something to these sections along t= he >> lines of "Here are some common tings that operators may wish to verify w= ith >> their network equipment. The impact of a particular question or test on= the >> network operator's architecture needs to be carefully considered, as not= all >> negative answers have a negative impact on the network". What I'm basic= ally >> going for here is that the operator needs to understand _why_ they're as= king >> the question and whether that question has any impact on their design. = My >> fear is that this becomes a pass/fail checklist regardless of impact to = any >> particular network. >>=20 >>=20 >>=20 >> Section 4 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> What's the overlap with rfc5695, particularly section 6? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> eric >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From adrian@olddog.co.uk Sun Nov 24 06:54:58 2013 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 02CC31AE2D4 for ; Sun, 24 Nov 2013 06:54:58 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 gD3VL2WEtM0k for ; Sun, 24 Nov 2013 06:54:55 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B84231AE2CD for ; Sun, 24 Nov 2013 06:54:54 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAOEsjja009921; Sun, 24 Nov 2013 14:54:45 GMT 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 rAOEsfNV009911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Nov 2013 14:54:42 GMT From: "Adrian Farrel" To: "'Lizhong Jin'" , References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> <528ce29e.4488440a.7edd.ffffed33@mx.google.com> In-Reply-To: <528ce29e.4488440a.7edd.ffffed33@mx.google.com> Date: Sun, 24 Nov 2013 14:54:41 -0000 Message-ID: <00ec01cee925$1d1091d0$5731b570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKA2ZT9n+urJ3by5MGg4ag7RJGDwAIkee94mL4lkMA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 14:54:58 -0000 Hi Lizhong, [snip] > > The comments on Sections 3.1 to 3.3, above, make me wonder about the > > value of Section 3. What does it add to the document? Was it = intended > > to prove that there is a purpose to this work, or was it just trying = to > > show some ways that HSMP might be used? > > > > If the latter, I recommend simply removing the whole section. [snip] > [Lizhong] I tend to remove section 3. The original purpose of section = 3 is > trying to show some use cases the HSMP LSP might be applied. That approach would work for me. [snip] > > Section 4 > > > > The transmission of packets from the root node of an HSMP LSP > > to the receivers is identical to that of a P2MP LSP. Traffic = from a > > leaf node follows the upstream path toward the root node, along a > > path that traverse the same nodes as the downstream node, but in > > reverse order. > > > > I believe this says that traffic is delivered back to the sender in = all > > cases. Is that the intent? > > > > This makes for a significant difference between HSMP and MP2MP, = doesn't > > it? Shouldn't the document make this clearer? > > [Lizhong] How about the below: > The transmission of packets from the root node of an HSMP LSP > to the receivers is identical to that of a P2MP LSP. Traffic from a > leaf node follows the upstream path toward the root node, and would > not be sent to any other leaf nodes. The upstream path is the > reverse path of traffic sent from the root node to the leaf node. OK. I see the confusion. Your text is making the distinction that traffic traveling upstream to = the root does so in a P2P fashion and is not branched to any other leaf = (as it would be in mp2mp). That is a good point to make clear. My question was about how traffic is distributed from the root back to = the leaf nodes. I believe that this use a single P2MP tree to distribute = traffic to all of the leaf nodes regardless of which leaf originated the = traffic. That is, there are not n distinct trees each containing (n-1) = nodes. Thus, it seems to me that the sender will receive a copy of every = packet that it sends to the root. If I am correct, and to include your point, I suggest the following = paragraph. The transmission of packets from the root node of an HSMP LSP to the = receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic = from a leaf node to the root follows the upstream path that is the = reverse of the path from the root to the leaf. Unlike an MP2MP LSP, = traffic from a leaf node does not branch toward other leaf nodes, but is = sent direct to the root where it is placed on the P2MP path and = distributed to all leaf nodes including the original sender. [snip] > > Somewhat to my surprise, the use of the HSMP capability TLV is not > > described anywhere. Reading between the lines in Section 4.1 I can = see > > that the new TLV is carried on the Initialization message. I can = also > > see that an implementation wishing to indicate it supports HSMP > > includes the TLV and follow the procedures for indicating = capabilities as > > defined in RFC 5561. > > > > But I don't find anything saying MUST NOT use HSMP FEC if peer does = not > > support HSMP. > > > > I also don't understand what happens if I am tying to build an HSMP = LSP > > and discover that the next hop does not support HSMP. Can I have an > > HSMP LSP with a hole in it? Does an LSR finding it cannot advance an > > HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an > > assumption that all nodes that might be on an HSMP tree will support > > HSMP? > > > > I think you need to explain all this. You could look to RFC 6388 for > > some suitable wording. > > [Lizhong] How about to add the following: > > If the peer has not advertised the corresponding capability, then = label > messages using the HSMP FEC Element SHOULD NOT be sent to the peer. In = that > case, the HSMP LSP has not been completely established, and leaf node = is unable > to send any traffic to root node (see section 4.3.1 for detail). Yes, but doesn't this mean that the root and some leaf nodes may think = that the LSP is more complete than it actually is? Maybe the DoD procedures mean that the root has knowledge of which leaf = nodes are fully attached? Perhaps this is all explained in the I-D and I can't remember it now, or = perhaps there are some unspoken assumptions about how many nodes support = these procedures and how LSPs get established. [snip] > > I am unconvinced by Section 7. As I read the rest of the document, = HSMP > > has a high reliance on being able to produce a tree where the = leaf-to- > > root path is co-routed (in the opposite direction) with the root-to- > > leaf path for each leaf. But I don't see anything in the document = that > > *makes* this happen. > > > > Section 7 seems to expose that the document assumes that co-routing > > will happen fortuitously. That is, when it doesn't occur, the = network is > > requested to detect the fact and scream. > > > > If the main purpose of HSMP is the co-routing, shouldn't this be > > factored into the protocol? > > > > If detection and reporting of non-co-routed HSMP LSPs is so = important, > > shouldn't the protocol enable it? And maybe the LSP shouldn't even = come > > up? > > [Lizhong] the intention of HSMP is to provide a leaf to root LSP path = along > the same node of downstream path. I tend to remove the co-routing word = in the > draft, and replace with the following description in section 7. >=20 > The co-routed path would be achieved for HSMP. Both LSR U and LSR D = would > ensure the same interface to send traffic by some procedures. For a = network > with symmetric IGP cost configuration, the following procedure MAY be = used. > To determine the downstream interface, LSR U MUST do a lookup in the = unicast > routing table to find the best interface and next-hop to reach LSR D. = If the next- > hop and interface are also advertised by LSR D via the LDP session, it = can be > used to transmit the packet to LSR D. Determine the upstream interface > mechanism is same as determine downstream interface by exchanging the > role of LSR U and LSR D. > > Static route table configuration on LSR U and D could also be a = possible way > to ensure co-routed path. >=20 > If co-routed is not required for HSMP LSP, LSR U is free to transmit = the packet > on any of the interfaces to LSR D, and vice versa. This is somewhat better. Thanks for the effort. Adrian From loa@pi.nu Sun Nov 24 17:04:59 2013 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 6E46C1AE32D for ; Sun, 24 Nov 2013 17:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 8lniOIF9k_G9 for ; Sun, 24 Nov 2013 17:04:55 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 561F01AE30F for ; Sun, 24 Nov 2013 17:04:55 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.29.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AD44718014F6 for ; Mon, 25 Nov 2013 02:04:45 +0100 (CET) Message-ID: <5292A22C.60704@pi.nu> Date: Mon, 25 Nov 2013 09:04:44 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A275721047001F@xmb-rcd-x09.cisco.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Comments on draft-ietf-mpls-forwarding-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, 25 Nov 2013 01:04:59 -0000 Folks, trawling the T´RFC sea I alos come up with STD3 and RFC 5505, they are requirement documents and maintained. Whether they are close enough to to Eric's question about a precedence for draft-ietf-mpls-forwarding is a bit open. But I don't see that it really matters. /Loa On 2013-11-24 17:45, Stewart Bryant (stbryant) wrote: > Sasha > > RFC1812 was a requirements document, but the IETF never maintained it. > > Indeed now I remember it, I should take a look and see if it needs to be recommended be made obsolete. > > Stewart > > > > Sent from my iPad > >> On 24 Nov 2013, at 08:46, "Alexander Vainshtein" wrote: >> >> Eric, >> You've asked (in the "Overall" section of your comment): >> >> Is there any IETF precedent for requirements docs like this? >> >> >> IMHO and FWIW RFC 2544 comes pretty close. >> >> And, as for encountering questions about the April Fools' RFCs in RFPs - well, people could do much worse, IMO, then referring to RFC 1925... >> >> Regards, >> Sasha >> >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne >>> (eosborne) >>> Sent: Friday, November 22, 2013 6:04 PM >>> To: draft-ietf-mpls-forwarding@tools.ietf.org; mpls@ietf.org >>> Subject: [mpls] Comments on draft-ietf-mpls-forwarding-03 >>> >>> Some overdue comments post-Vancouver: >>> >>> Overall >>> ======= >>> The document tries to walk a fine line between "here's things we've learned >>> over time and which will bite you if you ignore them" and "here's how you >>> MUST do things". The former is great; the latter is a trap. I think this doc would >>> go over well if it was something like "The Hitchhiker's Guide To Not Getting >>> Your MPLS Implementation Totally Wrong", but 'Forwarding and Performance >>> Requirements' feels like too mcuh of an ITU-style mandatory equipment spec. >>> Is there any IETF precedent for requirements docs like this? >>> >>> Also, I note that there's not much in the document talking about how you >>> handle RA packets for MPLS-TE. I hate to open up Yet Another Can Of Worms, >>> but the ability to deal with RA at a reasonable rate, including some TE scale >>> numbers, would be cool. This sort of straddles the line between forwarding and >>> control plane, so should at least be hinted at. >>> >>> >>> Section 1 >>> ========= >>> I appreciate section 1.2, but I'm not sure it'll hold. As a vendor who's gotten >>> RFPs for April Fools RFCS (yes...really), I doubt any self-indemnifying paragraph >>> will do much. In absence of that, I have two options: >>> i) claim conformance when asked >>> ii) ignore the question >>> >>> (ii) doesn't always work >>> >>> >>> Section 1.2 says ' RFC 2119 keywords are used where explicitly noted that the >>> keywords indicate that operator experiences indicate a >>> requirement, but there are no existing RFC requirements.' >>> >>> and >>> >>> 'Advice provided by this document may be ignored by implementations.' >>> >>> I don't get that. I read it as "MUST means MUST if operators have a >>> requirement and there are no existing requirements". This seems to be a huge >>> backdoor to set any requirements you want. >>> >>> >>> Section 1.3, I think most of what's in there belongs there. The only thing I don't >>> agree with is the inclusion of ACK-compression. It's great stuff to talk about, >>> but is it MPLS-specific? If yes, that's not clear from the text. If no, what is it >>> doing in an MPLS-specific document? >>> >>> Point 7 in Sec. 1.3 is one of those huge backdoor things I'm talking about: >>> >>> " The implementer and system designer SHOULD support adding an MPLS >>> entropy label [RFC6790]. Deployments MAY enable this feature. >>> See Section 2.4.4." >>> >>> 'SHOULD' in uppercase means "really ought to unless you have a very good >>> reason not to", and uppercase makes it normative. This is where that line >>> between "really ought to because we know people want it" and "mandatory per >>> spec" gets blurred. What does it mean to have 'SHOULD' in the face of the >>> exculpatory disclaimer in 1.2? If the intent is to provide good advice to naive >>> implementors, why not just say 'should' and be done with it? The doc has lots >>> of places where I think s/SHOULD/should/ is appropriate. >>> >>> Contrast this with text from section 2.1.3: " hardware should allow a >>> timestamp to be placed in an outgoing packet at any specified byte >>> position." >>> >>> Why is the first normative and the second not? What's the difference for the >>> audience? >>> >>> >>> >>> >>> Section 2 >>> ========= >>> In line with my previous comment, I don't think Section 2.3 belongs in this >>> documenet. If you can hit sawtooth in IP-only networks (are there any of those >>> left? :) ) then it's not MPLS-specific. >>> >>> Section 2.4.5.1 is another one of those non-normative uppercase things. >>> " If no ELI is encountered, and the first nibble of payload >>> contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support >>> the ability to interpret the payload as IPv4 or IPv6 and extract >>> and use appropriate fields from the IP headers." >>> >>> Where does this SHOULD come from? I didn't see anything similar in rfc6790. >>> Is this a normative requirement imposed on forwarding hardware? Or is it >>> intended as "here's something you ought to do if you want to ship a useful >>> product". The latter is good stuff, but I don't see why it warrants normative >>> language. >>> >>> >>> >>> >>> >>> Sections 3 and 4 >>> ================ >>> I understand the intent of sections 3 and 4, but they make me nervous. "here's >>> a bunch of tests you ought to run" means that if someone fails the test they're >>> held to account, and if the operator doesn't understand the questions they're >>> asking or the impact on their network then you may end up with unnecessary >>> confusion all around. Could you add something to these sections along the >>> lines of "Here are some common tings that operators may wish to verify with >>> their network equipment. The impact of a particular question or test on the >>> network operator's architecture needs to be carefully considered, as not all >>> negative answers have a negative impact on the network". What I'm basically >>> going for here is that the operator needs to understand _why_ they're asking >>> the question and whether that question has any impact on their design. My >>> fear is that this becomes a pass/fail checklist regardless of impact to any >>> particular network. >>> >>> >>> >>> Section 4 >>> ========= >>> What's the overlap with rfc5695, particularly section 6? >>> >>> >>> >>> >>> >>> >>> >>> >>> eric >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Sun Nov 24 17:21:08 2013 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 CE7061AE35E; Sun, 24 Nov 2013 17:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 7KXIXAuxmE6U; Sun, 24 Nov 2013 17:21:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 22D991AE206; Sun, 24 Nov 2013 17:21:07 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.29.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1A02F18014F6; Mon, 25 Nov 2013 02:20:56 +0100 (CET) Message-ID: <5292A5F7.3010609@pi.nu> Date: Mon, 25 Nov 2013 09:20:55 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: huubatwork@gmail.com, "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" References: <5290BEFC.20308@gmail.com> In-Reply-To: <5290BEFC.20308@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 25 Nov 2013 01:21:09 -0000 Folks, I think what should be done is to drop "some of" from the first paragraph and in the second say "Additionally, point-to-point PWs are not in general intended to ..." /Loa On 2013-11-23 22:43, Huub van Helvoort wrote: > Hello Matthew, > > You wrote: > > > PWE3 and MPLS Working Groups >> >> Please find below a draft response to the liaison from ITU-T SG15 of >> July 2013 on clarifying combinations of point to multipoint pseudowires >> and LSPs. > > Please see in-line [hvh] > Best regards, Huub. > >> =============== >> Body: >> >> Thank you for your liaison of July 2013 inquiring on the valid use of >> p2mp pseudowires and LSPs. A new version of the "Requirements and >> Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is >> available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that should >> help to clarify some of the points in your liaison. > > [hvh] you mention that some of the points are clarified, are the > remaining points clarified by another liaison or by the text that > follows? > >> In general, point-to-point PWs are not intended to be used in >> conjunction with P2MP LSPs. There is currently no way for the PEs >> terminating all of the P2MP LSP leaves to establish the applicable >> PW/FEC label mappings. We do not believe that this case is supported by >> the PWE3 architecture. The only current valid case for P2MP PWs is when >> used with corresponding P2MP LSPs, as described in the draft referenced >> above. >> >> Best regards, >> >> >> Matthew Bocci >> Andrew Malis >> >> IETF PWE3 Working Group Chairs >> >> >> _______________________________________________ >> 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 lizho.jin@gmail.com Sun Nov 24 19:05:01 2013 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 A655D1A1F3E for ; Sun, 24 Nov 2013 19:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 SccCH787j5l0 for ; Sun, 24 Nov 2013 19:04:44 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id C21881A1F55 for ; Sun, 24 Nov 2013 19:03:18 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so4505113pdj.26 for ; Sun, 24 Nov 2013 19:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=NDjtP7LKrrXCxFJRch3pL+sxKhv/M2fx5m4xzVzAkgE=; b=o6v8pny3L/iMMsThC6h1Te/2SJzyMEAYXzi1W9kuEKcs/ILuIQrpraSKZikI1HYBVY wKcgP33vkrnWpZMGKNyLE9+9s/T4x14ZywLi3OmuV1DwsKhTPEDMwDeFnNGCmkM96UgW /geZt381lXPB0UDlv5vu4SV72lbK2GF0Fevc59ZX4maRCdxrKP1xHXnLxwmFl9iIQ9Vr xVi6be4rCYRcFYkojX/O/G/xIBsRmyBcfkA011Wcfl/xKyLYvMibTKR5WZ/0V4Pr+6cV 2Ya/7/ru9t/3LxmgvINwpJM62dCsMgiyISIs8jacGp4AJPhIIqVgC3Q4umqoUcC2VJWI FqLg== X-Received: by 10.66.162.167 with SMTP id yb7mr25535795pab.16.1385348598724; Sun, 24 Nov 2013 19:03:18 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id uf2sm69487898pbc.28.2013.11.24.19.03.15 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 24 Nov 2013 19:03:17 -0800 (PST) From: "Lizhong Jin" To: , References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> <528ce29e.4488440a.7edd.ffffed33@mx.google.com> <00ec01cee925$1d1091d0$5731b570$@olddog.co.uk> In-Reply-To: <00ec01cee925$1d1091d0$5731b570$@olddog.co.uk> Date: Mon, 25 Nov 2013 11:03:12 +0800 Message-ID: <009501cee98a$e3ab3510$ab019f30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKA2ZT9n+urJ3by5MGg4ag7RJGDwAIkee94AlPUX5OYrZRVsA== Content-Language: zh-cn Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp 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, 25 Nov 2013 03:05:01 -0000 Hi Adrian, Thank you for the review. See inline for the reply. I will upload a new = version soon to reflect all the review comments. Regards Lizhong [snip] > > Section 4 > > > > The transmission of packets from the root node of an HSMP LSP > > to the receivers is identical to that of a P2MP LSP. Traffic = from a > > leaf node follows the upstream path toward the root node, along a > > path that traverse the same nodes as the downstream node, but in > > reverse order. > > > > I believe this says that traffic is delivered back to the sender in=20 > > all cases. Is that the intent? > > > > This makes for a significant difference between HSMP and MP2MP,=20 > > doesn't it? Shouldn't the document make this clearer? > > [Lizhong] How about the below: > The transmission of packets from the root node of an HSMP LSP to the=20 > receivers is identical to that of a P2MP LSP. Traffic from a leaf=20 > node follows the upstream path toward the root node, and would not be=20 > sent to any other leaf nodes. The upstream path is the reverse path of = > traffic sent from the root node to the leaf node. OK. I see the confusion. Your text is making the distinction that traffic traveling upstream to = the root does so in a P2P fashion and is not branched to any other leaf = (as it would be in mp2mp). That is a good point to make clear. My question was about how traffic is distributed from the root back to = the leaf nodes. I believe that this use a single P2MP tree to distribute = traffic to all of the leaf nodes regardless of which leaf originated the = traffic. That is, there are not n distinct trees each containing (n-1) = nodes. Thus, it seems to me that the sender will receive a copy of every = packet that it sends to the root. If I am correct, and to include your point, I suggest the following = paragraph. The transmission of packets from the root node of an HSMP LSP to the = receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic = from a leaf node to the root follows the upstream path that is the = reverse of the path from the root to the leaf. Unlike an MP2MP LSP, = traffic from a leaf node does not branch toward other leaf nodes, but is = sent direct to the root where it is placed on the P2MP path and = distributed to all leaf nodes including the original sender. [Lizhong] Accepted. Thanks. [snip] > > Somewhat to my surprise, the use of the HSMP capability TLV is not=20 > > described anywhere. Reading between the lines in Section 4.1 I can=20 > > see that the new TLV is carried on the Initialization message. I can = > > also see that an implementation wishing to indicate it supports HSMP = > > includes the TLV and follow the procedures for indicating=20 > > capabilities as defined in RFC 5561. > > > > But I don't find anything saying MUST NOT use HSMP FEC if peer does=20 > > not support HSMP. > > > > I also don't understand what happens if I am tying to build an HSMP=20 > > LSP and discover that the next hop does not support HSMP. Can I have = > > an HSMP LSP with a hole in it? Does an LSR finding it cannot advance = > > an HSMP FEC fail any received HSMP LDP messages? Is there, in fact,=20 > > an assumption that all nodes that might be on an HSMP tree will=20 > > support HSMP? > > > > I think you need to explain all this. You could look to RFC 6388 for = > > some suitable wording. > > [Lizhong] How about to add the following: > > If the peer has not advertised the corresponding capability, then=20 > label messages using the HSMP FEC Element SHOULD NOT be sent to the=20 > peer. In that case, the HSMP LSP has not been completely established,=20 > and leaf node is unable to send any traffic to root node (see section = 4.3.1 for detail). Yes, but doesn't this mean that the root and some leaf nodes may think = that the LSP is more complete than it actually is? Maybe the DoD procedures mean that the root has knowledge of which leaf = nodes are fully attached? Perhaps this is all explained in the I-D and I can't remember it now, or = perhaps there are some unspoken assumptions about how many nodes support = these procedures and how LSPs get established. [Lizhong] ordered mode is used for the upstream path, and it is = described in section 4: For setting up the upstream path of an HSMP LSP, ordered mode MUST be used which is same as MP2MP. Ordered mode can guarantee a leaf to start sending packets to root immediately after the upstream path is installed, without being dropped due to an incomplete LSP. Then if one node does not support HSMP, the Label Mapping with upstream = FEC element will not be received by leaf node, and the leaf node is unable to = establish the upstream path. I change the description as follows, to make it more clear. If the peer has not advertised the corresponding capability, then=20 label messages using the HSMP FEC Element SHOULD NOT be sent to the=20 peer. Since ordered mode (see section 4.3.1 for detail) is applied for = HSMP LSP signaling,=20 the label message break would ensure that the initiating leaf node is = unable to establish the=20 upstream path. From matthew.bocci@alcatel-lucent.com Mon Nov 25 04:44:34 2013 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 6A5B21AD687; Mon, 25 Nov 2013 04:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h4Vy-AycCj0; Mon, 25 Nov 2013 04:44:32 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E01671AD959; Mon, 25 Nov 2013 04:44:31 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rAPCiRKt008087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Nov 2013 06:44:29 -0600 (CST) 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 rAPCiR5K006356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 13:44:27 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 25 Nov 2013 13:44:27 +0100 From: "Bocci, Matthew (Matthew)" To: Loa Andersson , "huubatwork@gmail.com" , "pwe3@ietf.org" Thread-Topic: [PWE3] [mpls] Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO5yBViXeYAQSEMkaxB6wA8sJs35oy1aIAgAJEhoCAAL7ggA== Date: Mon, 25 Nov 2013 12:44:26 +0000 Message-ID: References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> In-Reply-To: <5292A5F7.3010609@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 25 Nov 2013 12:44:34 -0000 Loa,=20 Yes, I agree with your suggested clarification. Best regards Matthew On 25/11/2013 01:20, "Loa Andersson" wrote: >Folks, > >I think what should be done is to drop "some of" from the first >paragraph and in the second say "Additionally, point-to-point PWs are >not in general intended to ..." > >/Loa > >On 2013-11-23 22:43, Huub van Helvoort wrote: >> Hello Matthew, >> >> You wrote: >> >> > PWE3 and MPLS Working Groups >>> >>> Please find below a draft response to the liaison from ITU-T SG15 of >>> July 2013 on clarifying combinations of point to multipoint pseudowires >>> and LSPs. >> >> Please see in-line [hvh] >> Best regards, Huub. >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Body: >>> >>> Thank you for your liaison of July 2013 inquiring on the valid use of >>> p2mp pseudowires and LSPs. A new version of the "Requirements and >>> Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is >>> available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that >>>should >>> help to clarify some of the points in your liaison. >> >> [hvh] you mention that some of the points are clarified, are the >> remaining points clarified by another liaison or by the text that >> follows? >> >>> In general, point-to-point PWs are not intended to be used in >>> conjunction with P2MP LSPs. There is currently no way for the PEs >>> terminating all of the P2MP LSP leaves to establish the applicable >>> PW/FEC label mappings. We do not believe that this case is supported >>>by >>> the PWE3 architecture. The only current valid case for P2MP PWs is >>>when >>> used with corresponding P2MP LSPs, as described in the draft referenced >>> above. >>> >>> Best regards, >>> >>> >>> Matthew Bocci >>> Andrew Malis >>> >>> IETF PWE3 Working Group Chairs >>> >>> >>> _______________________________________________ >>> 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 eric.gray@ericsson.com Mon Nov 25 06:14:58 2013 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 7DDD31ADBE5; Mon, 25 Nov 2013 06:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 IJkfDLh7fVej; Mon, 25 Nov 2013 06:14:56 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF801AD957; Mon, 25 Nov 2013 06:14:56 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-43-52935b5e4e99 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4A.13.04556.E5B53925; Mon, 25 Nov 2013 15:14:55 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 09:14:54 -0500 From: Eric Gray To: Loa Andersson , "huubatwork@gmail.com" , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO6Xyexx76EhHG0UaIpalLNAEwWZo1+VIw Date: Mon, 25 Nov 2013 14:14:53 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> In-Reply-To: <5292A5F7.3010609@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPlG589OQggxtLRS1mzL7MavFv7hxm i8Nddxktbi1dyWrR92kLiwOrR+uzvaweO2fdZfdYsuQnk8es6W1sASxRXDYpqTmZZalF+nYJ XBlrFr9nLvgnU7FixWuWBsZXYl2MnBwSAiYSp2asZYewxSQu3FvPBmILCRxhlLh8UqGLkQvI Xs4ocedEJwtIgk1AQ+LYnbWMILaIwAZGiWU7NLsYOTiYBZQlTt2VAQkLCwRInNv+DKokUGLC yWdsELaRxJaX18F2sQioSjw9eJcJpJVXwFeid1YWxNpiiVtPf7KC2JxAJQdurAArZwQ67fup NUwgNrOAuMStJ/OZIE4WkFiy5zwzhC0q8fLxP1YIW1liyZP9LBD1OhILdn9ig7C1JZYtfA1W zysgKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIjKljEmyOOxgXfLI8 xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZom1n5F4UFT2SsiU11Y7m/ zt3W577wvu4tnc2uYvtkODZkr8ib3+qqX/x86ZTXa/1DvvJa8tUbfGgM/m+YteTr4l3BmUtK blZtkX653dw66XfkO9Fyi9k6b381GRRHsD5MCT8y68S6LZP2/VgU/inW4dfGTzLewX42YUFT WxsfL7a/c/T1y3VKLMUZiYZazEXFiQDVB2UCdwIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 25 Nov 2013 14:14:58 -0000 In addition, should the last sentence in the proposed liaison letter text b= e changed from: "The only current valid case for P2MP PWs is when used with corresponding= P2MP=20 LSPs, as described in the draft referenced above" to: "The only current valid case for PW use in a point-to-multipoint scenario= is when=20 a P2MP PW is used with a corresponding P2MP LSP, as described in the dr= aft=20 referenced above"? I believe we are trying to say two things: 1) use of multiple P2P PWs in conjunction with a single P2MP LSP is (genera= lly?)=20 not valid; 2) use of a P2MP PW in conjunction with one or more P2P LSPs is definitely = not=20 valid. We make the point (in the second paragraph) that there is (currently?) an i= ssue (potentially pathological?) associated with use of P2P PWs with a P2MP. I = would think we want to discourage this usage. The current text makes the second point, more than it makes the first. As = it is currently worded, this text implies that use of multiple P2P PWs _might_ be= a valid use case, even though this seems to differ slightly from what I think= we're trying to say in the second paragraph... -- Eric -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Sunday, November 24, 2013 8:21 PM To: huubatwork@gmail.com; Bocci, Matthew (Matthew); pwe3@ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinati= ons Folks, I think what should be done is to drop "some of" from the first paragraph a= nd in the second say "Additionally, point-to-point PWs are not in general i= ntended to ..." /Loa On 2013-11-23 22:43, Huub van Helvoort wrote: > Hello Matthew, > > You wrote: > > > PWE3 and MPLS Working Groups >> >> Please find below a draft response to the liaison from ITU-T SG15 of=20 >> July 2013 on clarifying combinations of point to multipoint=20 >> pseudowires and LSPs. > > Please see in-line [hvh] > Best regards, Huub. > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Body: >> >> Thank you for your liaison of July 2013 inquiring on the valid use of=20 >> p2mp pseudowires and LSPs. A new version of the "Requirements and=20 >> Framework for Point-to-Multipoint Pseudowires over MPLS PSNs" is=20 >> available (see draft-ietf-pwe3-p2mp-pw-requirements-06.txt) that=20 >> should help to clarify some of the points in your liaison. > > [hvh] you mention that some of the points are clarified, are the=20 > remaining points clarified by another liaison or by the text that=20 > follows? > >> In general, point-to-point PWs are not intended to be used in=20 >> conjunction with P2MP LSPs. There is currently no way for the PEs=20 >> terminating all of the P2MP LSP leaves to establish the applicable=20 >> PW/FEC label mappings. We do not believe that this case is supported=20 >> by the PWE3 architecture. The only current valid case for P2MP PWs=20 >> is when used with corresponding P2MP LSPs, as described in the draft=20 >> referenced above. >> >> Best regards, >> >> >> Matthew Bocci >> Andrew Malis >> >> IETF PWE3 Working Group Chairs >> >> >> _______________________________________________ >> 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Mon Nov 25 08:44:18 2013 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 4C4BE1A1F58 for ; Mon, 25 Nov 2013 08:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Rl_R61gnGO for ; Mon, 25 Nov 2013 08:44:15 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 689731ACB4E for ; Mon, 25 Nov 2013 08:44:15 -0800 (PST) Received: from mail84-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Mon, 25 Nov 2013 16:44:15 +0000 Received: from mail84-va3 (localhost [127.0.0.1]) by mail84-va3-R.bigfish.com (Postfix) with ESMTP id 018904E021A; Mon, 25 Nov 2013 16:44:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz62a3I9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h9a9j1155h) Received-SPF: pass (mail84-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(164054003)(252514010)(13464003)(31966008)(46102001)(76576001)(59766001)(74316001)(53806001)(76786001)(51856001)(76482001)(56816003)(74876001)(76796001)(74706001)(33646001)(87936001)(85306002)(74366001)(77982001)(79102001)(56776001)(47736001)(54316002)(50986001)(66066001)(81342001)(87266001)(80022001)(2656002)(81542001)(65816001)(19580395003)(47976001)(54356001)(74662001)(47446002)(74502001)(49866001)(4396001)(80976001)(83072001)(81686001)(81816001)(83322001)(69226001)(19580405001)(63696002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 1385397853322325_25810; Mon, 25 Nov 2013 16:44:13 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.225]) by mail84-va3.bigfish.com (Postfix) with ESMTP id 3F55C2C0122; Mon, 25 Nov 2013 16:44:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 25 Nov 2013 16:44:10 +0000 Received: from CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 25 Nov 2013 16:44:10 +0000 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.820.5; Mon, 25 Nov 2013 16:44:02 +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.0820.005; Mon, 25 Nov 2013 16:44:02 +0000 From: Ross Callon To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" Thread-Topic: mpls-rt review of draft-ryoogray-mpls-tp-psc-itu Thread-Index: AQHO5XPsHz4+GUOy3Um4tKMNJxZSGZo2L2Dg Date: Mon, 25 Nov 2013 16:44:01 +0000 Message-ID: <3e6b8a168a4945a3a0a9558129a70803@CO2PR05MB636.namprd05.prod.outlook.com> References: <528BE146.1030108@pi.nu> In-Reply-To: <528BE146.1030108@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0041D46242 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] mpls-rt review of draft-ryoogray-mpls-tp-psc-itu 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, 25 Nov 2013 16:44:18 -0000 I have also completed my review of this document. I fully agree with Loa's = assessment (except that I didn't find any issues at all in the -01 version)= . I believe that the document is ready for WG adoption.=20 Thanks, Ross -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Tuesday, November 19, 2013 5:08 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org Subject: mpls-rt review of draft-ryoogray-mpls-tp-psc-itu Working Group, I've reviewed draft-ryoogray-mpls-tp-psc-itu as part of the mpls-rt review. Is the document coherent - yes I think so, there are some issues but nothing that would stop an adoption as a working group document, I will hold the issues until we start working on the document as a working group document Is the document useful - yes is it likely that it will be deployed in operational networks Is the document technically sound - yes it is technically sound, but still a bit raw, quite a bit of working group effort will need to go into it I recommend that we accept the document as a working group document, it is a good starting point for the working group! / --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From wwwrun@rfc-editor.org Mon Nov 25 15:09:57 2013 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 91CEC1AE0B2; Mon, 25 Nov 2013 15:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 5RstW_ljelVG; Mon, 25 Nov 2013 15:09:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE41AE0AF; Mon, 25 Nov 2013 15:09:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F17BF75E017; Mon, 25 Nov 2013 15:09:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131125230952.F17BF75E017@rfc-editor.org> Date: Mon, 25 Nov 2013 15:09:52 -0800 (PST) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7060 on Using LDP Multipoint Extensions on Targeted LDP Sessions 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, 25 Nov 2013 23:09:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7060 Title: Using LDP Multipoint Extensions on Targeted LDP Sessions Author: M. Napierala, E. Rosen, IJ. Wijnands Status: Standards Track Stream: IETF Date: November 2013 Mailbox: mnapierala@att.com, erosen@cisco.com, ice@cisco.com Pages: 9 Characters: 19384 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-targeted-mldp-04.txt URL: http://www.rfc-editor.org/rfc/rfc7060.txt Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From loa@pi.nu Mon Nov 25 20:16:52 2013 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 D12161AE10F; Mon, 25 Nov 2013 20:16:52 -0800 (PST) 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, RP_MATCHES_RCVD=-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 bjrxnXaG_9RW; Mon, 25 Nov 2013 20:16:50 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B51ADFC6; Mon, 25 Nov 2013 20:16:50 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.29.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A3C2C1802038; Tue, 26 Nov 2013 05:16:47 +0100 (CET) Message-ID: <529420AD.5080405@pi.nu> Date: Tue, 26 Nov 2013 12:16:45 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Eric Gray , "huubatwork@gmail.com" , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 26 Nov 2013 04:16:53 -0000 > 2) use of a P2MP PW in conjunction with one or more P2P LSPs is definitely not > valid. > snip> Well a MS-PW could do P2MP over P2P LSPs, right? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From eric.gray@ericsson.com Tue Nov 26 06:45:34 2013 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 3E06D1AE221; Tue, 26 Nov 2013 06:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX-xydjY6VDO; Tue, 26 Nov 2013 06:45:32 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 892AC1AD8F5; Tue, 26 Nov 2013 06:45:32 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-81-5294b4084262 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A1.74.23183.804B4925; Tue, 26 Nov 2013 15:45:29 +0100 (CET) Received: from EUSAAMB104.ericsson.se ([147.117.188.121]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 26 Nov 2013 09:45:29 -0500 From: Eric Gray To: Loa Andersson , "huubatwork@gmail.com" , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO6l5VFd3RTdWJ902+UNphv84vuZo3kP7g Date: Tue, 26 Nov 2013 14:45:28 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6329A8587@eusaamb104.ericsson.se> References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> <529420AD.5080405@pi.nu> In-Reply-To: <529420AD.5080405@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPuC7nlilBBkuuC1rMmH2Z1eLf3DnM Foe77jJa3Fq6ktWi79MWFgdWj9Zne1k9ds66y+6xZMlPJo9Z09vYAliiuGxSUnMyy1KL9O0S uDIuH5Ao+CxYseqyUQPjBd4uRk4OCQETif7DX5ggbDGJC/fWs3UxcnEICRxhlFjV2ckO4Sxn lOh8f4QdpIpNQEPi2J21jCC2iMAGRollOzS7GDk4mAWUJU7dlQEJCwsESGxvX8sKURIo8e/h fRYI20ji4fXzYMtYBFQlfrYdABvDK+ArMf36TajFlxglPp65DFbECVR0+818sCJGoOu+n1oD FmcWEJe49WQ+1NUCEkv2nGeGsEUlXj7+xwphK0ssebKfBaJeR2LB7k9sELa2xLKFr5khFgtK nJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQKj6pgEm+4Oxj0vLQ8xSnOw KInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUc806YkF+56uMD2u76yO3Nfmsu/e H+c3Z/oV08kV+xbcv3tFsCHZ5/DN61NfvE/Vt7L+5V6s+/v8CT5B87yH83J2LlgadXIZo/ez wwtE1JPVFhyLUbPRM3185IV0OY/iKdk3ggqXu0zOT/z7UNfe443Q62cnY9+9+nD01AuhV0I9 LI/+Gf1SOajEUpyRaKjFXFScCABAc7ZpeAIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 26 Nov 2013 14:45:34 -0000 Loa, I think you mean on a per-segment basis, where a group of PW-branches would traverse the segment using the same segment-ingress/egress pair, righ= t? If so, this is not logically different from having the same set of PW-bran= ches traversing a common link. I guess it is possible that a P2MP MS-PW would o= nly use=20 P2P LSPs in every segment; that would require every branching point to be a= t the points where the P2P LSP in one domain terminates and two or more P2P LSPs = are used to forward distinct subsets of the P2MP PW through the next domain. T= his seems likely (to me, anyway) only if the LSR at the domain boundary belongs= to both domains (not the common case, I believe). =20 If there was no branching at domain boundaries, and no P2MP LSPs in any=20 domain, it beggars the imagination as to why a P2MP PW would be used in the= first=20 place, so the overall set of LSPs would effectively be P2MP - wouldn't they= ? But, if you think transport of a P2MP PW over a set of P2P LSPs exclusivel= y=20 is a valid scenario to consider, why include the text in question at all? Since you snipped it, I am adding back the text in question. It says: " The only current valid case for P2MP PWs is when used with correspondin= g P2MP=20 LSPs, as described in the draft referenced above." The primary message in this text is that carrying a P2MP PW over anything= =20 other than a P2MP LSP is invalid. If that is not the clarification we want= to provide, then we need to change this text, or remove it. -- Eric -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, November 25, 2013 11:17 PM To: Eric Gray; huubatwork@gmail.com; Bocci, Matthew (Matthew); pwe3@ietf.or= g Cc: mpls@ietf.org Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinati= ons Importance: High > 2) use of a P2MP PW in conjunction with one or more P2P LSPs is definitel= y not > valid. > snip> Well a MS-PW could do P2MP over P2P LSPs, right? /Loa --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From matthew.bocci@alcatel-lucent.com Tue Nov 26 07:56:18 2013 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 0E6FE1AD8DA; Tue, 26 Nov 2013 07:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1slG6FHoaC1h; Tue, 26 Nov 2013 07:56:16 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 310691AC85E; Tue, 26 Nov 2013 07:56:16 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAQFu91W009260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Nov 2013 09:56:11 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAQFu9xF022774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 16:56:09 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 26 Nov 2013 16:56:08 +0100 From: "Bocci, Matthew (Matthew)" To: Eric Gray , Loa Andersson , "huubatwork@gmail.com" , "pwe3@ietf.org" Thread-Topic: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO6l5XcbLTsfzeX02Vye95ekPlR5o3hssAgAATvAA= Date: Tue, 26 Nov 2013 15:56:08 +0000 Message-ID: References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> <529420AD.5080405@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A8587@eusaamb104.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6329A8587@eusaamb104.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 26 Nov 2013 15:56:18 -0000 Eric Theoretically it is possible, but the key is in the word =8Ccurrent=B9. The P2MP requirements/framework was deliberately scoped down after AD review, from the problem of any P2MP PW over any underlying LSP type. Trying to define all possible combinations in a single document (when we hadn=B9t eve= n characterised the simplest case) was going far beyond the basic requirements from VPMS. Maybe we should rephrase the sentence below as follows: " The only use case for P2MP PWs described in the draft referenced above is when used with corresponding P2MP LSPs. Other more complex use cases are for further study. If required, participants are encouraged to bring extensions to this architecture to the PWE3 working group." Matthew On 26/11/2013 14:45, "Eric Gray" wrote: >Loa, > > I think you mean on a per-segment basis, where a group of PW-branches >would traverse the segment using the same segment-ingress/egress pair, >right? > > If so, this is not logically different from having the same set of >PW-branches >traversing a common link. I guess it is possible that a P2MP MS-PW would >only use=20 >P2P LSPs in every segment; that would require every branching point to be >at the >points where the P2P LSP in one domain terminates and two or more P2P >LSPs are >used to forward distinct subsets of the P2MP PW through the next domain. >This >seems likely (to me, anyway) only if the LSR at the domain boundary >belongs to >both domains (not the common case, I believe). > > If there was no branching at domain boundaries, and no P2MP LSPs in any >domain, it beggars the imagination as to why a P2MP PW would be used in >the first=20 >place, so the overall set of LSPs would effectively be P2MP - wouldn't >they? > > But, if you think transport of a P2MP PW over a set of P2P LSPs >exclusively=20 >is a valid scenario to consider, why include the text in question at all? > > Since you snipped it, I am adding back the text in question. It says: > > " The only current valid case for P2MP PWs is when used with >corresponding P2MP > LSPs, as described in the draft referenced above." > > The primary message in this text is that carrying a P2MP PW over >anything=20 >other than a P2MP LSP is invalid. If that is not the clarification we >want to provide, >then we need to change this text, or remove it. > >-- >Eric > >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: Monday, November 25, 2013 11:17 PM >To: Eric Gray; huubatwork@gmail.com; Bocci, Matthew (Matthew); >pwe3@ietf.org >Cc: mpls@ietf.org >Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP >Combinations >Importance: High > > > > >> 2) use of a P2MP PW in conjunction with one or more P2P LSPs is >>definitely not >> valid. >> >snip> > >Well a MS-PW could do P2MP over P2P LSPs, right? > >/Loa > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From eric.gray@ericsson.com Tue Nov 26 07:59:07 2013 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 4A3991AD8F2; Tue, 26 Nov 2013 07:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNCieAsslrrK; Tue, 26 Nov 2013 07:59:05 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 338611AC85E; Tue, 26 Nov 2013 07:59:05 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-e7-5294c5462169 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.E8.23183.645C4925; Tue, 26 Nov 2013 16:59:02 +0100 (CET) Received: from EUSAAMB104.ericsson.se ([147.117.188.121]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 26 Nov 2013 10:59:01 -0500 From: Eric Gray To: "Bocci, Matthew (Matthew)" , "Loa Andersson" , "huubatwork@gmail.com" , "pwe3@ietf.org" Thread-Topic: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations Thread-Index: AQHO6l5VFd3RTdWJ902+UNphv84vuZo3kP7ggABuIQD//6x2QA== Date: Tue, 26 Nov 2013 15:59:01 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6329A970C@eusaamb104.ericsson.se> References: <5290BEFC.20308@gmail.com> <5292A5F7.3010609@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A3272@eusaamb107.ericsson.se> <529420AD.5080405@pi.nu> <48E1A67CB9CA044EADFEAB87D814BFF6329A8587@eusaamb104.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.134] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXSPt67b0SlBBusvGFnMmH2Z1eLf3DnM Foe77jJa3Fq6ktWi79MWFgdWj9Zne1k9ds66y+6xZMlPJo9Z09vYAliiuGxSUnMyy1KL9O0S uDLmbX3EVDBXpuL82QfsDYyzxLoYOTkkBEwk2g9eYIKwxSQu3FvP1sXIxSEkcIRR4tuLflYI ZzmjRMuv76wgVWwCGhLH7qxlBEmICGxilNj45x9QOwcHs4CyxKm7MiA1wgIBEtvb14LViwgE Svx7eJ8FpEREwEni9xYvkDCLgKrErW+L2UFsXgFfiTt7d0MtPsUksaTnAliCU8BO4srf2Ywg NiPQdd9PrQG7lFlAXOLWk/lQVwtILNlznhnCFpV4+fgfK4StLLHkyX4WiHoDiS/vb0PZ2hLL Fr5mhlgsKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy2MQIjKxjEmy6Oxj3 vLQ8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYYNkZNbelEDq6GrjA5 rsPP70nG2GqXpM9qqv3wIqnRYMarfQtnnwg+cnLFLg4hh1nKWQViE9iLJ786ocJT2HxrgaRY +uRWsawFTXttOZ+3NW2cdXmeS1pulRxDz52o7tasg3ve24RtzYqQ3fmaj+lmUJNgyy/BQ593 Tsv1SL0vur/qe6Z/phJLcUaioRZzUXEiAIurtbt6AgAA Cc: "mpls@ietf.org" Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinations 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, 26 Nov 2013 15:59:07 -0000 Matthew, Your wording is acceptable to me. It certainly makes the clarification cl= earer. :-) -- Eric -----Original Message----- From: Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcatel-lucent.com]=20 Sent: Tuesday, November 26, 2013 10:56 AM To: Eric Gray; Loa Andersson; huubatwork@gmail.com; pwe3@ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP Combinati= ons Importance: High Eric Theoretically it is possible, but the key is in the word =8Ccurrent=B9. The P2MP requirements/framework was deliberately scoped down after AD review, from the problem of any P2MP PW over any underlying LSP type. Trying to define all possible combinations in a single document (when we hadn=B9t eve= n characterised the simplest case) was going far beyond the basic requirements from VPMS. Maybe we should rephrase the sentence below as follows: " The only use case for P2MP PWs described in the draft referenced above is when used with corresponding P2MP LSPs. Other more complex use cases are for further study. If required, participants are encouraged to bring extensions to this architecture to the PWE3 working group." Matthew On 26/11/2013 14:45, "Eric Gray" wrote: >Loa, > > I think you mean on a per-segment basis, where a group of PW-branches >would traverse the segment using the same segment-ingress/egress pair, >right? > > If so, this is not logically different from having the same set of >PW-branches >traversing a common link. I guess it is possible that a P2MP MS-PW would >only use=20 >P2P LSPs in every segment; that would require every branching point to be >at the >points where the P2P LSP in one domain terminates and two or more P2P >LSPs are >used to forward distinct subsets of the P2MP PW through the next domain. >This >seems likely (to me, anyway) only if the LSR at the domain boundary >belongs to >both domains (not the common case, I believe). > > If there was no branching at domain boundaries, and no P2MP LSPs in any >domain, it beggars the imagination as to why a P2MP PW would be used in >the first=20 >place, so the overall set of LSPs would effectively be P2MP - wouldn't >they? > > But, if you think transport of a P2MP PW over a set of P2P LSPs >exclusively=20 >is a valid scenario to consider, why include the text in question at all? > > Since you snipped it, I am adding back the text in question. It says: > > " The only current valid case for P2MP PWs is when used with >corresponding P2MP > LSPs, as described in the draft referenced above." > > The primary message in this text is that carrying a P2MP PW over >anything=20 >other than a P2MP LSP is invalid. If that is not the clarification we >want to provide, >then we need to change this text, or remove it. > >-- >Eric > >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: Monday, November 25, 2013 11:17 PM >To: Eric Gray; huubatwork@gmail.com; Bocci, Matthew (Matthew); >pwe3@ietf.org >Cc: mpls@ietf.org >Subject: Re: [mpls] [PWE3] Response to Liaison on Clarifying P2MP >Combinations >Importance: High > > > > >> 2) use of a P2MP PW in conjunction with one or more P2P LSPs is >>definitely not >> valid. >> >snip> > >Well a MS-PW could do P2MP over P2P LSPs, right? > >/Loa > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Tue Nov 26 08:11:59 2013 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 02C7D1ADDAC; Tue, 26 Nov 2013 08:11:59 -0800 (PST) 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 1KfaRxu62qgs; Tue, 26 Nov 2013 08:11:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6471A1F78; Tue, 26 Nov 2013 08:11:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126161157.22419.84622.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 08:11:57 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-hsmp-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:11:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Extensions for Hub & Spoke Multipoint Label Switched= Path Author(s) : Lizhong Jin Frederic Jounay IJsbrand Wijnands Nicolai Leymann Filename : draft-ietf-mpls-mldp-hsmp-04.txt Pages : 15 Date : 2013-11-26 Abstract: This draft introduces a hub & spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic both from root to leaf through point-to-multipoint (P2MP) LSP and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream to each leaf node, exactly as if it is travelling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it is unicast to the root. The communication among the leaf nodes are not allowed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-hsmp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-mldp-hsmp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lizho.jin@gmail.com Tue Nov 26 08:14:46 2013 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 269F01ADDBF for ; Tue, 26 Nov 2013 08:14:46 -0800 (PST) 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 3oK8DB3ONdsZ for ; Tue, 26 Nov 2013 08:14:43 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 543721ADD02 for ; Tue, 26 Nov 2013 08:14:43 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y10so7939103pdj.37 for ; Tue, 26 Nov 2013 08:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=xim/L2cZ0T9sGJwZhVP+r4sp5RZD0ftWQKaATwoOzwo=; b=enyP0FUO8iZGG5vylz3sxa+XtsKZcBhl2M1xeLWsKOuQfTfpaVDJWdmOZiItZMiO+N HhGOHkEoEnT7U0aNfAjtMXErBX8vbU+pH/+s8fcwIPb0uL79PZYQ5BIYyXyJl7K0/Y7L LGoIEbr1zME8AaP1WsKzqzncF71sdXANx+nY0XXaZOcNxrM5WhVCmH1l6PCkxyAVB5GD dppPUud3MNNk2BqBBe0rI7ZLniaFyXbTSaX//Cqz6+noRmaFf22eBB03zwJZuhBQ9CkQ vBJEypWkV8dlPrctivJNU/AHl9DRhYitMJr8OqnaYndpGxQIgxIJTfVnla06lZ6Ilv9I Q+CA== X-Received: by 10.66.154.1 with SMTP id vk1mr36666882pab.85.1385482483225; Tue, 26 Nov 2013 08:14:43 -0800 (PST) Received: from LizhongPC ([114.62.198.173]) by mx.google.com with ESMTPSA id xe9sm92431799pab.0.2013.11.26.08.14.40 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Nov 2013 08:14:42 -0800 (PST) From: "Lizhong Jin" To: , References: <013a01cee3d2$ed3c4370$c7b4ca50$@olddog.co.uk> <528ce29e.4488440a.7edd.ffffed33@mx.google.com> <00ec01cee925$1d1091d0$5731b570$@olddog.co.uk> <009601cee98a$e48679e0$ad936da0$@gmail.com> In-Reply-To: <009601cee98a$e48679e0$ad936da0$@gmail.com> Date: Wed, 27 Nov 2013 00:14:37 +0800 Message-ID: <5294c8f2.c99f420a.3af2.5094@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQKA2ZT9n+urJ3by5MGg4ag7RJGDwAIkee94AlPUX5MCE+kwSZifb8Ow Content-Language: zh-cn Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-mldp-hsmp 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, 26 Nov 2013 16:14:46 -0000 Hi Adrian, I have uploaded the new version: = http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-hsmp-04.txt Please check if all of your comments are resolved. Thank you. Regards Lizhong > -----Original Message----- > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Monday, November 25, 2013 11:03 AM > To: adrian@olddog.co.uk; draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: AD review of draft-ietf-mpls-mldp-hsmp >=20 > Hi Adrian, > Thank you for the review. See inline for the reply. I will upload a = new > version soon to reflect all the review comments. >=20 > Regards > Lizhong >=20 >=20 > [snip] >=20 > > > Section 4 > > > > > > The transmission of packets from the root node of an HSMP LSP > > > to the receivers is identical to that of a P2MP LSP. Traffic > from a > > > leaf node follows the upstream path toward the root node, along > a > > > path that traverse the same nodes as the downstream node, but = in > > > reverse order. > > > > > > I believe this says that traffic is delivered back to the sender = in > > > all cases. Is that the intent? > > > > > > This makes for a significant difference between HSMP and MP2MP, > > > doesn't it? Shouldn't the document make this clearer? > > > > [Lizhong] How about the below: > > The transmission of packets from the root node of an HSMP LSP to the > > receivers is identical to that of a P2MP LSP. Traffic from a leaf > > node follows the upstream path toward the root node, and would not = be > > sent to any other leaf nodes. The upstream path is the reverse path > of > > traffic sent from the root node to the leaf node. >=20 > OK. I see the confusion. > Your text is making the distinction that traffic traveling upstream to > the > root does so in a P2P fashion and is not branched to any other leaf = (as > it > would be in mp2mp). > That is a good point to make clear. >=20 > My question was about how traffic is distributed from the root back to > the > leaf nodes. I believe that this use a single P2MP tree to distribute > traffic > to all of the leaf nodes regardless of which leaf originated the > traffic. > That is, there are not n distinct trees each containing (n-1) nodes. > Thus, > it seems to me that the sender will receive a copy of every packet = that > it > sends to the root. >=20 > If I am correct, and to include your point, I suggest the following > paragraph. >=20 > The transmission of packets from the root node of an HSMP LSP to the > receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic > from > a leaf node to the root follows the upstream path that is the reverse > of the > path from the root to the leaf. Unlike an MP2MP LSP, traffic from a > leaf > node does not branch toward other leaf nodes, but is sent direct to = the > root > where it is placed on the P2MP path and distributed to all leaf nodes > including the original sender. >=20 > [Lizhong] Accepted. Thanks. >=20 > [snip] >=20 > > > Somewhat to my surprise, the use of the HSMP capability TLV is not > > > described anywhere. Reading between the lines in Section 4.1 I can > > > see that the new TLV is carried on the Initialization message. I > can > > > also see that an implementation wishing to indicate it supports > HSMP > > > includes the TLV and follow the procedures for indicating > > > capabilities as defined in RFC 5561. > > > > > > But I don't find anything saying MUST NOT use HSMP FEC if peer = does > > > not support HSMP. > > > > > > I also don't understand what happens if I am tying to build an = HSMP > > > LSP and discover that the next hop does not support HSMP. Can I > have > > > an HSMP LSP with a hole in it? Does an LSR finding it cannot > advance > > > an HSMP FEC fail any received HSMP LDP messages? Is there, in = fact, > > > an assumption that all nodes that might be on an HSMP tree will > > > support HSMP? > > > > > > I think you need to explain all this. You could look to RFC 6388 > for > > > some suitable wording. > > > > [Lizhong] How about to add the following: > > > > If the peer has not advertised the corresponding capability, then > > label messages using the HSMP FEC Element SHOULD NOT be sent to the > > peer. In that case, the HSMP LSP has not been completely = established, > > and leaf node is unable to send any traffic to root node (see = section > > 4.3.1 for detail). >=20 > Yes, but doesn't this mean that the root and some leaf nodes may think > that > the LSP is more complete than it actually is? > Maybe the DoD procedures mean that the root has knowledge of which = leaf > nodes are fully attached? > Perhaps this is all explained in the I-D and I can't remember it now, > or > perhaps there are some unspoken assumptions about how many nodes > support > these procedures and how LSPs get established. >=20 > [Lizhong] ordered mode is used for the upstream path, and it is > described in > section 4: > For setting up the upstream path of an HSMP LSP, ordered mode MUST = be > used which is same as MP2MP. Ordered mode can guarantee a leaf to > start sending packets to root immediately after the upstream path = is > installed, without being dropped due to an incomplete LSP. > Then if one node does not support HSMP, the Label Mapping with = upstream > FEC > element > will not be received by leaf node, and the leaf node is unable to > establish > the upstream path. > I change the description as follows, to make it more clear. >=20 > If the peer has not advertised the corresponding capability, then > label messages using the HSMP FEC Element SHOULD NOT be sent to the > peer. Since ordered mode (see section 4.3.1 for detail) is applied for > HSMP > LSP signaling, > the label message break would ensure that the initiating leaf node is > unable > to establish the > upstream path. From Alexander.Vainshtein@ecitele.com Tue Nov 26 08:26:51 2013 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 9281F1ACC91; Tue, 26 Nov 2013 08:26:51 -0800 (PST) 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, RP_MATCHES_RCVD=-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 uJlCjE3Yw83G; Tue, 26 Nov 2013 08:26:48 -0800 (PST) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 15E821AC85E; Tue, 26 Nov 2013 08:26:46 -0800 (PST) X-AuditID: 93eaf2e7-b7f908e000003da1-57-5294da5ac419 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 08.E7.15777.A5AD4925; Tue, 26 Nov 2013 19:28:58 +0200 (IST) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 18:26:44 +0200 From: Alexander Vainshtein To: "curtis@ipv6.occnc.com" Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment Thread-Index: AQHO6gxo3oQggiALO0KcL/+gtz2uy5o3rlNQ Date: Tue, 26 Nov 2013 16:26:43 +0000 Message-ID: References: Your message of "Wed, 20 Nov 2013 14:35:41 GMT." <201311251829.rAPIThSu096500@gateway1.ipv6.occnc.com> In-Reply-To: <201311251829.rAPIThSu096500@gateway1.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILsWRmVeSWpSXmKPExsUy+dWnL7pRt6YEGcw+KW1x+vkpNotP73aw WEyedYbN4vCB6ewWP3ZsYre4tXQlq0Xfpy0sFsfff2Cz+ND1g9WB02PryR9sHlN+b2T12Dnr LrvHkiU/mTyW3b/I5nG96Sq7x+Ivfh6T1qYFcEQ1MNok5uXllySWpCqkpBYn2yoFFGWWJSZX KilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsL U0tdQyU7NWVDY2uukIzMYoVU3dzEzByF3NTi4sT0VAWgSMIW5ozdx4QL9lpUvPgxg6WB8adO FyMnh4SAicTNua8YIWwxiQv31rN1MXJxCAkcZJQ4sucGlHOUUWLh6VVsIFVsArYSm1bfBbNF BIwl/rbdBStiFrjDJDHv1D0gh4NDWCBeYt12DoiaBImdByewQNhGEjefzmMFsVkEVCWWdM4E s3kFAiSOXmljhFh2nFHi9uNHYA2cAk4S866eAjuPEei876fWMIHYzALiEreezGeCOFtAYsme 88wQtqjEy8f/WCFsOYknT06xQNTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsEDUS0ocXHGDZQKj +CwkK2YhaZ+FpH0WkvYFjCyrGEUzcwpKknLTDQz1UpMzS1JzUvWS83M3MULS2PMdjL/mqxxi FOBgVOLhNZw3OUiINbGsuDL3EKMkB5OSKO+L41OChPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw bjwBlONNSaysSi3Kh0m5AoNwIrMUd3I+MDXnlcQbGxjg5iiJ885pBhoikA5MgtmpqQWpRTBz ZDg4lCR4z5wCygoWpaanVqRl5pQgpJk4OEHO4AE64xxIDW9xQWJucWY6RP4Uoy7HrZ+fvjEK seTl56VKifNeASkSACnKKM2DmwPLaa8YxYEBIMx7A6SKB5gP4Sa9AlrCBLSky2gyyBJgVoFL STUwHlh7jGWVnm1bxSTBUyfDRa8W8DW6v4vmCcyQCVzvvVA8Ie87c2H1lrplvKk2SWYzOydq imm331njGcTPfOHpW8+M2kSZKyJhFez51hK9npfS1C4YXpZtt01+qzGd73ar/NNJiusqInQD Jn9fJPJvW89t06UmL6pfmf5Sf1FQfcJ6r0n0bUUlluKMREMt5qLiRAARe5RiRAQAAA== Cc: "samante@apple.com" , "kireeti@juniper.net" , "mpls@ietf.org" , "curtis@occnc.com" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment 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, 26 Nov 2013 16:26:51 -0000 Curtis, Lots of thanks for a prompt and very detailed response. May I suggest an alternative version of the following text fragment? > Identifying the position of any lost packets is important > for PW services which are attempting to reconstruct a bit stream > which maintains bit timing, such as time division multiplexing (TDM) > services. TDM and other PW services which require strict ordering > also require that misordered packets be either dropped or reordered. Identifying lost PW packets and exact amount of lost payload is critical for= PW services which maintain bit timing, such as Time Division Multiplexing (TDM) services= since these services MUST compensate lost payload on a bit-for-bit basis. With these services PW packets that have been received out of order also MUS= T also be identified and may be either re-ordered or dropped. Reordering requires, in addition to sequence numbering, a "de-jitter buffer"= in the egress PE, and ability to reorder is limited by the depth of this bu= ffer. The down side of maintaining a de-jitter buffer is added end-to-end service delay. Hopefully this will be useful. Regards, Sasha > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > Sent: Monday, November 25, 2013 8:30 PM > To: Alexander Vainshtein > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com; > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org) > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls- > forwarding: a minor comment > > > In message > om> > Alexander Vainshtein writes: > > > > Hi all, > > > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding > > Compliance and Performance Requirements > > . > > > > This section states, in short, that the main drive for using the > > sequence number in the PW Control Word is handling of packet > > reordering events. TDM PWs are presented as a major example, with CBR > > ATM services as another example. > > > > In fact, this statement is not accurate. > > Yes. You are correct in pointing this out as inaccurate by omitting > the other important function of identifying drops for the purpose of > recunstructing TDM bit streams. > > Andy brought up resequencing being a strong provider request. > Reordering is far more common than loss particularly for high priority > services on provider networks and without resequencing reorder results > in PW loss in what could otherwise be lossless service. > > So we should get the base requirements right but still reflect this, > but strictly as advice with no normative wording. We had used the > phrase "is beneficial" and will retain that. > > Andy brought up the topic. The incorrect wording in the existing > draft is my fault. This text went in fairly early with a lot of other > changes and it appears that no one had since given it a careful enough > read and review until you came along. > > > The main drive for mandating the use of sequence number in TM PWs is > > the need to detect and count lost packets because the egress PE MUST > > compensate the lost payload bit for bit. > > > > Ability to compensate reordering of PW packets at egress is a side > > effect of (a) sequence number usage and (b) usage of the de-jitter > > buffer in the egress PW. It is not mandatory and in any case is > > limited by the depth of the de-jitter buffer: re-ordered packets that > > cannot be accommodated within this buffer are treated as lost. > > > > Additional details can be found, e.g., in section 6.2.2 of RFC > > 4553. Ability to re-order > > mis-ordered PW packets is defined there as OPTIONAL, while replacement > > of the payload of lost PW packets is defined as MANDATORY. > > The change below at the top of the section more accurately reflects > requirements in the RFCs but still states that resequencing can be > beneficial. The comments about EPD and PPD are dropped and therefore > also the informative reference. > > Context: > > 2.1.8.1. Pseudowire Sequence Number > > OLD > > Pseudowire (PW) sequence number support is most important for PW > payload types with a high expectation of in-order delivery. > Resequencing support, rather than dropping at egress on out of order > arrival, is most important for PW payload types with a high > expectation of lossless delivery. For example, TDM payloads require > sequence number support and require resequencing support. The same > is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed > requirements, but generally require ATM Early Packet Discard (EPD) or > ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence > number support and resequencing support are beneficial to PW packet > oriented payloads such as FR and Ethernet, they are highly desirable > but not as strongly required. > > NEW > > Pseudowire (PW) sequence number support is most important for PW > payload types with a high expectation of lossless and/or in-order > delivery. Identifying the position of any lost packets is important > for PW services which are attempting to reconstruct a bit stream > which maintains bit timing, such as time division multiplexing (TDM) > services. TDM and other PW services which require strict ordering > also require that misordered packets be either dropped or reordered. > > PW services which are not timing critical bit streams in nature are > cell oriented or frame oriented. Though resequencing support is > beneficial to PW cell and frame oriented payloads such as ATM, FR and > Ethernet, they are highly desirable but not required. > > NEW (end of subsection after list of possible reording causes) > > In provider networks which use multipath techniques and which may > occassionally rebalance traffic or which may change PW paths > occasionally for other reasons, reordering may be far more common > than loss. Where reordering is more common than loss, resequencing > packets is beneficial, rather than dropping packets at egress when > out of order arrival occus. Resequencing is most important for PW > payload types with a high expectation of lossless delivery since in > such cases out of order delivery within the network results in PW > loss. > > The final paragraph sums up the motivation for highlighting > resequencing as beneficial and desirable. It does so without any > normative wording. > > > Hopefully these notes will be useful. > > > > Regards, > > Sasha > > These notes are very useful. Thank you. > > Please let us know if you (and the WG) are OK with the rewording > proposed above. > > Curtis This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From loa@pi.nu Tue Nov 26 09:02:29 2013 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 D9A0F1ADF95 for ; Tue, 26 Nov 2013 09:02:29 -0800 (PST) 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, RP_MATCHES_RCVD=-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 w1DNK-qQ_Bqt for ; Tue, 26 Nov 2013 09:02:28 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id EBBC81ADEAE for ; Tue, 26 Nov 2013 09:02:27 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.68.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ADF3A1802039; Tue, 26 Nov 2013 18:02:25 +0100 (CET) Message-ID: <5294D420.9040209@pi.nu> Date: Wed, 27 Nov 2013 01:02:24 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ryoogray-mpls-tp-psc-itu@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] draft-ryoogray-mpls-tp-, psc-itu adopted as an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:02:30 -0000 Working Group, Editors, Authors, After reviewing and discussing version -01 of draft-ryoogray-mpls-tp- psc-itu the MPLS working group co-chairs have decided to accept this draft as an MPLS working group document. Can the editors please re-post the current version of the draft as draft-ietf-mpls-tp-psc-itu-00, without any other changes than filename, version number and date. /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 iesg-secretary@ietf.org Tue Nov 26 14:04:01 2013 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 EEF051ADF72; Tue, 26 Nov 2013 14:04:00 -0800 (PST) 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 f_jewNhvLjrm; Tue, 26 Nov 2013 14:03:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6830E1ADF7C; Tue, 26 Nov 2013 14:03:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131126220358.7751.34703.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 14:03:58 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (LDP Extensions for Hub & Spoke Multipoint Label Switched Path) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:04:01 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Extensions for Hub & Spoke Multipoint Label Switched Path' 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 2013-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft introduces a hub & spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic both from root to leaf through point-to-multipoint (P2MP) LSP and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream to each leaf node, exactly as if it is travelling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it is unicast to the root. The communication among the leaf nodes are not allowed. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1777/ http://datatracker.ietf.org/ipr/2191/ From internet-drafts@ietf.org Wed Nov 27 17:49:32 2013 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 715B31AE0B7; Wed, 27 Nov 2013 17:49:32 -0800 (PST) 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 sGW7GbdcbWUf; Wed, 27 Nov 2013 17:49:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F08B81ADED8; Wed, 27 Nov 2013 17:49:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131128014930.5066.37417.idtracker@ietfa.amsl.com> Date: Wed, 27 Nov 2013 17:49:30 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-psc-itu-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 01:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Transport Profile (MPLS-TP) Linear Protection in Su= pport of ITU-T's Requirements Author(s) : Jeong-dong Ryoo Eric Gray Huub van Helvoort Alessandro D'Alessandro Taesik Cheung Eric Osborne Filename : draft-ietf-mpls-tp-psc-itu-00.txt Pages : 30 Date : 2013-11-27 Abstract: This document introduces alternate ways to perform certain operations defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection", and also defines additional behaviors. This set of modified and additional behaviors together with the protocol defined in RFC6378 meets the ITU-T's protection switching requirements. This document introduces capabilities and modes. A capability is an individual behavior. The capabilities of a node are advertised using the method given in this document. A mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC6378 in that the capability advertisement method defined here is an addition to that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-psc-itu There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-psc-itu-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 ietf-secretariat-reply@ietf.org Thu Nov 28 02:07:56 2013 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 6EA171ABBB1 for ; Thu, 28 Nov 2013 02:07:56 -0800 (PST) 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 ZqMzOqjGSklz for ; Thu, 28 Nov 2013 02:07:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFE21ADEA6 for ; Thu, 28 Nov 2013 02:07:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131128100754.1126.37446.idtracker@ietfa.amsl.com> Date: Thu, 28 Nov 2013 02:07:54 -0800 From: IETF Secretariat 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, 28 Nov 2013 10:07:56 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Thu Nov 28 04:55:38 2013 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 A28BA1AE105 for ; Thu, 28 Nov 2013 04:55:38 -0800 (PST) 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 EGbyWdbhWhyO for ; Thu, 28 Nov 2013 04:55:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE631AE110 for ; Thu, 28 Nov 2013 04:55:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131128125536.7902.76839.idtracker@ietfa.amsl.com> Date: Thu, 28 Nov 2013 04:55:36 -0800 From: IETF Secretariat 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, 28 Nov 2013 12:55:38 -0000 Changed milestone "draft-ietf-mpls-tp-psc-itu", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mpls/charter/ From internet-drafts@ietf.org Thu Nov 28 12:37:39 2013 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 115E51AE212; Thu, 28 Nov 2013 12:37:39 -0800 (PST) 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 DPRjIzsyqezp; Thu, 28 Nov 2013 12:37:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2C1AE208; Thu, 28 Nov 2013 12:37:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131128203737.12768.27160.idtracker@ietfa.amsl.com> Date: Thu, 28 Nov 2013 12:37:37 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-chen-mpls-p2mp-egress-protection-10.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, 28 Nov 2013 20:37:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protection Author(s) : Huaimo Chen Ning So Autumn Liu Fengman Xu Mehmet Toy Lu Huang Lei Liu Filename : draft-chen-mpls-p2mp-egress-protection-10.txt Pages : 15 Date : 2013-11-28 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-mpls-p2mp-egress-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-mpls-p2mp-egress-protection-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-mpls-p2mp-egress-protection-10 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 loa@pi.nu Thu Nov 28 21:13:11 2013 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 AEB471ADFBB for ; Thu, 28 Nov 2013 21:13:11 -0800 (PST) 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, RP_MATCHES_RCVD=-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 ZryyEtJCH0wv for ; Thu, 28 Nov 2013 21:13:10 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8191A1F4E for ; Thu, 28 Nov 2013 21:13:10 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A489D18015AB; Fri, 29 Nov 2013 06:13:07 +0100 (CET) Message-ID: <52982260.2020304@pi.nu> Date: Fri, 29 Nov 2013 13:13:04 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-tp-psc-itu@tools.ietf.org, "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] "opertor" in draft-ietf-mpls-tp-psc-itu 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, 29 Nov 2013 05:13:11 -0000 Authors/Editors, Section 4.1 of draft-ietf-mpls-tp-psc-itu-00 uses the term "network operator" in a way that makes the reader think that this is true for every network operator. "..., for network operators it is important that the MPLS-TP protection switching preserves the network operation behavior to which network operators have become accustomed." Admittedly "transport network operators" are a sufficiently large group, but far from the only once that think of themselves as "network operators", likely the majority of "network operators" are not for their operational activities interested or even aware of the commands described in this document. My experience is also that the IETF should not tell "network operators" what is important for them. Suggested new text (from the beginning of the paragraph): "Transport network operators run networks based on different technologies, e.g. optical transport networks, Etherent transport networks and MPLS-TP networks. Commonality between operational procedures are important. For transport network operators accustomed to the operational procedures for Optical and Ethernet transport networks this document defines the same procedures for MPLS-TP networks." /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Fri Nov 29 15:47:01 2013 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 BB7BE1AE170 for ; Fri, 29 Nov 2013 15:47:01 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 cpsLExT0_uJR for ; Fri, 29 Nov 2013 15:46:59 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBAD1AE147 for ; Fri, 29 Nov 2013 15:46:59 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATNkvmT023770; Fri, 29 Nov 2013 23:46:57 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATNku7u023753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Nov 2013 23:46:56 GMT From: "Adrian Farrel" To: Date: Fri, 29 Nov 2013 23:46:56 -0000 Message-ID: <0a1801ceed5d$4a03d670$de0b8350$@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: Ac7tXTla63Zqv1KqQwWysK9PSkQVLw== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-lsp-ping-ttl-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 23:47:01 -0000 Hi, Thanks for this simple little I-D. Just a few bits and pieces to resolve before we move forward. Cheers, Adrian === Obviously, the idnits issues need to be sorted out. --- Section 1 s/is being proposed/is defined/ s/this document this TLV/this document. This TLV/ --- Surely this mechanism only works if the echo reply is sent down the co-routed return path LSP. All other mechanisms for returning the echo reply make this mechanisms worse than silly! While you do say... The scope of this TTL TLV is currently limited to MS-PW or Bidirectional co-routed MPLS LSPs. ...I don't believe that actually applies the necessary constraint. Shouldn't this somehow be tied to require the use of the return path LSP, either by making the new TLV only valid when the return path is specified to be that LSP, or by saying that the presence of the TLV implies the use of the return path LSP. In either case, you have to describe what happens if the return path is specified using some other mechanism and yet the TLV is present. --- I think your security section should reference the security section of 4379. But there we find... To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message. You will need to explain how that recommendation is met since you have opened the box from just the ingress to any node along the path. Furthermore, you now have a field in the Echo Request that we can have fun over-writing. What would happen if I modified the TTL TLV value field in transit? --- The following paragraph in the IANA section needs work Time To Live TLV (See Section 3). The value should be assigned from the range (32768-49161) of optional TLV's which SHOULD be ignored if an implementation does not support or understand them as defined in section 3 of RFC 4379 [RFC4379]. 1. I think you mean that it must be assigned from 32768-49161 2. You can truncate the text at "...optional TLV's." 3. s/TLV's/TLVs/ From loa@pi.nu Fri Nov 29 20:25:19 2013 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 398071AE30A for ; Fri, 29 Nov 2013 20:25:19 -0800 (PST) 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, RP_MATCHES_RCVD=-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 qO7rU7hDDQ5M for ; Fri, 29 Nov 2013 20:25:17 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56D1AE308 for ; Fri, 29 Nov 2013 20:25:16 -0800 (PST) Received: from [192.168.1.12] (unknown [112.208.94.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EE50018015C4; Sat, 30 Nov 2013 05:25:12 +0100 (CET) Message-ID: <529968A5.9070603@pi.nu> Date: Sat, 30 Nov 2013 12:25:09 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "mpls@ietf.org" References: <52843518.6010202@pi.nu> In-Reply-To: <52843518.6010202@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , mpls-forwarding co-authors Subject: [mpls] Closed: wglc on draft-ietf-mpls-forwarding 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, 30 Nov 2013 04:25:19 -0000 Working Group, This working group last call has been closed! There have been comments and a new ID is needed. Can the authors please address the comments, verify with people making comments that they are comfortable with how it has been addressed and post the new version of the ID. /Loa for the working group chairs On 2013-11-14 10:27, Loa Andersson wrote: > Working Group, > > > this is to start a 2 week working group last call on > draft-ietf-mpls-forwarding-02. > > Please review the document and send comments to the > mpls@ietf.org mailing list. > > There are no IPR claims against this document. > > However, we know that some of the author contact information for this > document is changing; this will be updated together with the of > the last call comments. > > The working group last call ends November 29 - 2013. > > /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ietf-secretariat-reply@ietf.org Sat Nov 30 17:46:17 2013 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 4CF3D1AE255 for ; Sat, 30 Nov 2013 17:46:17 -0800 (PST) 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 p1wZXH1NQhnC for ; Sat, 30 Nov 2013 17:46:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F93E1AE4CF for ; Sat, 30 Nov 2013 17:46:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201014615.22774.17217.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2013 17:46:15 -0800 From: IETF Secretariat 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: Sun, 01 Dec 2013 01:46:17 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Sat Nov 30 18:15:16 2013 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 057BB1AE06E for ; Sat, 30 Nov 2013 18:15:16 -0800 (PST) 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 EH-G03CQPw1o for ; Sat, 30 Nov 2013 18:15:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 037E51AE255 for ; Sat, 30 Nov 2013 18:15:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201021514.25346.8115.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2013 18:15:14 -0800 From: IETF Secretariat 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: Sun, 01 Dec 2013 02:15:16 -0000 Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for publication", set due date to January 2014 from November 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Sat Nov 30 18:30:56 2013 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 5E37E1AE4D3 for ; Sat, 30 Nov 2013 18:30:56 -0800 (PST) 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 YMEbSkau69B4 for ; Sat, 30 Nov 2013 18:30:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D001AE4D6 for ; Sat, 30 Nov 2013 18:30:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201023054.29683.32268.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2013 18:30:54 -0800 From: IETF Secretariat 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: Sun, 01 Dec 2013 02:30:56 -0000 Changed milestone "Submit draft-ietf-mpls-seamless-mpls for publication", set due date to January 2014 from November 2013. URL: http://datatracker.ietf.org/wg/mpls/charter/ From ietf-secretariat-reply@ietf.org Sat Nov 30 20:08:13 2013 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 94CA81AE263 for ; Sat, 30 Nov 2013 20:08:13 -0800 (PST) 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 uc4aZ_crMBOR for ; Sat, 30 Nov 2013 20:08:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BAC1AE29F for ; Sat, 30 Nov 2013 20:08:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201040811.13346.12743.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2013 20:08:11 -0800 From: IETF Secretariat 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: Sun, 01 Dec 2013 04:08:13 -0000 URL: http://datatracker.ietf.org/wg/mpls/charter/