[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