Re: [6lo] instance ID in rfc6775 update

[Tony Przygienda <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]>
> *Sent:* jeudi 12 avril 2018 17:43
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]; Yan Filyurin <[e-mail]>;
> [e-mail]; [e-mail]
> *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) <
> [e-mail]> 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:* [e-mail]
> *Cc:* Yan Filyurin <[e-mail]>; Tony Przygienda <
> [e-mail]>; [e-mail]
> *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
>
>
>