Hi all, I would bring the following comment :
As far as I know, LDP and IGP are quite independent in term of managing their "addresses". An operator may choose a router ID for ISIS that could be different from LDP one. Personnally I don't really see an interrest in doing that but it's a possibility. Moreover I would be more worry on transient situations when you let the router choosing router IDs, you activate ISIS (ISIS choose a router ID based on IP address available), then you configure a new high address loopback, and then you configure LDP, in this case you will have a high probability to have a different router ID for each ... (it's clearly implementation dependant but the solution must work with all cases) -> we already had such situation with BGP having a different router-id than ISIS/LDP. Moreover regarding TLDP, I think implementations could be different in the way they are accepting T-LDP sessions. I don't know if there are some guidelines in LDP spec for this ... Some may accept TLDP sessions only on LDP router-id, some may accept on all loopbacks ... So is it a good think to rely on IGP router-id or IP address TLV 132 as it may not reflect how LDP is behaving ? Issue with TLV 135 is that it could transport external redistributed routes (we have the case ...) It could be good to have some tie breakers as Hannes proposed, the main point to address would be , how implementation must behave when the TLDP session cannot establish (for example because we chosen the bad IP address ...) ? Does it fallback and try another IP, does it fallback to another PQ ? (but problem would be the same with another PQ if problem comes from bad IP choice). I would see two complementary options : - define a spec, as Hannes proposed, where we rely on IGP address infos (router ID, TLV 132 ...) and give some guidelines to reader on how LDP must be parametered to ensure that it will work. - permit user to define by himself the addresses rLFA would use as transport address for TLDP (using admin tags for example). Regards, Stephane -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Peter Psenak Envoyé : mercredi 12 décembre 2012 17:34 À : Hannes Gredler Cc : [email protected]; [email protected] Objet : Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00 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. 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
