Subject: [mpls] Re: Last Call Assignment: draft-ietf-mpls-rsvpte-attributes-04.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Dec 2004 12:36:56 -0500

[This is a General Area review at last call.]

This draft is basically ready for publication as a Proposed Standard, but 
has nits that should be fixed before publication.

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?

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.

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?

At 09:22 AM 12/7/2004, you wrote:
>-  Joel Halpern
>    'Encoding of Attributes for Multiprotocol Label Switching (MPLS)
>Label
>    Switched Path (LSP) Establishment Using RSVP-TE '
>    <draft-ietf-mpls-rsvpte-attributes-04.txt> as a Proposed Standard

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 21:48:51 -0000

Joel,

Excellent. Thank you.

In line.

Adrian

> sufficient documentation?

Good catch. I never did get IANA sections right. We'll think about this and update the
draft.

> documented method would be helpful.

Sure. We can do that.

> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Dec 2004 17:55:59 -0500

The description you provide makes sense.
I am afraid that a reader who is not sufficiently involved in RRO work may 
well not understand what is meant.  If you could elaborate the second 
sentence (the one with "the RRO immediately before") just a bit, it would 
probably help.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Dec 2004 12:39:47 -0000

OK, we can do that (although in fairness, anyone not familiar with the RRO should really
not be playing with LSP Attributes!).

A
----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "Dimitri Papadimitriou" <[email-masked]>; <[email-masked]>; "Arthi
Ayyangar" <[email-masked]>; <[email-masked]>; "Alex Zinin" <[email-masked]>;
"George Swallow" <[email-masked]>; "Loa Andersson" <[email-masked]>
Sent: Tuesday, December 07, 2004 10:55 PM
Subject: Re: Last Call Assignment: draft-ietf-mpls-rsvpte-attributes-04.txt