Re: [Editorial Errata Reported] RFC4762 (4834)

Loa Andersson <loa@pi.nu> Wed, 19 October 2016 02:25 UTC

Return-Path: <loa@pi.nu>
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 <l2vpn@ietfa.amsl.com>; 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 <l2vpn@ietfa.amsl.com>; 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 <l2vpn@ietf.org>; 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 <rfc-editor@rfc-editor.org>, 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 <loa@pi.nu>
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: <https://mailarchive.ietf.org/arch/msg/l2vpn/gc9zuP1mv31LXzPGuRAczU-hotU>
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 <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=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 <prakash.ragunathan@yahoo.com>;
>
> 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