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

[Alia Atlas <[e-mail]>]

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