[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