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

[Yingzhen Qu <[e-mail]>]

Hi Luis,

Thanks for your support and comments. Please see my answers below inline.

Thanks,
Yingzhen

On Thu, Apr 4, 2024 at 2:34 PM LUIS MIGUEL CONTRERAS MURILLO <
[e-mail]> wrote:

> 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).
>
>
>
[Yingzhen]: We will definitely add more security considerations. Malicious
changes to schedules, or clock can disrupt network functionality which may
lead to a DoS attack.


> - 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)
>
>
>
[Yingzhen]: How a routing protocol may react to a schedule is out of the
scope of this draft, but we can add contents about operations, such as the
expected behaviors when multiple schedules are configured. This is why
"schedule-id" is introduced.


> 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)
>
>
>
[Yingzhen]: Good point. Will change this in the next revision.


> - 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.
>
>
>
[Yingzhen]: There are interfaces in the ietf-tvr-node module. I'd think for
a topology module, links between nodes are more appropriate. For example,
in case of LAG, a link is built with multiple interfaces, if one of the
interfaces is shut down to save power, the bandwidth of the link will
reflect this change. If I'm missing something here, please let me know.


> 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
> --
> Tvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tvr
>