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

[Vishwas Manral <[e-mail]>]

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 <[e-mail]>

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