Re: Mail regarding draft-zzhang-tsvwg-generic-transport-functions

Just to add a bit to Stewart's replies, I assume that you've read RFC 8469,
which was the result of the "disorderly queue of operators at the door of
PALS".

Also, regarding VPLS, VPLS is just a full mesh of P2P Ethernet PWs, and
while RFC 4762 is silent on the CW, in practice many (most?) VPLS
implementations use the CW.

Cheers,
Andy


On Wed, Nov 11, 2020 at 8:11 AM Stewart Bryant <[email protected]>
wrote:

> Oh there is a deeper problem
>
> Unless you guarantee that you have defeated ECMP, which I don’t think the
> design does since first nibble is not 0000, I think the different fragments
> can get ECMPed differently. If that happens then (unlike the PW case) you
> cannot be sure that the fragments will arrive on the same LC, and that
> means that you need to support cross line card reassembly. If that happens
> your performance falls through the floor.
>
> Of course you could argue that it will mostly work, just like people
> argued that not having the CW would work well enough in PW, and it did
> mostly work, until it didn’t and we had a disorderly :) queue of operators
> at the door of PALS WG.
>
> Now what happens in the VPN cases in the existing design is that just like
> PW you will be seeing occasional Ethernet reordering, which mostly does not
> matter because what is being carried is IP, but as we found out in PALS it
> sometimes does matter an it is very difficult for the operators to
> diagnose, and then it does matter. However what you have is potentially
> much worse because you will accumulate fragments on different line cards,
> or have a very complex implementation problem to reassemble at speed.
>
> - Stewart
>
>

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals