As I see it:
1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without
Explicit Routing.
2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth-
sensitiveness;
Could be done by explicitly-routed /hop-by-hop routed merging
LSPs, starting from the egress.
Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)?
3) p2mp LSP (for Multicast): from source towards receivers, upon leaf
initiated join requests. Not even started.
4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means
the bi-directional LSP. Is not provided at all.
Could be done by explictly routed /hop-by-hop
routed LSPs starting from whichever
edge node towards all the other edge nodes.
None of the following is done:
H-1) p2p H-LSP: see draft-hummel-mpls-hierarchical-lsp-01.txt
H-2) mp2p H-LSP: see expired draft-hummel-ppvpn-tunnel-sequencing-00.txt
H-3) p2mp H-LSP: for VPN multicast on top of the partial mesh LSPs,no blind
traffic to non-interested receiver sites
H-4) mp2mp H-LSP: for VPN multicast on top of the partial mesh LSPs, blind
traffic is accepted
I think any protocol can be extended to provide all of it. Syntax is just
syntax.
The question is:
Is this or that extension against the basic philosphy of the particular
protocol ?
Does it make sense to come up with an explicit release procedure for let's say
mp2mp H-LSP within RSVP-TE, if
for some religious belief a similar procedure is out of discusion for p2p LSP ?
Another thing is: The MPLS Forum's UNI PVC is clearly based on CR-LDP, and has
been developped with the help of companies which are now against CR-LDP. Funny
but true.
I also believe that it is much much much better to work with just one protocol.
However, if some
extension is reasonable and valuable, it should not be rejected because of
reasons, which were used to
fight other protocols in former times.
A word about LDP:
IMO it may have some value as a routing=advertisement protocol. But for setting
up LSPs??? I only see one single
merge LSP per egress (there is no LSP-ID as to cater for more). However it
makes a lot of sense to explicitly establish merging LSPs starting from the
egress.
Heinrich
-----Ursprüngliche Nachricht-----
Von: Loa Andersson [mailto:loa.andersson@xxxxxxxxx]
Gesendet: Freitag, 26. Juli 2002 15:25
An: Hummel Heinrich; MPLS wg
Betreff: Re: AW: initiating a discussion on mpls singaling protocols
Heinrich,
this seems to show that cr-ldp and rsvp-te addresses one problem
space and ldp another. Though I it is possible to create mp2p
lsps with rsvp-te, just use the same spec and lsp's will merge.
But, and more important, since there is no big difference and only
one protocol is deployed, would that support the position on focusing
on one protocol?
/Loa
Hummel Heinrich wrote:
> Let me try to give an answer myself w.r.t my previously asked question by
> this following
>
> Table of current accomplishments:
>
>
> CR-LDP, RSVP-TE, LDP
> ------------------------------------------------------
> 1) p2p LSP yes yes N/A
> 2) p2mp LSP no no no (or N/A?)
> 3) mp2p LSP no no yes
> 4) mp2mp LSP no no no (or N/A?)
> 5) p2p H-LSP no no N/A
> 6) mp2p H-LSP no no N/A
> 7) p2mp H-LSP no no no (or N/A?)
> 8) mp2mp H-LSP no no no (or N/A?)
>
>
> I think we should take this table into consideration which may effect the
> ongoing CR-LDP versus RSVP-TE discussion
> in one way or the other:
>
> We may say: There are too many NO's as to make a pro/con CR-LDP decision
> already now.
>
> And also: For economical reasons, let's turn only one NO into a YES p e r
> l i n e - by future work.
>
> Heinrich
>
--
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office +46 8 5270 2000
Office direct +46 8 5270 5038
Mobile +46 70 848 5038
Email loa.andersson@xxxxxxxxx
WWW www.utfors.se
|
