> I believe we discussed this last time but, with the new perspective, couldn’t > we just use the pair <IID, site-ID> to at least get per VLAN granularity in > some of these decisions.
Yes, that would work better since the site-ID is in the Map-Register (where you need the xTR distinction) and the IID is in the EID encoding of the EID-record where you need the VLAN association. So this is ideal. > We get the same benefits: no impact on the bis document, and some extra > granularity in the choice of DF or more detail when implementing split > horizon on the xTRs. Right. Agree. > And just to complete the story. When we use site-IDs this means that: > > • An EID registered with the same site-ID (and merge-bit) from > different xTRs is merged. If site-IDs differ this is considered a move. Correct. But you have to deal with misconfiguration so 2 xTRs at the same site advertising a different site-ID doesn't look like a move. So the xTR-ID needs to be checked as well. > • For “discovery” purposes in multihomed groups: An L2 EID registered > from one xTR and a specific site-ID, needs to be notified to all xTRs that > are using that same site-ID You have to keep a list of xTR-IDs for a merged registration over time. And the list is cleared when a new xTR-ID is discovered with a different site-ID. Right? Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
