From nobody Tue Oct 18 05:22:32 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F1C129624 for ; Tue, 18 Oct 2016 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 jd43iw_553lI for ; Tue, 18 Oct 2016 05:22:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D16E1204D9 for ; Tue, 18 Oct 2016 05:22:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 38C0BB80099; Tue, 18 Oct 2016 05:22:29 -0700 (PDT) To: mlasserre@alcatel-lucent.com, vach.kompella@alcatel-lucent.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, giheron@cisco.com, nabil.n.bitar@verizon.com Subject: [Editorial Errata Reported] RFC4762 (4834) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161018122229.38C0BB80099@rfc-editor.org> Date: Tue, 18 Oct 2016 05:22:29 -0700 (PDT) Archived-At: Cc: l2vpn@ietf.org, prakash.ragunathan@yahoo.com, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:22:30 -0000 The following errata report has been submitted for RFC4762, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4762&eid=4834 -------------------------------------- Type: Editorial Reported by: Prakash Ragunathan Section: 9.1 Original Text ------------- For example, if a customer site A, is shut down, eventually the other PEs should unlearn A's MAC address. Corrected Text -------------- For example, if customer site A1, is shut down, eventually the other PEs should unlearn A1's MAC address. Notes ----- customer site name is not mentioned in example. Naming the site (A1) gives clear info than just stating "customer site A". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4762 (draft-ietf-l2vpn-vpls-ldp-09) -------------------------------------- Title : Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Publication Date : January 2007 Author(s) : M. Lasserre, Ed., V. Kompella, Ed. Category : PROPOSED STANDARD Source : Layer 2 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Oct 18 19:25:51 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE61293DA for ; Tue, 18 Oct 2016 19:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 u3GH-xX-n_G2 for ; Tue, 18 Oct 2016 19:25:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A499C129517 for ; Tue, 18 Oct 2016 19:25:47 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.48.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CB3A818013BE; Wed, 19 Oct 2016 04:25:29 +0200 (CEST) Subject: Re: [Editorial Errata Reported] RFC4762 (4834) To: RFC Errata System , mlasserre@alcatel-lucent.com, vach.kompella@alcatel-lucent.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, giheron@cisco.com, nabil.n.bitar@verizon.com References: <20161018122229.38C0BB80099@rfc-editor.org> From: Loa Andersson Message-ID: <4e85eb96-d013-e58c-3a8c-d09cd0764fd7@pi.nu> Date: Wed, 19 Oct 2016 10:24:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161018122229.38C0BB80099@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: l2vpn@ietf.org, prakash.ragunathan@yahoo.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:25:50 -0000 Folks, When I started to look at this it looked rather simple, but the statement section 9.1 does not (necessarily) relate to figure 2. I wonder if the first paragraph in section 9.1 should be tweaked this way: OLD PEs that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with a PW label. This is important both for conservation of memory and for administrative purposes. For example, if a customer site A, is shut down, eventually the other PEs should unlearn A's MAC address. NEW PEs that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with a PW label. This is important both for conservation of memory and for administrative purposes. For example, if a customer site S, is shut down, eventually the other PEs should unlearn the MAC address(es) of this site. /Loa On 2016-10-18 20:22, RFC Errata System wrote: > The following errata report has been submitted for RFC4762, > "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4762&eid=4834 > > -------------------------------------- > Type: Editorial > Reported by: Prakash Ragunathan > > Section: 9.1 > > Original Text > ------------- > For > example, if a customer site A, is shut down, eventually the other PEs > should unlearn A's MAC address. > > Corrected Text > -------------- > For > example, if customer site A1, is shut down, eventually the other PEs > should unlearn A1's MAC address. > > Notes > ----- > customer site name is not mentioned in example. Naming the site (A1) gives clear info than just stating "customer site A". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4762 (draft-ietf-l2vpn-vpls-ldp-09) > -------------------------------------- > Title : Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling > Publication Date : January 2007 > Author(s) : M. Lasserre, Ed., V. Kompella, Ed. > Category : PROPOSED STANDARD > Source : Layer 2 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 20 06:59:19 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38A11299D4 for ; Thu, 20 Oct 2016 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaCcHogiKIhr for ; Thu, 20 Oct 2016 06:59:16 -0700 (PDT) Received: from nm14-vm1.bullet.mail.ne1.yahoo.com (nm14-vm1.bullet.mail.ne1.yahoo.com [98.138.91.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225841299CF for ; Thu, 20 Oct 2016 06:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476971954; bh=1333iW1pmiNQfHnZtvTpzLFpxBdGKrviUFPFjaXNEx0=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=oZe6/UPWsCWJ5iOCo1hAwTT3COK6Ap6mrT6QOjvXmPUOhJwpM1zQHx8AsZ5Po50QekkYOHNyhHP+tf1oGUd/B0fVBMvyaXDz3CuNyDsd/HVuTkW0XeKDVOo651vHUZR5FuFnALpAaqCWoWjymIsqhZF5n0OWX83rox1LHZYgimPlsN2sktc8TBA0YizjVrZvHNgelfG1/xr90LSjHJEKkBYDaEJi6GG/CUEJtXRPHjpJUyg48hJDCrBBFFXzNIPVzxB+G5iwIVoiqTmkBVExMFivU5b0xQo5QjWrJb225FyNfd3KTFFPS/iyQICz5ds6P9BEXeZXEenhjHKM0d7ERA== Received: from [98.138.100.113] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 13:59:14 -0000 Received: from [98.138.104.112] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 13:59:14 -0000 Received: from [127.0.0.1] by smtp221.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 13:59:14 -0000 X-Yahoo-Newman-Id: 355282.60219.bm@smtp221.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: R7l5RloVM1l7O4J1K3lN9cXqppnboc1OGThzrNPyn7ivrYX FrSORPsWkMCXOzO5hRv1CEt59BIfcUIjrKvkJZFW1edzvK.WG73o.wIRzyep hqIkzSZVpn4sYUeBw2g.4FPTmmYGev5uC_.9v4ZokUL0EVivw40kFHaz.frS jtj1E6OsGGjdXxkeL3P88k9NyJqoPvvF9R.vFylpwFUunfT7la3gBvfNPpjD _xNc7GNFkAEVnRXzfseG7OX0EYJ2gmIQMUUtSQrz1T5ggRKsk9ny8Ts96IVU fAfjObiQiYaNs4FN.tDWFpuIe4X_2tPczA1_cmJWrRGIHECG9kcayA8onKgx jZoSeI.GhMxliE1.2PSwoXUQ.BdUo5vQngB.wLjBrP17DlUIpT0NUJqO2nZD pq7xY5ZOY_QlYcfpRW9Qu4PyfwAO5Vvm28GwWK0oVqc3glB981vC0qTccoP. Emk769p9OROD871VzYTF2phFx1avP1qIl0kaE5cQnuoYgCWmdZWw4rCMa_6S jgoBRcJ3tKElnbBSM.0dJHD8Fx7_shy0HMUVyyZ03qjWswrk7F7qkM8LLh0L gLRCJgg93blyXU9z_ X-Yahoo-SMTP: aQ0aMMqswBD2BX6yiw_MJIqZGaT5jcsVroHE_mWaRg-- Received: by mail-lf0-f45.google.com with SMTP id b81so85014724lfe.1 for ; Thu, 20 Oct 2016 06:59:13 -0700 (PDT) X-Gm-Message-State: AA6/9RltdxM3PwKEZcD7e9piDowdM2+i1Awxl6UmPC7sXy2oDiN9wA/WIwrjD3bbkFE//YWIr1ijxfE6yjeBbA== X-Received: by 10.28.191.92 with SMTP id p89mr555980wmf.114.1476971949407; Thu, 20 Oct 2016 06:59:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.174.209 with HTTP; Thu, 20 Oct 2016 06:59:08 -0700 (PDT) In-Reply-To: <4e85eb96-d013-e58c-3a8c-d09cd0764fd7@pi.nu> References: <20161018122229.38C0BB80099@rfc-editor.org> <4e85eb96-d013-e58c-3a8c-d09cd0764fd7@pi.nu> From: Prakash Ragunathan Date: Thu, 20 Oct 2016 19:29:08 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Editorial Errata Reported] RFC4762 (4834) To: Loa Andersson Content-Type: multipart/alternative; boundary=001a114e27a0634a55053f4c54b7 Archived-At: Cc: vach.kompella@alcatel-lucent.com, l2vpn@ietf.org, giheron@cisco.com, suresh.krishnan@ericsson.com, RFC Errata System , mlasserre@alcatel-lucent.com, terry.manderson@icann.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:59:18 -0000 --001a114e27a0634a55053f4c54b7 Content-Type: text/plain; charset=UTF-8 Hi Loa, The changed looked really fine. This will avoid any unnecessary confusion. I found similar confusing statements in the same RFC. Will send it as separate requests. Thanks, Prakash R. On Wed, Oct 19, 2016 at 7:54 AM, Loa Andersson wrote: > Folks, > > When I started to look at this it looked rather simple, but the > statement section 9.1 does not (necessarily) relate to figure 2. > > I wonder if the first paragraph in section 9.1 should be tweaked this > way: > > OLD > PEs that learn remote MAC addresses SHOULD have an aging mechanism to > remove unused entries associated with a PW label. This is important > both for conservation of memory and for administrative purposes. For > example, if a customer site A, is shut down, eventually the other PEs > should unlearn A's MAC address. > NEW > PEs that learn remote MAC addresses SHOULD have an aging mechanism to > remove unused entries associated with a PW label. This is important > both for conservation of memory and for administrative purposes. For > example, if a customer site S, is shut down, eventually the other PEs > should unlearn the MAC address(es) of this site. > > /Loa > > > > > On 2016-10-18 20:22, RFC Errata System wrote: > >> The following errata report has been submitted for RFC4762, >> "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol >> (LDP) Signaling". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4762&eid=4834 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Prakash Ragunathan >> >> Section: 9.1 >> >> Original Text >> ------------- >> For >> example, if a customer site A, is shut down, eventually the other PEs >> should unlearn A's MAC address. >> >> Corrected Text >> -------------- >> For >> example, if customer site A1, is shut down, eventually the other PEs >> should unlearn A1's MAC address. >> >> Notes >> ----- >> customer site name is not mentioned in example. Naming the site (A1) >> gives clear info than just stating "customer site A". >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4762 (draft-ietf-l2vpn-vpls-ldp-09) >> -------------------------------------- >> Title : Virtual Private LAN Service (VPLS) Using Label >> Distribution Protocol (LDP) Signaling >> Publication Date : January 2007 >> Author(s) : M. Lasserre, Ed., V. Kompella, Ed. >> Category : PROPOSED STANDARD >> Source : Layer 2 Virtual Private Networks INT >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a114e27a0634a55053f4c54b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

The changed looked really fine.= This will avoid any unnecessary confusion. I found similar confusing state= ments in the same RFC. Will send it as separate requests.

Thanks,
Prakash R.
=
On Wed, Oct 19, 2016 at 7:54 AM, Loa Anderss= on <loa= @pi.nu> wrote:
Folks,

When I started to look at this it looked rather simple, but the
statement section 9.1 does not (necessarily) relate to figure 2.

I wonder if the first paragraph in section 9.1 should be tweaked this
way:

OLD
=C2=A0 =C2=A0PEs that learn remote MAC addresses SHOULD have an aging mecha= nism to
=C2=A0 =C2=A0remove unused entries associated with a PW label.=C2=A0 This i= s important
=C2=A0 =C2=A0both for conservation of memory and for administrative purpose= s.=C2=A0 For
=C2=A0 =C2=A0example, if a customer site A, is shut down, eventually the ot= her PEs
=C2=A0 =C2=A0should unlearn A's MAC address.
 NEW
=C2=A0 =C2=A0PEs that learn remote MAC addresses SHOULD have an aging mecha= nism to
=C2=A0 =C2=A0remove unused entries associated with a PW label.=C2=A0 This i= s important
=C2=A0 =C2=A0both for conservation of memory and for administrative purpose= s.=C2=A0 For
=C2=A0 =C2=A0example, if a customer site S, is shut down, eventually the ot= her PEs
=C2=A0 =C2=A0should unlearn the MAC address(es) of this site.

/Loa




On 2016-10-18 20:22, RFC Errata System wrote:
The following errata report has been submitted for RFC4762,
"Virtual Private LAN Service (VPLS) Using Label Distribution Protocol = (LDP) Signaling".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D4762&eid=3D4834

--------------------------------------
Type: Editorial
Reported by: Prakash Ragunathan <prakash.ragunathan@yahoo.com>

Section: 9.1

Original Text
-------------
For
=C2=A0 =C2=A0example, if a customer site A, is shut down, eventually the ot= her PEs
=C2=A0 =C2=A0should unlearn A's MAC address.

Corrected Text
--------------
For
=C2=A0 =C2=A0example, if customer site A1, is shut down, eventually the oth= er PEs
=C2=A0 =C2=A0should unlearn A1's MAC address.

Notes
-----
customer site name is not mentioned in example. Naming the site (A1) gives = clear info than just stating "customer site A".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4762 (draft-ietf-l2vpn-vpls-ldp-09)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Virtual Priva= te LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
Publication Date=C2=A0 =C2=A0 : January 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Lasserre, Ed., V. Ko= mpella, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Layer 2 Virtual Pr= ivate Networks INT
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Internet
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

--001a114e27a0634a55053f4c54b7--