Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt

From: Adrian Farrel <[email-masked]>
Date: Tue, 4 Jan 2000 06:16:32 -0000

Jerry, hi.

We've already discussed my major points with this draft, and they've also
recently been raised on the list.

Here are a few additional points, typos and editorial thoughts.

I hope they are of use.

Happy New Year,
Adrian

In sections 1 and 3 the text still refers to the _action indicator flag_ as
an extension to CR-LDP.  It is, of course, now part of the spec and the
_modify_ value is defined.  I suggest that the text be changed to read
something like...

   The LSP modification feature can be supported by CD-LDP by
   use of the _modify_ value for the _action indicator flag_
   in the LSPID TLV.

In section 2 you define the convention Lid: but in the text you use L-id:

In section 2 you might move FTN to below NHLFE.

In section 3 you twice refer to the action indication flag (should read
indicator).

4.1, para 2.  For "in the messages" read "in the message".

4.1 para 2.  Insert "its" to read "R1 now still has an entry in its FTN".

4.1 para 3.  I think it would be useful to clarify at this point that
bandwidth is never decreased while processing a modify Label Request.  I
suggest that the last part of the paragraph should read something like...
(I have also made a suggested change to the order of the words in the
penultimate sentence for clarity.)

   bandwidth required and derives the new service class. Compared with
   the already reserved bandwidth for L-id1, Ri now reserves only any
   increase in the bandwidth requirements. A reduction in bandwidth 
   requirements is only actioned when the old label is released. This
   prevents Ri from doing bandwidth double booking. If a new service 
   class is requested, Ri also prepares to receive the traffic on L1 
   in just the same way as handling it for a Label Request Message, 
   perhaps using a different type of queue. Ri assigns a new label for
   the Label Request Message.

4.1 para 4.  Insert "its" to read "R1 can now activate the new entry in its
FTN".

4.1 para 5, penultimate line.  Should "R1" read "Ri"?

4.1 para 5, last line.  Insert "s" to read "another set of labels".

4.1 para 5 (or 6 depending on the page break!)  The reference to using
modify to reroute an LSP is fine but perhaps a bit thin.  In particular, the
previous description of the behavior for assigning and releasing labels does
not apply itself well to the case where the LSPID only has one entry on
parts of the path where the path has diverged.  I suggest that an additional
subsection describing reroute should be added.  I'd be happy to draft some
text if you like.

4.2 Missing blank line between the paragraphs.

4.3 It is, perhaps, stating the obvious, but I think this section would
benefit from a direct statement such as...

   In the event of a modification failure, all modifications to 
   the LSP including the holding priority must be restored to
   their original values.

5.0 should be numbered simply 5.

5.0 para 1, last sentence.  For "priority" read "priorities".

5.0 para 2 and 3.  Many small typos.  Updated version below.

   The network operator wants to control the resource on the links of
   LSRs, so each LSR keeps the usage status of its links and based on
   the usage history, each link is assigned a current threshold
   priority Pi. Which means that the link has no bandwidth available
   for a Label Request with a setup priority lower than Pi. When an 
   LSP's bandwidth needs to be modified, the operator uses a policy 
   based algorithm to assign a priority for its modification request, 
   say Mp for LSP L2. Then the ingress LSR sends Label Request message
   with (Setup Priority = Mp). The rule is then only if there is enough
   bandwidth on the link and, the Setup priority in the Label Request
   Message is higher in priority (Mp numerically smaller) than Pi of
   the link, the Label Request Message will be accepted by the LSR.
   Otherwise, the Label Request message will be rejected with a
   Notification message indicating that there aren't enough resources. 
   It should also be noted that when OSPF (or IS-IS) floods the link
   available bandwidth information, the available bandwidth associated
   with priority lower than Pi (numerical value bigger) should be
   indicated as _0_. This procedure based on a priority threshold Pi is
   implementation specific and value added. It offers networks
   flexibility to prioritize and control its resources.

   The calculation of Mp is network dependent, based on the operator's 
   own algorithm. For example, the operator may assign a higher Mp to 
   L2 if L2 belongs to a customer with _Key_ priority. The operator may
   also collect the actual usage of each LSP and assign a high Mp to L2 
   if in the past week, L2 has exceeded its reserved bandwidth by 2 
   times on average, and the customer of L2 agrees to increase its
   bandwidth for a better guaranteed service. Some operators may try to
   increase the bandwidth of L2 on its existing path unsuccessfully as
   there isn't enough bandwidth there. Then the operator is willing to
   change the path of L2 in order to increase its bandwidth, but with a
   lower priority Mp this time as L2 is now routed on its secondary
   path, which should yield priority to the LSPs that are on its
   primary paths here.

Section 7.  Should this section include a comment about security with
respect to modifications made to LSPs by malign agents?

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

---

From: "Ash, Gerald R (Jerry), ALARC" <[email-masked]>
Date: Wed, 5 Jan 2000 09:59:32 -0500

Adrian,

Many thanks for your careful reading and helpful comments.  We agree with
essentially all your suggested changes (see responses below).

Happy New Year!
Jerry Ash
------------------------------------------------------------
Gerald R. (Jerry) Ash
AT&T Labs
Manager, Standards Strategy
Room MT E3-3C37
200 Laurel Avenue
Middletown, NJ 07748
USA
Telephone  732-420-4578
Fax            732-368-6687
Email          [email-masked]
------------------------------------------------------------

	-----Original Message-----
	From:	Adrian Farrel [SMTP:[email-masked]]
	Sent:	Tuesday, January 04, 2000 1:17 AM
	To:	Ash, Gerald R (Jerry), ALARC; [email-masked]'
	Subject:	RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt

	Jerry, hi.

	We've already discussed my major points with this draft, and they've
also
	recently been raised on the list.

	I hope they are of use.

	Happy New Year,
	Adrian

	In sections 1 and 3 the text still refers to the _action indicator
flag_ as
	an extension to CR-LDP.  It is, of course, now part of the spec and
the
	_modify_ value is defined.  I suggest that the text be changed to
read
	something like...

	OK

	In section 2 you define the convention Lid: but in the text you use
L-id:
	Will change Section 2 to L-id

	OK

	In section 3 you twice refer to the action indication flag (should
read
	indicator). 
	OK

	OK

	4.1 para 2.  Insert "its" to read "R1 now still has an entry in its
FTN". 
	OK

	4.1 para 3.  I think it would be useful to clarify at this point
that
	bandwidth is never decreased while processing a modify Label
Request.  I
	suggest that the last part of the paragraph should read something
like...
	(I have also made a suggested change to the order of the words in
the
	penultimate sentence for clarity.) 

	   bandwidth required and derives the new service class. Compared
with
	   the already reserved bandwidth for L-id1, Ri now reserves only
any
	   increase in the bandwidth requirements. A reduction in bandwidth 
	   requirements is only actioned when the old label is released.
This
	   prevents Ri from doing bandwidth double booking. If a new service

	   in just the same way as handling it for a Label Request Message, 
	   perhaps using a different type of queue. Ri assigns a new label
for
	   the Label Request Message.
	OK

	4.1 para 4.  Insert "its" to read "R1 can now activate the new entry
in its
	FTN". 
	OK

	yes

	OK

	4.1 para 5 (or 6 depending on the page break!)  The reference to
using
	modify to reroute an LSP is fine but perhaps a bit thin.  In
particular, the
	previous description of the behavior for assigning and releasing
labels does
	not apply itself well to the case where the LSPID only has one entry
on
	parts of the path where the path has diverged.  I suggest that an
additional
	subsection describing reroute should be added.  I'd be happy to
draft some
	text if you like.
	OK, also happy to get suggested text.

	OK

	4.3 It is, perhaps, stating the obvious, but I think this section
would
	benefit from a direct statement such as...

	   In the event of a modification failure, all modifications to 
	   the LSP including the holding priority must be restored to
	   their original values.
	OK, will insert at end of Section 4.3

	OK

	OK

	   The network operator wants to control the resource on the links
of
	   LSRs, so each LSR keeps the usage status of its links and based
on
	   the usage history, each link is assigned a current threshold
	   priority Pi. Which means that the link has no bandwidth available
	   for a Label Request with a setup priority lower than Pi. When an 
	   LSP's bandwidth needs to be modified, the operator uses a policy 
	   based algorithm to assign a priority for its modification
request, 
	   say Mp for LSP L2. Then the ingress LSR sends Label Request
message
	   with (Setup Priority = Mp). The rule is then only if there is
enough
	   bandwidth on the link and, the Setup priority in the Label
Request
	   Message is higher in priority (Mp numerically smaller) than Pi of
	   the link, the Label Request Message will be accepted by the LSR.
	   Otherwise, the Label Request message will be rejected with a
	   Notification message indicating that there aren't enough
resources. 
	   It should also be noted that when OSPF (or IS-IS) floods the link
	   available bandwidth information, the available bandwidth
associated
	   with priority lower than Pi (numerical value bigger) should be
	   indicated as _0_. This procedure based on a priority threshold Pi
is
	   implementation specific and value added. It offers networks
	   flexibility to prioritize and control its resources.

	   The calculation of Mp is network dependent, based on the
operator's 
	   own algorithm. For example, the operator may assign a higher Mp
to 
	   L2 if L2 belongs to a customer with _Key_ priority. The operator
may
	   also collect the actual usage of each LSP and assign a high Mp to
L2 
	   if in the past week, L2 has exceeded its reserved bandwidth by 2 
	   times on average, and the customer of L2 agrees to increase its
	   bandwidth for a better guaranteed service. Some operators may try
to
	   increase the bandwidth of L2 on its existing path unsuccessfully
as
	   there isn't enough bandwidth there. Then the operator is willing
to
	   change the path of L2 in order to increase its bandwidth, but
with a
	   lower priority Mp this time as L2 is now routed on its secondary
	   path, which should yield priority to the LSPs that are on its
	   primary paths here.

	The text at
	
http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-00.txt
	was already updated to remove many of the typos.  Here is further
updated text based on your suggested changes:

	  The network operator wants to control the resource on the links of
	   the LSRs, so each LSR keeps the usage status of its links.  Based

	   on the usage history, each link is assigned a current threshold
	   priority Pi, which means that the link has no bandwidth available
	   for a Label Request with a setup priority lower than Pi.  When an

	   LSP's bandwidth needs to be modified, the operator uses a 
	   policy-based algorithm to assign a priority for its modification 
	   request, say Mp for LSP L2. The ingress LSR then sends a Label 
	   Request message with Setup Priority = Mp.  If there is sufficient
	   bandwidth on the link for the modification, and the Setup
priority 
	   in the Label Request Message is higher in priority (Mp
numerically 
	   smaller) than the Pi threshold of the link, the Label Request 
	   Message will be accepted by the LSR.  Otherwise, the Label
Request 
	   message will be rejected with a Notification message which 
	   indicates that there are insufficient resources.  It should also
be 
	   noted that when OSPF (or IS-IS) floods the
available-link-bandwidth 
	   information, the available bandwidth associated with a priority 
	   lower than Pi (numerical value bigger) should be interpreted as
_0_.  

	   This example based on a priority threshold Pi is implementation 
	   specific, and illustrates the flexibility of the modification
	   procedure to prioritize and control network resources.
	   The calculation of Mp can be network and service dependent, and
is
	   based on the operator's routing policy.  For example, the
operator 
	   may assign a higher priority (lower Mp value) to L2 bandwidth
	   modification if L2 belongs to a customer or service with _Key_ 
	   priority.  The operator may also collect the actual usage of each

	   LSP and assign a lower priority (higher Mp) to L2 
	   bandwidth-increase modification if, for example, in the past week
	   L2 has exceeded its reserved bandwidth by 2 times on the average.

	   In addition, an operator may try to increase the bandwidth of L2 
	   on its existing path unsuccessfully if there is insufficient 
	   bandwidth available on L2.  In that case, the operator is willing

	   to increase the bandwidth of another LSP, L3, with the same 
	   ingress/egress LSRs as L2, in order to increase the overall 
	   ingress/egress bandwidth allocation.  However, in this case the
	   L3 bandwidth modification is performed with a lower priority 
	   (higher Mp value) since L3 is routed on a secondary path, which 
	   results in the higher bandwidth allocation priority being given
	   to the LSPs that are on their primary paths [2].

	 Please let us know of any more suggested changes to the above text.

	Section 7.  Should this section include a comment about security
with
	respect to modifications made to LSPs by malign agents?
	OK, how about adding the following sentence in Section 7:

	Protection against LSP modification by malign agents has to be
controlled by the MPLS domain.

	Thanks again,
	Regards,
	Jerry

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 5 Jan 2000 15:32:57 -0000

Jerry,

>Many thanks for your careful reading and helpful comments. 

No problem.

>>using modify to reroute an LSP is fine but perhaps a bit thin.  
>>In particular, the previous description of the behavior for 
>>assigning and releasing labels does not apply itself well to the
>>case where the LSPID only has one entry on parts of the path 
>>where the path has diverged.  I suggest that an additional
>>draft some text if you like.

Fine. I'll try to get to it soon (but not, this week I think).

>Here is further updated text based on your suggested changes:
[SNIP]
>Please let us know of any more suggested changes to 

Looks good to me.

>with respect to modifications made to LSPs by malign agents?

Yes that probably covers it at least as well as the main CR-LDP draft ;-)

Regards,
Adrian