aguoietf / ietf-network-slice-topology

0 stars 1 forks source link

Respond to Med's comments on ns-topo #9

Closed aguoietf closed 1 year ago

aguoietf commented 1 year ago

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

aguoietf commented 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:

aguoietf commented 1 year ago

draft responses are available at : https://demo.hedgedoc.org/-SB65MyqSFCldWRTkVR_Kg

aguoietf commented 1 year ago

Responses posted to teas mailing list: https://mailarchive.ietf.org/arch/msg/teas/0GG7t9GmlBkIDQE9mp11ErYIvug/