Even though I didn't make Michael Meisel's short-list of acknowledged contributers, I'd like to offer a thought:
>The other option would be for the ITR to punt the packets to its default >mapper, as in APT. The ITR's default mapper has the full mapping table, >and delivers the packet while sending the ITR the mapping info for its >cache. If we are going to do this, I'd like to see it done in a way that preserves the model of the DFZ as a giant NBMA link on which all xTR's are one-hop neighbors. That means that, when the ITR punts a packet to the Default Mapper (DM), I want for the DM to *not* decapsulate the packet but rather examine its mapping tables based on the inner destination address and *rewrite* the outer destination address to an RLOC of the ETR. So, the packet coming in to the DM would have: inner_src=EID(A) inner_dst=EID(B) outer_src=RLOC(ITR) outer_dst=RLOC(DM) and (after the DM does the mapping lookup) the packet coming out of the DM would have: inner_src=EID(A) inner_dst=EID(B) outer_src=RLOC(ITR) outer_src=RLOC(ETR) In this way, the DM is "off-link" from the viewpoint of the ETR, and the ETR gets to perform link-scoped operations (e.g., IPv6 ND) with the ITR as if it were an on-link neighbor. Is this what you had in mind? The alternative is for the DM to decapsulate, perform the mapping, then re-encapsulate while injecting its RLOC as the outer_src in the transaction, which makes it such that the ITR is off-link from the viewpoint of the ETR - not so good for link-scoped operations. I would prefer option A, if that is OK with you. Fred [EMAIL PROTECTED] _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
