[mpls] For your review - Issues/errors/clarifications in RFC3036

Ina Minei <ina@juniper.net> Mon, 27 September 2004 22:47 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17650; Mon, 27 Sep 2004 18:47:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC4Ox-0002iZ-5M; Mon, 27 Sep 2004 18:55:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC45R-0002Om-Kd; Mon, 27 Sep 2004 18:35:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC0Hs-0003IK-AA for mpls@megatron.ietf.org; Mon, 27 Sep 2004 14:31:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18869 for <mpls@ietf.org>; Mon, 27 Sep 2004 14:31:45 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC0PR-0002zG-4Z for mpls@ietf.org; Mon, 27 Sep 2004 14:39:43 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i8RIV3937217; Mon, 27 Sep 2004 11:31:03 -0700 (PDT) (envelope-from ina@juniper.net)
Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i8RIUwe49271; Mon, 27 Sep 2004 11:30:58 -0700 (PDT) (envelope-from ina@juniper.net)
Date: Mon, 27 Sep 2004 11:30:58 -0700
From: Ina Minei <ina@juniper.net>
To: mpls@ietf.org
In-Reply-To: <20040819172140.A7956@garnet.juniper.net>
Message-ID: <20040927112038.O76276@garnet.juniper.net>
References: <20040819172140.A7956@garnet.juniper.net>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-295533280-1096309858=:76276"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5dbeeab5a9674d0f943758c1a782c445
X-Mailman-Approved-At: Mon, 27 Sep 2004 18:35:11 -0400
Subject: [mpls] For your review - Issues/errors/clarifications in RFC3036
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@ietf.org
Errors-To: mpls-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5c5bd9ed2a6a243c797338f13c9fe22e

   As part of the effort to move RFC3036 to draft standard, here is an
annotated version of RFC3036, with the changes enclosed by ###.
There is a separate section summarizing all changes towards the end of the
document.

   Please review the changes and send comments to the list by October
11th.

   At the end of this mail is a list of issues that were raised but
were not included in the annotated RFC (with an explanation of
why).

   Please review both the RFC changes and the list of issues not
included. Also let me know if I forgot to include any other issues
that were raised on the list.

   Many thanks to all who contributed, and in particular to Bob Thomas
for maintaining an extensive list of errors/issues over the years.


    		Thank you,

			Ina


Issues that were raised but not included in the annotated RFC
=============================================================

- Issue: discussion on the merits/drawbacks of independent-control and
ordered-control
- Issue: discussion on which FECs should be advertised
Reason why not included: The above two issues are either for the
applicability doc or for the "experiences with the protocol" document.

- Issue:  minor optimization: if A is a stub node, i.e., only one LDP
session, does it really have to send a label mapping for every FEC that
it has, or can it do it lazily, e.g., when it has a second LDP session?
Reason why not included : It is not clear what problem this change in
behavior brings, and what would be the added benefit,the issue must
be discussed on the list first.

- Issue: the ldp loop detection mechanisms don't make sense in DU.
We should add something explicitly that
says that these TLVs should not be used in DU mode. ( This is the
current practice in all implementations that I know of )
Why not included: RFC 3036 already states this in the section
describing these TLVs, when it talks about the usage of the TLVs.

- Issue: the rfc should specifically say that  a  wildcard release
message should be sent only in response to a wildcard withdraw message.
Reason not included: it is covered in the rules in the appendix.

- There is a long list of issues that was added to the "for future
study" area of the RFC. The list is quite long, we could probably
remove some of the items.
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls