Hi Maik,
Here is a proposed new text, let me know if it fits your comment :
"Service providers often perform manual link shutdown (using router
CLI) to perform some network changes/tests. A manual link shutdown
may be done at multiple level : physical interface, logical
interface, IGP interface, BFD session ... Especially testing or
troubleshooting FRR requires to perform the manual shutdown on the
remote end of the link as generally a local shutdown would not
trigger FRR.
To enhance such situation, an implementation SHOULD
support triggering/activating LFA Fast Reroute for a given link when
a manual shutdown is done on a component that currently supports FRR
activation.
For example :
o if an implementation supports FRR activation upon BFD session down
event, this implementation SHOULD support FRR activation when a
manual shutdown is done on the BFD session. But if an
implementation does not support FRR activation on BFD session
down, there is no need for this implementation to support FRR
activation on manual shutdown of BFD session.
o if an implementation supports FRR activation on physical link down
event (e.g. Rx laser Off detection, or error threshold raised
...), this implementation SHOULD support FRR activation when a
manual shutdown at physical interface is done. But if an
implementation does not support FRR activation on physical link
down event, there is no need for this implementation to support
FRR activation on manual physical link shutdown.
"
Stephane
De : rtgwg [mailto:rtgwg-boun...@ietf.org] De la part de Maik Pfeil
Envoyé : mercredi 22 janvier 2014 15:07
Cc : rtgwg@ietf.org
Objet : Re: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt
Hi,
as stated in section 4.2
<snip>
To enhance such situation, an implementation SHOULD
support triggering/activating LFA Fast Reroute for a given link when
a manual shutdown is done.
</snip>
The triggering of a FRR could also happen by BFD in some implementations. The
last sentence should be more generalized or even get more details. What exactly
should a "shutdown" trigger? For e.g. a tx-laser off on local side -> triggers
LFA on remote side.
// Maik
2014/1/22 <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group Working Group of
the IETF.
Title : Operational management of Loop Free Alternates
Authors : Stephane Litkowski
Bruno Decraene
Clarence Filsfils
Kamran Raza
Martin Horneffer
Pushpasis Sarkar
Filename : draft-ietf-rtgwg-lfa-manageability-01.txt
Pages : 21
Date : 2014-01-22
Abstract:
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
(and MPLS LDP traffic by extension). Following first deployment
experiences, this document provides operational feedback on LFA,
highlights some limitations, and proposes a set of refinements to
address those limitations. It also proposes required management
specifications.
This proposal is also applicable to remote LFA solution.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-01
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
tools.ietf.org<http://tools.ietf.org>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg
_________________________________________________________________________________________________________________________
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,
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, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
