Re: comments on rsvp-te-06

[Lou Berger <lberger@movaz.com>]

per today's discussion:

At 10:14 AM 11/30/2001, Zhi-Wei Lin wrote:

>Hi folks,
>
>In rsvp-te-06, IANA consideration section, the Notify message message
>type also needs to be assigned by IANA.

agreed.  there is no change to the document here.

>Also, several error codes/values
>were introduced in the document. I believe these also need to be
>identified and assigned (e.g., routing problem/switching type, routing
>problem/unsupported link protection)

agreed.  This will be part of the IANA assignment request.  (Which will be 
forthcoming soon.)

>In section 9.3, two error messages were defined:
>         "Control Channel Degraded State"
>         "Control Channel Active State"
>Are these both new error codes, or a single error code with two error
>values, or part of an existing error code?

yes.  will be part of the IANA assignment.

>Also, the text says "inform other nodes of the restoration via a
>PathErr...". What are the other nodes? Is it all RSVP-aware nodes, all
>nodes where a LSP passes through the failed node, etc. ?
>

sorry, it should say "upstream" rather than "other".
(It'll be this way in the post IETF last call rev.)

>In section 4.3.1, reference to RFC2205 for error codes and values is
>insufficient. Many of the relevant error codes are also in the RSVP-TE I-D.

The reference is to the error_spec definition, which is rfc2205.

>In section 7.2.1, both step 3 are the same description.

yes, this is intentional!

>Based on the
>flow of description, I think the first step 3 should read:
>"Upon receiving the Admin Status Object with the Delete (D) bit set in
>the Path message, the egress node sends a PathErr message (with
>      ^^^^              ^^^^^^              ^^^^^^^         ^^^^^
>Path_State_Removed flag set) upstream to remove the LSP and normal RSVP
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>processing takes place."

The egress triggers the ingress to do the delete.

>In section 9.1, a statement under "recovery time":
>         A value of 0xffffffff indicates that resynchronization may
>           occur at a rate selected by the receiver.
>while in section 9.5.2, the following statement is made:
>         A Recovery Time value of 0xffffffff indicates that the
>         Recovery Period is effectively infinite.
>which is correct? or am I misinterpreting this?

These statements are mutually consistent.  If you'd like, I can just remove 
the text, but I think most will find the comment useful.

Lou

>Looking forward to comments...
>
>Zhi