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 protected] [mailto:[email protected]] 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 <[email protected]> > 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 > <[email protected]> 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 > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/ospf > >>> > > > > > _______________________________________________ > CCAMP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
