Subject: Re: ATM/Ethernet/Control drafts minor corrections

From: Wei Luo <[email-masked]>
Date: Tue, 25 Nov 2003 10:10:39 -0800

In the control draft Section 5.4.2, the following sentence should be removed as 
it did in the latest draft-martini:

"Note that receiving a Label Withdraw should not cause a corresponding Label 
Release to be sent."

---Wei

Luca Martini wrote:
> WG members,
> 
> I have collected all the comments on the atm and ethernet  
> encapsulation, drafts, as well as the control and maintenance protocol 
> draft.
> Most are either spelling , punctuation, or english corrections which are 
> not significant enought to spell out individually.
> But there is a minor text clarification below that does not change the 
> technical design , but makes the reading easier.
> 
> First , the title of the ATM draft does not fit:
> 
> Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS 
> Networks
> So has chaged to :
> Encapsulation Methods for Transport of ATM Over IP and MPLS Networks
> 
> To fit in 72 columns.
> 
> In the sequnce section:
> 
> BEFORE:
> 4.3.4. Processing the sequence number field in the control word
> [snip]
> When a packet is received on that emulated VC, the sequence number
>   should be processed as follows:
> 
>     - if the sequence number on the packet is 0, then the packet passes
>       the sequence number check
> 
>     - otherwise if the packet sequence number >= the expected sequence
>       number and the packet sequence number - the expected sequence
>       number < 32768, then the packet is in order.
> 
>     - otherwise if the packet sequence number < the expected sequence
>       number and the expected sequence number - the packet sequence
>       number >= 32768, then the packet is in order.
> 
>     - otherwise the packet is out of order.
> 
>   If a packet passes the sequence number check, or is in order then, it
>   can be delivered immediately. If the packet is in order, then the
>   expected sequence number should be set using the algorithm:
> 
>   expected_sequence_number := packet_sequence_number + 1 mod 2**16
>   if (expected_sequence_number = 0) then expected_sequence_number:= 1;
> 
>   Packets which are received out of order MAY be dropped or reordered
>   at the discretion of the receiver.
> 
>   If a router PE2 does not support receive sequence number processing,
>   then the sequence number field MAY be ignored.
> 
> 
> AFTER:
> 
> 4.3.4. Processing the sequence number field in the control word
> [snip]
> When a packet is received on that emulated VC, the sequence number
>   should be processed as follows:
> 
>     - if the sequence number on the packet is 0, then the packet passes
>       the sequence number check.
> 
>     - otherwise if the packet sequence number >= the expected sequence
>       number and the packet sequence number - the expected sequence
>       number < 32768, then the packet is in order.
> 
>     - otherwise if the packet sequence number < the expected sequence
>       number and the expected sequence number - the packet sequence
>       number >= 32768, then the packet is in order.
> 
>     - otherwise the packet is out of order.
> 
>   If a packet is in order then, it can be delivered immediately. If the
>   packet is in order, then the expected sequence number MUST be set
>   using the algorithm:
>  
>   expected_sequence_number := packet_sequence_number + 1 mod 2**16
>   if (expected_sequence_number = 0) then expected_sequence_number:= 1;
> 
> 
>   Packets which are received out of order MAY be dropped or reordered
>   at the discretion of the receiver.
> 
>   A simple extension of the above processing algorithm can be used to
>   detect lost packets.
> 
>   If a router PE2 does not support receive sequence number processing,
>   then the sequence number field MAY be ignored.
> 
> 
> This section is identical in the ethernet or atm draft, and should be 
> identical in the frame-relay draft as well.
> Also Stewart, Yakov Stein and I discussed the concerns raised at the 
> last ITU  meeting , and concluded that this text is correct and needs no 
> changes.
> 
> Thanks.
> Luca
> 
> 
> Luca
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Tue, 25 Nov 2003 12:44:01 -0700

Yep, that was missed thanks.
( BTW the original intent of this sentence was to have the word 
"immediately " at the end of it, not to violate rfc 3036 )
Luca

Wei Luo wrote:

> In the control draft Section 5.4.2, the following sentence should be 
> removed as it did in the latest draft-martini:
>
> "Note that receiving a Label Withdraw should not cause a corresponding 
> Label Release to be sent."
>
> ---Wei
>
> Luca Martini wrote:
>
>> WG members,
>>
>> encapsulation, drafts, as well as the control and maintenance 
>> protocol draft.
>> Most are either spelling , punctuation, or english corrections which 
>> are not significant enought to spell out individually.
>> But there is a minor text clarification below that does not change 
>> the technical design , but makes the reading easier.
>>
>> Encapsulation Methods for Transport of ATM Cells/Frame Over IP and 
>> MPLS Networks
>> So has chaged to :
>> last ITU  meeting , and concluded that this text is correct and needs 
>> no changes.
>>
>> Thanks.
>> Luca
>>
>>
>> Luca
>>
>>
>>
>>
>>