From: Acee Lindem <acee.lindem@ericsson.com>
To: "<spencer.giacalone@thomsonreuters.com> "
 <spencer.giacalone@thomsonreuters.com>
Thread-Topic: ISIS TE Metric Extension Discussion (IETF-85 Followup)
Thread-Index: AQHODmxXCA5/6zyM6kyuQL6T6MtVQJiBJNBwgABrygA=
Date: Tue, 19 Feb 2013 14:24:25 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470DFB49@eusaamb101.ericsson.se>
References: <CDFBD39D51B6734A9402D4B52ABDF059ECDBEF@C111TZDHMBX75.ERF.thomson.com>
In-Reply-To: <CDFBD39D51B6734A9402D4B52ABDF059ECDBEF@C111TZDHMBX75.ERF.thomson.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A4F841E996E8734E82C4C425A7715994@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: George Swallow <swallow@cisco.com>,
 "equinox-ietf@diac24.net" <equinox-ietf@diac24.net>,
 "isis-wg@ietf.org" <isis-wg@ietf.org>, Clarence Filsfils <cfilsfil@cisco.com>,
 "nabil.n.bitar@verizon.com" <nabil.n.bitar@verizon.com>,
 "kireeti.kompella@gmail.com" <kireeti.kompella@gmail.com>,
 Robert Raszuk <raszuk@cisco.com>,
 Samita Chakrabarti <samita.chakrabarti@ericsson.com>,
 Alia Atlas <akatlas@juniper.net>, "dward@bgp.nu" <dward@bgp.nu>,
 OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] ISIS TE Metric Extension Discussion (IETF-85 Followup)
Precedence: list

Hi Spence,=20
Note that the bar for WG last call and request for publication as a standar=
ds track RFC is quite a bit higher than for WG adoption (OSPF WG copied). W=
e need to have this discussion now and either address the questions surroun=
ding the delay metrics or agree that they are out of scope.=20
Having said that, speaking as a WG member of both WGs, I have re-read the d=
raft and don't have problems with the guidance given for delay metrics when=
 these metrics are used for TE.=20
Thanks,
Acee=20

On Feb 19, 2013, at 7:58 AM, <spencer.giacalone@thomsonreuters.com>
 wrote:

> Pls note that the ospf wg has already adopted express path as ospf metric=
 extensions.
>=20
> We really need to stop talking about the fuxh drafts. A) we (john, dave, =
alia, myself) are not primary authors, and b) those drafts are "application=
" drafts. Pls read my slide deck for more info on that
>=20
> Even assuming you don't agree with fuxh or Alias draft (which I support) =
then we do NOT need to hold up metric extensions. The metric extensions dra=
fts support the others, but are not the same thing
>=20
>=20
>=20
>=20
> ----- Original Message -----
> From: Curtis Villamizar [mailto:curtis@occnc.com]
> Sent: Tuesday, February 19, 2013 12:42 AM
> To: Lou Berger <lberger@labn.net>
> Cc: Giacalone, Spencer (Financial&Risk); jdrake@juniper.net <jdrake@junip=
er.net>; donald.fedyk@alcatel-lucent.com <donald.fedyk@alcatel-lucent.com>;=
 chopps@rawdofmt.org <chopps@rawdofmt.org>; isis-wg@ietf.org <isis-wg@ietf.=
org>; hshah@ciena.com <hshah@ciena.com>; acee.lindem@ericsson.com <acee.lin=
dem@ericsson.com>; curtis@occnc.com <curtis@occnc.com>; samita.chakrabarti@=
ericsson.com <samita.chakrabarti@ericsson.com>; nabil.n.bitar@verizon.com <=
nabil.n.bitar@verizon.com>; equinox-ietf@diac24.net <equinox-ietf@diac24.ne=
t>; huaimo.chen@huawei.com <huaimo.chen@huawei.com>; dward@bgp.nu <dward@bg=
p.nu>; swallow@cisco.com <swallow@cisco.com>; raszuk@cisco.com <raszuk@cisc=
o.com>; sprevidi@cisco.com <sprevidi@cisco.com>; kireeti.kompella@gmail.com=
 <kireeti.kompella@gmail.com>; akatlas@juniper.net <akatlas@juniper.net>; c=
filsfil@cisco.com <cfilsfil@cisco.com>
> Subject: Re: ISIS TE Metric Extension Discussion (IETF-85 Followup)
>=20
>=20
> In message <511E40B0.40903@labn.net>
> Lou Berger writes:
>=20
>> Spencer,
>>=20
>> On 2/14/2013 7:19 PM, you wrote:
>>> The use case is my network, where I want to setup TE tunnels based on
>>> performance, not cost, and I want to re-groom when changes occur,
>>> such as when optical path protect kicks in underneath me.
>>>=20
>>=20
>> ...
>>=20
>>> To your comment about adaptive routing, if you read the draft, it's
>>> clear we are aiming at TE tunnel setup/comp, not IGP manipulation
>>>=20
>>=20
>> I think you're providing critical context that some may have missed
>> during the presentation.  A slide or two on use case (rather then just
>> the generic nature of the extension) probably would have helped...
>>=20
>> WRT the draft, I think referencing the related drafts
>> (draft-fuxh-mpls-delay-loss-te-problem-statement and/or
>> draft-fuxh-mpls-delay-loss-te-framework) would provide the needed
>> pointer for those not familiar with the context.
>>=20
>> Lou
>=20
>=20
>=20
> My point at IETF-85 which still stands are:
>=20
>  1.  There needs to be a problem statement, requirements, and
>      framework providing that context.
>=20
>  2.  draft-fuxh-mpls-delay-loss-te-problem-statement and/or
>      draft-fuxh-mpls-delay-loss-te-framework are candidates but in
>      poor shape.  [btw- I emailed the set of authors of
>      problem-statement about a week or more ago and got no response.]
>=20
>  3.  As is the requirements of draft-fuxh-mpls-delay-loss-te-* are
>      not met by the isis or ospf te extensions (for example, a
>      working and protect relative delay is discussed, which would
>      require a min delay and max delay, not just a delay which is
>      implied to be min).
>=20
>  4.  There are Composite Link requirements that should be met.  The
>      draft-fuxh-mpls-delay-loss-te-* drafts cite this work but
>      address a subset of the issues related to delay and jitter.  For
>      example, the topic of stability is completely ignored.
>=20
> So my points still stand.
>=20
> It was premature to move the ospf work to wg.  It is premature to move
> this to wg.  The same issues need to be addressed in both since they
> are functionally identical.
>=20
> Curtis