Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-01.txt

From: <[email-masked]>
Date: Sat, 25 Aug 2012 22:54:03 +0400

> In regards to Appendix A in the new version of the draft, it is suggested 
> that the reverse metric TLV be used to address IGP-LDP synchronization 
> issues. But these issues have been addressed by solutions discussed in RFC 
> 5443 and RFC 6138. I do not see that the use of Reverse Metric TLV for the 
> same purpose provides a solution which is in any way better than what has 
> already been deployed in many environments.
>
> I would like to see Appendix A removed.
>
>   Les
>

Les,

when I've first suggested Shane to consider reverse metric as a possible 
solution to LDP-IGP sync on broadcast media I was fully aware of rfc6138. 
The methods described in draft-ietf-isis-reverse-metric and in rfc6138 are 
very similar so it should be easy and familiar to follow what's being 
proposed. Despite similarities there are few important differences. First of 
all, 6138 method looks more like a hack retrofitted into protocol specs - it 
does the job but it isn't intuitive in operational environment to figure out 
why traffic flow doesn't seem to match content of LSDB. On the other hand 
the method described in draft-ietf-isis-reverse-metric behaves essentially 
the same but with clear record in LSDB about the metric, and in fact this 
method is has more similarities to rfc5443 than 6138 has. From operational 
standpoint the method suggested in draft-ietf-isis-reverse-metric is more 
friendly.

One thing where 6138 has edge is implementation - it's already implemented 
and I perfectly understand that developers need very good reason to add a 
feature that does essentially the same but slightly differently. However I 
hope that such reason can be found while we discuss proposal of 
draft-ietf-isis-reverse-metric. And for this purpose I think we should keep 
Appendix A while we're at the draft stage - after all isn't it purpose of 
the text in the drafts to have discussions?

Cheers,
iLya