I would like to at least see a sentence indicating that if a
configuration of egress processing needs instance IDs that differ on the
upper 8 bits, they need separate ETR instances.
Using the incoming RLOC is risky at best, and probably will fail in
real-world circumstances.
I think there needs to be some explanation in the LCAF draft. The more
verbose explanation can be in the VPN draft.
Yours,
Joel
On 5/2/16 3:16 PM, Dino Farinacci wrote:
I have a problem. I was hoping to stay out of this.
Glad you joined in.
But the proposed description does not work.
Well we can improve on it.
Since xTRs form overlapping sets, I don't see any way to assign IDs to
Instances such that any given xTR does not need see the upper 8 bits of the
instance-ID it receives.
Well the lisp-vpn document could explain in more detail. We had one, it
expired, and I think its going to refreshed soon. I’ll contact the authors.
If the argument were that we want future flexibility, so we are supporting 32
bits in the control plane, I could see it. But as written, I would not know
what to do in an Etr or ITR if I had an Instance ID with the upper bits set?
Do I truncate on send, and compare only the lower 24 bits upon receipt? Once
we start needing the upper byte, I don't see how that could work very long.
Here is an example.
Say a network administrator wants to configure instance-IDs 0x800000ff and
0x000000ff each on different interfaces. Much like VRFs can be configured. This
xTR *could* encap with this configuration but cannot decap. So let’s go through
each direction:
(1) When a packet arrives on interface 0x800000ff, the ITR knows what map-cache
to use based on the 32-bit instance-ID. If there is a cache miss, it can do a
32-bit lookup and the mapping system will certainly return RLOCs for the given
EID being requested (the extended EID as defined in the DDT spec).
(2) Let’s say the RLOCs go to ETRs that are configured with instance-ID
0x800000ff. So when packets arrive at this ETR, the data header indicates
0x0000ff. The ETR has no problem finding the correct routing table for 0x0000FF
(it is the same as 0x800000FF). That is there are two names for the table.
(3) Let’s say the RLOCs that are returned for an EID lookup for 0x000000FF
(which is unique from 0x800000ff in the mapping system) for another ETR. And
that ETR is configured with only the instance ID 0x000000ff (just like the ETR
in (2)). Here there is no problem. And encapsulated packets to 0x0000ff go to
to the ETR for decap and delivery.
(4) If the ITR in (1) is also an ETR and gets encapsulated packets for
0x0000ff, it has some choices:
(a) Don’t allow this to happen and disallow the configuration so the xTR in
(1) looks like
the xTRs in (2) and (3).
(b) Check both tables for an EID match. And use the one that matches. This
assumes globally
unique addresses so the EID is in either one or the other table but not
both.
(c) Do a source RLOC lookup where the xTR can register what instance-IDs it
supports so you can get
the other 8 bits.
This needs to be explained in a use-case document on the usage of assigning
instance-IDs. The LCAF spec needs to resist putting these details in there, but
just describe the encoding and the format of messages.
Comments?
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
