Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4090
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
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
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
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) (was No Record, Yes) No Objection
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
(Margaret Cullen; former steering group member) No Objection
This draft has too many authors.
(Ned Freed; former steering group member) No Objection
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
(Scott Hollenbeck; former steering group member) No Objection
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) (was Discuss) No Objection
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?