Subject: [OSPF] draft-giacalone-ospf-te-express-path-01

From: Spencer Giacalone <[email-masked]>
Date: Mon, 20 Jun 2011 16:30:20 -0400

Hello everyone,

As you may have noticed, another version of the OSPF TE Express Path
draft has been posted. We made a number of changes based on feedback
from IETF 80. We invite your comments and suggestions. The main
changes include:

-We have consolidated some sub-TLVs for efficiency. There are no
longer nominal and anomalous sub-TLVs for delay and loss. The
functionality for signaling steady state verses abnormal performance
for these parameters have been moved into two sub-TLVs (where we used
to have four).

-In order to advertise both normal and abnormal network performance
state in consolidated sub-TLVs, a bit, called the anomalous (A) but
has been added to certain sub-TLVs. The A bit is set when the measured
value of a parameter exceeds a configured maximum threshold. The A bit
is cleared when the measured value falls below its configured reuse
threshold. If the A bit is clear, the sub-TLV represents steady state
link performance.

-We changed the encodings of certain variables from floating point to
fixed point. This change permits the addition of the A bit (when
necessary), it allows bit-space reservations to be made, and it
permits a common TLV format across the bulk of the TLVs in the draft.
In addition, the new encodings address concerns about granularity and
interoperability.

-We added sub-TLVs for Residual Bandwidth and Available Bandwidth.
Residual bandwidth is defined as the Maximum Bandwidth [RFC3630] minus
the bandwidth currently allocated to RSVP-TE LSPs. Available bandwidth
is defined to be residual bandwidth minus the measured bandwidth used
for the actual forwarding of non-RSVP-TE LSP packets.

-Various other modifications were made across the draft. These
include, but are not limited to, the abstract, the introduction, the
thresholding specifications, and a number of field descriptions.

-Last, but certainly not least, Stefano Providi has joined the draft

We look forward to hearing your comments and concerns.

Thanks,

Spencer, Alia, Dave, John, Stefano

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Jun 2011 12:49:49 -0400

Hi Spencer (CCAMP copied as well),

Here is a link for everyone's convenience: 

http://www.ietf.org/id/draft-giacalone-ospf-te-express-path-01.txt  

At IETF 80, there were questions about overlap with other CCAMP drafts containing interface delay metrics and proposals for new TE sub-TLVs. Have you or your co-authors, done looked at how your draft is positioned versus these other drafts? While these applications have differing goals, the CCAMP/OSPF chairs requested that this analysis be done. 

http://www.ietf.org/id/draft-wang-ccamp-latency-te-metric-03.txt

We would like to avoid having exactly the same information advertised in two different link Sub-TLVs. I'd hope we could agree on common units. 

Thanks,
Acee

On Jun 20, 2011, at 4:30 PM, Spencer Giacalone wrote:

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 21 Jun 2011 14:08:20 -0400

Hi Acee,

John Drake and I did take a look at the draft mentioned in CCAMP.  It
had a large number of requirements and extensions to
a number of different protocols.  There is one sub-TLV (latency) that
appears the same - but the expectations
as to averaging vs. instantaneous were different.

The OSPF TE Express Path work is fairly self-contained and doesn't
specify in exact detail how the information
for the sub-TLVs is measured or obtained.  I think it could be used
for multiple purposes.

Alia

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Jun 2011 21:06:11 -0400

Hi Alia,
I guess I agree with Lou - heretofore, we've done TE requirements in the MPLS/CCAMP WGs and the TE encodings in the IGP WGs. I think we should give the decision explicit consideration before we branch off and do TE for application X independently. Additionally, if we do decide to split this off independently, an E-mail to the list saying there is no overlap is not sufficient to move forward. At a minimum, I believe we need to:

   1. Explicitly document this alternate applicability and relationship to existing TE in the draft.
   2. Determine whether any sub-TLVs can be shared (my opinion was consistent with yours that there are not due to differences in requirements and measurement). 
   3. Assure the sub-TLVs are appropriately named to avoid confusion between the latency applications. 
  
Thanks,
Acee

---

From: Alia Atlas <[email-masked]>
Date: Tue, 21 Jun 2011 21:45:04 -0400

Hi Acee,

I do agree that we should explicitly document this in the draft & work
on better names for the sub-TLVs that might be confused.
I also agree that we need to give the decision explicit consideration;
to give this the exposure necessary and consideration for
applications was why we had this draft discussed in rtgwg as well as ospf.

In addition to the obvious uses for RSVP-TE, another potential
application is the idea of a path-weighted ECMP, where traffic is
split to the different next-hops based upon the total path bandwidths
out those next-hops.  This is a pure IP application (LDP follows
of course) and I'd prefer not to lose track of those options when
considering the RSVP-TE applications.

Alia

---

From: John E Drake <[email-masked]>
Date: Tue, 21 Jun 2011 20:10:46 -0700

Hi,

I am a bit confused.  I thought the proper home for this work would either be the rtg wg or the mpls wg.  I thought it was presented to the OSPF wg for information only.

Thanks,

John 

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alia Atlas
> Sent: Tuesday, June 21, 2011 6:45 PM
> To: Acee Lindem
> Cc: Spencer Giacalone; CCAMP; OSPF WG List
> Subject: Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01
> 
> Hi Acee,
> 
> > I guess I agree with Lou - heretofore, we've done TE requirements in
> the MPLS/CCAMP WGs and the TE encodings in the IGP WGs. I think we
> should give the decision explicit consideration before we branch off
> and do TE for application X independently. Additionally, if we do
> decide to split this off independently, an E-mail to the list saying
> there is no overlap is not sufficient to move forward. At a minimum, I
> believe we need to:
> >
> >   1. Explicitly document this alternate applicability and
> relationship to existing TE in the draft.
> >   2. Determine whether any sub-TLVs can be shared (my opinion was
> consistent with yours that there are not due to differences in
> requirements and measurement).
> >>> At IETF 80, there were questions about overlap with other CCAMP
> drafts containing interface delay metrics and proposals for new TE sub-
> TLVs. Have you or your co-authors, done looked at how your draft is
> positioned versus these other drafts? While these applications have
> differing goals, the CCAMP/OSPF chairs requested that this analysis be
> done.
> >>>
> >>> We would like to avoid having exactly the same information
> advertised in two different link Sub-TLVs. I'd hope we could agree on
> common units.
> >>>
> >>> Thanks,
> >>> Acee
> >>>
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Jun 2011 10:22:57 +0200

Hi John,

Protocol extensions should be standardized by the WG focusing on the
protocol .. be it OSPF, ISIS, BGP you name it. It may very easily
compromise operation of the base protocol if done incorrectly.

Very recently we went via very similar discussions reg route server and 
while it does not even introduce any new changes to BGP protocol on the 
wire .. changes to BGP state were sufficient reason to split the draft 
into operational focus in GROW WG and BGP behaviour change in IDR WG.

Similarly here rtg wg or mpls wg could define in separate documents how 
you are going to use newly flooded information or how you are going to 
collect and populate those information into IGPs.

Rgs,
R.

> Hi,
>
> I am a bit confused.  I thought the proper home for this work would
> either be the rtg wg or the mpls wg.  I thought it was presented to
> the OSPF wg for information only.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas Sent:
>> Tuesday, June 21, 2011 6:45 PM To: Acee Lindem Cc: Spencer
>> Giacalone; CCAMP; OSPF WG List Subject: Re: [CCAMP] [OSPF]
>> draft-giacalone-ospf-te-express-path-01
>>
>> Hi Acee,
>>
>> I do agree that we should explicitly document this in the draft&
>> work on better names for the sub-TLVs that might be confused. I
>> also agree that we need to give the decision explicit
>> consideration; to give this the exposure necessary and
>> consideration for applications was why we had this draft discussed
>> in rtgwg as well as ospf.
>>
>> split to the different next-hops based upon the total path
>> bandwidths out those next-hops.  This is a pure IP application (LDP
>> follows of course) and I'd prefer not to lose track of those
>> options when considering the RSVP-TE applications.
>>
>> Alia

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Jun 2011 08:33:43 -0400

Hi Alia, 

> on better names for the sub-TLVs that might be confused.

Note that it may be the it may be the names in the Y.1540/Y.1541 TE latency draft that need further qualification since their definitions are more strictly scoped. Anyway, lets see how the discussion on where this should be done proceeds. 

> applications was why we had this draft discussed in rtgwg as well as ospf.

Great - I think we are in agreement. I'm not adamantly opposed to doing TE independently for applications falling into this category - I just think we should have the discussion Lou is proposing. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Jun 2011 08:40:01 -0400

Hi John, 
As it stands, the draft contains mainly OSPF TE encodings and considerations. Hence, my inclination would be to keep it in the OSPF WG. However, I'm willing to listen to other proposals. 

Thanks,
Acee

---

From: Spencer Giacalone <[email-masked]>
Date: Wed, 22 Jun 2011 09:17:20 -0400

That was our thought as well. Also, Dave Ward did have some
conversations with Lou.

Spence

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Jun 2011 11:16:25 -0400

OSPF WG for the OSPF extensions seems very reasonable to me ;-)

I still hope that the OSPF portions of
draft-wang-ccamp-latency-te-metric can be combined with
draft-giacalone-ospf-te-express-path given that both drafts state that
they are addressing essentially the same high-level problem.

Lou

---

From: [email-masked]
Date: Tue, 28 Jun 2011 14:32:58 +0800

Hi All,

I read through the draft-giacalone. For the portion of latency, there is 
no any essential difference between both of drafts. 
In the latest version, they added a bit in sub-TLV and gave some 
consideration for the advertisment control. This has aslo been described 
in our draft.
Control plane always combines routing constraints with pre-defined 
priorities, e.g., SRLG diversity, latency, cost, and bandwidth. 
But I don't understand why we need to add Residualand Availablebandwidth 
in draft-giacalone. Why don't you use RFC4203 and RFC3630 to calculate 
them?

We will restructure draft-wang into a framework and some protocol specific 
parts (i.e., OSPF-TE and RSVP-TE) to address the issues raised in the 
framework. 
Based on suggestions from Lou and Acee, we agree that the OSPF protions 
from our draft is combined with draft-giacalone. OSPF extension will be 
developed in draft-giacalone.
The framework document will mainly focus on the requirement of latency 
application and how to use latency information. 
I prefer framework document is done in CCAMP. But it is related to RTGWG 
and MPLS.
Before we define the ability to report latency, it must be clear what we 
are reporting. So different implementations will report the same thing. 
Based on the discussion with Adrian by email, we will give some 
description about what we are gong to report in this framework document.
The rsvp-te document in CCAMP will give some solution for latency TE 
(e.g., accumulation and verification of the delay). 

Xihua Fu

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2011-06-22 下午 11:16

收件人
Acee Lindem <[email-masked]>
抄送
CCAMP <[email-masked]>, OSPF WG List <[email-masked]>
主题
Re: [CCAMP] [OSPF]   draft-giacalone-ospf-te-express-path-01

Lou

On 6/22/2011 8:40 AM, Acee Lindem wrote:
> Hi John, 
> As it stands, the draft contains mainly OSPF TE encodings and 
considerations. Hence, my inclination would be to keep it in the OSPF WG. 
However, I'm willing to listen to other proposals. 
>> I am a bit confused.  I thought the proper home for this work would 
either be the rtg wg or the mpls wg.  I thought it was presented to the 
OSPF wg for information only.
>>> On Tue, Jun 21, 2011 at 9:06 PM, Acee Lindem 
<[email-masked]>
>>> wrote:

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 28 Jun 2011 23:06:46 -0700

Hi Fu,

There are some basic issues in the documents, especially regarding loss and
jitter. I had written a document addressing the same, but never got into
actually posting it.

I have attached the same here. Do let me know what you feel about the same?

Thanks,
Vishwas
2011/6/27 <[email-masked]>

>
> Hi All,
>
> I read through the draft-giacalone. For the portion of latency, there is no
> any essential difference between both of drafts.
> consideration for the advertisment control. This has aslo been described in
> our draft.
> But I don't understand why we need to add *Residual*and *Available*bandwidth
> in draft-giacalone. Why don't you use RFC4203 and RFC3630 to calculate them?
>
> Based on the discussion with Adrian by email, we will give some description
> about what we are gong to report in this framework document.
> The rsvp-te document in CCAMP will give some solution for latency TE (e.g.,
> accumulation and verification of the delay).
>
> Xihua Fu
>
>
>   *Lou Berger <[email-masked]>*
> either be the rtg wg or the mpls wg.  I thought it was presented to the OSPF
> wg for information only.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> Sent from my iPhone
> >>
> >>
> >>> On Tue, Jun 21, 2011 at 9:06 PM, Acee Lindem <[email-masked]
> >
> >>> wrote:
> >>>> Hi Alia,

---

From: [email-masked]
Date: Wed, 29 Jun 2011 14:43:18 +0800

Hi Vishwas,

Thank you for the information. 
I know those drafts cover loss or jitter.  For the latency portions, they 
are same.

Xihua

Vishwas Manral <[email-masked]> 
2011-06-29 下午 02:06

收件人
[email-masked]
抄送
Lou Berger <[email-masked]>, Acee Lindem <[email-masked]>, 
OSPF WG List <[email-masked]>, CCAMP <[email-masked]>, 
[email-masked]
主题
Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01

Hi Fu,
 
There are some basic issues in the documents, especially regarding loss 
and jitter. I had written a document addressing the same, but never got 
into actually posting it.
 
I have attached the same here. Do let me know what you feel about the 
same?
 
Thanks,
Vishwas

Hi All, 

Xihua Fu 

收件人

Lou

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Jun 2011 07:23:22 -0700

Hi Fu,

If you see the document, it is trying to give an overview of what needs to
be done and the architecture of the same. I think that is what you have
stated.

Thanks,
Vishwas
2011/6/28 <[email-masked]>

>   *Vishwas Manral <[email-masked]>*
>
> 2011-06-29 下午 02:06
>    收件人
>  [email-masked]
>  抄送
> 2011/6/27 <[email-masked]* <[email-masked]>>
>
> Hi All,
>
>   *Lou Berger <[email-masked]* <[email-masked]>*>*
> 发件人:  [email-masked]* <[email-masked]>
>
> 2011-06-22 下午 11:16
>
>   收件人
> Acee Lindem <[email-masked]* <[email-masked]>>
> 抄送
> CCAMP <[email-masked]* <[email-masked]>>, OSPF WG List <[email-masked]*<[email-masked]>
> >
> 主题
> >>> From: [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] On Behalf
> >>> Of Alia Atlas
> >>> On Tue, Jun 21, 2011 at 9:06 PM, Acee Lindem <*
> [email-masked]* <[email-masked]>>
> >>> wrote:
> >>>> Hi Alia,
> >>>>> On Tue, Jun 21, 2011 at 12:49 PM, Acee Lindem
> >>> <[email-masked]* <[email-masked]>> wrote:
> >>>>>> *http://www.ietf.org/id/draft-giacalone-ospf-te-express-path-01.txt
> * <http://www.ietf.org/id/draft-giacalone-ospf-te-express-path-01.txt>
> >>>>>>
> >>>>>> *http://www.ietf.org/id/draft-wang-ccamp-latency-te-metric-03.txt*<http://www.ietf.org/id/draft-wang-ccamp-latency-te-metric-03.txt>
> >>>>>>
> >>>>>>> [email-masked]* <[email-masked]>
> >>>>>>> *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf>
> >>>>>>
> >>>>>> [email-masked]* <[email-masked]>
> >>>>>> *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf>
> >>>>>>
> >>>>
> >>>>
> >>> [email-masked]* <[email-masked]>
> >>> *https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp>
> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf>
> >
> >
> >
> >
> CCAMP mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp>
>
>
>
> CCAMP mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp>
>
>
>

---

From: [email-masked]
Date: Thu, 30 Jun 2011 09:44:22 +0800

Hi Vishwas, 

Thank you for your clarification.
What you and we are going to do is very reasonable. 
The latency and loss TE application are related to packet (e.g., MPLS) and 
tdm (e.g., OTN). 
In my opinion, tdm TE application is always standardized in ccamp. That's 
why we posted our document to CCAMP in 79th and 80th.
I have a question to chairs and the authors. Because there are more and 
more documents appearing, we should think about how to move forward these 
work. 
What's your opinion? 

Xihua

2011-06-29 下午 10:23

收件人
[email-masked]
抄送
Acee Lindem <[email-masked]>, CCAMP <[email-masked]>, 
[email-masked], Lou Berger <[email-masked]>, OSPF WG List 
<[email-masked]>
主题
Re: Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01

Hi Fu,

Thanks,
Vishwas

Hi Vishwas, 

Xihua 

收件人
[email-masked] 
抄送

Hi Fu, 

 
Thanks, 
Vishwas 

Hi All, 

Xihua Fu 

收件人

Lou

>>> <[email-masked]> wrote:

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jun 2011 08:19:04 -0400

Xihua,
	For at least now, the OSPF work should be done in the OSPF WG.  The
chairs of the various candidate WG are having some off-line discussions
on were the requirements/RSVP work belongs.  We should have an answer
for you by early next week.

Lou

PS Please don't cc [email-masked] on mail you send, it makes the
mail system think your mail is a bounce!

On 6/29/2011 9:44 PM, [email-masked] wrote:
> more documents appearing, we should think about how to move forward
> these work.
> What's your opinion?

---

From: [email-masked]
Date: Thu, 30 Jun 2011 20:28:21 +0800

Hi Lou

Thank you for your response.
That is always a good news for guys who are standing on a cross road. 
We respect the decision made by chairs and move forward these work 
together.

Xihua

2011-06-30 下午 08:19

收件人
[email-masked]
抄送
Vishwas Manral <[email-masked]>, Acee Lindem 
<[email-masked]>, CCAMP <[email-masked]>, OSPF WG List 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01

Xihua,
                 For at least now, the OSPF work should be done in the 
OSPF WG.  The
chairs of the various candidate WG are having some off-line discussions
on were the requirements/RSVP work belongs.  We should have an answer
for you by early next week.

Lou