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

[Acee Lindem <[e-mail]>]

Hi Alia, 

On Jun 21, 2011, at 9:45 PM, Alia Atlas wrote:

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

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. 


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

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 



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