| A very reasoned note.
I know this is a ridiculous request, but is it possible to call the question? Sent from my iPhone Hi, all experts:
I noticed that during the Ketan and Med’s review of this document, they all recommended that the “operation consideration” part should be added but the authors refused.
Here I want to remind the operators that focus on the UPA feature, that the protocol extension defined in this document is implementable, but NOT practical to be deployed in the network.
Any operator try to adopt this feature in their network should be aware that the following issues:
1) The UPA propagation between the areas is conflict with the base OSPF standard(RFC 2328).
That is to say, according to the description in RFC 2328, UPA can’t be propagated further to the remote area(only to the neighbor area).
The quotes link gives an answer Ketan has given many times:
The link states:
OSPF ABRs or ASBRs, which would be responsible for propagating
UPA advertisements into other areas MUST recognize such advertisements. Advertising prefix reachability between OSPF areas assumes prefix reachability
in a source area. Such requirement of reachability MUST NOT be applied
for UPAs, as they are propagating unreachability.
At best I could see giving Operational Considerations guidance of deploying this in a mixed environment where some, but not all devices suport this feature. If you really believe that is a concern, please write a sentence of two on how operators should handle this. This could be as simple as "dont enable this feature until all your devices support it". If you cannot give such a short operational advise sentence for consideration, I will assume the issue need no further addressing.
2) The exploitation of LSInfinity feature is one disaster to the operator’s network.
One can easily imagine the confusion scenario: One prefix with metric set to slightly lower than LSInfinity will become “unreachable” after several hops because the accumulated cost will exceed the LSInfinity.
Same as above - instead of simply saying "disaster", try to give constructive operational consideration sentences. I noticed until now, among the IESG reviewers, only Med is from the operator, but ignored also the above issues( I appreciate that Med insisted that UP flag was unnecessary, despite of the authors’ unsound resistance to change——Until now, there is no vendor implement the U flag, not to mention UP flag).
The above issues are so obvious, I am wondering why it can pass the final IESG review.
It can pass review because you have not convinced anyone beyond yourself that there is a problem.
Is it necessary to appeal to the IAB after the IESG’s review to pass this document?
Can IAB amend the so called consensus procedure to eliminate such standards that have flaws, or challenging to be deployed in the operator’s network?
The consensus being questioned by a single individual is hardly convincing. Where are the other operators? Until now, we have never seen a single individual predicting the demise of the internet, and being correct.
I am wondering. Can anyone give some suggestions, or explain the solutions to above issues?
See above. Write constructive text that you think would give proper warning on how/when to use these features or not.
Paul
|
