Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
1397595
commit 0ff93ad
Showing
1 changed file
with
73 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| # YANG model for Optical Impairment aware Topology weekly call (April 20,2021) | ||
|
|
||
|
|
||
| ****Attendees**** | ||
| - [x] Dieter Beller | ||
| - [x] Aihua Guo | ||
| - [x] Esther Lerouzic | ||
| - [x] Julien Meuric | ||
| - [x] Italo Busi | ||
| - [ ] Gert Grammel | ||
| - [x] Gabriele Galimberti | ||
| - [ ] Yuji Tochio | ||
| - [x] Enrico Griseri | ||
| - [x] Sergio Belotti | ||
| - [ ] Victor Lopez | ||
| - [ ] Haomian Zheng | ||
| - [x] Igor Bryskin | ||
| - [ ] Brent Foster | ||
|
|
||
|
|
||
| ## Review of the minutes of the last call | ||
| ### Past Actions: | ||
|
|
||
|
|
||
| ### Github issues review | ||
| Issues #54,#58: These issues both require to move some identities defined in optical-impairment module to layer0-types-ext to make these usable also by other modules. | ||
| We agree to move these identities to layer0-types-ext. | ||
|
|
||
| AP @Sergio/@Italo: to move indentities related to these two issues to layer0-types-ext | ||
| Addressed with PR#25 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/pull/25 | ||
|
|
||
| AP @Esther/@Ahiua/@Dieter: to review PR#25 | ||
| #### Status: on-going | ||
|
|
||
| Issue #55 (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/55): remove transponder-attributes-grouping | ||
| AP @Dieter: to check again the grouping and see if the attributes is already covered by other grouping so that we can remove from our draft | ||
| #### Status: on-going | ||
|
|
||
| ### Discussion | ||
|
|
||
| #### It was restarted the discussion about how to model the 3R functionality.Issue #23 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/23 | ||
|
|
||
| Dieter summarized the basic options to provide 3R functionality in the presentation uploaded at | ||
| https://github.com/younglee-ietf/ietf-optical-impairment-yang/files/3657468/3R.configs.pptx | ||
|
|
||
| Italo observed that the unidirectional option, requires that the 2 OTs operated in unidirectional 3R mode have to be configured consistently. | ||
| This is not the case for the bidirectional option,in which any OT is used independently, dealing with both directions each. | ||
| 3R unidirectional case: tx and rx need to have two different transponder. | ||
| Gabriele highlighted some issues that can raise with both options, implying 2 different devices (OT): Automatic shutdown, ... | ||
| Italo said that,if OTs are in "integrated" architecture any issues can be solved and are implementation dependent. | ||
| In case OTs are outside of the single box, then the problem is more difficult. | ||
| In any case,from model propsective,Dieter said that what is needed is to have attributes in the model to make understandable the relation between OTs to provide 3R. | ||
| For example in bidir case client interface is closed in a loop,and the impossibility to use client port means the usage of the 2 OT as 3R, only. | ||
| Italo, mentioned also that a third architectural option could be to use single board to host the 3R function. | ||
| All agreed that 3R is a L0 function. | ||
| Gabriele mentioned that 3R is a L0 function apart if used as add/drop multiplexer at L1. | ||
|
|
||
| Italo summarized his own slides https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/5312928/3R-Modelling-03.pptx | ||
| to describe in more details 3R process and layering implications about tunnel setup | ||
|
|
||
| It is possible to model the 3R functionality as a L0 network service function, which can be modeled by augmenting the SF-aware topology: | ||
| https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-07 | ||
| Esther had questions about the port/direction identification in case of unidir 3R. | ||
| Today Transceivers only face one direction and datamodels have been set accordingly and Esther was not sure that this case can easily be supported. | ||
| Besides todays transpoder model does not differentiate emitter and transceiver, | ||
| so that the same "transponder" can contain both emission and reception info. | ||
| With unidir 3R, these are associated with different lightpaths. | ||
| Esther was not sure that current model supports that (one transponder id associated with 2 tunnel-termination-points). | ||
|
|
||
| AP@all: need to study how to model that, and which parameters/attributes are needed to describe OTs relationship in case the 2 OTs are used in 3R functionality | ||
|
|
||
| ### Next call | ||
| *April, 27th 2pm CET* |