Hi Bruno,
On 09/09/2021 14:43, [email protected] wrote:
Hi authors, all,
I have a question related to the two-way connectivity check performed on each
link during the FlexAlgo SPF.
flex-algo is defined as set of:
(a) calculation-type
(b) metric-type,
(c) a set of constraints
Two way connectivity check for any link in the MT topology is orthogonal
to flex-algo and is done once only and used for all algorithms.
Flex-algo calculation using (a), (b), and (c) is done on top of MT
topology using only links for which the 2WCC has already been performed.
Is this point documented in the document? I could not find it so far.
If not, what is the (reverse connectivity) check that need to be performed on
the reverse link?
none.
thanks,
Peter
A priori I could see multiple options:
a) link exist
b) link exist with a standard IGP metric (seem the option defined in the ISO
spec §7.2.8.2)
c) link exist with the FlexAlgo metric used by FlexAlgo
d) link exist with the FlexAlgo metric used by FlexAlgo and link complies to
FlexAlgo constraints.
I think we'll agree that this point requires uniformity across nodes hence
standardization.
Personally, I don't have significant preference, but the algo defined in §13 "Calculation of Flexible
Algorithm Paths" could be read as defining option "d" (as links not following the constraints
are "pruned from the computation") but I'm not sure that this is intended for the two-way
connectivity check.
Thanks,
Regards,
--Bruno
_________________________________________________________________________________________________________________________
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
