Hi Jim, > >fully agreed that MPLS should not be absent from the draft, and it is >not. The current draft-ietf-softwire-gateway-init-ds-list-03 doesn't >restrict things to IP tunneling. The draft already allows for MPLS >transport between Gateway and AFTR using MPLS VPNs.
For the simple MPLS case w/o VPN, it will limit the GW not to be able to serve overlapped address space. > > >On multicast: Don't fully follow your thought below. Do you consider >running multicast over the softwire between AFTR and Gateway? The >multicast considerations for GI-DS-lite (see >draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that this >would not be the case. > I agree with Frank. Multicast in gi-ds-lite should be simple and not tied to p2mp mpls. Our proposal is very simple. Our assumption is that the operator should have far fewer gateways than customer devices, so the GW can create an IPv4 over ANY tunnel and run multicast on it. From the GW, it could do RFC 4541. /Yiu > > >> -----Original Message----- >> From: Jim Guichard [mailto:[email protected]] >> Sent: Thursday, March 24, 2011 9:43 PM >> >> Hi Frank, >> >> bi-directional tunnels are necessary if you wish for traffic flows to >> take >> the same path in both directions across the network. It is possible to >> use >> point-to-point but this is cumbersome to deploy. Point-to-multipoint >> may >> be necessary for multicast. >> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that should >> not >> be absent from the draft. If an operator has MPLS why restrict them to >> IP >> tunneling? >> >> >> > >> >to kick-start the discussion, could you outline the usage scenarios >> that >> >would drive the requirements you mention below? >> > > >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
