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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 Sep 2012 02:07:23 +0000

Ilya -

The primary question in regards to this draft is whether the use of reverse metric as a tool for shifting traffic away from a link as an aid to maintenance operations is something we want to introduce/standardize. What I would like to see is more discussion on the pros/cons of doing this. If there is consensus that this is a "good idea", then (and only then) we might consider additional uses of the new TLV. As the additional uses proposed to date have been to address problems which have already been solved/implemented/deployed in other ways, I am concerned that we might justify the introduction of reverse metric TLV on the basis that it could also be used to solve problems that have already been solved - which seems to be a weak way to make the case for the new TLV.

In regards to the primary use of reverse metric TLV as a maintenance aid, the solution is idiosyncratic to IS-IS e.g. you cannot introduce an equivalent solution in OSPF (at least not on LANs) because the Network LSA has no metric. As the network operations problem is not unique to IS-IS, this means that there will ultimately have to be another solution to the same problem which likely will be based on the information/infrastructure proposed by (for example):

http://www.lucidvision.com/draft-ward-irs-framework-00.txt 

and

http://datatracker.ietf.org/doc/draft-gredler-idr-ls-distribution/

This will eventually provide the information necessary to allow a management application to be used by the operator to easily modify the configuration on both ends of a link in a way which is protocol agnostic. At which point the reverse metric solution will be redundant. And frankly I think a management application is the right tool to use to solve the very real problem which network operators face.

In that context, does the IS-IS community want to invest in what will become redundant once the more generic solution is available? I am reluctant to do so.

As regards your remarks concerning RFC 6138, I don't understand:

"it isn't intuitive in operational environment to figure out why traffic flow doesn't seem to match content of LSDB..."

RFC 6138 recommends suppressing the advertisement of the adjacency to the pseudo-node while waiting for LDP sessions to come up - so in fact traffic flow does follow the state of the LSDB. Perhaps what you mean is that you find the absence of an IS-Neighbor advertisment when one would be expected less intuitive than the presence of a reverse-metric TLV which overrides the locally configured metric associated w the IS-Neighbor advertisement??? If so, I don't agree - but at least I understand what you are trying to say.

LDP-IGP sync isn't an easy read. Unless one understands in some detail how the IGP and LDP interact some things which seem intuitive (why isn't the advertised metric what I expect?) don't occur as expected, confuse users and lead to support questions. I don't think any method we come up with to implement it will ever be "easy to understand".

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, August 25, 2012 11:54 AM
> To: Les Ginsberg (ginsberg); Naiming Shen (naiming); Tony Li (tli);
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-01.txt
> 
> > 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

---

From: Tony Li <[email-masked]>
Date: Tue, 4 Sep 2012 21:21:16 -0700

Hi Les,

> The primary question in regards to this draft is whether the use of reverse metric as a tool for shifting traffic away from a link as an aid to maintenance operations is something we want to introduce/standardize. What I would like to see is more discussion on the pros/cons of doing this. If there is consensus that this is a "good idea", then (and only then) we might consider additional uses of the new TLV.

At the risk of being redundant, yes, I think the ability to easily cost out an interface is a good idea.

> This will eventually provide the information necessary to allow a management application to be used by the operator to easily modify the configuration on both ends of a link in a way which is proto…

Well, our history with network management applications is none too good.  I've been watching them for awhile now, and we have yet to see anyone produce anything that was truly successful.  With all due respect to those who are proposing things now, it is far from certain that these applications will be adopted, much less become sufficiently ubiquitous that they can be seen as the sole and sufficient solution for network operations.

> In that context, does the IS-IS community want to invest in what will become redundant once the more generic solution is available? I am reluctant to do so.

Well, yes.  It may become redundant.  But then again, it may not.  Predicting the future is pretty hard.

For my money, the small, pragmatic progress that we can make now is always going to be the right option.

Tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Sep 2012 08:04:54 +0200 (CEST)

On Wed, 5 Sep 2012, Les Ginsberg (ginsberg) wrote:

> on the basis that it could also be used to solve problems that have 
> already been solved - which seems to be a weak way to make the case for 
> the new TLV.

I am no stranger to solving the same problem in different ways, especially 
if the new way is more robust. My take on LDP IGP SYNC is that it's been 
problematic and has caused operational problems, and it's also not 
symmetric. I have always thought that it was limiting that IGPs do not 
have IN+OUT metric to the "link".

> In regards to the primary use of reverse metric TLV as a maintenance 
> aid, the solution is idiosyncratic to IS-IS e.g. you cannot introduce an 
> equivalent solution in OSPF (at least not on LANs) because the Network 
> LSA has no metric. As the network operations problem is not unique to 
> IS-IS, this means that there will ultimately have to be another solution 
> to the same problem which likely will be based on the 
> information/infrastructure proposed by (for example):

Can't OSPF be extended with a new Network LSA actually gets a metric? I 
realise they would have to do more than in ISIS, but I believe the 
operational need is the same there.

> This will eventually provide the information necessary to allow a 
> management application to be used by the operator to easily modify the 
> configuration on both ends of a link in a way which is protocol 
> agnostic. At which point the reverse metric solution will be redundant. 
> And frankly I think a management application is the right tool to use to 
> solve the very real problem which network operators face.

The problem here is that a management application is what major ISPs might 
use, but the small and medium ones do not, and then I'm ignoring 
enterprise altogether (which I shouldn't).

To create a management application to handle changing metrics at both end, 
the management system needs to know a lot about the network, which 
generally small and medium ISPs do not have the resources to do.

I imagine that the few tens of router software vendors (I imagine there 
are not THAT many from-scratch implementations of ISIS, smaller router 
vendors seem to buy the suite from someone or use FOSS ones) would spend 
less time on implementing the proposed changes to ISIS, than what the tens 
of thousands of ISPs and hundreds of thousands of enterprise would spend 
on a management system for the equipment. I know I expect my router vendor 
to implement new features and do it properly, instead of me as an ISP 
trying to create scripts and/or systems that do this. I trust my router 
vendor(s) implementation/testing skills a lot more than mine (and my 
colleagues) equivalent skills.

I believe TRILL is based on ISIS, right? Wouldn't what we discuss be 
applicable to TRILL based networks as well? Isn't TRILL aimed at wide 
market adoption?

> In that context, does the IS-IS community want to invest in what will 
> become redundant once the more generic solution is available? I am 
> reluctant to do so.

I guess we have disagreement on how generic and ubiquous that solution 
would be. I don't see all users of ISIS adopting that kind of management 
system anytime soon.

> RFC 6138 recommends suppressing the advertisement of the adjacency to 
> the pseudo-node while waiting for LDP sessions to come up - so in fact 
> traffic flow does follow the state of the LSDB. Perhaps what you mean is 
> that you find the absence of an IS-Neighbor advertisment when one would 
> be expected less intuitive than the presence of a reverse-metric TLV 
> which overrides the locally configured metric associated w the 
> IS-Neighbor advertisement??? If so, I don't agree - but at least I 
> understand what you are trying to say.

I have seen problems with single-connected routers inital link coming up, 
and LDP IGP SYNC. I don't know the exact problem reason, but anything but 
high metric seems a recipe for disaster when doing LDP over TCP sessions 
between loopbacks (which is what we're doing). Until the ISIS adjacency is 
up there is no routing to the loopback interface at the other end that LDP 
needs to setup its session to.

I think a way for a node to signal to the other end that both are ready to 
take traffic (LDP is up, all labels are installed etc) is better than the 
LDP IGP SYNC way of just waiting until I'm done at my end and then start 
sending traffic and hoping for the best.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 Sep 2012 16:30:39 +0000

Mikael -

In regards to OSPF, changing the format of the Network LSA represents a fundamental change in the protocol which would not be backwards compatible. I think this is a non-starter - but feel free to ask the OSPF-WG their opinion.

In regards to LDP-IGP sync, the advantage of RFC 6138 (aside from the fact that it is already deployed) is that I can control my own destiny i.e. I don't need help from a neighbor, who may/may not support the protocol extension, in order to determine when to use the link.

As for your comments on network management applications, I won't repeat my statements. Now there are at least three of us who have expressed their opinion - which is exactly the discussion I think we should be having.

    Les

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2012 11:05 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; Naiming Shen (naiming); Tony Li (tli);
> [email-masked]; [email-masked]
> Subject: RE: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-01.txt
>

---

From: <[email-masked]>
Date: Thu, 6 Sep 2012 09:14:02 +0200

Les,

Regarding the primary question, yes it's a good idea to simplify traffic shifting. In our case, we are doing this everydays ! The solution sounds good and simple, except that there is a need to upgrade routers with a new code to handle this. This means that (depending on SP case and OS deployment policies), it will not appear in a live network before 2 or maybe 3 years ...
The main question is : is it too late or not ? IMHO (I'm only speaking on my case, but I'm interrested to know other SP position on this ...), we have developped automated scripts that detects adjacencies, connect on remote node and update metric. As it is already developped, will we move to the new easier method in future, I don't know ... But clearly it would be interresting for people who don't have such automated scripting.
The other issue I see but it's mentionned in "Operational considerations", is how to handle the deployment of the feature, some nodes may have the benefit of the feature because neighbor is upgraded also (and understand the TLV), and some not, and on big networks, it will be hard to manage. So basically, IMHO the feature would not be used until the full network is upgraded. But how if some nodes never support it ? I would be interrested to have another solution than checking traffic counters, to know that the neighbor is not capable of handling reverse metric ... Would it be possible to add something in "HELLO" to advertise sort of "capability" ? And so basically the local router may be advise the operator that if a reverse metric is configured, it may not be applied because the neighbor doesn't support it.

Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Les Ginsberg (ginsberg)
Envoyé : mercredi 5 septembre 2012 04:07
À : [email-masked]; Naiming Shen (naiming); Tony Li (tli); [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Isis-wg] I-D Action: draft-ietf-isis-reverse-metric-01.txt

Ilya -

and

   Les

> > 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.
> >
> 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

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.