Re: [OSPF] ISIS TE Metric Extension Discussion (IETF-85 Followup)

[Acee Lindem <[e-mail]>]

Hi Spence, 
Note that the bar for WG last call and request for publication as a standards track RFC is quite a bit higher than for WG adoption (OSPF WG copied). We need to have this discussion now and either address the questions surrounding the delay metrics or agree that they are out of scope. 
Having said that, speaking as a WG member of both WGs, I have re-read the draft and don't have problems with the guidance given for delay metrics when these metrics are used for TE. 
Thanks,
Acee 

On Feb 19, 2013, at 7:58 AM, <[e-mail]>
 wrote:

> Pls note that the ospf wg has already adopted express path as ospf metric extensions.
> 
> 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
> 
> 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 drafts support the others, but are not the same thing
> 
> 
> 
> 
> ----- Original Message -----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Tuesday, February 19, 2013 12:42 AM
> To: Lou Berger <[e-mail]>
> Cc: Giacalone, Spencer (Financial&Risk); [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: ISIS TE Metric Extension Discussion (IETF-85 Followup)
> 
> 
> In message <[e-mail]>
> Lou Berger writes:
> 
>> Spencer,
>> 
>> 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.
>>> 
>> 
>> ...
>> 
>>> 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
>>> 
>> 
>> 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...
>> 
>> 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.
>> 
>> Lou
> 
> 
> 
> My point at IETF-85 which still stands are:
> 
>  1.  There needs to be a problem statement, requirements, and
>      framework providing that context.
> 
>  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.]
> 
>  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).
> 
>  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.
> 
> So my points still stand.
> 
> 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.
> 
> Curtis