Bruno,
On 13.12.2012 15:21, [email protected] wrote:
Peter,
From: Peter Psenak
Hannes,
On 12.12.2012 17:05, Hannes Gredler wrote:
in favor of explicit advertisement, i'd rather do 3 rules here :
1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node
itself
2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node itself
3. Highest /32 address advertised by PQ node in it's Router LSA
ether (1) or (3) is mandatory for the t-LDP session creation. (2) is
optional and not sufficient for t-LDP session, so we can not have it
before (3).
It looks to me we are trying to solve the configuration problem which
should not be addressed here.
It looks to me that we are trying to address the network management problem and
deployability/interoperability in a multi-vendor network.
May be this can be done by configuration. In this case, could you please
elaborate on what you propose?
Given that at least two routers (the PLR and the PQ) must agree on establishing the T-LDP
session, there is a priori room for coordination. And given that a PLR (resp. PQ) needs
to be able to use (resp. used) "any" PQ (resp. PLR), it seems useful that the
same mechanism be shared by all PQs and PLRs, rathers than one relying on ISIS tag,
another on order of IP addresses, another on static address range...
Hannes' request seems a relevant point to discuss on the mailing list and IMO
the R-LFA draft should discuss this.
Even if the R-LFA proposition is not specific to a network environment (e.g.
type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that
deployment will be a specific environment, where this is expected to work. I
also think MPLS tunnels (LSPs) established by LDP seems a reasonably popular
target deployment.
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.
thanks,
Peter
Thanks,
Regards,
Bruno
thanks,
Peter
_______________________________________________
rtgwg mailing list
[email protected]
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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
