Closed aguoietf closed 1 year ago
It seems that the intension for customized topology is not clearly described in the ns-topo document. Need to clean up the document to state that the customized topology is defined by the customer and is not for internal mapping purposes.
The current SAP model defines a list of SAPs that pre-exist before network slice creation and are exposed to customer. So it does not look like a topology and it is unclear what Med means about the "SAP topology".
Action Items:
draft responses are available at : https://demo.hedgedoc.org/-SB65MyqSFCldWRTkVR_Kg
Responses posted to teas mailing list: https://mailarchive.ietf.org/arch/msg/teas/0GG7t9GmlBkIDQE9mp11ErYIvug/
https://mailarchive.ietf.org/arch/msg/teas/O9y1pQ6BOGqQqKztKHxn5o9nnl8/
Hi Authors,
Thank you for writing this document.
The document claims that this model is exposed to customers, while this is not justified. At least, the current text fails to motivate such a use. It is true that an NSC can use a customized topology for mapping purposes, but this is kept internal to the NSC and not exposed to a customer.
Also, a network topology for slicing is readily available by setting the network type in draft-ietf-opsawg-sap to “network-slice”. I would expect to build missing pieces over the SAP topo rather than the current model in the draft. The draft should discuss why it is not sufficient to use the SAP topology.
FWIW, a more detailed review can be found at:
pdf: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-liu-teas-transport-network-slice-yang-06-rev%20Med.pdf doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-liu-teas-transport-network-slice-yang-06-rev%20Med.doc
Cheers, Med