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

[John E Drake <[e-mail]>]

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