The MPLS WG Archive

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

Heinrich,

the answer to this is simple - reviving work is up to you. Re-issue the
drafts and take the discussion to the list. If there are sufficent
interest from the working group it will be progressed as a wg doc.

However, I would like to ask three things

- do not rename the message, all those suggestions were discussed -97
   and we chose the current names - whether the names are good or not is
   not a fruitul discussion - rename them will cause confusion

- wether we decide to focus on rsvp-te only or not, it is my take that
   this has to be designed for rsvp-te (also) to have any chance to fly

- since we have the signaling protocol disucssion hold the revising of
   the draft until you know the design environment.

/Loa

Hummel Heinrich wrote:

> 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