Re: [mpls] AD review of Soft Preemtion work

[JP Vasseur <[e-mail]>]

Hi Adrian,

Both documents have been posted with all editorial comments addressed.  
I attached the Diffs for convenience.

> On Jul 26, 2009, at 1:32 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> I've been reading draft-ietf-mpls-3209-patherr-04.txt,
>>
>> prior to kicking off IETF last call.
>>
>> I don't have many questions...
>>
>> The Abstract and Introduction to draft-ietf-mpls-3209- 
>> patherr-04.txt explicitly call out MPLS when discussing RSVP-TE  
>> PathErr messages. But they do not mention GMPLS. In fact, the only  
>> reference to RFC3473 is in section 2.2. I think that the text needs  
>> to be clear on whether or not it is intended to apply to GMPLS  
>> signaling. This obviously affects how the document is read and  
>> applied, and should not be left for people to assume (one way or  
>> the other).
>>
>
> Main intention was MPLS for Soft Preemption. That said (as discussed  
> with Lou) this does apply to GMPLS, which is also fine with me.  
> Sentence added.
>
>> draft-ietf-mpls-3209-patherr-04.txt uses some BNF (copied from RFC  
>> 2205). New "rules" require that any document that uses a formal  
>> language includes a reference to the definition of the formal  
>> language. Your choice here is:
>> - leave out the text copy from 2205
>> - insert a reference to RFC 5511
>
> We left out the text copy from 2205.
>
>>
>> draft-ietf-mpls-3209-patherr-04.txt Page 4
>>  Additionally, PathErr messages may be used in two circumstances:
>> Strike "Additionally,"
>
> Fixed.
>
> Diffs attached.
>
>>
>> The RFC Editor will require the first section of draft-ietf-mpls- 
>> soft-preemption-17.txt to be the Introduction. I think you can  
>> simply re-order the sections you already have, and expand the  
>> acronyms in the Introduction section.
>
> Fixed.
>
>>
>> I am trying to not re-open my mailing list discussions of draft- 
>> ietf-mpls-soft-preemption-17.txt from the last couple of years. :-)  
>> In section 6.1 you have
>>  For each preempted TE LSP, instead of sending an RSVP Path Tear
>>  message after the receipt of an RSVP PathErr message notifying a
>>  fatal action as documented in [I-D.ietf-mpls-3209-patherr] upon
>>  preemption as with hard preemption (which would result in an
>>  immediate traffic disruption for the preempted TE LSP), the
>>  preempting node's local bandwidth accounting for the preempted TE  
>> LSP
>>  is zeroed and a PathErr with error code "Reroute" and a error value
>>  "Reroute request soft preemption" for that TE LSP is issued upstream
>>  toward the head-end LSR.
>> I can't parse this single-sentence paragraph. Can you look at how  
>> to break it up?
>
> Indeed!
>
>> I think the node being described is the preempting node. But the  
>> preempting node does not receive a PathErr so the first part of the  
>> sentence confuses me.
>>
>
> Done.
>
>> draft-ietf-mpls-soft-preemption-17.txt section 6.1
>>  Should a refresh event for a soft preempted TE LSP arrive before the
>>  soft preemption timer expires, the soft preempting node MUST  
>> continue
>>  to refresh the TE LSP.
>> This is the first mention of a soft preemption timer. I think you  
>> need to swap the text around so the definition of the timer (2  
>> paras later) is introduced first.
>>
>
> Ah yes.
>
>> draft-ietf-mpls-soft-preemption-17.txt Section 13.2
>> [I-D.ietf-mpls-3209-patherr] should be a Normative reference
>>
>>
>
> yes.
>
>> I have marked the documents as:
>> draft-ietf-mpls-soft-preemption  "AD Evaluation : Revised I-D Needed"
>> draft-ietf-mpls-3209-patherr  "AD Evaluation : Revised I-D Needed"
>> draft-ietf-mpls-gmpls-lsp-reroute  "AD Evaluation : External Party"
>>
>> I'm willing to discuss:
>> a. whether these changes are needed
>> b. whether the changes need a respin or an RFC Editor note
>>
>
>
>
> Many Thanks.
>
> JP.
>
>
>
>
>> Cheers,
>> Adrian
>>
>>
>>
>