Subject: RE: [L1vpn] Autodiscovery Protocol

From: <[email-masked]>
Date: Mon, 27 Mar 2006 20:25:10 +0200

> 
> 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)

> 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.

> 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.

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. 

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 
> > [email-masked] https://www1.ietf.org/mailman/listinfo/l1vpn
> > 
> > .
> > 
> 
> _______________________________________________
> L1vpn mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l1vpn
> 

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 27 Mar 2006 22:16:47 +0200

> used for the purpose of discovery)

afaik, there is no large "install base" as for IP/MPLS (L3VPN)

> 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 
>>L1(VPN) into BGP if such need is identifed ?) 
> 

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

> IETF, I agree with Julien that not all of them necessarily need to be

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