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?

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to