Stephane
Would some coarse increment version of incremental cost change
be an appropriate compromise approach for link up?
Stewart
On 03/03/2016 10:57, [email protected] wrote:
Hi Jeff,
There is two existing implementations of the link down.
Based on the feedback from my testing, I need to update the draft to
be more clear on the behavior when remote LSP is received before local
detection happens. That’s on my task list.
For the link up , there was some feedback that tweaking the flooding
machinery as a bad idea.
One option may be to remove the link up.
Best Regards,
*From:*rtgwg [mailto:[email protected]] *On Behalf Of *Jeff Tantsura
*Sent:* Wednesday, March 02, 2016 20:06
*To:* Routing WG
*Subject:* progress of draft-ietf-rtgwg-uloop-delay
Hi RTGWG,
Chris and I wanted to get a sense of how the working group would like
to proceed regarding draft-ietf-rtgwg-uloop-delay
For sake of simplicity – anyplace further in the email - any changes
to proposed to the existing IGP timers behavior by uloop–delay draft
will be called - "uloop–delay algorithm"
The basic question for the working group is: Should we proceed
towards publication of the draft more or less as is, or should we wait
to incorporate feedback from one or more implementations of the
uloop-delay algorithm?
As far as we know, there haven't been any implementations of the
proposed uloop-delay algorithm. It would be good to get an
understanding if any implementations are in progress or planned.
The uloop-delay algorithm proposed in the document seems quite
reasonable. However, it is also quite possible that a single
implementation would uncover some unforeseen issues or suggest
improvements for the functioning of the algorithm in a single vendor
network. Testing with two or more implementations may provide
feedback to improve the algorithm with respect to the goal of having
common uloop-delay timers in a multi-vendor network. But we won't
know until that work is done.
If there are implementations in progress or planned, then we think it
would be worth waiting to incorporate feedback from those
implementations before publishing.
Instead, if there are no implementations planned, we have several
options. We can proceed towards publication more or less as is, with
WG last call in the near future. Or we can explicitly decide to wait
to publish the document, leaving it either as an active WG document or
as a parked WG document, and wait for one or more implementations.
With the last option, we could leave open the option of publishing at
some point in the future, even if no implementations appear.
Personally, I am quite hopeful that there will be at least prototype
implementations in the not too distant future. While it is very
unlikely that a vendor would change their defaults, it can easily be
implemented with a knob to activate this algorithm. This gives a
simple way to try out the new algorithm incrementally, lowering the
bar significantly for at least a prototype implementation.
We look forward to hearing feedback from the WG on how to proceed with
the draft.
Cheers,
Jeff
_________________________________________________________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
