I think the other necessary change is for section 5. Could you agree to change the 1st bullet to allow for dynamic establishment of softwires? It seems restrictive to mandate that they be pre-established.
Jim Guichard Principal Networking Architect IPG CTO Office Juniper Networks CCIE #2069 Sent from my iphone On Jul 8, 2011, at 4:49, "Paco Cortes" <[email protected]> wrote: > Hi Yiu, > > I believe that the conclusion of the discussion between Jim and me is > that the following bullet should be added to section 6: > > o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID might be the next MPLS > label in the stack, if present, or the AD's IP address. > > What do you think of it? > In your suggested text, I find the usage of the term "context" > confusing. It is already well defined in the draft what a CID is. > And the text "if the AFTR is the last hop of the LSP" is redundant, isn't it? > > br, > Paco > > > 2011/7/7 Lee, Yiu <[email protected]>: >> Hi Frank, >> >> Did Jim and Paco metnion to also allow IP for the CID? So, I suggest to >> modify Section 6: >> >> Section 6: >> >> - add the following bullet: >> o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS >> label in the stack or IPv4 address if the AFTR is the last hop of the LSP. >> The AFTR may use the CID locally to identify context within a given >> inbound softwire. >> >> >> >> On 7/7/11 5:52 PM, "Frank Brockners (fbrockne)" <[email protected]> wrote: >> >>> >>> 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 >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
