Subject: Re: Call for ethernet WG document.

From: Giles Heron <[email-masked]>
Date: 24 Jul 2002 19:47:01 +0000

On Wed, 2002-07-24 at 11:15, Ali Sajassi wrote:
> 
> Overall this draft looks like a nice improvement relative to its 
> predecessor. However, I have a few comments that I'd like to be addressed.
> 
> sec. 4.1: a 16-bit sequence number may not be adequate specially for 
> Ethernet services. If a PW is used for connecting two GE ports, then a 
> 16-bit sequence counter can be wrapped around every tens of milliseconds 
> and thus a small hiccup in the network (in order of tens of milliseconds) 
> can cause the packet sequence processing between transmitter and receiver 
> to get out of synch and thus all the subsequent frames to be discarded. I 
> would suggest to use a 32-bit sequence number.

I'm not sure there are actually that many cases where a 32 bit sequence
number works better than a 16 bit one.  In a network "hiccup" packets
typically get discarded rather than delayed?

The one case that might be pertinent is where an MPLS LSP falls back
from a secondary (or FRR) path to a better path using "make before
break".  In this case the new path will probably have lower latency than
the reroute path.  If the difference is indeed tens of milliseconds then
it is possible that PWs running at GigE rates would see counter wrap.

But in any case it would seem to me that the aim of the control word is
not to prevent transient reordering but to prevent steady-state
reordering.  16 bits is probably more than adequate to overcome problems
caused by round-robin load-sharing anywhere in the path?  Of course most
SPs engineer their networks not to use round-robin load-sharing - so I
wouldn't mind betting that deployment of the control word for Ethernet
PWs is zero at this point.

The benefit of the 16 bit sequence number is that it is compatible with
the other encapsulations (FR, ATM, PPP, HDLC).  FR and ATM use those
first 16 bits for other purposes...

Somehow I have this suspicion that we had a long debate on this topic on
this very list a while ago ;-)

> Also if a PE does not support sequence number processing (either on the 
> transmit or receive side) then why the control word is sent in first place 
> given that the control word is optional.

yes, I can't see much value in sending a control word and not processing
the sequence number in the Ethernet case.  This wording is carried over
from other encapsulations where there are other uses for the control
word.

> sec. 4.3 and 4.4: It seems like the raw-mode is the super set of the 
> tag-mode and the tag-mode is listed for backward compatibility, right ?

pretty much.  See the "Ethernet Circuit Types" thread for a debate on
this ;-)

> Appendix A, figure 4: It seems like the table doesn't quite correspond to 
> the figure 3 with respect to points "A" and "B". The table talks about 
> changing, adding, removing vlan tag at "B"; whereas, earlier on these 
> operations were specified as NSP functionality. Also what is "C" ? Can you 
> modify/clarify this table to show Ethernet services at each end and the 
> recommended PW type to be used for it.

ah, probably an editing hiccup.

Giles

> -Ali
> 
> At 09:48 AM 7/23/2002 -0600, Luca Martini wrote:
> 
> 
> >I would like to ask the PWE3 WG to accept the ID:
> >
> >http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-01.txt
> >
> >
> >As as PWE3 WG document for the ethernet encapsulation charter requirement.
> >
> >
> >We feel this work has progressed sufficiently , and is the result of many PWE3
> >contributors that at this time it should be accepted as a WG document.
> >
> >
> >Thanks .
> >
> >Luca Martini
> >
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 25 Jul 2002 03:47:40 -0700

>typically get discarded rather than delayed?

I was actually thinking about packet discard as the result of the re-route. 
Lets go over an example: Lets assume that as the result of a LSP re-route, 
a 40 ms worth of packets have been dropped. At GE rate this can translate 
into 40K packets (assuming 1K-bit packet size). Now the sequence number of 
packet = expected sequence number of packet + 40K mod 2**16.  If you plug 
any number in here, you can see that both checks in the section 4.1.2 
fails. And the packets are assumed to be out-of-ordered even though all the 
subsequent packets are actually in order and there was just a loss of 40 ms 
worth of packets. Based on the algorithm specified, there is no recovery 
from this.

However, if you use a 32-bit sequence number, then it would take 67 min. of 
outage for the same condition to occur; however, the PW will be torn down 
way before that (after a few seconds) based on OAM ping messages and thus 
we would never get into such situation.

>first 16 bits for other purposes...

Yes I know; however, I was trying to point out the need for a 32-bit 
sequence number as well. We should probably have options for both 16-bit as 
well as 32-bit sequence number. The 16-bit can be use as default and a 
32-bit sequence number can be used where it is needed.

>this very list a while ago ;-)

It wasn't with me :-)

-Ali

---

From: Giles Heron <[email-masked]>
Date: 25 Jul 2002 13:31:38 +0000

> worth of packets. Based on the algorithm specified, there is no recovery 

Hi Ali,

What sort of recovery are you looking for?  Packets have been lost.

or are you saying effectively "if we lose > 64 k packets as a result of
a reroute then it would be a bad thing to then lose another 0 to 64k
packets because of counter wrap"?

I would contend that the difference between losing X packets and losing
X + Y packets, where Y is < X and likely to be << X, isn't really worth
worrying about.

But I suppose the counter argument to this might be that if the outage
has caused the endpoints of the PW to detect the failure in their IGP
then it may take much longer to send Y packets post-failure than it does
to send X packets pre-failure.

One possible response to that would be that SPs need to reroute LSPs
faster than the customer IGP can detect PW failure.

> we would never get into such situation.

agreed, the PW will be torn down way before that.  Not based on OAM ping
though, but based on the tLDP session between the PEs going down.

> 32-bit sequence number can be used where it is needed.

I would disagree with this.  More options are generally a bad thing :(

Frankly I'd rather we just killed the control word option for Ethernet. 
But then I suspect people will complain that we might violate the IEEE
spec.

> >this very list a while ago ;-)

yeah, I guess I'm just saying "I'm too lazy to reread all those mails
and summarise them to you, but perhaps you might be interested in
trawling through them?" ;-)

Giles