CCAMP @ IETF 124
Pavan (TEAS WG chair): [commenting about dependencies of CCAMP drafts
with the TE YANG] TE YANG and TE Types update document both have been
submitted to publication. Those two should be enough to progress these
documents.
Ketan (Routing AD, from Zulip): Optical impairment is in IETF LC ...
Ending on Monday. Going to IESG soon after.
[generic recommendation, not only for this draft]
Daniele: we usually tend to add a lot of contributors to the
document to acknoledge their input. Please avoid putting too many
contributors, otherwise it would cause an high effort to chase them
for IPR polling.
Ketan: I have just shared on the chat an IESG statement:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-addressing-comments-and-crediting-contributions/
Aihua/Daniele: this draft is the result of the merge of many
documents which reulted in a long list of contributors
Aihua: we can discuss and see if we can clean-up the list
[discussion]
Daniele: in slide 3, you speak about dependencies. Both the WDM path
computation and the pluggable work can have an impact on this draft.
Italo: One clarification, it is the WDM path computation taht depends on
this draft. This draft depends only on TE tunnel for which publication
has just been requested. The WDM tunnel depends from this draft and the
TE path computation draft, for wich publication will be requested soon
Italo: regarding the pluggable gaps, we can follow the same approach
done for optical impairments and interface and progress indidependently.
We can also be opportunistic. If a gap is identified when the draft is
open, we can address it. Otherwise, if a gap is identified after the
document is done, we can plan for a -bis
Hoping that in the meahwhile a more lightweight process for -bis is
established
Daniele: we may need to develop some -bis documents
Reza: We had a long discussion on the mailing list in the last couple of
weeks.
The important aspect is what problem we are addressing which is exactly
what we have started in the pluggable drafts being able to plug a
pluggable model from vendor A into an host of vendor B.
The suggestion is to put effort on the current two drafts on pluggable.
The problem of how to handle opaque attributes (like the custom page) is
a valid issue and we can address that after we have completed the gap
analysis.
Shunsuke: I understand and hope to contribute to the work from carrier's
aspects.
Daniele: the first issue is whether the WG is willing to work on CMIS
but I have seen some objections on the mailing list.
Roberto: In reality this draft is proposing to send binary data directly
to the pluggable. Even if done throught the NOS, the NOS has no
visibility on what the data it is passing through is doing.
It is not also clear how this is solving the problem of white box
implementations.
There are a lot of registers in standard pages that are clearly RW or
RO. If we allow the
Shunsuke: It will be hard to make open source, such as SONiC, support
various DCO transceivers. New transceivers such as 800G or over 1T are
released and need to lead open source community to support them. It's
hard and may take long time.
Daniele: My doubt is to have a standard solution to configure something
that is not standard
Fatai: I agree with Reza that CMIS-based. For CCAMP perspective we
usually define control plane technologies for data plane technologies
defined by ITU-T, expecially SG15. SG15 has agreed in October to start a
new project on similar things as CMIS so we can wait a while to wait to
see what happens in ITU-T.
Swamy: Problem statement valid, but I do not believe that a pluggable
can be configured transparently from the Host OS. Custom capabilities
should be handled in a more abstract, not tight to.
Nigel: Support to the comments made on custom page handling and
proprietary properties. They should be presented in an appropriate
abstract way way via standard Yang and not exposing CMIS in the detail.
Italo: I agree with Nigel. The problem statement is valid. WDM is a
cutting-edge technology so the standard is inherenthly behind the
capabilities available in the marked.
Without a solution to this problem plugging a vendor A module into a
vendor B host will result is lower capabilities than those available in
the market.
There are valid concerns on the proposal of exposing CMIS custom page in
YANG, so a better solution should be found.
I understand this is not an easy work but it has to be done.
Roberto: From an host perspective, there will be pluggable from multiple
vendors, so it is quite hard to allow multiple controllers controlling
different pluggables.
However, I agree this is an issue to be addressed.
Fatai: It would be good to invite some operators to review and
contribute this work, especially those active in ITU-T SG15 Q14.
Bin Yeong: I missed to add some names from the Korean major operator and
three three other operators.
Poll: Is this a topic the WG is interested to work on?
Result:
| Yes: 12 | No: 1 | No opinion: 0 |
Daniele: we will check with the mailing list
Daniele: I understand your use case is quite specific for optical
network but I still struggle why you wish to be so specific instead of
having an unified compute and network orchestrator which can connect to
an IP controller or to an MDSC controlling an IP+Optical network
In other words: can this scenario be generalized to cover broader
scenarios?
Stephen: I agree that the problem statement is not generic enough.
The general problem is how to manage a collection of network, compute
and storage. There is also a memory aspect as well, not only GPU. There
are three ways to manage a bit: compute, store or transfer.
Having an optical network is one way to transfer bits but there are
other ways to transfer bits.
Adrian (as CAT co-chair): I would be interested to see how this picture
fits with the CAT architecture which is entering WG LC.
If the CAT architecture does not fit for optical networks, this is the
right time to raise a comment. Afterwards, it will be too late.
Daniele: I see CATS was mentioned so it seems that the relationship with
CATS work has been taken into account.
Adrian: There is a piece which is missig in CATS, which is provisioning
paths. In CATS we are selecting existing paths while here it is possible
also to provision paths.
Update on the proposed new charter, waiting for feedback.
Links: