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

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 1 Feb 2010 14:55:52 +0100

This is to start a four week working group last call on "Flow Aware
Transport of Pseudowires over an MPLS PSN",
 http://tools.ietf.org/html/draft-ietf-pwe3-fat-pw-03

Please review the draft and send any comments to the PWE3 mailing list.

I have also asked Pranjal Dutta and Luca Martini to review the control
plane aspects of the draft.

This last call will close on Monday 1st March 2010.

Best regards

Matthew

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 5 Feb 2010 16:38:09 -0600

Vach and Stewart,
I would like to propose a couple of changes to the signaling procedures
in draft-ietf-pwe3-fat-pw-03.

1. For the flow-label sub-TLV, I would like to follow the negotiation
procedures used for the VCCV capability. In other words, if the local PE
sent this sub-TLV with F=1 but received a label mapping message from the
remote PE without this sub-TLV, the local PE will still bring up the PW
but will not insert the flow label in PW packets forwarded to the remote
PE. 

The current version of the draft suggests that a new label mapping
message be sent with the flow-label sub-TLV included with a value of
F=0. 

2. What is the use case for allowing asymmetric enabling of the flow
label in the two directions of the PW? Can we enforce that both
directions use or not use the flow label in the PW packets? This will
simplify the signaling procedures since we would not have to process
label mapping differently depending on F bit setting.

I appreciate if you could comment on whether these can be accommodated.

Regards,
Mustapha. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of BOCCI Matthew
> Sent: Monday, February 01, 2010 8:56 AM
> To: [email-masked]
> Subject: [PWE3] WG Last Call for draft-ietf-pwe3-fat-pw-03
> 
> This is to start a four week working group last call on "Flow 
> Aware Transport of Pseudowires over an MPLS PSN",
> I have also asked Pranjal Dutta and Luca Martini to review 
> the control plane aspects of the draft.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 18:54:00 +0000

Matthew, Authors,

My comments on draft-ietf-pwe3-fat-pw-03 are below:

1) Section 4.1 6th paragraph doesn't make much sense:

If a PE that previously did not received a label binding without a FL
Sub-TLV receives a new a label mapping with one included, it MAY send a new
label mapping including an FL Sub-TLV with F = 1.

I think you mean:

If a PE that previously received a label binding without a FL Sub-TLV
subsequently receives a new a label mapping with a FL Sub-TLV included, it
MAY send a new label mapping including an FL Sub-TLV with F = 1.

2) Section 7.4. states:

   The MPLS Transport Profile (MPLS-TP) [RFC5654] requirement 44 states that
"MPLS-TP SHOULD support mechanisms to enable the reserved bandwidth of a
transport path to be decreased without impacting the existing traffic on
that transport path, provided that the level of existing traffic is smaller
than the reserved bandwidth following the decrease."  The flow aware
transport of a PW reorders packets (albeit in an application friendly way),
therefore SHOULD NOT be deployed in a network conforming to the MPLS-TP.

I don't see how the quoted requirement leads to the conclusion. However the
requirement you quote from RFC5654 is actually requirement 43! Requirement
44 which does lead to the conclusion you draw is:

   44  MPLS-TP MUST support mechanisms that ensure the integrity of the
transported customer's service traffic as required by its associated SLA.
Loss of integrity may be defined as packet corruption, reordering, or loss
during normal network conditions.

Also I think the section should be titled "Applicability to MPLS-TP"

Thanks
Ben

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sun, 21 Feb 2010 05:55:54 +0530

Mathew, Authors and WG,

          Here are some of my review comments:

Section 4 of the draft states below:

   "A PE that wishes to use a flow label includes in its label mapping
   message a Flow Label Sub-TLV (FL Sub-TLV) with F = 1 (see
   Section 4.1).  A PE that can correctly process a flow label, and is
   willing to receive one, but does not wish to send a flow label,
   includes an FL Sub-TLV with F = 0.

   If a PE has sent an FL Sub-TLV with F = 1, and has received an FL
   Sub-TLV it MUST include a flow label in the label stack."

   The above text implies asymmetric behavior in terms of conversation
   hashing - that is flow label is used in one direction but not in reverse
   direction. It is understood that such asymmetry is desired in networks
   where more traffic flowing from core to edge etc. So we should allow
   asymmetric behavior as it is useful.

   Section 4 also states below:

   "If a PE has sent an FL Sub-TLV with F = 1 and does not receive an FL
   Sub-TLV it MUST send a new label mapping using an FL Sub-TLV with F =
   0.

   A PE that has sent an FL Sub-TLV with F = 0 MUST NOT include a flow
   label in the label stack.

   If a PE that previously did not received a label binding without a FL
   Sub-TLV receives a new a label mapping with one included, it MAY send
   a new label mapping including an FL Sub-TLV with F = 1."

   The above explanation seems to be a bit contradictory if we should allow 
   asymmetric behavior. If a PE1 intends to insert the flow label on the PW
   packets (signals F=1) and PE2 doesn't intend to insert it but can receive 
   PW packet with the flow label (signals F=0), then net would be asymmetric
   behavior and doesn't require that PE1 re-sends the label mapping message

   Similarly, if PE1 included FL Sub-TLV with F=1 and PE2 doesn't include 
   one then net would be - don't use FL in either direction and both end 
   would fallback to the least common denominator. There is no need of
   re-mapping in this case as well.

   Note that since the FL negotiation is at per PW level, re-signaling is
   costly and should be avoided unless necessary. Even if we don't allow
   asymmetry, we can still avoid re-signaling. We just need to do logical
   AND of Flow Label support from both the ends and the behavior is well
   determined without extra re-mapping messages. One example, is
   negotiation of hello timers in ldp where both sides proposes values
   independently and negotiation falls back to lowest denominator.
   Another example is VCCV negotiation procedures.

   In summary, I would suggest for procedures like below:

   - use of flow label in both directions when F=1 signaled by both PEs.

   - use of flow label in one direction when F=1 is signaled in that 
     direction while F=0 was signaled in the reverse direction.

   - no use of flow label if one side did not signal the flow label sub-TLV     
     while the other did. Note that if both sides signaled F=0 then you also 
     get same net outcome.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: Monday, February 01, 2010 5:56 AM
To: [email-masked]
Subject: [PWE3] WG Last Call for draft-ietf-pwe3-fat-pw-03

Best regards

Matthew