Re: [mpls] [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[Stewart Bryant <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi Andy, Stewart,
>  
> Please see zzh> below.
>  
> From: Andrew G. Malis <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, November 11, 2020 8:17 AM
> To: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Cc: Jeffrey (Zhaohui) Zhang <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; mpls <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> 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 <[e-mail] <mailto:[e-mail]>> 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
>