Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4090

Note: This ballot was opened for revision 07 and is now closed.

(Harald Alvestrand) (was No Record, Yes) No Objection

Comment (2003-11-19 for -)
No email
send info
Comment removed after discussion with security ADs (see log).
There's reason to worry, but no more reason to worry with this document than without it, and that justifies the "no new security considerations" language.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

Comment (2003-11-19 for -)
No email
send info
This draft has too many authors.

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-11-19 for -)
No email
send info
Nonstandard IPR section talks explicitly about Cisco having IPR in this
area. Is this OK? I thought the idea was not to embed IPR claims in RFCs.

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2003-11-20 for -)
No email
send info
I gave this a protesting no objection - my concern is that the extended usage of the ERO to access bypass paths in the network heightens the risks of ERO.  We are very concerned about source route risks in IP, but have neglected the topic in RSVP-TE.

(Thomas Narten) (was Discuss) No Objection

Comment (2003-11-19)
No email
send info
I don't understand the IANA stuff. Section 4.1 mentions:

>       Class = TBD  (use form 11bbbbbb for compatibility)
>       C-Type = 1

That seems fine. But later in the section,

>    For informational purposes, a different C-type value and format for
>    the FAST_REROUTE object are specified below.  This is used by
>    existing implementations.  The meaning of the fields is the same as
>    described for C-Type 1.

But, there is no corresponding C-Class defined (since it is actually
TBD). Is the assumption that C-Class must be 63? I guess this will all
work out if the IANA makes the following assignments as requested:

> 10. IANA Guidelines
>    IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and
>    DETOUR objects.  Currently, in production networks, FAST_REROUTE uses
>    C-class 205, and DETOUR uses C-class 63.

Shouldn't the C-Types be mentioned here as well?

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2003-11-20 for -)
No email
send info
I am a no(further)Objections.

The background section reads weird when this gets published as an RFC.
It talks about "this draft" a few times and it talks about "the goal is
to standardize".

(Alex Zinin) No Objection