Forwarding this discussion to BESS list as the main use case now is EVPN.
This draft is also on the BESS agenda.


From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, November 10, 2020 6:13 PM
To: Andrew G. Malis <[email protected]>; Stewart Bryant 
<[email protected]>
Cc: [email protected]; mpls 
<[email protected]>; [email protected]
Subject: RE: [Pals] Mail regarding 
draft-zzhang-tsvwg-generic-transport-functions

Hi Andy, Stewart,

If I understand it correctly, RFC4623 is specifically for PWs (p2p) and cannot 
be used for EVPN/VPLS.

The reason is that the sequence number in the control word is specific to the 
PW and the fragmentation/reassembly is performed in the context of the PW. In 
case of EVPN/VPLS, an egress PE could receive fragments from different ingress 
PEs and reassembly must be done in the right context.

In addition, RFC 7432 (EVPN) specifically calls out that control word is either 
not used or only with all-0:

   - If a network uses deep packet inspection for its ECMP, then the
     "Preferred PW MPLS Control Word" 
[RFC4385<https://tools.ietf.org/html/rfc4385>] SHOULD be used with the
     value 0 (e.g., a 4-octet field with a value of zero) when sending
     EVPN-encapsulated packets over an MP2P LSP.

   - If a network uses entropy labels 
[RFC6790<https://tools.ietf.org/html/rfc6790>], then the control word
     SHOULD NOT be used when sending EVPN-encapsulated packets over an
     MP2P LSP.

   - When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP,
     then the control word SHOULD NOT be used.

This draft-zzhang allows the context to be determined from the extended 
“identification” field or from the outer header. In addition, it is “generic” 
such that it can be used for any situations where fragmentation is needed at 
any layer for any solution.

Thanks.

Jeffrey

From: Andrew G. Malis <[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 10, 2020 10:33 AM
To: Stewart Bryant <[email protected]<mailto:[email protected]>>
Cc: 
[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]

Indeed, this is an already-solved problem.

Cheers,
Andy


On Tue, Nov 10, 2020 at 9:57 AM Stewart Bryant 
<[email protected]<mailto:[email protected]>> wrote:
Please can I draw the attention of the authors to 
https://tools.ietf.org/html/rfc4623<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4623__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1ENEdsSd$>

This standards track RFC  specifies how you can sent a fragmented Ethernet 
frame over a PW in an MPLS network and would seem applicable to the problem 
that you address in your draft.

BR

Stewart
_______________________________________________
Pals mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/pals<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!WnDW7J-i0YOpcV5sF1KDAfZnAaxHY5z-pG0oiSXKdSXdg9o9pRoRlJeq1KRQDg8M$>


Juniper Business Use Only
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to