Thanks Jim, now I get it. You were aiming at (outer label= SWID; inner label = CID), and I misunderstood it as (outer label = SWID, inner label = something_new; IP @ = CID). Speaking about "vanilla MPLS" I was actually expecting (only label = SWID; IP @ = CID)
It sounds sensible to me. But do you really want to restrict the vanilla MPLS case to (outer label = SWID, inner label = CID)? In such case, the user IP@ is pure overhead. Wouldn't it be better to cover both cases in one go? This could be done with a change like: - SWID is the top MPLS label. CID might be the next MPLS label in the stack, if present, or the AD's IP address. But don't take this email as an opposition to your last proposal to Frank. If nobody is interested on (single label=SWID, IP@=CID), then I will not be the one pushing for it. br, Paco 2011/7/7 Jim Guichard <[email protected]>: > Hi Paco, > > Comments inline .. > > On 7/7/11 3:39 AM, "Paco Cortes" <[email protected]> wrote: > >>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. > > Jim> yes, exactly this. In this case the SWID is the top label and the > next label in the stack is the CID. > >> >>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. > > Jim> let me clarify .. I completely agree that VPN should be included. My > overkill comment was more to do with the fact that in some situations it > is not necessary to deploy the full MPLS VPN machinery. >> >>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? > > Jim> I would like to see SWID = top label, CID = next label in stack > noting that the SWID label is not PHP. >> >>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
