[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] PWE3 new WG items? PW QoS
- To: "'Proch, Daniel'" <Daniel.Proch at marconi.com>, "'Rahul Aggarwal'" <rahul at juniper.net>, benjamin.niven-jenkins at bt.com
- Subject: RE: [PWE3] PWE3 new WG items? PW QoS
- From: "Busschbach, Peter B (Peter)" <busschbach at lucent.com>
- Date: Thu, 19 Feb 2004 09:35:03 -0500
- Cc: hshah at ciena.com, "Busschbach, Peter B (Peter)" <busschbach at lucent.com>, pwe3 at ietf.org
- List-help: <mailto:pwe3-request@ietf.org?subject=help>
- List-id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
- List-post: <mailto:pwe3@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,<mailto:pwe3-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,<mailto:pwe3-request@ietf.org?subject=unsubscribe>
- Sender: pwe3-admin at ietf.org
> -----Original Message-----
> From: Proch, Daniel [mailto:Daniel.Proch@marconi.com]
> Sent: Thursday, February 19, 2004 9:21 AM
> To: 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com
> Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 new WG items? PW QoS
>
>
> >>For the purpose of PW QoS, this is reasonable. Note that the
> >>MPLS WG has 2 defined mechanisms for transport LSP setup:
> >> - LDP
> >> - RSVP-TE
> >>
> >>Of these RSVP-TE is used primarily for QoS/TE and Fast
> Reroute. LDP on the
> >>other hand is deemed easier to configure and manage when TE is not a
> >>requirement.
> >>
> >>There is no reason why PWE setup cannot follow a similar model:
> >> - LDP for PW signaling without QoS
> >> - RSVP-TE for PW signaling with QoS
> >>
> >>rahul
> >>
> >>
>
> dan -
> Maybe I misunderstand the problem, but it seems that RSVP-TE is not
> necessary. Signaling PW QoS is separate from PSN tunnel QoS.
> The problem
> that I see is how to inform the other side of a pseudo wire what QoS
> considerations should be taken the connection. It is an
> implementation
> specific task for the PE router to determine how to multiplex
> the PW into a
> PSN tunnel based on the requested QoS.
>
> LDP already exists for PW label distribution and the any LDP
> conversation is
> targeted to the directly to the other PE router (invisible to core).
> Therefore LDP can be extended to add QoS signaling for the PW as is.
>
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
> If RSVP-TE was already used for PW setup, I'd agree that it
> could also be
> used to signal QoS, but absent that, why would it be used in this
> application? For example, in the ATM Forum ATM/MPLS
> interworking specs PNNI
> is used for PW label distribution for ATM VCs and therefore PW QoS is
> supported as is.
>
> dan proch
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3