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

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

Stewart,

Please see zzh2> below.

From: Stewart Bryant <[e-mail]>
Sent: Thursday, November 19, 2020 1:21 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]

On 11 Nov 2020, at 16:32, Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>> 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