More text about security, mgt/ops?

[cabo]

Either in the charter proposal itself or in the discussion below, we should say more about security, management, and operations of a LOOPS tunnel (comment from Colin Perkins).

draft-ietf-tsvwg-transport-encrypt-05 might inform us here with some of the issues to be addressed.

A separate deliverable could expand on this, but we wouldn’t want to ship the initial one (information model/protocol) without some thinking about this, so I'm not sure such a deliverable should be called out separately.

We would like to keep the “orchestrator” that sets up LOOPS segments as out of scope, though; this would likely be some form of SDN controller for the overlay that we don’t have to standardize to make LOOPS work. (Or maybe we want to standardize some form of it later [as a YANG model?].)

[liyizhou]

ACL can be used to direct traffic to LOOPS-enalbed tunnel. I think it is very reasonable to keep the “orchestrator” stuff out of scope. The “orchestrator” usually does more work besides LOOPS enablement. It is also responsible for path selection in our demo system. Hard to peel LOOPS alone from the whole orchestrator. So it is not necessary to standardize the LOOPS setup part.

I do not think YANG model needs to be included right now. It looks the LOOPS setup now can be a simple KV configuration file, for example, initial PSN, recovery mode (rtx/fec), no complex structure is required.

[csperkins]

I suspect this doesn't need more than a single sentence in the charter, saying that "The WG will consider security, management, and operations in the design of the LOOPS protocol". I doubt that a separate deliverable is needed.