Agree with Adrian. The SAP seems to me to be the SDP simply places on the PE instead of the SDP.
", "time": "2022-11-08T13:38:45Z"}, {"author": "Dhruv Dhody", "text": "Unfortuanelyly opsawg SAP is per node in that draft (which we are currently referencing)
", "time": "2022-11-08T13:43:22Z"}, {"author": "Dhruv Dhody", "text": "https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/
", "time": "2022-11-08T13:43:50Z"}, {"author": "Mohamed Boucadair", "text": "To Danielle: The value of having peer-sap-id (which will be set to something that points to a CE/NF/etc.) is to ease request correlation, and thus, identification where to graft the service at the PE side
", "time": "2022-11-08T13:43:58Z"}, {"author": "Mohamed Boucadair", "text": "@Druv: there is a sap information grouping that can be used outside a node, if there is a need
", "time": "2022-11-08T13:45:16Z"}, {"author": "Dhruv Dhody", "text": "thanks Med!
\nanyways peer-sap-id is not bound to per PE (which is a good news for us)
Why is it called \"IETF Network Slice\"? Why not simply \"Network Slice\"? The former sounds like a slice reserved for IETF!
", "time": "2022-11-08T13:51:34Z"}, {"author": "Eduard V", "text": "to step aside from 3GPP Slice
", "time": "2022-11-08T13:52:10Z"}, {"author": "Mohamed Boucadair", "text": "Agree with Italo.
", "time": "2022-11-08T13:52:23Z"}, {"author": "Mohamed Boucadair", "text": "The technology-agnostic is not an argument here as we need technology specific for the AC part for example
", "time": "2022-11-08T13:54:53Z"}, {"author": "Kotikalapudi Sriram", "text": "Thanks, Eduard
", "time": "2022-11-08T13:57:15Z"}, {"author": "Italo Busi", "text": "I think that the technology-agnostic requirement needs some clarification
", "time": "2022-11-08T14:00:54Z"}, {"author": "Daniele Ceccarelli", "text": "@Med if the customer knows which are the available ports on the PE side, why can't them be considered the SDP of the NS? If on the other side the SDP is on the CE why does the customer care if port A or port B is used on the PE side?
", "time": "2022-11-08T14:01:03Z"}, {"author": "Italo Busi", "text": "As Med already mentioned, the AC configuration can only be technology-specific. And in fact, in the opaque attributes we are writing technology-specific information such as BGP or IP attributes
", "time": "2022-11-08T14:02:02Z"}, {"author": "Italo Busi", "text": "The only thing that can (and shall) be technology-agnostic is the technology used within the network to realize the network slice
", "time": "2022-11-08T14:02:35Z"}, {"author": "Lou Berger", "text": "vn-yang has an example of an alternate approch for handling technology specifics
", "time": "2022-11-08T14:03:24Z"}, {"author": "Adrian Farrel", "text": "On the SAP/SDP/AC debate, I find myself thinking that if the SDP is on the AC it is easy - everything is the same. If the SDP is in the PE, then there is the need to instruct the PE how to classify traffic into the SDP - this might be using the AC or some flowspec. If the SDP is in the CE then traffic is already in the slice when it reaches the PCE and (presumably) a slice identifier is used. Of course, in this latter case, the realisation of the slice (slice network model) might indicate a different AC used as traffic for different slices is carried from CE to PE.
", "time": "2022-11-08T14:12:09Z"}, {"author": "Adrian Farrel", "text": "Some of my concern may also come from puzzling over why the relationship of AC to SDP is n:1 and not n:m
", "time": "2022-11-08T14:12:46Z"}, {"author": "Adrian Farrel", "text": "But probably, to re-hash the L3SM/L3NM debate, we need to strongly understand the difference between a service level request and a service realisation
", "time": "2022-11-08T14:13:49Z"}, {"author": "John Scudder", "text": "can remote ppl hear the speaker?
", "time": "2022-11-08T14:20:02Z"}, {"author": "Ketan Talaulikar", "text": "no
", "time": "2022-11-08T14:20:12Z"}, {"author": "Tony Li", "text": "Thank you, much better.
", "time": "2022-11-08T14:20:31Z"}]