In my view, the discussion on this draft demonstrate that it is not yet ready for detailed discussion by these working groups next week.
- Stewart > On 11 Nov 2020, at 16:32, Jeffrey (Zhaohui) Zhang <[email protected]> wrote: > > Hi Andy, Stewart, > > Please see zzh> below. > > From: Andrew G. Malis <[email protected] <mailto:[email protected]>> > Sent: Wednesday, November 11, 2020 8:17 AM > To: Stewart Bryant <[email protected] > <mailto:[email protected]>> > Cc: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; mpls > <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > Subject: Re: [Pals] Mail regarding > draft-zzhang-tsvwg-generic-transport-functions > > [External Email. Be cautious of content] > > 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". > > Zzh> Actually I need to read on that yet. > > 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. > > Zzh> OK if VPLS relies on data plane mac learning for packets received from > the core then indeed they’re a full mesh of PWs and that’s different from > EVPN. I’ll need to dig deeper into that. Still, if we solve the EVPN problem > using the generic fragmentation method, the solution works for VPLS/PW as > well. > > Cheers, > Andy > > > On Wed, Nov 11, 2020 at 8:11 AM Stewart Bryant <[email protected] > <mailto:[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. > > Zzh> I see what you mean. Perhaps we can separate the one-octet “Next Header” > from the existing IP “Next Header” space so that the first nibble is always > 0000? That gives us 16 types of “Next Header” – or we only need to make sure > the nibble is not 4 or 6 – that gives us more types. > > Zzh> Thanks. > > Zzh> Jeffrey > > 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 > > > Juniper Business Use Only >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
