RE: [PWE3] PWE3 new WG items? PW QoS

["Shah, Himanshu" <hshah at ciena.com>]

If one was to map one PW per transport LSP,
one does not need RSVP signaling for PW QOS....:-)

I remember a debate at IETF where a group of people 
were concerned about scaling of RSVP's use 
for LSP signaling. Well, PWs are multi magnitude
higher order than transport LSPs.

Also, isn't direction an issue?
Target PE (tail end) tells the source PE (head end)
about his local AC's QOS requirements. Source PE (head-end)
then selects an appropriate transport tunnel to target PE (tail-end).
If I remember correctly, in RSVP-TE the head-end specifies
the QOS requirement (which tail-end can adjust in RESV).

/himanshu


> -----Original Message-----
> From: Luca Martini [mailto:lmartini@cisco.com]
> Sent: Thursday, February 19, 2004 10:51 AM
> To: Busschbach, Peter B (Peter)
> Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com;
> Shah, Himanshu; pwe3@ietf.org
> Subject: Re: [PWE3] PWE3 new WG items? PW QoS
> 
> 
> Busschbach, Peter B (Peter) wrote:
> 
> [snip]
> 
> >I would agree that if QoS were the only problem that needs 
> to be solved it could be acceptable to carry QoS information 
> in the LDP messages that are used for PW setup (albeit that 
> it is somewhat ugly since it makes LDP look like CR-LDP which 
> has been depreciated).
> >
> >However, there are other issues that need to be solved. 
> Several people on this mailing list suggested that we need to 
> address PW stitching. It seems to me that stitching of PWs 
> requires a signaling protocol that establishes a multi-hop PW 
> through switches that switch based on the PW label. RSVP is 
> in my view the only reasonable solution.
> >
> >Hence, if we don't look at one problem at a time, but at the 
> entire problem space, I think we need to adopt RSVP as a way 
> to establish PWs. It would solve the problems of both QoS and 
> stitching.
> >
> >Peter
> >
> >  
> >
> Peter,
> It is possible ( I already know of one implementation ) to select an 
> RSVP LSP to transport a single PW.
> That does not change the protocol , and does carry QoS information 
> needed by the PSN. It also achieves another property that as it turns 
> out is quite useful in practice: explicit routing of the PW 
> across the 
> PSN. ( this is for TE , but also other reasons like avoiding 
> shared PSN 
> failure modes )
> 
> Luca
> 
> >
> >_______________________________________________
> >pwe3 mailing list
> >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >  
> >
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3