[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Also note that QOS information exchange
is not necessarily restricted to TE-LSP
(Eric made that point while back)

The Receiving PE may use this info only 
to select the right Policer for local AC.

/himanshu



> -----Original Message-----
> From: Shah, Himanshu 
> Sent: Thursday, February 19, 2004 10:53 AM
> To: 'Luca Martini'; Busschbach, Peter B (Peter)
> Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com;
> pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 new WG items? PW QoS
> 
> 
> 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
> 

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