Subject: review assignment: draft-ietf-mpls-rsvpte-attributes-04.txt: rcallon; mshand

From: Alex Zinin <[email-masked]>
Date: Fri, 27 Aug 2004 15:22:48 -0700

skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair)
round-robin: Mike

http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-04.txt

>   Encoding of Attributes for  Multiprotocol Label Switching (MPLS)
>          Label Switched Path (LSP) Establishment Using RSVP-TE

> Abstract
> 
>    Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
>    be established using the Resource Reservation Protocol Traffic
>    Engineering extensions (RSVP-TE). This protocol includes an object
>    (the SESSION_ATTRIBUTE object) which carries a flags field used to
>    indicate options and attributes of the LSP. That flags field has
>    eight bits allowing for eight options to be set. Recent proposals in
>    many documents that extend RSVP-TE have suggested uses for each of
>    the previously unused bits.
> 
>    This document defines a new object for RSVP-TE messages that allows
>    the signaling of further attribute bits and also the carriage of
>    arbitrary attribute parameters to make RSVP-TE easily extensible to
>    support new requirements. Additionally, this document defines a way
>    to record the attributes applied to the LSP on a hop-by-hop basis.
> 
>    The object mechanisms defined in this document are equally applicable
>    to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to
>    GMPLS non-PSC LSPs.

-- 
Alex
http://www.psg.com/~zinin

---

From: mike shand <[email-masked]>
Date: Tue, 31 Aug 2004 11:53:39 +0100

>skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair)

OK.

         Mike

---

From: Ross Callon <[email-masked]>
Date: Wed, 08 Sep 2004 16:36:08 -0400

>skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair)

Looking this over, I think that it is pretty good.

Its purpose is to correct a deficiency in RSVP signalling formats which is,
in my opinion, a rather unfortunate deficiency. Specifically, the flags field
in the SESSION_ATTRIBUTE object is simply not large enough (8 bits).

This is therefore solving a fairly basic issue in the RSVP packet formats.

The problem is solved with a reasonable consideration for compatibility
with older (not-yet-updated) systems.

The approach here allows general TLV-based items to be added to the
packet format, which seems like a good general way to solve the problem
(for example, if they instead just made the field twice as large, we might
run into the same problem all over again in a few years).

Defines both end-to-end (intermediate hops may ignore) and hop-by-hop
(all hops should interpret and process) types of RSVP objects (again, a
useful distinction).

Is useful in applications such as inter-domain MPLS TE signaling.

Ross