OK, I read too fast then ;-) The opaque is what we call TID then (topology ID, I observe that we ran out of good 3 letter acronyms years ago ;-)
agreed with all ... 0 for default topology helps obviously because you say "0 on send, ignore on receive" on a good spec so even if the other side is not aware of the extension, good chance they'll send you 0 which you interpret as "hey, default stuff" and life goes on in default topology --- tony On Thu, Apr 12, 2018 at 8:49 AM, Pascal Thubert (pthubert) < [email protected]> wrote: > Hello Tony > > > > I agree that 0 is default, this helps for backward compatibility as well. > > Note that the field is not the TID (T is for transaction). I’m proposing > to add a new Opaque field since what is carried is opaque to ND. > > New text would say: > > > > A new Opaque field is introduced to carry opaque information in > case the > > registration is relayed to another process, e.g.; injected in a > routing > > protocol. > > A new "I" field provides an abstract type for the opaque > information, and > > from which the 6LN derives to which other process the opaque is > expected > > to be passed. > > A value of Zero for I indicates an abstract topological information > to > > be passed to a routing process if the registration is > redistributed. > > In that case, a value of Zero for the Opaque field is > backward-compatible > > with the reserved fields that are overloaded, and the meaning is to > use > > the default topology. > > > > 8 bits is what’s left in the option that we need to keep backwards > compatible. > > > > 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 ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What do you think? > > > > Pascal > > > > *From:* Tony Przygienda <[email protected]> > *Sent:* jeudi 12 avril 2018 17:43 > *To:* Pascal Thubert (pthubert) <[email protected]> > *Cc:* [email protected]; Yan Filyurin <[email protected]>; > [email protected]; [email protected] > *Subject:* Re: instance ID in rfc6775 update > > > > 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) < > [email protected]> 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 protected] > *Cc:* Yan Filyurin <[email protected]>; Tony Przygienda < > [email protected]>; [email protected] > *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 [email protected] https://www.ietf.org/mailman/listinfo/6lo
