<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>The discussion at yesterday’s meeting surrounding the presentation by <span style="font-size: 13px;">Huawei got me thinking.</span></div>
<div><span style="font-size: 13px;"><br>
</span></div>
<div><span style="font-size: 13px;">In most every switch I remember working on we add a tag to each packet at the ingress. It used to be that the tag was used to direct the packet across the backplane or the switch fabric to the required egress. These days
 the required egress is just as likely to be in the far corner of the same piece of silicon. However, in all cases, the egress is far enough removed from the ingress that it cannot share the parsed representation of the packet that was created during ingress
 processing.</span></div>
<div><span style="font-size: 13px;"><br>
</span></div>
<div><font size="2">It is likely that a large class of switch designs will want to avoid completely re-parsing the packet at the egress. To avoid re-</font><span style="font-size: small;">parsing</span><font size="2"> the packet it may be sufficient to expand
 the transit tag and have the ingress add a few pointers, indexes and flags sufficient for the egress to do its job. If so, at the egress, all we have to work with are the fields of the transit tag and an opaque packet header. I begin to see the justification
 for wanting to be able to specify table operations in terms of widths and offsets at least at the egress.</font></div>
<div><font size="2"><br>
</font>
<div>
<div>—Peter</div>
<div><br>
</div>
</div>
</div>
</body>
</html>