[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

hi arthi - see in-line

Arthi Ayyangar wrote:

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.


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


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


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


--------> Will fix.


1.2. Terminology
  LSR: Label Switch Router
"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.

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.

thanks,
-arthi


.