Subject: RE: [L1vpn] Autodiscovery Protocol

From: "Drake, John E" <[email-masked]>
Date: Mon, 27 Mar 2006 12:37:16 -0800

Dimitri,

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

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. 

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.    

Thanks,

John
> -----Original Message-----
> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Monday, March 27, 2006 12:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [L1vpn] Autodiscovery Protocol
> 
> 
> 
> [email-masked] 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
> >>>[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

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 27 Mar 2006 23:10:46 +0200

john,

> 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

> 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

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