[mpls] [Technical Errata Reported] RFC5036 (4512)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 26 October 2015 10:11 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2F61B3AA5 for <mpls@ietfa.amsl.com>; Mon, 26 Oct 2015 03:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.512
X-Spam-Level:
X-Spam-Status: No, score=-105.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGH5p8pdKKx1 for <mpls@ietfa.amsl.com>; Mon, 26 Oct 2015 03:11:45 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D862D1B3AA1 for <mpls@ietf.org>; Mon, 26 Oct 2015 03:11:45 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1E98A18046B; Mon, 26 Oct 2015 03:11:14 -0700 (PDT)
To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20151026101114.1E98A18046B@rfc-editor.org>
Date: Mon, 26 Oct 2015 03:11:14 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/yZhGJqtKcFX_BkhrgSFhI6DfCrU>
Cc: mpls@ietf.org, rfc-editor@rfc-editor.org, jiessie.xu@ericsson.com
Subject: [mpls] [Technical Errata Reported] RFC5036 (4512)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2015 10:11:47 -0000
The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=4512 -------------------------------------- Type: Technical Reported by: Jiessie <jiessie.xu@ericsson.com> Section: 2.5.2 Original Text ------------- 2.4.1. Basic Discovery Mechanism To engage in LDP Basic Discovery on an interface, an LSR periodically sends LDP Link Hellos out the interface. LDP Link Hellos are sent as UDP packets addressed to the well-known LDP discovery port for the \\"all routers on this subnet\\" group multicast address. 2.5.2. Transport Connection Establishment Note that when an LSR sends a Hello, it selects the transport address for its end of the session connection and uses the Hello to advertise the address, either explicitly by including it in an optional Transport Address TLV or implicitly by omitting the TLV and using it as the Hello source address. Corrected Text -------------- Notes ----- According to 2.4.1, an LSR send Hellos to \\"all routers on this subnet\\", the eligible reception LSR should be on this subnet. 2.5.2 states that one way for an LSR to advertise Transport Address is to uses it as Hello source address. On the topology below, LSRa uses 1.1.1.1 as Transport Address and sends Hello(source:1.1.1.1 destination:224.0.0.2) to LSRb. LSRb will ignore this packet which is not on its interface subnet. 1.1.1.1 |LSRa|--------------|LSRb| 10.1.1.1 10.1.1.2 My question is: What\\'s the scenario to use \\"implicitly\\" way to send Hello? 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. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG
- [mpls] [Technical Errata Reported] RFC5036 (4512) RFC Errata System
- Re: [mpls] [Technical Errata Reported] RFC5036 (4… Renato Westphal
- [mpls] [Errata Rejected] RFC5036 (4512) RFC Errata System