RE: [PWE3] PWE3 new WG items?

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

Ditto.

Understand your concern but like Peter says
we can not scrap everything and start
from the scratch.


/himanshu

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
> Sent: Wednesday, February 18, 2004 10:03 AM
> To: 'benjamin.niven-jenkins@bt.com'; Shah, Himanshu; pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 new WG items?
> 
> 
> Ben,
> 
> I agree that the PWE3 WG could have decided to treat PWs as 
> LSPs (which currently is not true) and to use RSVP as the 
> protocol for PW set up. I have argued on this mailing list 
> that that would have been a better approach, e.g. because it 
> would provide a solution for the creation of multi-hop PWs, 
> preferable to the splicing approach that is now on the table. 
> Similarly, RSVP would provide an immediate solution for 
> signaling QoS parameters.
> 
> I am in favor of adopting RSVP as a valid protocol for PW set 
> up. However, as long as that is not accepted by the WG, there 
> is a need to address QoS for PWs in a different way. You can 
> call it re-inventing the wheel, but it needs to be done.
> 
> Peter
> 
> > -----Original Message-----
> > From: benjamin.niven-jenkins@bt.com
> > [mailto:benjamin.niven-jenkins@bt.com]
> > Sent: Wednesday, February 18, 2004 9:38 AM
> > To: hshah@ciena.com; pwe3@ietf.org
> > Subject: RE: [PWE3] PWE3 new WG items?
> > 
> > 
> > > Signaling of the QOS parameters that is specific to 
> > > a given PW-FEC falls within the charter of PWE3 as
> > > it is an attribute of a PW-FEC.
> > > 
> > > This is my understanding.
> > 
> > Well, I would say that as:
> > 
> > 1) PWs are basically LSPs (and therefore they inherit all the 
> > properties of a LSP and add their own PW specific properties)
> > 
> > 2) PW signalling is an extension to LSP signalling (and 
> > therefore it inherits all the properties of LSP signalling 
> > and adds its own PW specific properties)
> > 
> > The problem of signalling QoS parameters is not a PW specific 
> > problem and therefore should not be addressed by the PWE3 WG.
> > 
> > If the QoS signalling mechanisms that exist already (e.g. 
> > CR-LDP) are adequate then why not re-use them for PWs because 
> > PWs should automatically inherit any traffic parameters 
> > signalled at the same time as the PW-FEC?  If the existing 
> > QoS signalling mechanisms are not adequate then fix them but 
> > in such a way that they can be used for MPLS LSPs and PWs.
> > 
> > IMO defining PW specific QoS signalling just limits the 
> > amount of functional convergence/re-use that can be achieved 
> > and therefore increases the complexity of any solution (and 
> > by implication increases the opex for any service provider 
> > wishing to deploy that solution).
> > 
> > Unfortunately CR-LDP has been deprecated so the opportunities 
> > for functional convergence/re-use are more limited and it 
> > looks like re-inventing the wheel[1] is one possible 
> > (although I would consider it to be an undesirable) solution :-(
> > 
> > Ben
> > 
> > [1] either the PW signalling wheel (e.g. add PW signalling to 
> > RSVP-TE) or the LDP QoS wheel (e.g. add QoS signalling to LDP).
> > 
> > 
> > 
> > _______________________________________________
> > 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
> 

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