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

[Spencer Giacalone <[e-mail]>]

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

Spence




On Wed, Jun 22, 2011 at 8:40 AM, Acee Lindem <[e-mail]> 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
>
>