john,
The CE-PE link characteristics could be easily placed in a BGP based
auto-discovery design. (I think they were in the antecedent I-Ds.)
indeed, such parameters were initially considered & an auto-discovery
procedure should take such parameters into account
Further, due to scalability (#s of links) and frequency of updates, it
is not clear that the CE-PE links should be placed in the provider's
IGP. There is also the issue that you would need to modify the IGP
flooding procedures to advertise the CE->PE link characteristics, and
the issue that if you do all this, it still only works intra-AS.
that's one of the major issue - is there a need for an inter-AS solution
and by when - i don't have the answer to this question but on the other
side i don't also know the number of L1 networks that could accommodate
an IGP-based solution (at the sine qua non-condition that these flooding
procedures do not modify or introduce additional processing on ABR than
what's currently required)
note that in any case this information needs to be placed in the DB used
to perform path computation
Btw, the call procedures that we jointly worked on provide yet another
mechanism for obtaining CE-PE link characteristics, a pull rather than a
push, and they work inter-AS.
yes, but i assume that this approach will become beneficial when none of
the routing based approach would fit either the number of CE-PE links or
the diameter of the network would become so large that convergence time
would increasing blocking probability ... this said it is again a matter
of tradeoff (extended signaling vs extended routing mechanism)
Thanks,
John
-----Original Message-----
From: dimitri papadimitriou [mailto:[EMAIL PROTECTED]
Sent: Monday, March 27, 2006 12:17 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [L1vpn] Autodiscovery Protocol
[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
.
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
