Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt

From: "Vasile Radoaca" <[email-masked]>
Date: Mon, 14 Apr 2003 23:31:57 -0400

Ali,
 
             Your observation about packet re-ordering in GVPLS has a point.
However, as Himanshu said
             it is a very low probability  and this in the case when the
VPLS core is not well design. 
             In Himanshu's example the remote unicast packet needs to travel
twice the speed of the multicast
             packet, along the Unicast PW(s), in order to arrive before the
multicast packet, at the remote destination.
 
             Also, we don't need to forget  the U-PE devices are most of the
time connected with low speed
             connections to the PE, if we compare with the high speed core
links, and most of the time via L2 
             devices. The Remote packet and local unicast packet need to
traverse twice such connections in order
             to get the unicast packet in front of the multicast packet.
 
             As it was suggested, in most of the cases, the Unicast PW and
M-P2P PW  share the same
             Tunnel between two PEs.  Other option, is to  do a better
design of the M-P2P PWs using TE or other 
             Qos techniques that can give   a better response time (for
example, a typical VPLS design is to combine
             a VPN pipe model in the VPLS core, with the VPLS hose model
between the VPN Members). 
 
             In GVPLS,  the M-P2P PWs are treated as an optimization for the
multicast traffic and are defined per VPN
             (regular Unicast  VC-Labels can be used also).
             In the VPLS scope the multicast or unknown traffic needs to be
very careful design - is easy to proof
              that in scalable VPLS configurations (with thousand of VPLSs
), the multicast traffic that can be generated  can 
             block  the unicast traffic  and jeopardize, overall, the QoS of
the VPLS Services.
             The idea of the M2-P2P PWs is to provide a kind of "Multicast
tree" where the packets are replicated
             as minimum as possible between U-PE and N-PE devices. 
 
             If the packet re-ordering is a key component of a given
application (a given VPLS context) and all the
             tools that are available are not enough to lower the
probability  of the packet re-ordering, then the replication
             can  be done using the Unicast PWs in the VPLS scope.
             The VPLS forwarding engine is transparent to the use of a
VC-M-Label or a regular VC-Label.
             
             In general the Multicast issue is a complex one in the VPLS
scope - I belive that the current proposal is
             is a starting point  in providing  a good  solution. 
 
          Cheers
                Vasile

-----Original Message-----
From: himanshu shah [mailto:[email-masked]] 
Sent: Monday, April 14, 2003 2:42 PM
To: 'Ali Sajassi'; [email-masked]
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt

response in line.

-----Original Message-----
From: Ali Sajassi [mailto:[email-masked]]
Sent: Monday, April 14, 2003 1:44 PM
To: [email-masked]; 'Ali Sajassi'; [email-masked]
Subject: RE: Issues with draft-radoaca-ppvpn-gvpls-01.txt

That would exasperate the problem even more. So if some of the existing
platforms have different internal processing path that would result in
packet re-ordering between unknown unicast versus known unicast, then we
should fix the problem instead of amplifying it by allowing it to be done
everywhere in the network (both edge and core).  Also I would like to know
where in IEEE standards, it allows for such behavior. We can take this
discussion to IEEE list.

HS> Out-of-order packets between unknown-unicast/multicast and
HS> known unicast is well known and well accepted fact. Perhaps
HS> you should inquire this on IEEE mailing list.

Not for the steady state. If you look at the IEEE 802.1D standards it says:

"NOTE 1 -The Forwarding Process in Bridges (7.7)does not mis-order or
duplicate frames.
Where Bridges in a Bridged LAN are capable of connecting the individual MACs
in such a way that
multiple paths between any source station -destination station pairs
exist,the operation of a protocol is required to ensure that a single path
is used.
NOTE 2 -Frame misordering and duplication (6.3.4) does not occur during
normal operation."

It clearly states that during normal operation misordering DOES NOT OCCUR !!

[himanshu shah] Despite what it says, today in normal bridges, broadcast
(unknown unicast frame is a flood and hence it is a broadcast) and unicast
frames between two stations may get out of order for the reasons I described
before; irrespective of the state of the network. Again, I invite you to
site an example where a miniscule possibility of such an out-of-order spells
disaster for a protocol (at session initiation time).

Even with this, you can still have out-of-ordering because of ECMP !!

HS> Thank you. You give one more example of how an out-of-order
HS> delievery could occur even when traffic is going over single
HS> pseudowire.

No !!! traffic doesn't get re-order when a single PW is used in case of
ECMP. It can get re-order when there are multiple PWs are involved for the
same flow  (as in the case of GVPLS).
[himanshu shah] If one was to do ECMP using the bottom most label, then it
is true that out-of-order would not occur for a single PW. However, is it
mandated that ECMP must be done on bottom-most label (i.e. PW label which
technically could be below several labels)? Lets for a moment accept that
such out-of-order would occur for 2 PWs. I would like to see an example
where a rare case of mis-order between broadcast-path frame and unicast-path
frame.

HS> The point is out-of-order can happen in GVPLS in very rare
HS> circumstances.  If you look at RSTP, out-of-order is mentioned
HS> as a possibility during topo changes as an acceptable risk against
HS> greater benefits. I suppose one can apply same logic here.

As mentioned before, IEEE 802.1D standards allows for possibility of
reordering in case of topology changes but not in steady state operation.
[himanshu shah] topo changes in small bridged network as compared to topo
changes in big-I network are at quite different scale. If one was to compare
the number of out-of-order packets due to topo-changes in big-I network to
out-of-order packets due to 2 PW, one would wonder where the real problem
is.

Regards,
Ali

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 15 Apr 2003 08:41:11 -0700

Vasile,

At 11:31 PM 4/14/2003 -0400, Vasile Radoaca wrote:
>          Ali,
>
>              Your observation about packet re-ordering in GVPLS has a 
> point. However, as Himanshu said
>              In Himanshu's example the remote unicast packet needs to 
> travel twice the speed of the multicast
>              packet, along the Unicast PW(s), in order to arrive before 
> the multicast packet, at the remote destination.

Yes, I would acknowledge the probability of it being low but it is much 
higher than packet re-ordering during topology change because network 
congestion can happen more frequently in the network than network topology 
and network congestion can result in significant path differential delay. 
And in case of simultaneous transmission, the multicast path doesn't need 
to be twice the delay of unicast path.

>
>              Also, we don't need to forget  the U-PE devices are most of 
> the time connected with low speed
>              connections to the PE, if we compare with the high speed 
> core links, and most of the time via L2
>              As it was suggested, in most of the cases, the Unicast PW 
> and M-P2P PW  share the same

Even when both are sent through the same tunnel with the same QoS, it can 
get our of order at the egress due to load balancing of ECMP.

>
>              In GVPLS,  the M-P2P PWs are treated as an optimization for 
> the multicast traffic and are defined per VPN
>              In the VPLS scope the multicast or unknown traffic needs to 
> be very careful design - is easy to proof
>               that in scalable VPLS configurations (with thousand of 
> VPLSs ), the multicast traffic that can be generated  can
>              block  the unicast traffic  and jeopardize, overall, the QoS 
> of the VPLS Services.
>              The idea of the M2-P2P PWs is to provide a kind of 
> "Multicast tree" where the packets are replicated

As two different PWs are used for unicast and multicast, there is a chance 
for this packet re-ordering even if you build your unicast out of PtP PWs.

>              is a starting point  in providing  a good  solution.

I think there is definitely a merit for having a solution based on MPtP PW 
and the discussion in here is just to highlight the issue with such 
solutions. My answer to the whole discussion is simple - we are doing LAN 
emulation and not exactly LAN so it is O.K. not to be exact. We just need 
to document it and make sure that IEEE 802.1 group doesn't have strong 
objection.

-Ali

>Where Bridges in a Bridged LAN are capable of connecting the individual 
>MACs in such a way that
>frames between two stations may get out of order for the reasons I 
>described before; irrespective of the state of the network. Again, I 
>invite you to site an example where a miniscule possibility of such an 
>out-of-order spells disaster for a protocol (at session initiation time).
>
>
>where a rare case of mis-order between broadcast-path frame and 
>unicast-path frame.
>
>changes in big-I network are at quite different scale. If one was to 
>compare the number of out-of-order packets due to topo-changes in big-I 
>network to out-of-order packets due to 2 PW, one would wonder where the 
>real problem is.
>Regards,
>Ali