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?

Alia


On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <[email protected]> wrote:

> Bruno,
>
> On 13.12.2012 15:50, [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]
>>>>> 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]
> 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

Reply via email to