Subject: Re: [PWE3] FW: WG Last Call for draft-ietf-pwe3-fat-pw-03

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 Oct 2010 16:41:06 +0100

Lucy
>
> Some statement about QoS and DSCP aspect is necessary when applying it 
> to DiffServ enabled domain.
>
> What is the problem that you wish to see addressed here? The TC bits 
> will not be examined until after the PW label has been popped. Are you 
> suggesting that the egress queue may be chosen on the basis of the FL 
> TC bits?
>
> Something like: "The ingress PE MAY set the TC bits in the FL to 
> indicate to the egress PE the relative priority of the flow with 
> respect to other flows delivered to the egress interface?"
>
> [LY] Not really. This is not the behavior we expect, right? Something 
> like: PW with flow label can apply to a Diff-Serv enabled domain. 
> DiffServ [RFC3270] specifies per hop based Diff-Serv forwarding that 
> uses TC bits of the top label on label stack. Since flow label is 
> always pushed in or popped out with PW label together, the flow label 
> is never appear on the top of label stack. Thus, Diff-Serv forwarder 
> does not exam TC bits on flow label; Diff-Serv behavior is the same 
> whether flow label is used or not.
>
Whilst it is true that the we do not expect any Diff-Serv decision in 
the forwarding path based on the value of the TC bits in the FL, I am 
reluctant to add anything to the draft that implies that the label is 
anything other than a normal MPLS label.

Why do you think we need to add this text?

Stewart

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Oct 2010 09:39:11 -0700

Lucy,

I agree with Stewart.  A document produced by the PWE3 wg cannot be redefining the semantics of an MPLS label.  That is the purview of the MPLS wg.

Thanks,

John

Sent from my iPhone

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, October 13, 2010 8:41 AM
To: Yong Lucy
Cc: [email-masked]
Subject: Re: FW: [PWE3] WG Last Call for draft-ietf-pwe3-fat-pw-03

Lucy

Some statement about QoS and DSCP aspect is necessary when applying it to DiffServ enabled domain.
What is the problem that you wish to see addressed here? The TC bits will not be examined until after the PW label has been popped. Are you suggesting that the egress queue may be chosen on the basis of the FL TC bits?

Something like: "The ingress PE MAY set the TC bits in the FL to indicate to the egress PE the relative priority of the flow with respect to other flows delivered to the egress interface?"
[LY] Not really. This is not the behavior we expect, right? Something like: PW with flow label can apply to a Diff-Serv enabled domain. DiffServ [RFC3270] specifies per hop based Diff-Serv forwarding that uses TC bits of the top label on label stack. Since flow label is always pushed in or popped out with PW label together, the flow label is never appear on the top of label stack. Thus, Diff-Serv forwarder does not exam TC bits on flow label; Diff-Serv behavior is the same whether flow label is used or not.
Whilst it is true that the we do not expect any Diff-Serv decision in the forwarding path based on the value of the TC bits in the FL, I am reluctant to add anything to the draft that implies that the label is anything other than a normal MPLS label.

Stewart

---

From: Yong Lucy <[email-masked]>
Date: Wed, 13 Oct 2010 12:31:18 -0500

Stewart,

This is not about changing MPLS semantics. It is just clarification.
Although FL has the same semantics as PW/LSP label, it only appears at
bottom of label stack and does not serve for label switching and DiffServ
function in PSN (including PE). It is only used in multipath forwarding.

Am I right on this? Explicit clarification reduces a lot of confusion.  

Lucy

  _____  

From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, October 13, 2010 10:41 AM
To: Yong Lucy
Cc: [email-masked]
Subject: Re: FW: [PWE3] WG Last Call for draft-ietf-pwe3-fat-pw-03

Lucy

Some statement about QoS and DSCP aspect is necessary when applying it to
DiffServ enabled domain.

What is the problem that you wish to see addressed here? The TC bits will
not be examined until after the PW label has been popped. Are you suggesting
that the egress queue may be chosen on the basis of the FL TC bits? 

Something like: "The ingress PE MAY set the TC bits in the FL to indicate to
the egress PE the relative priority of the flow with respect to other flows
delivered to the egress interface?"

[LY] Not really. This is not the behavior we expect, right? Something like:
PW with flow label can apply to a Diff-Serv enabled domain. DiffServ
[RFC3270] specifies per hop based Diff-Serv forwarding that uses TC bits of
the top label on label stack. Since flow label is always pushed in or popped
out with PW label together, the flow label is never appear on the top of
label stack. Thus, Diff-Serv forwarder does not exam TC bits on flow label;
Diff-Serv behavior is the same whether flow label is used or not.

Whilst it is true that the we do not expect any Diff-Serv decision in the
forwarding path based on the value of the TC bits in the FL, I am reluctant
to add anything to the draft that implies that the label is anything other
than a normal MPLS label.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Oct 2010 17:35:59 +0100

Lucy,

How about the following text WRT the TC bits:

The use of the TC bits in the FAT label is outside the scope of this 
document. Unless otherwise agreed by the PEs these bits MUST be set to 
zero by the ingress PE and MUST be ignored by the egress PE.

-Stewart