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

From: [email-masked]
Date: Sun, 07 Oct 2012 11:23:54 -0700

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/

---

From: Lou Berger <[email-masked]>
Date: Mon, 08 Oct 2012 12:26:41 -0400

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, [email-masked] wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: Elisa Bellagamba <[email-masked]>
Date: Thu, 11 Oct 2012 15:46:09 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: den 8 oktober 2012 18:27
To: [email-masked]
Cc: [email-masked]
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

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Oct 2012 15:00:30 -0400

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

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

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

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

- 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]."

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

---

From: Pontus Sköldström <[email-masked]>
Date: Wed, 17 Oct 2012 13:18:20 +0200

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
+46 8 632 7731
[email-masked]

Acreo AB – Part of Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
________________________________________
From: Lou Berger [[email-masked]]
Sent: Thursday, October 11, 2012 21:00
To: Elisa Bellagamba
Cc: [email-masked]; [email-masked]; Pontus Sköldström
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.txt

WG,

Elisa,

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Oct 2012 14:22:09 -0400

Pontus,

Please see below.

> Netlab - Networking and Transmission Laboratory

Have all the nits been fixed?

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

okay.

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

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

> just say "MUST carry the same value used in the Refresh Timer field

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

---

From: Pontus Sköldström <[email-masked]>
Date: Thu, 18 Oct 2012 13:54:54 +0200

Hi Lou, 

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

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

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

> 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

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

Pontus,

Please see below.

okay.

 Your text now reads:

Your text now reads:

Okay.

Your text now reads:

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Oct 2012 09:22:59 -0400

Pontus,

Just noticed, the draft says:
   3.4.2.  MPLS OAM PM Delay sub-TLV

   The "MPLS OAM PM Delay sub-TLV" depicted below is carried as a sub-
   TLV of the "OAM Functions TLV".

Shouldn't it read:
   TLV of the "Performance Monitoring sub-TLV"

and (in same section)
   define, suggested value 1).
should be
   define, suggested value 2).

Please also see below.

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

okay

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

Fair enough.

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

Perhaps the way to address is to make a general statement on this
earlier in the section and removed both statements of:

Perhaps something at the start of 3.4 that says something like:

The Performance Monitoring sub-TLV provides the configuration
information mentioned in Section 7 of [RFC6374]. It includes support for
the configuration of quality thresholds and, as described in [RFC6374],
"the crossing of which will trigger warnings or alarms, and result
reporting and exception notification will be integrated into the
system-wide network management and reporting framework."

Lou

---

From: Pontus Sköldström <[email-masked]>
Date: Thu, 18 Oct 2012 20:10:29 +0200

See inline, 

Cheers, 
Pontus 
--- snip --- 
>    define, suggested value 2).

[Pontus] 
You're absolutely correct, fixed. 

--- snip --- 
> system-wide network management and reporting framework."

[Pontus] 
Sure, that makes sense, fixed.

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Oct 2012 17:29:35 -0400

Pontus,
	Thank you for addressing my comments!

Lou