Subject: Call for ethernet WG document.

From: Luca Martini <[email-masked]>
Date: Tue, 23 Jul 2002 09:48:17 -0600

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

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 24 Jul 2002 04:15:15 -0700

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.

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.

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 ?

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.

-Ali

At 09:48 AM 7/23/2002 -0600, Luca Martini wrote:

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Khalid Ahmad" <[email-masked]>
Date: Thu, 25 Jul 2002 14:44:11 -0400

Hi pwe3 colleagues,

all this discussion around the issue of sequence numbering on PWs brings
back to mind why I argued (unsuccessfuly !) against including sequence
numbering in the first place.  It seems a long time ago now.

The wiser solution would have been (and maybe still is) to specify packet
loss targets in the PSN for the different CoS's, and then dimension the
networks to achieve these using good old traffic engineering/management
guidelines.  I have the impression other label switching transfer modes seem
to be able to manage that way, thank you.

Sequence numbering may appear enticing as a simple means to detect frame
loss, but if folks are serious about numbering each frame they float down a
PW, good luck !

Its not going to be free.

Regards,
Khalid

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 9:32 AM
To: Ali Sajassi
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] Call for ethernet WG document.

On Thu, 2002-07-25 at 10:47, Ali Sajassi wrote:
> 
> >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?
> 
> 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.

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.

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

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.

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

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.

> >Somehow I have this suspicion that we had a long debate on this topic on
> >this very list a while ago ;-)
> 
> It wasn't with me :-)

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

> >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.
> >
> >pretty much.  See the "Ethernet Circuit Types" thread for a debate on
> >this ;-)
> >
> >ah, probably an editing hiccup.
> >
> >Giles
> >
> > > -Ali
> > >
> >--
> >=================================================================
> >Giles Heron    Principal Network Architect    PacketExchange Ltd.
> >ph: +44 7880 506185              "if you build it they will yawn"
> >=================================================================
> >
> >
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Giles Heron <[email-masked]>
Date: 25 Jul 2002 23:44:20 +0000

Hi Khalid,

> numbering in the first place.  It seems a long time ago now.

I would agree that sequence numbering is, in general, a waste of time.
 
> to be able to manage that way, thank you.

This isn't about packet loss targets.  Sequence numbers aren't there to
detect packet loss (though sure they could do this), they are there to
detect out of order packets.

The issue Ali has raised is (I think) whether there is a risk of the
mechanism used to detect out of order packets being fooled by network
rerouting events.

The "other label switching transfer modes" you refer to don't typically
carry sequence numbers AFAIK.  This has nothing to do with packet loss
(that I am aware of), but is - I believe - because they make the
assumption that all cells/frames for one virtual circuit follow the same
path as each other and will therefore arrive in the same order.  Which
won't always be the case when re-routing from a less optimal to a more
optimal path (unless you do break before make or deliberately discard
all traffic at ingress for a sufficient period of time to compensate for
any difference in path length...)

> loss, but if folks are serious about numbering each frame they float down a

I don't think any serious SP is serious about numbering frames :)

Giles

---

From: "Khalid Ahmad" <[email-masked]>
Date: Fri, 26 Jul 2002 15:00:20 -0400

Hi Giles,

you are right, I meant to say out of sequence packets (not packet loss), but
I guess my brain wasnt in gear at the time! Thanks for pointing out my slip.

Nonetheless, same considerations apply as regards network design.  It seems
to me still preferable to set out objectives for out of order packets, and
then engineer the network to ensure these targets are met, rather than use
sequence numbering. Much easier.

Regards,
Khalid

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 7:44 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Ali Sajassi; Luca Martini; [email-masked]
Subject: RE: [PWE3] Call for ethernet WG document.

Hi Khalid,

 

Giles

> > > > tag-mode and the tag-mode is listed for backward compatibility,
right
> ?
> > > > Appendix A, figure 4: It seems like the table doesn't quite
correspond
> to
> > > > operations were specified as NSP functionality. Also what is "C" ?
Can
> you
> > > > >We feel this work has progressed sufficiently , and is the result
of 
> > > many PWE3

---

From: [email-masked]
Date: Sun, 28 Jul 2002 11:32:27 +0100

Couple of observations on this.
 
Agreed that networks should *not* re-order pkts when emulating a co network
service........but if you don't have a sequence number how can you *tell*
they are not doing this (esp if its happening on a regular basis for some
reason)?
 
The basic point I think Ali was making out was that if a seq no. is to be
used it should never wrap under *any* failure conditions for a 'defined
period of time'..........so its important to understand what this defined
period of time is (since the required size of seq no. counter is directly
related to this and the largest pkt rate expected looking forward).  One way
to choose this period would be based on some definition of availability.
For example, if it was decided that availability should be based on a 10s
period (to be consistent with what has been traditionally used on co
networks), counters should not wrap in <10s at highest expected pkt rate.
 
regards, Neil

-----Original Message-----
From: Khalid Ahmad [mailto:[email-masked]]
Sent: 26 July 2002 20:00
To: Giles Heron
Cc: Ali Sajassi; Luca Martini; [email-masked]
Subject: RE: [PWE3] Call for ethernet WG document.

Hi Giles, 

Regards, 
Khalid 

-----Original Message----- 
From: Giles Heron [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 25, 2002 7:44 PM 
To: Ahmad, Khalid [CAR:CS40:EXCH] 
Cc: Ali Sajassi; Luca Martini; [email-masked] 
Subject: RE: [PWE3] Call for ethernet WG document. 

Hi Khalid, 

  

Giles 
  
> From: Giles Heron [ mailto:[email-masked]
<mailto:[email-masked]> ] 

> > > > transmit or receive side) then why the control word is sent in first

> place 

right 
correspond 
Can 
> > http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-0
<http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-0>  
> > > 1.txt 
of 
> > > > >contributors that at this time it should be accepted as a WG 
<https://www1.ietf.org/mailman/listinfo/pwe3>  
<https://www1.ietf.org/mailman/listinfo/pwe3>  
<https://www1.ietf.org/mailman/listinfo/pwe3>  
<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" 
=================================================================