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

[Dimitri.Papadimitriou@alcatel.be]

hi adrian, all

> 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 any case a description of stitching of PSC, and non-PSC LSPs should be
detailed - ideally operations should be as common as possible

>  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).

at least i'm not the only one thinking that at some point in time this
ambiguity should be removed in particular within the CCAMP WG context but
even the title of the document is ambiguous from that perspective

>   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

i could also be interesting to have a bit more details on "NULL" label and
related processing - other comments to follow

> Nits
> ====
> Copyright date at the head of the document is wrong.
>
> 1.2. Terminology
> LSR: Label Switch Router "Switching"