Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt

[Pontus Sköldström <[e-mail]>]

Hi Lou, 

Thanks for the quick reply! 
I'll copy comments in here (outlook is terrible with inline comments.. ) 

>         Thank you for the update.  Some comments.
> - Please review IDNITs and ensure that the document is clean, see
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10.txt

I've cleaned the nits out of my local copy, in the diffcheck URL I posted I'd only dealt with the other comments.

>> - Threshold definition, lines 687/8:   I really don't think these
>> definitions are adequate to ensure consistent implementation. How about:
>>  Loss Threshold: indicates the MaxLMIntervalLoss threshold (measured in
>>  packets) as defined in [RFC6374].
>>
> Your text now reads:
>   Loss Threshold: the threshold value of measured lost packets per
>   measurement over which action(s) SHOULD be triggered.  Configuration
>    of triggered action(s) is out of scope for this document but may
>    include signaling an NMS, triggering protection switching, etc.
>
>I'm sorry, I just can't parse this.  Also, why not refer back to [RFC6374]?

The Loss Threshold that we define is unrelated to MaxLMIntervalLoss (the upper bound of lost packets per measurement interval).
We do not wish to configure that value, what we'd like to do is, exactly like with the Delay Threshold, configure an upper limit that if exceeded triggers some kind of response. 
So we might for example want to tell an NMS that something strange is going on because packet loss is exceeding normal levels. 
Or perhaps we'd like to immediately trigger protection switching, or write the current time into a log file for later analysis, something like that. 
We'd rather not specify exactly what happens when the threshold is exceeded but leave that open (could be that nothing happens).
And since we're not talking about any particular thing in RFC6374 there's no reference to it.  

>Your text now reads:
>   Refresh Timer: indicates the refresh timer of fault indication
>   messages, in seconds.  The value MUST be between 1 to 20 seconds as
>   specified for the Refresh Timer field in [RFC6427].  If the edge LSR
>   receiving the Path message can not support the value it can reply
>   with a higher timer value.

> does "can" mean "MAY" or "SHOULD"?

Ah, it SHOULD be SHOULD, I MAY have made a mistake here :-) 



Cheers,

Pontus Sköldström, M.Sc.
Research Scientist
Netlab - Networking and Transmission Laboratory
[phone]
[e-mail]

Acreo AB – Part of Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
________________________________________
From: Lou Berger [[e-mail]]
Sent: Wednesday, October 17, 2012 20:22
To: Pontus Sköldström
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt

Pontus,

Please see below.


On 10/17/2012 7:18 AM, Pontus Sköldström wrote:
> Hi all,
>
> Based on the comments from Lou we've made some minor updates to the text, changes are shown in red/green at this link:
> http://diffchecker.com/7g8cJ8zI
>
> If there are any objections to these updates please let us know ASAP, if there's no comments we'll upload the suggested changes later this week.
>
> Best regards,
>
> Pontus Sköldström, M.Sc.
> Research Scientist
> Netlab - Networking and Transmission Laboratory
> [phone]
> [e-mail]
>
> Acreo AB – Part of Swedish ICT
> Electrum 236, 164 40 Kista, Sweden
> www.acreo.se
> ________________________________________
> From: Lou Berger [[e-mail]]
> Sent: Thursday, October 11, 2012 21:00
> To: Elisa Bellagamba
> Cc: [e-mail]; [e-mail]; Pontus Sköldström
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt
>
> WG,
>         Please review and comment on changes.  See
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10.txt
>
> Recall that this document is post WG LC.
>
> Elisa,
>         Thank you for the update.  Some comments.
> - Please review IDNITs and ensure that the document is clean, see
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10.txt
>

Have all the nits been fixed?

> - Missing metrics:  line 684 (using lines numbers from nits URL),

okay.


>
> - Threshold definition, lines 687/8:   I really don't think these
> definitions are adequate to ensure consistent implementation. How about:

>  Loss Threshold: indicates the MaxLMIntervalLoss threshold (measured in
>  packets) as defined in [RFC6374].
>
 Your text now reads:
    Loss Threshold: the threshold value of measured lost packets per
    measurement over which action(s) SHOULD be triggered.  Configuration
    of triggered action(s) is out of scope for this document but may
    include signaling an NMS, triggering protection switching, etc.

I'm sorry, I just can't parse this.  Also, why not refer back to [RFC6374]?

> - Line 742-4, Delay Threshold: is this one way or two way delay?  I
> don't see how you can specify a default.
>

Your text now reads:
    Delay Threshold: the threshold value of measured two-way delay (in
    milliseconds) over which action(s) SHOULD be triggered.
    Configuration of triggered action(s) is out of scope for this
    document but may include signaling an NMS, triggering protection
    switching, etc.

Okay.

> - line 784, Refresh Timer.  This should have a reference and perhaps
> just say "MUST carry the same value used in the Refresh Timer field
> defined in [rfc6427]."

Your text now reads:
   Refresh Timer: indicates the refresh timer of fault indication
   messages, in seconds.  The value MUST be between 1 to 20 seconds as
   specified for the Refresh Timer field in [RFC6427].  If the edge LSR
   receiving the Path message can not support the value it can reply
   with a higher timer value.

does "can" mean "MAY" or "SHOULD"?

Lou

>
> You might want to discuss your proposed changes on the list and get
> agreement before rev'ing the document again.  Of course, rev numbers are
> cheap too...
>
> Lou
>
> On 10/11/2012 11:46 AM, Elisa Bellagamba wrote:
>>
>> Hi Lou,
>>
>> we have just uploaded version 10 which is inserting back the refresh timer field in accordance with RFC 6427 and fixing the TBD values to the ones recommended in RFC 6375.
>>
>> Thanks,
>> Elisa
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
>> Sent: den 8 oktober 2012 18:27
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt
>>
>> Authors,
>>       I see you still have some default values called out as TBD.
>> Can you please send your proposed defaults to the WG so that we can ensure consensus on these? (Obviously, these need to be filled in before any publication request.)
>>
>> Also, I see you removed the units from the Refresh Timer field.  Was this intentional?  I think some unit of measure is needed.
>>
>> Thanks,
>> Lou
>>
>> On 10/7/2012 2:23 PM, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>  This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>>>
>>>      Title           : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE
>>>      Author(s)       : Elisa Bellagamba
>>>                           Loa Andersson
>>>                           Pontus Skoldstrom
>>>                           Dave Ward
>>>                           Attila Takacs
>>>      Filename        : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt
>>>      Pages           : 22
>>>      Date            : 2012-10-07
>>>
>>> Abstract:
>>>    This specification describes the configuration of pro-active MPLS-TP
>>>    Operations, Administration, and Maintenance (OAM) Functions for a
>>>    given LSP using a set of TLVs that are carried by the RSVP-TE
>>>    protocol.
>>>
>>>    This document is a product of a joint Internet Engineering Task Force
>>>    (IETF) / International Telecommunication Union Telecommunication
>>>    Standardization Sector (ITU-T) effort to include an MPLS Transport
>>>    Profile within the IETF MPLS and PWE3 architectures to support the
>>>    capabilities and functionalities of a packet transport network.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-
>>> ext
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-mpls-tp-oam-
>>> ext-09
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
>
>
>