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

Alia Atlas <akatlas@gmail.com> Tue, 21 June 2011 18:08 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BB211E8114; Tue, 21 Jun 2011 11:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLjApsiIDum1; Tue, 21 Jun 2011 11:08:21 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7950811E8171; Tue, 21 Jun 2011 11:08:21 -0700 (PDT)
Received: by pzk5 with SMTP id 5so11431pzk.31 for <multiple recipients>; Tue, 21 Jun 2011 11:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gkEg6M/c1t7goJptoN/k7f7yi+LpNpfD+yINgWsroK4=; b=P03ilzPNI8fR0/joQw6h8vLeQiWBzNpCWm1siCMW8c1FB8AuEu5e/UC4aMV4WWUA5K rjz66rZIZrhhagWBpsPqkEl073Y+2nCVAktKr8CHnoZDFnBWD3jvdJUhy2+G3xjjoM5/ LFCD0CBozDuGqkLhKyoWjtWZlSsv4W93ibLb0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L3a2dnWAxycd7aB46njRvXtjpKNhw2N20RwDfJxd9Dx4MofprB2b4QQq6r+yYwa5ME WNRVxh48EuG0h8sg4lddKLk3pDXserak3kGs6P+YbGOlUlmhgDRPoqR3qDsIOMzCj8gn 3fZBrkpnUqrVckfNLCuyJ4lxaImY3WqJRv1c8=
MIME-Version: 1.0
Received: by 10.68.13.73 with SMTP id f9mr3245700pbc.100.1308679700972; Tue, 21 Jun 2011 11:08:20 -0700 (PDT)
Received: by 10.68.46.98 with HTTP; Tue, 21 Jun 2011 11:08:20 -0700 (PDT)
In-Reply-To: <A04F4AB9-8D0B-4EBC-B69E-06ACD6B49697@ericsson.com>
References: <BANLkTimtJPOO+-atPS=YvkngZd2dmX-W6w@mail.gmail.com> <A04F4AB9-8D0B-4EBC-B69E-06ACD6B49697@ericsson.com>
Date: Tue, 21 Jun 2011 14:08:20 -0400
Message-ID: <BANLkTim7C4b3CGkpwSoA6Aro=OX4ZXNZgw@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Acee Lindem <acee.lindem@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 21 Jun 2011 11:13:28 -0700
Cc: Spencer Giacalone <spencer.giacalone@gmail.com>, CCAMP <ccamp@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2011 18:08:22 -0000

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 <acee.lindem@ericsson.com> 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
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>