Hi Jim, can you clarify with the upper case part of your proposal?
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. You are speaking about a fully different case than the "MPLS VPN" case currently in the draft, where the VPN label (i.e. the inner MPLS label) is the SWID. To me it sounds like a very significant change to gi-ds-lite, as you seem to be proposing that traffic inside a softwire can be further "split" into contexts with some meaning (differentiated handling?) by the AFTR. Regarding the overall discussion in this thread (sorry I didn't answer earlier), I disagree on the MPLS VPN case to be an overkill. In many cases, the one-label overhead in part of the path is fully justified by the gained operational simplicity (given by relaying on MP-BGP and possibly CE-PE protocol for "softwire" setup and control signalling). Also, as already mentioned by Yiu, it enables a very simple implementation of overlapping IP addresses. Although this could also be possible with your "vanilla MPLS" proposal, it would require some kind of additional (proprietary?) implementation both in Gateway and AFTR. This said, I do see the point on adding "vanilla MPLS" as possible embodiment to the draft. There may be simple scenarios where it is fully sufficient. Maybe adding a bullet to section 6 like: o IPv4/IPv6-in-MPLS: SWID is the MPLS label. Would this be ok for you? br, Paco 2011/7/6 Frank Brockners (fbrockne) <[email protected]>: > 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
