[mpls] Re: Last Call Assignment: draft-ietf-mpls-rsvpte-attributes-04.txt
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 07 December 2004 22:18 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 RAA06167; Tue, 7 Dec 2004 17:18:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbnm3-0002Pm-B7; Tue, 07 Dec 2004 17:25:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnPk-0006Lr-DX; Tue, 07 Dec 2004 17:02:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnCY-0007JK-JI for mpls@megatron.ietf.org; Tue, 07 Dec 2004 16:48:54 -0500
Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01514 for <mpls@lists.ietf.org>; Tue, 7 Dec 2004 16:48:51 -0500 (EST)
Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id DAAD5E000394; Tue, 7 Dec 2004 21:48:16 +0000 (GMT)
Received: from Puppy ([217.158.145.173] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 21:48:18 +0000
Message-ID: <04c401c4dca6$934dd550$fd919ed9@Puppy>
From: Adrian Farrel <adrian@olddog.co.uk>
To: gen-art@alvestrand.no, "Joel M. Halpern" <joel@stevecrocker.com>
References: <5E17B42A-485B-11D9-8830-000393CC2112@psg.com> <6.1.2.0.0.20041207111453.03e2ed38@localhost>
Date: Tue, 07 Dec 2004 21:48:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 07 Dec 2004 21:48:19.0678 (UTC) FILETIME=[774307E0:01C4DCA6]
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org, jpv@cisco.com
Subject: [mpls] Re: Last Call Assignment: draft-ietf-mpls-rsvpte-attributes-04.txt
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
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.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Joel, Excellent. Thank you. In line. Adrian > IANA Considerations: > The document identifies two new spaces for the IANA to manage. It > lists the properties of relevance to values in these spaces. However, it > does not indicate what procedure is to be followed for assigning values in > these registries. Are they to be assigned only by IETF Standards Track > RFCs? Are they assigned simply on a first-come, first-served basis with > sufficient documentation? Good catch. I never did get IANA sections right. We'll think about this and update the draft. > Minor comments: > > The document talks about several degrees or kinds of mandatory / optional > information, ranging from information that must be examined at every node > to information that only needs to be examined at the end-points. The > specific example is given of information that needs to be examined at > ABR/ASBRs, but should be deployable without upgrading all routers in the > path. It is not clear that this stated goal is met by the solution > provided. Some text on how the various cases listed are met by the > documented method would be helpful. Sure. We can do that. > In section 7.3.1, there are two lines which confused me: > The Attributes subobject is pushed onto the RECORD_ROUTE object > immediately prior to pushing the node's IP address or link > ... > This means that an Attributes subobject is bound to the LSR > identified by the subobject found in the RRO immediately before the > Attributes subobject. > The first sentence seems to say that when I parse the message I will find > the Attributes subobject followed by the ID of the node which put it there. > The later sentence seems to say that the Attributes subobject is bound to > the ID which precedes it, rather than the ID which follows it? No, RRO is described as a stack. So, that which you push first, you pop last. You receive an RRO and you add your sub-objects to the front. You add the Attributes sub-object first, then you add your node/link. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
- [mpls] Re: Last Call Assignment: draft-ietf-mpls-… Joel M. Halpern
- [mpls] Re: Last Call Assignment: draft-ietf-mpls-… Adrian Farrel
- [mpls] Re: Last Call Assignment: draft-ietf-mpls-… Joel M. Halpern
- [mpls] Re: Last Call Assignment: draft-ietf-mpls-… Adrian Farrel