Yes, I agree that this change makes sense and provides more flexibility .. thanks
On 7/7/11 9:48 AM, "Paco Cortes" <[email protected]> wrote: >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
