[EMAIL PROTECTED] wrote:
acee - one specific question from my side then
it seems you do not want to consider auto-mesh of tunnels, why is this
specific to IPSEC
because there is a draft called <draft-ietf-ccamp-automesh-01.txt> that
does the same
kind of discovery process but for MPLS tunnels ?
ps: that draft has also a group number ID and end-name ... where is the
difference ?
Dimitri,
I do think TE is a far different application than VPN. For one thing, I
view the
TE tunnels as part of the intra-domain topology. Accepting this premise,
TE tunnels
themselves are part of the same control plane as the IGP. Additionally, it
is more likely that the volume of TE information is bounded by the size
of the routing domain. Conversely, VPNs represent the services provided
external
to the routing domain of the IGP and the amount of VPN information is
not at all
bounded by the routing domain.
As for the mesh groups, I've been assured that a given router will be
part of one
or a "small" number of mesh groups :^).
Thanks,
Acee
Acee Lindem <[EMAIL PROTECTED]>
11/05/2006 22:40
To:
cc: [EMAIL PROTECTED], Rohit Dube <[EMAIL PROTECTED]>
Subject: Re: [L1vpn] Issues and concerns about Basic Mode
OSPF Discovery
See one clarification below:
Acee Lindem wrote:
Hi Lou,
Lou Berger wrote:
Hi Acee,
Thanks for the response, see below.
At 12:22 PM 5/10/2006, Acee Lindem wrote:
[...]
More seriously, if there's a technical point here can someone help
me find it.
For L2VPN and L3VPN the job of dissemination and discovery has been
done
in iBGP since it lends itself very nicely to limiting the scope of
the information
to the PE that need. With the proposal of using opaque AS LSAs,
every router
in the OSPF routing domain must receive the L1VPN information.
correct. But keep in mind that the context of operation is a L1
transport network, who's sole purpose is to support delivery of
transport services. The scale of these networks, and the number of
total routes carried, is radically different than in the general IP
network case where L2 and L3VPNs operate. Also, most (actually, I
think it is all) of these L1 networks do not run BGP and have no
intention of running BGP. Furthermore, the sole purpose for running
BGP would be to support L1VPNs. BGP isn't something that is already
present to be leveraged.
so, for the time being (say 3-5 years) the choices are:
(a) no solution
(b) a proprietary solution
(c) a standardized OSPF solution
The plan of the WG, as I understand it, is to work on both a BGP and
OPSF solution and then (possibly based on an implementation survey)
decide if both should move forward to PS.
I guess maybe I don't fully understand the L1VPN requirements.
Are you saying an SP offerring L2 and L3 VPN services would not want
to offer
L1 services as well? It seems that you're saying that the environment
is similiar to a
control plane for a SONET network - correct? I also thought these type
of networks
were heavily dependent on the provisioning system anyway.
What would you suggest as a way forward?
I think the experimental realm is where this belongs if it is done in
OSPF at all.
Additionally, heretofore, we've avoided making OSPF a generalized
transport
mechanism for flooding information. Before we'd take such a
direction, you'd need to
convince the OSPF WG that this is a prudent direction. IMHO, this
probably
isn't going to happen.
huh??? That horse escaped the barn with RFC2370. To quote "The
information field may be used directly by OSPF or by other
applications." Certainly TE, rfc3630, also falls into the category
of using OSPF as a generalized transport mechanism.
I know Igor made this point as well so I'll both of you here. TE was
the first opaque LSA application. The tunnels provided are internal
to the routing domain (yeah I know inter-AS TE has been proposed).
Potentially, every router in the area will need to advertise and
maintain
a TE database. This is not the case with VPNS where only PEs that
are endpoints for a common VPN need to share the information.
We've rejected other attempts to put dynamic discovery into the IGPs
(e.g.,
IPSec tunnels). I don't see why we should reverse this position now.
For those of you who don't remember, there was a proposal similar to
this one
to use OSPF opaque LSAs to advertise IPSec tunnel group IDs and endpoint
addresses and similarly self-configure one or more meshes of IPSec
tunnels
between PEs.
Acee
If there are more discussion points that I have dropped, please
feel free to raise them as well.
I guess the lack of response speaks volumes.
Thanks,
Adrian
BTW, I really don't like the "dark smoky-room" approach being taken
here. If a WG participant/AD/etc. has an issue, then they should
raise it themselves and not ask the WG chair to do it for them. If
they don't care enough to raise it themselves, then IMO we, the WG,
shouldn't waste our time on it!
Better that Adrian solicted input from the OSPF WG than have you
wait for this to be
rejected by the OSPF WG at a later IETF. Your L1VPN solution hasn't
been
presented to OSPF WG or even posted to the OSPF WG list. Lest you
make the
same mistake twice, I suggest you socialize the IDR WG (where this
application
belongs) early on in the process.
Thanks - I wasn't aware that other people concerns had been raised
through Adrian.
Acee
Acee
My apologies, this comment was *not* directed at the OSPF WG chairs.
I think it *is* appropriate for one WG chair to consult with another
WG chair and report back to the WG on that conversation. I also
think it appropriate for the other WG chair to chime in on the
follow-up discussion as you have thankfully done. My comment was
really directed at the comments by other L1VPN WG member's that where
represented in Adrian's mail.
Much thanks,
Lou
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
