The MPLS WG Archive

[Arthi Ayyangar <arthi@juniper.net>]

Hello,

Here are a few editorial comments:

1)
Make Before Break - Technique used to non-intrusively alter the path of
an LSP.  The ingress LER First signals, sharing the bandwidth with the
	 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
primary LSP (to avoid double booking), then switches forwarding over to
a new path. Finally the old path state is torn down.

AA> The ingress LER first signals the new path, sharing ....

2)
Soft Preemption Desired Flag - This flag is set on an IPv4 or IPv6 Path
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^
RRO sub-object to indicate to LSRs along the path that, should the LSP
^^^^^^^^^^^^^^
need to be preempted, soft preemption should be used if supported.

AA> This flag is set on the SESSION_ATTRIBUTES Flags in the Path message
for the LSP to indicate ....

3) In section 2 Motivations, noticed a few extra spaces between sentences.

4) Section 5,
Both TE LSPs are signaled with the Soft Preemption bit of their
                                  ^^^^^^^^^^^^^^^^^^^^
SESSION-ATTRIBUTE object set.

AA> Soft preemption desired bit

5) Section 5 again,
In the case that Diff-Serv [DIFF-MPLS] & TE [RSVP-TE]are deployed (as
opposed to Diff-Serv-aware TE [DS-TE]), receiving preemption pending may
imply to a ingress LER that the available bandwidth for the affected
                                                           ^^^^^^^^^^
priority level and greater has been exhausted for the indicated node
^^^^^^^^^^^^^^^^^^^^^^^^^^^
interface.

AA> for the affected priority level and numerically greater priority
levels ?

6) Section 7,
Backward compatibility should be assured as long as the implementation
followed the recommendation set forth in RFC 3209. "The presence of an
unrecognized subobject which is not encountered in a node's ERO
processing SHOULD be ignored.  It is passed forward along with the rest
of the remaining ERO stack."  An LSR without soft preemption
capabilities but that followed the aforementioned recommendation will
simply ignore the RRO Preemption Pending flag and treat the Resv
message as a regular Resv refresh message.

AA> The sentence inside "" above, quoted from 3209 talks about ERO and we
are interested in the RRO processing in this document. So you may want to
probably replace this with the sentence in section 4.4.5 of 3209.

Secondly, since this document does not actually introduce any "new
sub-object", is this even an issue ? It is just defining a new flag in an
existing (as per 3209) sub-object(s). So nodes that do not recognize the
new flag will not process it.

7) For References,
AA> Do you need to classify them as Normative or Informative ?

8) Missing Copyright statement, and use new boilerplate.

9) Does the IPR statement need to be updated ?

thanks,
-arthi


> this initiates a working group last call on
>
> draft-ietf-mpls-soft-preemption-02.txt
>
> Please send comments to the working group mailing list.
>
> The last call ends end of business day July 7th.
>
> /Loa and George
>
> --
>
> Loa Andersson
>
> mobile +46 739 81 21 64
>
>
>