draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Arthi and Jean-Philippe,

Thanks for putting this draft together; a good start.

A few thoughts.

Cheers,
Adrian

As has been discussed on the list already, I think it would be really helpful to have a
brief architectural description of how stitched LSPs work. This is probably best suited to
a separate draft.

In the Abstract you say...
  This document describes extensions to Generalized Multi-Protocol Label
  Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
  (RSVP-TE) signaling required to support mechanisms for the establishment
  and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
  (LSPs), both packet and non-packet, that traverse multiple domains.
...in the Introduction
   This document presents the RSVP-TE signaling extensions for the setup
   and maintenance of TE LSPs that span multiple domains. The signaling
   procedures described in this document are applicable to both packet
   LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS
   extensions as described in [RSVP-GMPLS]. Three different signaling
   methods along with the corresponding RSVP-TE extensions and
   procedures are proposed in this document.
There seems to be some mix up between MPLS and GMPLS. Presumably we want to support this
work in all MPLS TE and all GMPLS (i.e. PSC and non-PSC).


LSP_ATTRIBUTES bits.
You may recall that I am tracking provisional assignments of LAP Attributes bits at
www.olddog.co.uk/lsp-attrib.txt.
This enables people to go ahead with provisional implementations without seeing a conflict
of meaning, and handles the situation until IANA has control of these bits.
I have added your two uses to the list at values 5 and 6


Nits
===
Copyright date at the head of the document is wrong.

1.2. Terminology
   LSR: Label Switch Router
"Switching"