Hi, Peter: I suggest that you consider such problems and the solutions from the broader viewpoint, not just the behavior of one single device, or only from the vendor side. To deploy the mechanism into the network, the operator must assure it will not conflict with other possible usages, and no more constrained for the network planning, network operations.
There are already amounts of solutions cannot be deployed widespread in the network. Let’s take the explicit signaling approaches. Aijun Wang China Telecom > On Nov 10, 2022, at 10:41, Peter Psenak <[email protected]> > wrote: > > On 09/11/2022 22:51, Aijun Wang wrote: >> Hi, Peter: >> Actually, the “unreachable” meaning of LSInfinity in current standard is not >> the same as the “unreachable” meaning that we are supposed to act: >> 1) In current standard, the “unreachable” is meant that the related prefix >> will not be in the FIB.(you can read again and again >> https://www.rfc-editor.org/rfc/rfc2328.html#page-157 >> <https://www.rfc-editor.org/rfc/rfc2328.html#page-157>) >> 2) What we aim to solve is that although the specific prefixes is not in the >> FIB, there is another summary address that cover it is in the FIB. Even in >> such situations, the specific prefixes is still unreachable. >> Then, depend solely on 1) is not enough. >> We must need one explicit information to signal 2). >> There are so many experts within LSR state that your solution is not >> appropriate, will bring much chaos into the network, you still insist your >> approach. Is this productive? > > interesting that you, who hardly listen to these experts at all, are saying > that. > > Peter > > >> The final solution should be definitely in “Standard Track”, but not your >> approach. >> The explicit signaling is the right direction. >> Even the experts in LSR are confusing on your multiplex usage of >> “LSInfinity”, how to deploy it in the large scale network? >> Please don’t let the operator struggle to explain such vague usages to its >> Network OPS, Network Planning team. >> Aijun Wang >> China Telecom >>> >>>> I wasn't clear on that in the first mail but Bruno clarified >>>> that this would still be inside a high-metric prefix reachability TLV. >>>> The only difference is that there is a flag/sub-TLV inside that triggers >>>> UPA behavior. However, prefixes with > 0xfe000000 metric *without* >>>> the UPA indicator MUST be ignored as they were before and MUST NOT >>>> trigger UPA/PIC. >>> >>> for me flagging something that is unreachable with a unreachable flag is >>> redundant. But I let the WG to decide. That would obviously push the draft >>> to standard track trajectory. >>> >>> Peter >>> >>> >>>> Cheers, >>>> -David >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
