Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 19 Sep 2014 17:49:10 +0000

After more than 3 years of discussion and revision, the chairs feel that we are ready for a WG last call on the OSPF TE Metric extensions. While it is only one piece of an end-to-end delay/loss aware routing solution, we believe that the draft, as scoped, is ready. The WG last call will end at 12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL:

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

Thanks,
Acee and Abhay

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 19 Sep 2014 21:39:14 +0200

Some Comments
- I personally don't like the word Anomalous Bit, I prefer something like Exceeded Bit
- why are some Sub TLVs are stated as do not send when not measured and others are set to all 
1's when not measured? Section 8 requires that every sub-TLV can be enabled and disabled 
individually.

Section 4.2
In my opinion the A bit should exist for the Min Delay and Max Delay Value and not only combined 
for both values, if not splitted to two Sub-TLV as there can be cases where a min delay must be 
met and others where there a max delay which should not be exeeded.

Section 4.7
"The bandwidth utilization advertised by this sub-TLV MUST be the bandwidth from the system 
originating this Sub-TLV."

I would like to change it to something like:
The bandwidth advertised by this sub-TLV MUST be the bandwidth utilization from the system 
originating this Sub-TLV.

Section 6
   Only the accelerated advertisement threshold mechanism described in
   section 6 may shorten the re-advertisement interval.

the mechanism is described in Section 5

Regards
Karsten

Am Freitag, 19. September 2014, 17:49:10 schrieb Acee Lindem:

After more than 3 years of discussion and revision, the chairs feel that we are ready for a WG last 
call on the OSPF TE Metric extensions. While it is only one piece of an end-to-end delay/loss 
aware routing solution, we believe that the draft, as scoped, is ready. The WG last call will end at 
12:00 AM PDT on Oct 4th, 2014. For your convenience, here is a URL: 

https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions[1]/

Thanks,
Acee and Abhay 

--------
[1] https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Sep 2014 21:11:18 +0000

Support

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Friday, September 19, 2014 10:49 AM
To: OSPF WG List; [email-masked]
Subject: Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

Thanks,
Acee and Abhay

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Sep 2014 09:59:44 +0000

Hi All,

Fully support moving this work along. 

I have following comments/suggestions, which can handled along with other last call comments.  

(1) Sec 1: Introduction

   This document describes extensions to OSPF TE (hereafter called "OSPF
   TE Metric Extensions"), that can be used to distribute network
   performance information (such as link delay, delay variation, packet
   loss, residual bandwidth, and available bandwidth).

Utilized Bandwidth can also be added in the above list. 

(2) A reference to PCE should also be added along with the mention of ALTO server. See http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/
In fact the steps mentioned for the ingress in section 3 are applicable for a stateful PCE as well. 

(3)Is there a particular reason to reference RFC6375, which is MPLS-TP document below? Or the intention was to use 6374?
   
   The methods for initially gathering that
   performance information, such as [RFC6375], or acting on it once it
   is distributed are outside the scope of this document.  Example
   mechanisms to measure latency, delay variation, and loss in an MPLS
   network are given in [RFC6374].

(4) Suggested change to add delay variation and to update packet-loss to just say percentage (the unit).  
OLD:
   Delay values MUST be quantified in units of microseconds,
   packet loss MUST be quantified as a percentage of packets sent, and
   bandwidth MUST be sent as bytes per second.
NEW:
   Delay and delay variation values MUST be quantified in units of microseconds,
   packet loss MUST be quantified as a percentage, and
   bandwidth MUST be sent as bytes per second.

(5) Sec 4.2.7. Reserved

   This field is reserved for future use. It MUST be set to 0 when sent
   and MUST be ignored when received.

   When only an average delay value is sent, this field is not present
   in the TLV.

I think you meant to say that the Min/Max Unidirectional Link Delay Sub-TLV is not present instead of reserved field. 

(6) Sec 4.3. Unidirectional Delay Variation Sub-TLV
   
   The delay variation advertised by
   this sub-TLV MUST be the delay from the local neighbor to the remote
   one (i.e. the forward path latency).

We should say 'forward path latency-variation' in this case. 

(7) Sec 11. Security Considerations
Since the network performance metric might be considered extra sensitive in some deployments it should be strongly suggested that this information must be protected from tampering using existing mechanism. 

(8) Sec 12. IANA Considerations
This section needs updating with the list of the TLVs

(9) A reference to RFC5392 for Inter-AS-TE-v2 LSA should be added to avoid any confusion to the reader.. 

Nits
- Remove reference from abstract for [RFC3630]
- Update [Alto] reference to [RFC7285]
- Expand CSPF, RSVP-TE, LSA on first use
- Min/Max delay and Low/High delay are used interchangeably, suggest to use only one 

Regards,
Dhruv
 
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: 20 September 2014 01:49
To: OSPF WG List; [email-masked]
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

Thanks,
Acee and Abhay

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Sep 2014 22:45:25 +0000

This subject draft in WG last call has this IPR statement:

https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-ospf-te-metric-extensions

Authors – please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

From: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 19, 2014 at 1:49 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

Thanks,
Acee and Abhay

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 25 Sep 2014 01:07:00 +0000

Thanks Spencer – copying WG

From: Spencer Giacalone <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 24, 2014 at 7:12 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

I am not

On Wed, Sep 24, 2014 at 11:45 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
This subject draft in WG last call has this IPR statement:

Thanks,
Acee

Thanks,
Acee and Abhay

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: John E Drake <[email-masked]>
Date: Thu, 25 Sep 2014 13:59:22 +0000

I am not aware of any IPR.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 3:45 PM
To: OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); John E Drake; Alia Atlas; Spencer Giacalone
Subject: Re: [OSPF] Working Group Last Call for OSPF Traffic Engineering (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)

Authors - please indicate whether or not you are aware of any other IPR.

Thanks,
Acee

Thanks,
Acee and Abhay

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Sep 2014 10:17:07 -0400

I am also not aware of any other IPR.

Alia
On Sep 25, 2014 9:59 AM, "John E Drake" <[email-masked]> wrote:

> *From:* Acee Lindem (acee) [mailto:[email-masked]]
> *Sent:* Wednesday, September 24, 2014 3:45 PM
> *To:* OSPF WG List; David Ward (wardd); Stefano Previdi (sprevidi); John
> E Drake; Alia Atlas; Spencer Giacalone
> *Subject:* Re: [OSPF] Working Group Last Call for OSPF Traffic
> Engineering (TE) Metric Extensions
> (draft-ietf-ospf-te-metric-extensions-06.txt)
>
>
>
> *From: *Acee Lindem <[email-masked]>
> *Date: *Friday, September 19, 2014 at 1:49 PM
> *To: *OSPF WG List <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> *Subject: *[OSPF] Working Group Last Call for OSPF Traffic Engineering
> (TE) Metric Extensions (draft-ietf-ospf-te-metric-extensions-06.txt)
>
>
>
>
>
> After more than 3 years of discussion and revision, the chairs feel that
> we are ready for a WG last call on the OSPF TE Metric extensions. While it
> is only one piece of an end-to-end delay/loss aware routing solution, we
> believe that the draft, as scoped, is ready. The WG last call will end at
> [email-masked]

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 26 Sep 2014 06:35:24 +0000

I'm not aware of any IPR.

s.

On Sep 25, 2014, at 4:17 PM, Alia Atlas wrote:

> From: Acee Lindem <[email-masked]>
> To: OSPF WG List <[email-masked]>, "[email-masked]" <[email-masked]>