On 7/5/18 18:25, stephane.litkowski@xxxxxxxxxx wrote: > I found a couple of MAY requirements in here that I feel should be stronger or > offer some additional recommendation (mainly to favor operators or help guide > vendors). First, section 4 states "For simplicity, an implementation MAY use > the minimum ERLD between each linecard as the ERLD value for the system." I > feel there should be a stronger recommendation on what to do here given that > ERLD is later described as a key piece of the algorithm for EL placement. A > vendor may opt for the simple approach, but should they consider a more robust > approach to favor operators? > > [SLI] Proposed addition: > "The drawback of using a single ERLD for a system lower than the capability of one or more specific component is that it may increase the number of ELI/ELs inserted. This leads to an increase of the label stack size." That sounds reasonable. Wouldn't it also potentially cause a loss of load balancing capability along a path? You're still leaving this a MAY, which may be fine. But is there a recommended approach other than using the minimum value? I haven't read the other advertisements drafts, so they may be recommending something (in which case a reference link would be nice to add). > > Second, section 5 states "this node MAY advertise its MSD value or a subset of > its MSD value to the controller." It MAY NOT do that, too. It would be good > to highlight pros and cons to this. > > [SLI] Here is the proposal:" As the controller does not have > the knowledge of the entire label stack to be pushed by the node, the > node SHOULD advertise an MSD value which is lower than its actual limit. If the node advertises an MSD values equal to its actual limit, the controller could program an LSP using a number of labels equal to the MSD value. When receiving this label stack from the controller, the ingress node may not be able to add any service (L2VPN, L3VPN, EVPN...) label on top of this label stack. The consequence could be for the ingress node to drop service packets that should have been forwarded over the LSP." Works for me. > > > > Finally, section 7.2 states "In case of a trade-off, an implementation MAY > provide flexibility to the operator to select the criteria to be considered > when placing EL/ELIs..." I can see this being of great value to operators to > have vendors allow this. But as with any MAY, the vendor MAY choose NOT to do > it. SHOULD seems better here for that reason. > > [SLI] Agree that "SHOULD" better fits here Thanks! Joe
