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

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 21 Jul 2000 13:06:46 -0400

Thanks Adrian,

     I have filed away your comments for a future editing session. I
personally have no problems with any of your suggestions but I suspect the
first one may cause some interesting debate. Might be fun to argue about it
in Pittsburgh.

     Cheers,

     Peter

	-----Original Message-----
	From:	Adrian Farrel [SMTP:[email-masked]]
	Sent:	Friday, July 21, 2000 11:33 AM
	To:	[email-masked]; Ashwood-Smith, Peter [CAR:CS57:EXCH]
	Cc:	[email-masked]
	Subject:	draft-ashwood-generalized-mpls-signaling-00

	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