Subject: [PWE3] resending: "negotiated" text in RFC 4385 and atm-encap

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 8 Nov 2006 20:26:17 +0200

I understand that there was a problem with this message
being cut off after the second paragraph.
 
So I am resending.
 
Y(J)S
 
========================================================
 
Yesterday Luca suggested that the word "negotiated" in the text:
  
            If a PE negotiated not to use receive sequence number
processing, 
            and it received a non-zero sequence number, then it SHOULD
send a 
            PW status message indicating a receive fault, and disable
the PW. 
 
meant "received a thousand packets with zero in the sequence number
field".
 
I would like to explain why I think this is a really BAD idea.
 
Luca's wording "a thousand packets" meant that he agrees that we don't
make drastic decisions based on a single (possibly bad) packet.
So equally we wouldn't want to disable the PW based on a single
non-zero sequence number, but rather from some number of packets
containing sequence numbers. 
 
Let's call the number of zero-SN packets that we require to be received 
before assuming that the "negotiation" has succeeded - N0, 
and the number of packets we require to be received with nonzero SN N1. 
So we disable the PW if we receive N1 or more packets
with nonzero SN after having received N0 packets with zero SN.
 
This check requires maintaining two counters, let's call them n0 and n1,

to be compared  n0 to N0 and n1 to N1.
For each packet received we update one of the counters and zero the
other. 
Of course we don't want these counters to overflow and look small again,

so once either counter passes its limit we cease updating it.
I won't write the pseudocode here, but we check the SN for zero-ness,
branch, increment and check of overflow, zero, and then check for the
criterion.
 
This processing, in addition to already being longer and more complex
than the present SN processing, significantly increases the per-packet
processing
time, and due to the exception processing makes HW implementation more
complex.
 
Of course, if we want to catch all errors, why don't we disable the PW
if we had N0 nonzero SNs and then N1 zero SNs ?
This only requires a few more cycles/gates.
But then we should add checks for the flags field as well.
 
A short count shows that adding this per-packet processing
more than doubles the processing required per packet.
And what have we gained? Certainly not true packet integrity guarantees.
 
I think this interpretation of the text is even worse than the previous
interpretation, and propose removing this text.
 
Y(J)S
 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 8 Nov 2006 21:10:52 +0200

Yaakov and all,
I agree that the text proposed by Luca is a bad idea:

1.	
	There would be still no explanation as to what exactly "negotiation" means
2.	
	It would be still possible to create a complete mess by intermittently sending packets with non-zero and zero SN

I see only one way out of the problem:

1.	Delete the entire problematic text from the ATM-PW RFC
2.	Write a short generic document applicable for all non-TDM PWs. It would:

	*	Explicitly specify that mix of zero and non-zero SN on the same direction of the same PW MUST NOT (SHOULD NOT?) be used
	*	Introduce a new Interface Parameters sub-TLV defining the SN processing capabilities of the receiver (OPTIONAL with well-defined default behavior if it is absent)

Regards,

                  Sasha

________________________________

From: Yaakov Stein [mailto:[email-masked]]
Sent: Wed 11/8/2006 06:26
To: [email-masked]
Subject: [PWE3] resending: "negotiated" text in RFC 4385 and atm-encap

So I am resending.
 
Y(J)S

  
            If a PE negotiated not to use receive sequence number processing, 
            and it received a non-zero sequence number, then it SHOULD send a 
            PW status message indicating a receive fault, and disable the PW. 
 
meant "received a thousand packets with zero in the sequence number field".

 
 
This check requires maintaining two counters, let's call them n0 and n1, 
to be compared  n0 to N0 and n1 to N1.
For each packet received we update one of the counters and zero the other. 
Of course we don't want these counters to overflow and look small again, 
so once either counter passes its limit we cease updating it.
I won't write the pseudocode here, but we check the SN for zero-ness,
branch, increment and check of overflow, zero, and then check for the criterion.
 
This processing, in addition to already being longer and more complex
than the present SN processing, significantly increases the per-packet processing
time, and due to the exception processing makes HW implementation more complex.

 
 
Y(J)S