The MPLS WG Archive

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

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@utfors.se]
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@utfors.se
     WWW             www.utfors.se