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

Reply via email to