Re: [Tvr] WG adoption poll: draft-united-tvr-schedule-yang

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi all,

I support the adoption of the draft.

There are however some questions / comments that I would like to be discussed along the progress of the document.

These are my questions / comments:

- The draft comments briefly about the usage of the models. I think it would be beneficial to go into more detail on that. The reason for it is because security considerations can be derived from that usage. For instance, malicious users could enforce contradicting schedules in the network, or even schedules that can cause service disruption (e.g., schedules in two nodes connecting via alternative interfaces, where one of the nodes is scheduled for a link to become unavailable in one of the paths, while the other node being scheduled for the link becoming unavailable at the same time in the other path).

- It could be interesting to comment about the behavior of the nodes when receiving the schedules through these models. The nodes could either simply keep the schedule once received for being processed at proper time, or in addition to that, start populating the scheduled changes for instance by means of OSPF, as described in the Annex. I mention this because, again, some security considerations can be derived from that. For instance, in the second case, a malicious user could configure different schedules very often creating continuous routing protocol updates, which could produce Denial-of-Service. (Some of these situations are already referred in draft-ietf-tvr-requirements)

Note. Looking at the charter items, these two initial comments could be maybe subject of charter item 6 (Implementation and Operational Considerations) and documented in depth in a separate document, even though could be worthy to mention also in this respect here.

- [comment here with CCAMP chair hat on] The TVR schedule node module contains the parameter "router-id". I think we should go generic here and stay with node-id. The reason is that other nodes than routers could be subject of these models, as in the case of microwave or OTN (to mention CCAMP-related kind of nodes/technologies)

- The TVR topology module refers to nodes and links. Besides nodes, I think we should consider both links and interfaces. The reason is because there could be situations in which an interface could support more than one link (as could be in microwave nodes with multiple radio links on the same interface) or situations in which a link can be built with multiple interfaces (as could be the case of LAG). So, for the sake of generality, it could be better to consider nodes, interfaces and links, so that particular situations can be accommodated in the model.

Thanks,

best regards

Luis


De: Tvr <[e-mail]> En nombre de Tony Li
Enviado el: martes, 2 de abril de 2024 0:25
Para: [e-mail]
CC: TVR WG Chairs <[e-mail]>
Asunto: [Tvr] WG adoption poll: draft-united-tvr-schedule-yang


[WG chair hat: on]


Hi all,

This is to announce the start of a two-week WG adoption poll for draft-united-tvr-schedule-yang.


An affirmative response indicates that you believe that the document is a good starting point for the WG to continue it’s work.
It does NOT imply that you feel that the document is ready for publication.


Please reply-all with


          “Yes, I support adopting draft-united-tvr-schedule-yang”


or


          “No, I do not support adopting draft-united-tvr-schedule-yang”




This poll closes at 5pm PDT Apr 15 2024.


Thanks,
Ed & Tony



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição