Alia,
On 13.12.2012 16:03, Alia Atlas wrote:
Peter,
One of the goals of LFA & remote-LFA is for ease of manageability. Why
are you pushing for requiring additional configuration, which I don't
see as adding any benefit from the flexibility, instead of documenting
the straightforward rules for automatic interoperabiity?
for most of the deployments, no config is required and picking the
router-id or highest /32 address advertised by PQ node will work fine.
For those cases where above does not work, there are no magic rules that
will make it work in all cases. We would need a protocol extension to
guarantee it.
thanks,
Peter
Alia
On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Bruno,
On 13.12.2012 15:50, [email protected]
<mailto:[email protected]> wrote:
Peter,
Unless it is believed that a local algorithm, without
coordination between
routers/vendor, can work in 100% of the cases. Is this your
point?
local algorithm that picks any of the /32 IP addresses
advertised by PQ
node will work in 100% of cases.
Does this include the case of an IS-IS L1/L2 router (ABR)
redistributing into L2 the loopbacks of the routers in L1?
ISIS may have a specific problem of not distinguishing between
intra/inter/external prefixes. For that case some local policy on
the computing node can be used to pick the ones that will work for LDP.
thanks,
Peter
thanks,
Peter
Thanks,
Regards,
Bruno
thanks,
Peter
_________________________________________________
rtgwg mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/rtgwg
<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,
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.
_________________________________________________________________________________________________________________________________
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.
_________________________________________________
rtgwg mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/rtgwg
<https://www.ietf.org/mailman/listinfo/rtgwg>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
