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

[[e-mail]]

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




Vishwas Manral <[e-mail]> 
2011-06-29 下午 10:23

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






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 <[e-mail]>

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 <[e-mail]> 
2011-06-29 下午 02:06 


收件人
[e-mail] 
抄送
Lou Berger <[e-mail]>, Acee Lindem <[e-mail]>, 
OSPF WG List <[e-mail]>, CCAMP <[e-mail]>, 
[e-mail] 
主题
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 
2011/6/27 <[e-mail]> 

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 <[e-mail]> 
发件人:  [e-mail] 
2011-06-22 下午 11:16 


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











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

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. 
> 
> Thanks,
> Acee
> On Jun 21, 2011, at 11:10 PM, John E Drake wrote:
> 
>> 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: [e-mail] [mailto:[e-mail]] 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.
>>>
>>> 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
>>>
>>> On Tue, Jun 21, 2011 at 9:06 PM, Acee Lindem <[e-mail]
>
>>> wrote:
>>>> 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
>>>> On Jun 21, 2011, at 2:08 PM, Alia Atlas wrote:
>>>>
>>>>> 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
>>>>>
>>>>> On Tue, Jun 21, 2011 at 12:49 PM, Acee Lindem
>>> <[e-mail]> wrote:
>>>>>> 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:
>>>>>>
>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> OSPF mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>
>>>>>> _______________________________________________
>>>>>> OSPF mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp



_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp