Hi Frank, Reviewing version 04 of the draft I still do not see "vanilla" MPLS encapsulation given as an option. I would like to suggest adding something like the following to section 6:
o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within SWID may be indicated by the next MPLS label in the stack. On 3/28/11 1:17 PM, "Jim Guichard" <[email protected]> wrote: >Hi Frank, > >What I would like to see is the ability to use TE without VPN's. I do not >want to be forced to deploy VPN infrastructure in this case. RSVP-TE is an >important piece of the puzzle as it provides the ability to steer traffic >based upon policy that I may wish to enforce. I would be happy to supply >text for the draft but would like to agree on this alias before doing so >.. > >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" <[email protected]> >wrote: > >> >>Jim, >> >>why is VPN "overkill" (kind of delicate wording these days...)? TE could >>also be combined with MPLS VPNs. >> >>Would also be interested in other folks' thoughts on the need for >>"plain" IP-over-MPLS tunnels. >> >>Thanks, Frank >> >>> -----Original Message----- >>> From: Jim Guichard [mailto:[email protected]] >>> Sent: Friday, March 25, 2011 8:03 PM >>> To: Frank Brockners (fbrockne) >>> Cc: [email protected] >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>> >>> VPN is overkill imho plus i want the ability to engineer traffic paths >>> and for this i need TE >>> >>> Jim Guichard >>> >>> Principal Networking Architect >>> IPG CTO Office >>> Juniper Networks >>> >>> CCIE #2069 >>> >>> Sent from my iphone >>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>> <[email protected]> wrote: >>> >>> > 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. >>> > >>> > Hence the question: For the use cases you have in mind, couldn't we >>> just >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in a >>> VPN - >>> > Gateway and the AFTR)? Personally I've nothing against additional >>> > encapsulations, though so far there's always been a push in the WG >>> (and >>> > also in 3GPP SA2) to keep the number of encapsulations to a minimum >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we could >>do >>> > the very same thing with GRE). >>> > >>> > 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. >>> > >>> > Thanks, Frank >>> > >>> >> -----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
