Dataplane, and yes, the issues (and benefits) would be the same as with STT Need to look into the details of SCTP, as it is a streaming protocol, it might perform better.
One thing that I forgot to mention is about backup traffic, VM mobility and heartbeat cluster traffic. These applications are performed on the private network and by using BCP for SAN you have two fabrics for the private network (DCB enabled). With a singlepath transport protocol I have to choose either fabric A or B for the backup traffic, heartbeat etc, in order to keep the air gap between the fabrics. With multipath support these applications could use both fabrics concurrently. Patrick On Fri, Sep 7, 2012 at 9:46 PM, Ivan Pepelnjak <[email protected]> wrote: > Are you talking about control or data plane? Data plane has to run over a > datagram service or you're back to the TCP-over-SSH type of problems (not to > mention performance issues). > > ===== > Mistyped and autocorrected on a clunky virtual keyboard > > On 7. sep. 2012, at 20:09, Patrick Frejborg <[email protected]> wrote: > >> Ivan, >> >> I have been following this discussion for a while, think we could >> avoid having IGP on the NVE in the hypervisor by changing the >> transport protocol to a multipath enabled one such as SCTP/MPTCP. >> >> By doing that no need to have an IGP/BGP on the NVE and you can >> aggregate NVE IP addresses at the underlying network because the >> multpath transport protocol would take care of liveness problem. If a >> multi-homed NVE (e.g. two NICs to two separate ToRs) knows the remote >> NVEs locators (two Nics, two ToRs) the multi-path protocol has the >> possible to setup four paths to the remote NVE (Local locator >> 1->Remote Locator1, LL1-RL2, LL2->RL1 and LL2->RL2). The consequences >> of this is that some of the traffic engineering is moved away from the >> network to transport protocol, check out this study >> http://www-malted.cs.ucl.ac.uk/staff/M.Handley/papers/multipath_dc_hotnets.pdf >> >> The demarcation point between the hypervisor based NVE and the ToR >> becomes simple, i.e. IP subnets and the underlying network doesn't >> need to exchange much information to the NVE. >> >> And when we get to the storage part we can maintain the air gap >> between the two fabrics by leveraging SCTP/MPTCP - I'm thinking of >> lossless iSCSI here and if the storage target supports multipath >> transport protocol we can build SANs as we do today and maintain the >> best practices. >> >> Think it would be worthwhile to have a look on what SCTP/MPTCP can >> offer, it seems that they might simplify things quite a lot. >> >> Patrick >> >> On Fri, Sep 7, 2012 at 8:23 PM, Ivan Pepelnjak <[email protected]> wrote: >>> On 9/7/12 6:23 PM, Lucy yong wrote: >>> [...] >>>> >>>> To use MPLS/VPN, you have a IGP network as underlay network first. If >>>> NVE acts as PE. The server need to participate IGP first, the >>>> loopback address of server is advertised in IGP. It does not matter >>>> how many nics exist, the ecmp make it work. >>> >>> >>> Ah, that's how it works. Thank you! Now I get it. >>> >>>> If the server does not run IGP protocol and act as a IP host in >>>> underlay network. This seems not aligning with the nvo3 framework and >>>> MPLS/VPN architecture. >>> >>> >>> Then I sincerely apologize for wasting everyone's time and bandwidth. >>> >>> Thank you for your guidance, >>> Ivan >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
