Hi Jim, ... works for me (any additional opinions from others?).
In order to get a -05 version out quickly, could you detail the change - i.e. possibly expand the bullet you propose below with some additional explanation, like e.g. what would be used as CID for "vanilla MPLS"; propose another row for the table in section 6; etc. Once we have this, we could quickly compile a -05. Thanks, Frank > -----Original Message----- > From: Jim Guichard [mailto:[email protected]] > Sent: Wednesday, July 06, 2011 6:24 AM > To: Jim Guichard; Frank Brockners (fbrockne) > Cc: [email protected] > Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 > > 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
