The MPLS WG Archive

[Adrian Farrel <AF@datcon.co.uk>]

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:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422