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

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 9 Aug 2010 17:35:18 +0100

Stewart,

Apologies for the delay in responding, I also note there is -04 version that incorporates your suggestions but I thought I'd formally close the loop.

On 5 Jul 2010, at 19:16, Stewart Bryant wrote:
> On 16/02/2010 18:54, [email-masked] wrote:
>> 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.

OK I will read & respond to that e-mail separately.

>> 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.

This change is fine with me.

Ben