On Dec 13, 2012, at 3:25 PM, Peter Psenak wrote:
> 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.
peter,
two questions:
1) how do you know that the other side will be accepting the T-LDP session at a
non loopback IP address ?
2) what is your proposed scheme for minimizing the amount of T-LDP sessions
between a pair of routers ?
(is it numerically highest IP ?)
/hannes
>>
>> 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
