The MPLS WG Archive

[Loa Andersson <loa.andersson@utfors.se>]

Heinrich,

see inline

Hummel Heinrich wrote:

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


If you have a the same spec's this is a request to merge, in fact you
have to make sure that you don't have the same spec's if you don't
want to merge. Maybe one of the rsvp-te authors could correct me if
i'm wrong. in some scenarios life would be easier if i were ;)


>                    
> 3) p2mp    LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started.


there were a multicast proposal in yokohama, we said that it was
premature to have an opinion on that, since the multicast fw were
just through the iesg review and that we need a discussion on how
much of this we want to do.
there is alos early work on mpls  multicast based on ldp (not cr-ldp)

/Loa


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