Works for me (and thanks for the suggested text). If I don't hear otherwise, I'll post an -05 version by tomorrow including Jim's suggestions.
Thanks, Frank > -----Original Message----- > From: Jim Guichard [mailto:[email protected]] > Sent: Thursday, July 07, 2011 6:54 AM > To: Paco Cortes > Cc: [email protected]; Frank Brockners (fbrockne) > Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 > > 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
