Stewart, Please see zzh2> below.
From: Stewart Bryant <[email protected]> Sent: Thursday, November 19, 2020 1:21 AM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: Stewart Bryant <[email protected]>; Andrew G. Malis <[email protected]>; [email protected]; mpls <[email protected]>; [email protected]; [email protected] Subject: Re: [Pals] Mail regarding draft-zzhang-tsvwg-generic-transport-functions [External Email. Be cautious of content] On 11 Nov 2020, at 16:32, Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: 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. You should use 0000. This is the IP version number space. 4 and 6 are taken as IP. BIER sits on 3, PWs sit on 0 and 1 (for OAM), and of course there is a chance that INT might like invent another IP at some time in the future (a general note and nothing to do with NewIP). Zzh> Agreed. Now what I am not sure about is why you need a next header as this is not needed elsewhere in MPLS PWs. Zzh> PW fragmentation is in the context of PWs, and the egress PE does not need to care what the payload it is. Zzh> With *generic* fragmentation, the egress PE does need to care what the reassembled payload is to continue processing, that’s why it needs a “next header” field. If you do, then I would suggest that 16 is likely too few. Zzh> Because of that, what was presented in BIER/BESS is that the “Hdr Len” field, not the “Next Header” field gets squeezed. The Next Header field is still 8-bit. The “Hdr Len” is 4-bit but in the unit of 8-octets, so it should be enough (and we could make it 16-octet units if necessary). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Next Header |Hdr Len| Fragment Offset |R|S|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The standard MPLS method is to trigger processing from the label, so if you want to do other processing then why not allocate a new label so you can vector straight to the right packet handler. Zzh> There is a GFH label in front of the GFH, and that tells the packet handler that a GFH follows (and optionally tell who did the fragmentation – the reassembling node can advertise different GFH labels for different fragmenting nodes). Zzh> It’s what happens after the reassembly that requires the “Next Header” in the GFH. Consider the EVPN-MPLS example, the fragments received by the egress PE have the following headers: <label stack1, GFH, label stack2>, where the label stack1 is <transport labels, GFH label> and the label stack2 is <EVPN related labels>. In potential other use cases (we’re talking about “generic” fragmentation), the payload after the GFH may be other types. What I think you need is the existing PW frag design with the identification field appended. Then to advertise those propertied with the label. Zzh> The intention is to have a generic solution, not tied to EVPN-MPLS or PW. You can see that while the immediate use case is EVPN-MPLS, the solution is not tied to it. *In theory*, this can be used for fragmenting at Ethernet level between two Ethernet nodes. Zzh> Thanks! Zzh> Jeffrey - Stewart Juniper Business Use Only
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
