Yes, we do have discussions over RIFT where it seems a multi-plane or if you want multi-topology concept as introduced originally in RFC5120 would be helpful. RIFT can be very easily instantiated on multiple ports and with that has no problem to run multi-instance/topology but the dataplane correlation from the leaf would be very helpful. RIFT leaf implementation is very "thin" and with that architectures that don't rely on either LOC-ID or BGP overlays become feasible, albeit obviously not @ the scale something like 2547bis or EVPN can operate.
So in short, I think I support this suggestion fully. For the practical encoding, I suggest to choose TID=0 as "default topology", i.e. "what you do today" and avoid an I bit which will cause an encoding corner case if it's not set but TID<>0? >From experience, 8 bits is just about enough but 12 bits are plenty for # of topologies people sometimes think they need on building network architectures ... my 2c ... --- tony On Thu, Apr 12, 2018 at 7:23 AM, Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hi again > > > > A proposed text would be like: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | Status | Opaque | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Rsvd | I |R|T| TID | Registration Lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ... Registration Ownership Verifier ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > …. > > > > Opaque: > > One-byte Opaque field; this is an octet that ND does not need to > process > > but that the 6LN wishes the 6LR to pass transparently to another > process. > > I: > > Two-bit Integer: A value of zero indicates that the Opaque field > carries > > an abstract index that is used to decide in which routing topology > the > > address is expected to be injected. In that case, the Opaque field > is > > passed to a routing process with the indication that this is a > topology > > information and the value of 0 indicates default. All other values > are > > reserved. > > > > > > Does that work? > > > > Pascal > > > > *From:* Pascal Thubert (pthubert) > *Sent:* jeudi 12 avril 2018 15:40 > *To:* email@example.com > *Cc:* Yan Filyurin <yanf...@gmail.com>; Tony Przygienda < > tonysi...@gmail.com>; draft-ietf-6lo-rfc6775-upd...@ietf.org > *Subject:* instance ID in rfc6775 update > > > > Dear all : > > > > During a conversation on the RIFT protocol it appeared that there are use > cases in RIFT to support host mobility with rfc6775-update. > > There is a caveat, though, which is in fact common with RPL. Both cases > need a concept of multi topology routing. > > In the case of RPL, the topology is indexed by an instance ID. In the case > of RIFT, there is a need for an index to a RIB, so one octet is probably > enough. > > A suggestion is thus to use the reserved octet in the ARO to carry an > instance ID, and use a bit to signal that this is what that field does, in > case there is a need later to overload it with something else. > > > > I understand this is coming late in the process; but then there is no > logic associated to the change, this is just passing on an additional > information that is useful for more than one candidate protocol. > > > > Please let me know if there is an issue pursuing this. If there is no > opposition, my plan it currently to add this in rev-19. > > > > All the best, > > > > Pascal >
_______________________________________________ 6lo mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/6lo