Hi Frank, Suggested changes as follows:
Section 5: - first bullet currently states "The softwire between the Gateway and the AFTR is created at system startup time and stays up active all time". I would like to allow flexibility to initiate a SW at any point in time. Given this could this bullet be changed to the following: "The softwire between the Gateway and the AFTR MAY be created at system startup time OR dynamically established on-demand" 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. The AFTR may use the CID locally to identify context within a given inbound softwire. On 7/6/11 10:59 AM, "Frank Brockners (fbrockne)" <[email protected]> wrote: >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
