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

From: Stewart Bryant <[email-masked]>
Date: Mon, 05 Jul 2010 19:08:50 +0100

Taking the second issue first.

I propose to add some text to explain the asymmetric requirements:

=====

7.6.  Asymmetric Operation

    The protocol defined in this document supports the asymmetric
    inclusion of the FAT label.  Asymmetric operation can be expected
    when there is asymmetry in the bandwidth requirements making it
    unprofitable for one PE to perform the flow classification, or when
    that PE is otherwise unable to perform the classification but is able
    to receive flow labeled packet from its peer.  Asymmetric operation
    of the PW may also be required when one PE has a high transmission
    bandwidth requirement, but has a need to receive the entire PW on a
    single interface in order to perform a processing operation that
    requires the context of the complete PW (for example policing of the
    egress traffic).

=====

It's always difficult to know how much detail to put in the draft, but 
note that if a PE says it is going to do FAT, but only puts a constant 
value in the packet this is worse than not doing FAT at all.

However when investigating asymmetry further I found the need to add 
signalling for the two directions. In doing so I propose to address the 
first requested change (i.e. to no longer require the PW to be resignalled)

The signaling text that I am suggesting we use is:

=========

4.  Signaling the Presence of the Flow Label

    When using the signalling procedures in [RFC4447], a Pseudowire
    Interface Parameter Flow Label Sub-TLV (FL Sub-TLV) type is used to
    synchronise the flow label states between the ingress and egress PEs.

    The absence of a FL Sub-TLV indicates that the PE is unable process
    flow labels.  A PE that is using PW signalling and that does not send
    a FL Sub-TLV MUST NOT include a flow label in the PW packet.  A PE
    that is using PW signalling and which does not receive a FL Sub-TLV
    from its peer MUST NOT include a flow label in the PW packet.  This
    preserves backwards compatibility with existing PW specifications.

    A PE that wishes to send a flow label in a PW packet includes in its
    label mapping message a FL Sub-TLV with T = 1 (see Section 4.1).

    A PE that is able to receive a flow label includes in its label
    mapping message a FL Sub-TLV with R = 1 (see Section 4.1).

    A PE that receives a label mapping message a FL Sub-TLV with R = 0
    MUST NOT include a flow label in the PW packet.

    Thus a PE sending a FL Sub-TLV with T = 1 and receiving a FL Sub-TLV
    with R = 1 MUST include a flow label in the PW packet.  Under all
    other combinations of FL Sub-TLV signalling a PE MUST NOT include a
    flow label in the PW packet.

    The signalling procedures in [RFC4447] state that "Processing of the
    interface parameters should continue when unknown interface
    parameters are encountered, and they MUST be silently ignored."  The
    signalling procedure described here is therefore backwards compatible
    with existing implementations.

    If PWE3 signalling [RFC4447] is not in use for a pseudowire, then
    whether the flow label is used MUST be identically provisioned in
    both PEs at the pseudowire endpoints.  If there is no provisioning
    support for this option, the default behaviour is not to include the
    flow label.

    Note that what is signalled is the desire to include the flow label
    in the label stack.  The value of the label is a local matter for the
    ingress PE, and the label value itself is not signalled.

4.1.  Structure of Flow Label Sub-TLV

    The structure of the flow label TLV is shown in Figure 3.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FL            |    Length |T|R|      Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: Flow Label Sub-TLV

    Where:

    o  FL is the flow label sub-TLV identifier assigned by IANA.

    o  Length is the length of the TLV in octets and is 4.

    o  When T=1 the PE is requesting the ability to send a PW packet that
       includes a flow label.  When T= 0, the PE is indicating that it
       will not send a PW packet containing a flow label.

    o  When R=1 the PE is able to receive a PW packet with a flow label
       present.  When R=0 the PE is unable to receive a PW packet with
       the flow label present.

    o  Reserved bits MUST be zero on transmit and MUST be ignored on
       receive.

==========

Stewart

On 05/02/2010 22:38, AISSAOUI Mustapha wrote:
> 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",
>>   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
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>>      
>    

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Sami Boutros <[email-masked]>
Date: Mon, 05 Jul 2010 13:11:23 -0700

I agree with the text, Asymetric operation is needed.

As well, now signaling a FL sub-TLV means that the PE supports the 
sub-TLV in signaling, and T and R bits allow
the PE to say wether it's willing to send and/or receive flow labels, 
so the presence of the sub-TLV doesn't mean any
more that a PE can receive flow labels, it only mean it can signal it.

The text would address Mustapha's issue 1 below as well, since there 
will be no need to re-signal with F bit=0,
F bit will be eliminated we have now T and R bits correct?

Thanks,

Sami
At 11:08 AM 7/5/2010, Stewart Bryant wrote:
>It's always difficult to know how much detail to put in the draft, 
>but note that if a PE says it is going to do FAT, but only puts a 
>constant value in the packet this is worse than not doing FAT at all.
>
>signalling for the two directions. In doing so I propose to address 
>the first requested change (i.e. to no longer require the PW to be resignalled)
>
>>>From: <mailto:[email-masked]>[email-masked] 
>>>[mailto:[email-masked]] On
>>>Behalf Of BOCCI Matthew
>>>To: <mailto:[email-masked]>[email-masked]
>>><http://tools.ietf.org/html/draft-ietf-pwe3-fat-pw-03>http://tools.ietf.org/html/draft-ietf-pwe3-fat-pw-03
>>>
>>>
>>><mailto:[email-masked]>[email-masked]
><http://www.cisco.com/web/about/doing_business/legal/cri/index.html>http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>