Subject: [mpls] AD review of Soft Preemtion work

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 26 Jul 2009 12:32:34 +0100

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).

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

draft-ietf-mpls-3209-patherr-04.txt Page 4
   Additionally, PathErr messages may be used in two circumstances:
Strike "Additionally,"

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.

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? 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.

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.

draft-ietf-mpls-soft-preemption-17.txt Section 13.2
[I-D.ietf-mpls-3209-patherr] should be a Normative reference

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

Cheers,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Sun, 26 Jul 2009 22:12:14 +0200

Hi Adrian,

I basically agree with all your comments ...
Few comments/replies:
With regards to the path-error ID, it is IMO MPLS focussed, Lou/ 
Deborah may want to chime in.
I definitely agree to insert of reference to 5511. For the other  
changes, I tend to think that they could be addressed with an editor  
note but your call of course.

Thanks.

JP.

On Jul 26, 2009, at 1:32 PM, Adrian Farrel wrote:

> 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).
>
> 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:
> 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.
>
> 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
> I can't parse this single-sentence paragraph. Can you look at how to  
> break it up? 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.
>
> 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.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Jul 2009 09:19:19 +0100

OK JP,

Complete the discussions with the other authors, then prepare the text as 
RFC Editor instructions. If they look OK I will just post them. If they look 
too large, you can use them to make the changes yourselves.

Thanks,
Adrian
----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Lou Berger" <[email-masked]>; 
"Deborah Beebe (dbeebe)" <[email-masked]>
Cc: <[email-masked]>; 
<[email-masked]>; 
<[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, July 26, 2009 9:12 PM
Subject: Re: AD review of Soft Preemtion work

> With regards to the path-error ID, it is IMO MPLS focussed, Lou/ Deborah 
> may want to chime in.
> I definitely agree to insert of reference to 5511. For the other  changes, 
> I tend to think that they could be addressed with an editor  note but your 
> call of course.
>
> Thanks.
>
> JP.
>
>> 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).
>>
>> 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:
>> 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.
>>
>> break it up? 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.
>>
>> 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.
>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 27 Jul 2009 10:30:16 +0200

Great plan, many thanks. Will be done before end of this week.

Thanks.

JP.

On Jul 27, 2009, at 10:19 AM, Adrian Farrel wrote:

> OK JP,
>
> Complete the discussions with the other authors, then prepare the  
> text as RFC Editor instructions. If they look OK I will just post  
> them. If they look too large, you can use them to make the changes  
> yourselves.
>
> Thanks,
> Adrian
> ----- Original Message ----- From: "JP Vasseur" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; "Lou Berger" <[email-masked] 
> >; "Deborah Beebe (dbeebe)" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked] 
> >; <[email-masked]>; <[email-masked] 
> >; <[email-masked]>; <[email-masked]>
>> changes, I tend to think that they could be addressed with an  
>> editor  note but your call of course.
>>
>> Thanks.
>>
>> JP.
>>
>>> 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).
>>>
>>> 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
>>> I can't parse this single-sentence paragraph. Can you look at how  
>>> to break it up? 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.
>>>
>>> need to swap the text around so the definition of the timer (2  
>>> paras  later) is introduced first.
>>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 27 Jul 2009 15:36:21 +0200

Hi Lou,

On Jul 27, 2009, at 2:23 PM, Lou Berger wrote:

> JP,
>
> Why do you say MPLS only?
>

It does but a fatal error in the packet case is quite different than  
in the non packet case. That said, the signaling of a fatal error is  
unchanged.

> It seems to me that this draft could be applied to gmpls as wellll  
> The definition of "fatal error" may be different for gmpls and mpls,

Exactly.

> but as this term isn't defined anywhere there is no issue.
>

Fine with me for sure. Adrian ?

Thanks.

JP.

> Lou
> -----Original Message-----
> From:  JP Vasseur <[email-masked]>
>
> Date: Sun, 26 Jul 2009 22:12:14
> To: Adrian Farrel<[email-masked]>; Lou  
> Berger<[email-masked]>; Deborah Beebe (dbeebe)<[email-masked]>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 29 Jul 2009 10:39:37 +0200

Hi Adrian,

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

>> 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.
>
> We left out the text copy from 2205.
>
>>
> Fixed.
> Diffs attached.
> Fixed.
>> ietf-mpls-soft-preemption-17.txt from the last couple of years. :-)  
>> In section 6.1 you have
>> 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.
>
> Ah yes.
> yes.
> Many Thanks.