[EMAIL PROTECTED] wrote:
o) time - depending on need's importance vs urgency, if dynamic PTI
tables population is to be there in a couple of month, or in
a couple of
years (would like to point out that understimating the time
it may take
to convince l1/trans networks to make use of BGP may be impacting)
I think I understand the timing issue, but what is the specific
'problem' with BGP in relation to L1 transport network? (with BGP being
used for the purpose of discovery)
afaik, there is no large "install base" as for IP/MPLS (L3VPN)
o) cost - can be seen both ways is there a need to have a single
protocol for LxVPN (x = 1, 2, 3) or is there a need to have a single
protocol for L1/TE operations ? so it depends whether operators are
looking for integrating their TE operations (including VPN or not) or
VPN operations (including TE or not);
Possibly both .. the same/similar protocols for VPN (L1,2,3..) and for
TE (L1,2,3..). I'm not the same protocols for VPN and TE is that
obvious, the applications are very different.
because there is a need to have some characterization of the CE-PE links
(in part. if dual homing like discussed during last L1VPN is going to be
part of the ref.architecture)
o) perf - concerning the protocol perf. we're discussing path vector vs
link-state protocol so impact/properties are different by nature but TE
processing overhead/impact would be worth investigated (note that this
depends on the problem statement e.g. what would be the impact of
progressively incorporating TE specific mechanisms for
L1(VPN) into BGP if such need is identifed ?)
How is L1VPN discovery related to TE (path computation?) these seem not
related to me.
this has been discussed during ietf63 also, having CPI-PPI information
delivers a set of reachable end-points only but the CE-PE links have TE
attributes like any other links that are to be taken into account by the
ingress PE for correctly route the request and reach (one out of the
possible) egress PE
If multiple solutions for L1VPN discovery are to be described within the
IETF, I agree with Julien that not all of them necessarily need to be
made standard.
possible but this was not the purpose of my message (as one solution is
more than certainly better than multiple) the real issue is that none of
the proposed approaches is going to be applicable without appropriate
extensions; so it is certainly of interest to have better understanding
of the real motivations behind
cheers,
Eduard
MEURIC Julien RD-CORE-LAN wrote:
Hi all.
Allow me to get back to the issue raised during the L1VPN meeting:
the autodiscovery protocol.
I think it is clear for everyone that BGP really fits the
job. Thus I
do not see why we would need to add an IGP to do less
things. Lots of
drawbacks were even pinpointed during the meeting: more flooding,
less scalability, no AS crossing, less flexibility (full
mesh)... but
no real advantage.
What is more, as Kireeti said, starting with 2 different
solutions is
likely to bring more problems than solve any. Since something needs
to be added, I am not sure that extending an IGP (or both if we do
not want to preclude any option...) will be easier/quicker
than using
BGP. And if, despite this, some consider it as a 1st step, then I
think we do not need to make it a standard.
So I am in favour of BGP autodiscovery, but BGP only.
Best regards,
Julien
_______________________________________________ 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
.
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
