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 <[email protected]> > > 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 <[email protected]>* > > 2011-06-29 下午 02:06 > 收件人 > [email protected] > 抄送 > Lou Berger <[email protected]>, Acee Lindem <[email protected]>, > OSPF WG List <[email protected]>, CCAMP <[email protected]>, > [email protected] > 主题 > 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 <*[email protected]* <[email protected]>> > > 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 *Residual*and *Available*bandwidth > 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 <**[email protected]* <[email protected]>*>* > 发件人: *[email protected]* <[email protected]> > > 2011-06-22 下午 11:16 > > 收件人 > Acee Lindem <*[email protected]* <[email protected]>> > 抄送 > CCAMP <*[email protected]* <[email protected]>>, OSPF WG List > <*[email protected]*<[email protected]> > > > 主题 > 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: *[email protected]* <[email protected]> [mailto:* > [email protected]* <[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]* <[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]* <[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 > * <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*<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]* <[email protected]> > >>>>>>> *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OSPF mailing list > >>>>>> *[email protected]* <[email protected]> > >>>>>> *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf> > >>>>>> > >>>> > >>>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> *[email protected]* <[email protected]> > >>> *https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp> > > > > _______________________________________________ > > OSPF mailing list > > *[email protected]* <[email protected]> > > *https://www.ietf.org/mailman/listinfo/ospf*<https://www.ietf.org/mailman/listinfo/ospf> > > > > > > > > > _______________________________________________ > CCAMP mailing list* > **[email protected]* <[email protected]>* > **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp> > > > > _______________________________________________ > CCAMP mailing list* > **[email protected]* <[email protected]>* > **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp> > > >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
