[Teas] Re: [RTG-DIR]Re: Rtgdir early review of draft-ietf-teas-rfc8776-update-14

[[e-mail]]

Hi Oscar,

I've looked at the diff and the latest version of the document resolves 
my concerns and adjusts the scope to avoid the last one. As a result, 
this version looks good to me.

Thank you Italo and co-authors for addressing my comments,

Julien


On 25/09/2025 16:32:08 OSCAR GONZALEZ DE DIOS 
<[e-mail]>, wrote:
>
> Hi Julien,
>
>     As part of the shepherd review of draft-ietf-teas-rfc8776-update, 
> I found that the Rtgdir early review is still in a state with issues. 
> Italo replied to your comments and provided a revised version of the 
> document.  Could you check if the modifications proposed by the 
> authors address your comments?
>
>         Best Regards,
>
>         Oscar
>
>
> ------------------------------------------------------------------------
> *De:* Italo Busi <Italo.Busi=[e-mail]>
> *Enviado:* Sábado, 25 de Enero de 2025 21:30
>
> Thanks Julien
>
> For the generalized TE bandwidth, we have agreed to remove the text on 
> OTN and WDM bandwidth. IMHO, we can discuss the second part of your 
> comment on WDM tunnel bandwidth, in the context of the L0/L1 
> discussion for the WDM technology-specific extensions of the TE tunnel 
> model
>
> For the units, we have agreed to use "kbits per second"
>
> We have just updated the -15 version of the draft addressing your comments
>
> Italo
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* venerdì 24 gennaio 2025 15:37
>
> Ciao Italo,
>
> Sorry for the delay. Snipping the resolved items, my responses are 
> below, as [JM].
>
> Thank you,
>
> Julien
>
> On 10/01/2025 22:12:28 Italo Busi 
> <Italo.Busi=[e-mail]> 
> <mailto:Italo.Busi=[e-mail]>, wrote:
>
> [...]
>
>     > - [Page 17] The te-bandwidth tries to give an example for WDM
>     which I really
>
>     > don't understand. I starts with the term "number", then uses it
>     as "index"
>
>     > ("slot 0") but why would anyone point to a slot when specifying
>     a bandwidth?
>
>     > Since spectral width is already defined in layer 0 types as
>     flexi-m, I believe we
>
>     > should keep WDM te-bandwidth in bytes/s and drop all the
>     WDM-related text
>
>     > (besides, I need an attribute to express the payload bandwidth
>     my WDM
>
>     > tunnels can carry).
>
>     [Italo]
>
>     As described in
>     https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang#section-5.3
>     <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang#section-5.3> there
>     is no need to define WDM technology-specific TE bandwidth information.
>
>     However:
>
>       * since this data type was already defined in RFC8776, changing
>         the semantic of its description could be an NBC change, if not
>         carefully considered
>       * I am not sure whether this data type (and the data nodes using
>         it) have been actually implemented, so NBC change may not be
>         an issue for existing implementations/deployments
>       * I am also not sure whether it will ever be implemented at all
>         instead of technology-specific augmentations, so I am not sure
>         how important is to fix this issue
>
>     I think we have few options (in order of my preference):
>
>      1. Just deprecate this data type (as well as the data nodes using
>         it) in favor of technology-specific augmentations (no
>         changes/fix to the current description): BC change
>      2. No changes
>      3. Fix the description, indicating that this data type is not
>         applicable to WDM (NBC change)
>      4. Fix the description, indicating that using this data type for
>         WDM (keeping the same description) has been deprecated (BC change)
>      5. Fix the description, indicating that this data type should not
>         be used for WDM, and deprecate this data type (as well as the
>         data nodes using it) in favor of technology-specific
>         augmentations (BC change)
>
>     IMHO, we better deprecate this data type (and associated data
>     nodes) in favor of technology-specific augmentations and, for
>     consistency, also the generalized TE label attributes.
>
>     What is your and TEAS WG opinion?
>
>     [\Italo]
>
> [JM] I'd clearly put option 2 ("No changes") at the bottom (5th) of my 
> prioritized list. I also believe the current description needs to be 
> fixed, which brings your option 1 at my 4th place. Then, I don't have 
> a strong opinion between your options 3 to 5, just a slight preference 
> for option 5.
> [JM] Your listed options leaves out a piece of my comment. In MPLS 
> cases, this attributes carries the payload bitrate and that info may 
> be also required for my WDM tunnels: does this need to be part of 
> WDM-specific augmentations? Do we consider that starting from a failed 
> definition in RFC 8776, it's better/easier to deprecated rather than 
> redefine? (which I can understand)
>
>
>     > - [p 43] On top restoration-scheme-presignaled and
>
>     > restoration-scheme-precomputed, I'don't understand what is
>     refered to by
>
>     > restoration-scheme-preconfigured. (Note that those terms aren't
>     used in the
>
>     > referenced RFC 4872.) Maybe we could consider deprecating it?
>
>     [Authors]
>
>     Our interpretation is the following:
>
>       * *precomputed* means that the recovery path is computed but not
>         signaled nor provisioned nor activated (i.e., commit resource
>         allocation at the data plane) prior to the failure
>       * *presignaled* means that the recovery path has been computed
>         and signaled but not provisioned nor activated (i.e., commit
>         resource allocation at the data plane) prior to the failure
>       * *preconfigured* means that the recovery path has been
>         computed, signaled, provisioned and activated
>         (cross-connections are created in the data plane) prior to the
>         failure
>
>     The pre-planned LSP rerouting, defined in RFC 4872, corresponds to
>     the presignaled case.
>
>     We would propose to:
>
>       * improve the description of the three cases;
>       * add note indicating that the presignaled case corresponds to
>         the pre-planned LSP rerouting (similar to the note in the
>         restoration-scheme-rerouting which corresponds to the Full LSP
>         Re-routing of RFC 8472)
>       * remove the reference to the other two cases
>
>     What is your and TEAS WG opinion?
>
>     [\Authors]
>
> [JM] It looks like your proposed set of clarifications would address 
> my concern.
>
>
>     > - [p 107] The short format for "kilobits per second" units
>     should use a lowercase K, i.e.
>
>     > "kbps".
>
>     [Italo] We will fix in the next draft update
>
>     What about following a consistent approach and use bits/second,
>     kilobits/second, megabits/second, gigabit/second and byte/second?
>
>     Otherwise we can define some convention and use consistently bps,
>     kbps, Mbps, Gbps and Bps.
>
>     What is your and TEAS WG opinion?
>
>     [\Italo]
>
> [JM] The full expansion avoids the issue. Otherwise, acronyms would do 
> it, provided we have consistency. AFAIR, k/M/G are international 
> conventions (while K is Kelvin), and B could be Byte... or Bel! ;-)
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.