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

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

On 16/02/2010 18:54, [email-masked] wrote:
> 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.
>    

Ben, yes you are correct, but I am proposing that we make other changes 
to the PW signalling - please see earlier email.
>
> 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"
>
>
>    
Yes to both, however there is the issue of what to do about the 
supporting LAG, I therefore propose that we change the text to :

======

7.5.  Applicability to MPLS-TP

    The MPLS Transport Profile (MPLS-TP) [RFC5654] requirement 44 states
    that "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. "
    The flow aware transport of a PW reorders packets, therefore MUST NOT
    be deployed in a network conforming to the MPLS-TP unless these
    integrity requirements specified in the SLA can be satisfied.

=======

This gives the integrity requirements supremacy, but allows FAT to be 
used if those requirements can be adequately met.

- Stewart

> Thanks
> Ben

>
>
>
> On 01/02/2010 13:55, "BOCCI Matthew"<[email-masked]>
> wrote:
>
>    
>> 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
>>      
> _______________________________________________
> 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