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

Acee Lindem <acee.lindem@ericsson.com> Wed, 22 June 2011 12:40 UTC

Return-Path: <acee.lindem@ericsson.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 20B2111E810F; Wed, 22 Jun 2011 05:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bF4VPF-ybp71; Wed, 22 Jun 2011 05:40:09 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9EACC11E80D4; Wed, 22 Jun 2011 05:40:09 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5MCe2HC015958; Wed, 22 Jun 2011 07:40:07 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 22 Jun 2011 08:40:06 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: John E Drake <jdrake@juniper.net>
Date: Wed, 22 Jun 2011 08:40:01 -0400
Thread-Topic: [CCAMP] [OSPF] draft-giacalone-ospf-te-express-path-01
Thread-Index: Acww2YNKmJJM/9C4QQ2SV+eP06Aqdg==
Message-ID: <6268B75A-0841-4F97-BC85-589CECF97FD3@ericsson.com>
References: <BANLkTimtJPOO+-atPS=YvkngZd2dmX-W6w@mail.gmail.com> <A04F4AB9-8D0B-4EBC-B69E-06ACD6B49697@ericsson.com> <BANLkTim7C4b3CGkpwSoA6Aro=OX4ZXNZgw@mail.gmail.com> <9AA9A2E7-ECDC-4FF0-A1B0-00808617D764@ericsson.com> <BANLkTinCKqk+LM+J6=1quLYuHuYHLx6Daw@mail.gmail.com> <5E893DB832F57341992548CDBB333163A0A803F422@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A0A803F422@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Spencer Giacalone <spencer.giacalone@gmail.com>, CCAMP <ccamp@ietf.org>, OSPF WG List <ospf@ietf.org>, Alia Atlas <akatlas@gmail.com>
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: Wed, 22 Jun 2011 12:40:11 -0000

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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 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 <acee.lindem@ericsson.com>
>> 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
>> <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
>>>>> 
>>> 
>>> 
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp