I've always thought adding a switch was a non-disruptive activity. You have VSAN 10 on a core switch. You add that same VSAN to an edge switch and give it a different DID from the one that is randomly assigned and make it static (mostly for documentation so you know which DID's are being used where, I know changing it to static is non-disruptive.)
That DID change is what has me worried. Wouldn't the VSAN then have to be restarted? Is it only the edge switch version of VSAN 10? The VSAN gets segmented while they figure out who's who but then you go and change the DID on the local VSAN. I'm thinking since it (the DID change) should only affect ports on the edge switch (which at the time of creation there are none.) BTW we're running 3.3.(1c) of SAN-OS.
If you set the edge switch VSAN 10 to a DID that is not used in VSAN 10 at the core, or anywhere else in VSAn 10, before bringing up the ISL, then the connection would be non-disruptive. The switches would do a build fabric (BF) which is basically a merging of the DIDs used between the 2 fabrics. If there is a DID overlap, then the standard provides for a reconfigure fabric (RCF) which is disruptive. The MDS by default will not accept an RCF...it will fail to merge and leave the fabrics isolated as to not cause a traffic disruption.
If you do change a DID on the VSAN, and it is not the same as the one that was assigned, you would need to issue a disruptive VSAN restart and it would logout the devices that are logged into that switch. If you are simply making an assigned DID static, that can be accomplished with a non-disruptive VSAN restart which would not cause the devices to log out.
The key is to get the DIDs unique and static before bringing up the ISL between the 2 switches. For a TE port, this applies to any VSAN that is using the trunk.
Hope this helps,