Subject: RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

From: Uma Chunduri <[email-masked]>
Date: Mon, 10 Feb 2014 21:53:40 +0000

Stephane,

As I have given my feedback on the recent updates offline  and new versions looks fine to me.
I have 2 more final comments as noted below [Uma1]:

========

3. Similarly Section 4.4 coverage monitoring guidelines for the vendor implementations are good ones but these are neither addressing any issues 
     presented in Section 2 nor helping solve any interoperability issue. 
The problem I see with this is lot of implementations may quickly become non-compliant from customers point of view once this becomes RFC. Do you see that way?
[SLI] As mentioned in previous comment, coverage informations are mandatory to be able to maintain LFA deployment (SP experience speaking ...). As proposed, I can add something in section 2 to detail the need. 

[Uma1]: I am not at all saying coverage information and monitoring information is less important, in fact it could be critical for SPs but my question is towards, 
how far we can mandate these kind of implementation choices of the vendors ?

5. Section 3.2.1

   Also,  say you might have a legacy node to deal with and you are not able to establish TLDP with PQ here 
   in that case, you might look for a knob to choose the policy (remote or local policy).

[SLI] This may be managed by "neighbor exclude" policy statement.

[Uma1]: It may not be neighbor exclude as this is PQ node's preference and multiple destinations can have different PQs with same neighboring node.
                 Probably you mean to say node-admin tag kind of stuff?

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 12:07:04 +0100

Hi Uma,

Inline answers ([SLI2])

-----Message d'origine-----
De : Uma Chunduri [mailto:[email-masked]] 
Envoyé : lundi 10 février 2014 22:54
À : LITKOWSKI Stephane DTF/DERX; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

Stephane,

========

[Uma1]: I am not at all saying coverage information and monitoring information is less important, in fact it could be critical for SPs but my question is towards, how far we can mandate these kind of implementation choices of the vendors ?

[SLI2] IMHO, LFA cannot be used in a service provider network requiring FRR without such information. That's why we putted a MUST for some of the items that we consider to be the minimum subset to make LFA being usable. We can discuss on the exact subset to be MUST/SHOULD/MAY but some items need to be as MUST. I agree that this does not prevent LFA to work, but it prevents it to be used ...

5. Section 3.2.1

[Uma1]: It may not be neighbor exclude as this is PQ node's preference and multiple destinations can have different PQs with same neighboring node.
                 Probably you mean to say node-admin tag kind of stuff?
[SLI2] Ok,  sounds to be a vocabulary issue ... when I use the "neighbor" statement here, I mean alternate preference ... I will fix it to be more clear in the document( s/neighbor/alternate/g)

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.