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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Jul 2004 16:13:22 +0100

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"

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 29 Jul 2004 11:10:41 -0700 (PDT)

Hi Adrian,

Thanks for reviewing the document and providing feedback.

> 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.
--------> I thought that it was a private e-mail exchange. Anyway, this is
probably a good point to be discussed during the meeting next week.

>    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).
------------> I agree, that this needs to be re-worded. Will do so in the
next revision.

> 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
--------> Thanks!

> Copyright date at the head of the document is wrong.
--------> Will fix.

> "Switching"
-----------> Will fix.

I also noticed that section 3.2 has been titled as "Stitching of packet
LSPs"...I think that needs to be fixed as well. There are some aspects
there which only apply to packet LSPs, but some other aspects which apply
to both packet and non-packet LSPs. So, this needs to be clarified as
well.

thanks,
-arthi

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 29 Jul 2004 21:12:21 +0200

hi arthi - see in-line

> to both packet and non-packet LSPs. So, this needs to be clarified as

but the whole document is oriented towards RSVP-TE signaling only RFC 
3473 is only referenced in the introduction

several additional comments here below

1) section 3.1

"A mid-point
    LSR not supporting contiguous TE LSP MUST send a Path Error message
    upstream with an error code of "Routing Problem" and error sub-
    code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not
    be modified by any downstream node."

first tiem the term "mid-point" LSR is used but the major point is that
1) there is a difference between capability and policy
2) there is from point 1) a distinction to be made from which entry 
point we're speaking about

in brief as in the most common contiguous LSP is supported by any LSR, 
the above rule should be refined

2) would it be possible to replace the section with the examples by the 
generic operations to be performed ?

3) how FRR section applies to non-PSC environments ?

4) in the re-optimization part it is unclear how in a multi-domain 
context one constraints the head-end to use the same entry point as the 
one from which re- optimization has been initiated ? wouldn't it be 
better to focus on setup and recovery and come up in a next step with a 
re-optimization solution that applies once the former items get more 
stable ?

thanks,
- dimitri.

> .