Subject: draft-ashwood-generalized-mpls-signaling-00

From: Adrian Farrel <[email-masked]>
Date: Fri, 21 Jul 2000 16:33:13 +0100

Peter, Lou,

Good draft.

Attached a few small questions, a couple of editorial suggestions and a
clutch of typos.

I hope this helps.

Regards,
Adrian

Questions
=========

1. I know I was shot down last time I suggested this, but that was
   in the optical discussion before the draft became "generalized"...
   Given that we can now set up LSPs as downstream on demand, or 
   downstream on demand AND downstream unsolicited at the same time 
   i.e. bidirectional), why don't we allow downstream unsolicited on 
   its own?  This would make for a fully generalized solution .
   The answer before was "There are no applications for this," but I 
   would argue for making this fully generalized while we're at this 
   stage especially since the work is simply to relax the requirement
   that 'label request' must be present on REQUEST/Path to say that at
   least one of 'label request', 'label' and 'generalized label' must
   be present.

2. Is it an issue that you cannot choose at LSP set up whether the LSP
   will switch a wavelength or the whole fiber?  Since this is a 
   property of the link and not of the signaled label, a link's usage 
   for wavelength switching or whole fiber switching cannot be
   selected dynamically.  Is this an issue?

3. Could you explain the "compatibility reasons" why a new c-type is 
   required for a Generalized Label that contains a Waveband Label?
   I've looked through the archive and can't find any reference - sorry
   if I wasn't paying attention when this was discussed.

4. Would it be worth prohibiting bidirectional LSP setup where the
   forward label is of one type and the reverse label of a different
   type?  This would be a bit odd since the resource requirements are
   the same in both directions.

5. I like the concept of Egress Label in an ERO to support splicing to
   an existing tunnel.  Would now not be a good time to add support 
   for stacking as well?  The ERO suboject format would match that of
   Egress Label, but a new type would be needed.  I'm sure there would
   be many uses in the optical world.

   Compare with the ER-Hop type of LSPID in CR-LDP.

Editorial
=========

Section 1, item 3.  I think this could usefully mention wavebands up front.
Simply add "or waveband"?

Section 3.1.3. Need to clarify the description of LSP Encoding Type since
currently "transparently passed by transit node" appears to contradict
3.1.2.  "forwarded unchanged" might be a better description.

Section 3.2.2. Cover bidirectional labels by adding to the end of the first
paragraph to say "or downstream in REQUEST/Path messages as specified in
section 4.2 for bidirectional LSP set up."

Typos
=====

Page header shows "Draftraft"

2., para 3, line 1 Strike duplicate "and"

2., para 3, line 2 Read "...is that bandwidth allocation for a non-PSC
LSP..."

2., para 6, line 4 For "come" read "comes"

3., para 1  For "such at the ingress" read "such that the ingress"

3.2.1, Link ID, 1st line, For "request" read "requested"

--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 14:20:50 -0400

Adrian,
         Thank you for your usual quality comments.

See below for some responses.

Lou
>    least one of 'label request', 'label' and 'generalized label' must

I still think understanding a use for this makes sense before considering 
adding it.  What application are you thinking about?

Also, in the bidirectional case, I completely don't see the point.  What am 
I missing?

>    selected dynamically.  Is this an issue?

I don't think I understand the question.  Perhaps we should just talk about 
this one face-to-face in Pittsburgh.

>    if I wasn't paying attention when this was discussed.

It allows nodes that don't support waveband switching to respond with an 
appropriate error message.  The message falls out of previously specified 
signaling behavior.  For RSVP the relevant behavior is defined in RFC2205, 
under handling of "Unknown C-Type for Known Class".

>    the same in both directions.

I'm not sure how you could signal setting up different label types in each 
direction.  Do you see a way?

>    for stacking as well?

Again, I think this should be driven by application.  If you've got one, 
lets talk about it.

>  The ERO suboject format would match that of

[Rest of original message delete, looked good to me.]

Thanks again,
Lou