The MPLS WG Archive

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

Loa,
Quite some time ago (in Oslo)I presented a solution how to provide explicit routing information w.r.t. a tree route
and I would be pleased to revive this work if it is oked.

By chance, it was using CR-LDP syntax and not RSVP-TE syntax, but this can be changed.BTW: I neither like the message
names PATH/RESERVE nor LABEL_REQUEST/LABEL_MAPPING but rather LSP_SETUP/LSP_SETUP_ACK.But this is my humble opinion only. 

It started with a simple algorithm which inversed the Dijkstra tree representation (where each node points to another
node one hop closer to the root) to a sequence of "("- TLVs, ")"-TLVs and ER-TLVs, where the bracket-TLVs shaped the tree and where the ER-TLVs represented non-branching sections within the tree.

The over-all "TREE ROUTE TLV" might also contain   new Node-Info-TLVs,which, properly positioned, would carry specific information (like FEC) to the right individual nodes on the tree.And finally,by pairs of (new) Nodes-Info-Begin-TLV and Nodes-Info-End-TLV specific information could be sent to clusters of nodes within the tree, e.g. how much bandwidth shall be reserved by each node for the respective links of some non-branching section of a merging LSP.

I also showed how each node must handle the received "TREE ROUTE TLV", as to recognize what information it has to
evaluate by itself, and which part of the received TLV has to be forwarded along which child-link.

The handling of this TREE ROUTE TLV, would be beneficial to
mp2p- LSPs, mp2mp- LSPs and  p2mp-LSPs,  be they elementary LSPs or Hierarchical LSPs.
 
In all these cases, the message would start at some root node and progress towards multiple leaf nodes.
It is just this simple, and to hell with discussion "what is hereby DoD versus DU" :-)
 
Needless to say: If the initial Dijkstra tree had been sensitive to QoS/Bandwidth-availability/Policy, then the inverse
representation,i.e. the TREE ROUTE TLV representation would be as well.

Loa, if you ok  so, I can sketch the algorithm for inversing the Dijkstra tree representation already in the next email
and also submit a revived draft. 

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