Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-06: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I support Lars's discuss. I don't really object to publishing this document, although I don't really like the fact that the LAG member information that is being propagated isn't of any relevance to OSPF routing itself, and OSPF is being used only as a generic information propagation mechanism. However, I acknowledge that horse has probably bolted long ago. One point that is not clear to me, is the configuration/management of this feature: Is the expectation that OSPF implementations that support this RFC would automatically propagate bundle member information? Or would this be disabled by default and need to be enabled through configuration? If there is configuration associated with this feature then would it be part of a updated version of the standard OSPF YANG model, or is it via YANG module augmentation to the base OSPF YANG module? If this is configurable then having an informational reference to how/where this OSPF feature can be configured would likely be helpful. Regards, Rob _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
