Subject: AW: AW: initiating a discussion on mpls singaling protocols

From: Hummel Heinrich <[email-masked]>
Date: Fri, 26 Jul 2002 17:20:04 +0200

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:[email-masked]]
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           [email-masked]
     WWW             www.utfors.se

---

From: David Charlap <[email-masked]>
Date: Fri, 26 Jul 2002 13:25:33 -0400

>                 Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)?

RSVP-TE does not support this.  Being a TE protocol, each LSP originates 
from exactly one ingress node.

It should be theoretically possible for multile LSPs to merge (share an 
outgoing label) if their QoS and explicit routes are identical for the 
remainder of the path to the egress, but this is more of an optimization 
than a feature that can be explicitly requested.  I would hesitate to 
call the result of this a mp2p LSP.

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

RSVP-TE, as specified right now, can handle this.  RFC 3209 does not 
specify a multicast version of the ERO (explicit route object), but I 
think the rest of the RFC can work fine for multicast, if the tunnel 
endpoint address is a multicast group address.

A multicast ERO object has been defined in Saisho Yasukawa's draft, if 
you consider that a requirement for p2mp LSPs.

I don't think there any implementations at this time, however.  I don't 
know which (if any) vendors are currently working on this.

>                                edge node towards all the other edge nodes. 

I don't know of any work in this area.  I think (but don't know enough 
to be sure) that LDP could theoretically work here, by using multicast 
group addresses as FECs.  But I don't know the protocol well enough to 
know if there are other issues that might make it impossible.

RSVP-TE, as currently defined, can't do this.  Same reasons as mp2p (see 
above.)

-- David

---

From: Loa Andersson <[email-masked]>
Date: Fri, 26 Jul 2002 17:57:03 +0200

Heinrich,

see inline

>                 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