Hi Vishwas,
Was it your intent to fully incorporated the changes we discussed into
the -01 rev? If so, I think some were missed (and I can send which in
a separate message.)
Thanks,
Lou
On 11/24/2012 12:21 PM, Vishwas Manral wrote:
> Hi WG-participants,
>
> As its been a week and I have not heard any objections, I will update
> this requirement and post the draft across.
>
> Thanks,
> Vishwas
> On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral <[email protected]
> <mailto:[email protected]>> wrote:
>
> Thanks Lou,
>
> Let me heard back from the WG on this, if they have any opinion. If
> not we can go ahead with your suggestion.
>
> -Vishwas
>
>
> On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <[email protected]
> <mailto:[email protected]>> wrote:
>
> Vishwas,
>
> On 11/16/2012 1:48 PM, Vishwas Manral wrote:
> > Hi Lou,
> >
> > Got it. Can you suggest some text for this? I will try to
> incorporate
> > the same into the document.
>
> Assuming you don't like my prior attempt:
> X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].
>
> How about something like:
> X. The solution MUST support Provider Edge (PE) based VPNs.
>
> Note that this phrasing doesn't indicate a specific solutions
> which is
> why I now suggest "MUST" vs "SHOULD".
>
> Lou
>
> >
> > Thanks,
> > Vishwas
> >
> > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> > Vishwas,
> > Sure, but it's the BGP information that indicates
> what IPsec
> > tunnels
> > are needed / when the SAs get established...
> >
> > Again, I just asking for language that points to this use
> case, not
> > implementation details.
> >
> > Thanks,
> > Lou
> >
> > On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> > > Hi Lou,
> > >
> > >> I'm not sure I agree with this statement. Let's say
> you have
> > >> a BGP VPN that uses IPsec tunnels between the PEs (which
> > >> was described in a couple of expired drafts and can be
> supported
> > >> using RFC5566), and then wants to be able to use dynamic PE
> > >> to PE IPsec tunnels. Does this fit your "2 different
> layer"
> > >> perspective?
> > > IPsec with ADVPN secures the tunnel and creates the mesh
> underlay on
> > > need basis/ or automatically. L3VPN creates the overlay,
> > identifies the
> > > tenant/ customer a packet belongs to and passes the
> packet on.
> > >
> > > Where do we see the need for tighter integration here?
> Is it allowing
> > > the ability to create groups of ADVPN instances?
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>> wrote:
> > >
> > > Vishwas,
> > >
> > > Please see below.
> > >
> > > On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> > > > Hi Lou,
> > > >
> > > > Thanks for the quick reply. Just a few comments
> prefixed
> > with a "VM>":
> > > >
> > > > >
> > > > > We can add something in the lines of
> additional protocols
> > > are run over
> > > > > the IPsec tunnels and the solution should
> make an
> > effort to
> > > allow for
> > > > > additional protocols like OSPF to be run
> optimally without
> > > too many
> > > > > changes in configuration.
> > > > >
> > > > > Infact we have a requirement to the effect
> in section 4.1
> > > >
> > > > yes, this is what I referred to as 4.2 below, and
> > suggested some
> > > > replacement text...
> > > >
> > > > OK got it.
> > > >
> > > > >
> > > > > Gateways MUST allow tunnel binding, such
> that
> > > applications like
> > > > > Routing using the tunnels can work seamlessly
> > without any
> > > > updates to
> > > > > the higher level application
> configuration i.e. OSPF
> > > > configuration.
> > > > >
> > > > > - In section 4.2, how about:
> > > > > (replacement text)
> > > > > 3. Gateways MUST allow for the
> operation of
> > > tunneling and
> > > > > routing protocols operating over
> spoke-to-spoke
> > IPsec
> > > Tunnels
> > > > > with minimal, or no, configuration
> impact.
> > > >
> > > > VM> Ok will specifically specify tunnels and
> routing protocols.
> > > >
> > >
> > > Great.
> > >
> > > >
> > > > >
> > > > >
> > > > > X. The solution SHOULD support
> BGP/MPLS IP
> > VPNs, see
> > > > [RFC4364].
> > > > >
> > > > > If you want, you can make the "SHOULD" a
> "MUST", and
> > > "support"
> > > > could be
> > > > > "be compatible with".
> > > > >
> > > > > I do not want to go ahead into details of
> what other
> > routing
> > > solutions
> > > > > it should support.
> > > > >
> > > > > With that said I am not sure what you mean
> by having BGP
> > > MPLS VPN
> > > > in an
> > > > > ADVPN scenario. BGP MPLS VPN is a provider
> provisioned VPN
> > > solution,
> > > > > this is a customer provisioned one.
> > > >
> > > > Ahh, interesting point. When I read the
> document I was
> > > looking to see
> > > > if it was scoped purely to CE/customer based
> solutions.
> > > Reading section
> > > > 2 (intro) and 2.2, I saw no such restriction.
> So I think
> > > section 2.2
> > > > should be explicit on this point either way.
> Which is why I
> > > proposed the
> > > > text "There is also the case when L3VPNs
> operate over IPsec
> > > Tunnels."
> > > > (To explicitly include this case.) If the WG
> wants this
> > case
> > > excluded,
> > > > that's fine too.
> > > >
> > > > VM> It is not scoped purely as a CE device
> scenario, and
> > after seeing
> > > > your comment I see no reason to leave that out of
> scope
> > (though if I
> > > > understand your concern better I may feel
> otherwise). L3VPN
> > can work
> > > > over GRE tunnels/ L2TP tunnels, which can
> themselves use IPsec.
> > > Again in
> > > > my view the L3VPN and the IPsec VPN are 2
> different layers
> > in the
> > > stack
> > > > if they run on the same device.
> > >
> > > I'm not sure I agree with this statement. Let's say
> you have
> > a BGP VPN
> > > that uses IPsec tunnels between the PEs (which was
> described
> > in a couple
> > > of expired drafts and can be supported using
> RFC5566), and
> > then wants to
> > > be able to use dynamic PE to PE IPsec tunnels. Does
> this fit
> > your "2
> > > different layer" perspective?
> > >
> > > Either way, I think such usage should be explicitly
> in scope
> > as it is a
> > > very different model / use case from CE-based IPsec
> VPNs.
> > >
> > > > Do you see a reason to explicitly
> > > > mention L3VPN in this case?
> > >
> > > I'm open to different ways to cover the above.
> > >
> > > Much thanks,
> > > Lou
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > >
> > > >
> > > > > I see the 2 working in different
> > > > > layers, and interacting only in edge
> gateways where both
> > > solutions
> > > > have
> > > > > an edge.
> > > >
> > > > Sure, but the problem exists for both.
> > > >
> > > > Thanks,
> > > > Lou
> > > > >
> > > > >
> > > > > I also have a few more minor comments:
> > > > >
> > > > > I am ok with the minor suggestions you have.
> > > > >
> > > > > Thanks,
> > > > > Vishwas
> > > > >
> > > > >
> > > > >
> > > > > - In section 2.1, you introduce the term
> "NAT
> > gateway" and
> > > > then later
> > > > > use just "gateway" when I suspect you
> mean "NAT
> > gateway". I
> > > > suggest
> > > > > using the term "NAT" and thereby not
> introduce
> > possible
> > > confusion
> > > > > between the gateway term defined in
> section 1.1
> > and "NAT
> > > > gateways".
> > > > >
> > > > > - In section 2.2, s/occupies/requires
> > > > >
> > > > > - In sections 2.2, and Section 3.2 you
> say dynamic
> > > addresses makes
> > > > > static configuration impossible. This
> doesn't reflect
> > > the use of
> > > > > dynamic dns to handle this issues (and
> is currently
> > > supported
> > > > by some
> > > > > vendors.)
> > > > >
> > > > > Let me know what you think,
> > > > > Lou
> > > > >
> _______________________________________________
> > > > > IPsec mailing list
> > > > > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
> > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > > > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>>
> > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
