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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Stewart,

I hope you did not mean that the draft should not be presented. Whether detailed discussions can happen after the presentation in the session itself depends on many factors (we quite often run out of time in the sessions), and the presentation itself quite often is a good way to stir up wide discussions.

Thanks to your review and comment, I think we’re having good discussions on mailing lists on the draft. I hope I have answered your questions and addressed your main concerns, and I hope more people chime in, before and after the presentations in relevant WGs.

Thanks.
Jeffrey


From: Stewart Bryant <[e-mail]>
Sent: Thursday, November 12, 2020 7:16 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Stewart Bryant <[e-mail]>; Andrew G. Malis <[e-mail]>; [e-mail]; mpls <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions

[External Email. Be cautious of content]

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]<mailto:[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



Juniper Business Use Only