Skip to main content

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

No Objection

(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Russ Housley)
(Scott Hollenbeck)
(Steven Bellovin)
(Ted Hardie)

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

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection (2003-11-20)
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.

(Bert Wijnen; former steering group member) No Objection

No Objection (2003-11-20)
I am a no(further)Objections.

Comment:
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".

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) (was No Record, Yes) No Objection

No Objection (2003-11-19)
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.

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection (2003-11-19)
This draft has too many authors.

(Ned Freed; former steering group member) No Objection

No Objection (2003-11-19)
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.

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Steven Bellovin; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection ()

                            

(Thomas Narten; former steering group member) (was Discuss) No Objection

No Objection (2003-11-19)
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?