Re: [6lo] instance ID in rfc6775 update

[Pascal Thubert (pthubert)]

Dear all :

I just published -19 including this change and to my best knowledge, the draft 
now incorporates all that was reported so far.

Cheers,

Pascal



From: Pascal Thubert (pthubert)
Sent: jeudi 12 avril 2018 16:23
To: 6lo@ietf.org
Cc: Yan Filyurin ; Tony Przygienda ; 
draft-ietf-6lo-rfc6775-upd...@ietf.org
Subject: RE: instance ID in rfc6775 update

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: 6lo@ietf.org
Cc: Yan Filyurin >; Tony Przygienda 
>; 
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
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] instance ID in rfc6775 update

[Tony Przygienda]

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) <
pthub...@cisco.com> 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 
> *Sent:* jeudi 12 avril 2018 17:43
> *To:* Pascal Thubert (pthubert) 
> *Cc:* 6lo@ietf.org; Yan Filyurin ;
> draft-ietf-6lo-rfc6775-upd...@ietf.org; r...@ietf.org
> *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) <
> 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:
>
>

Re: [6lo] instance ID in rfc6775 update

[Pascal Thubert (pthubert)]

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 
Sent: jeudi 12 avril 2018 17:43
To: Pascal Thubert (pthubert) 
Cc: 6lo@ietf.org; Yan Filyurin ; 
draft-ietf-6lo-rfc6775-upd...@ietf.org; r...@ietf.org
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) 
> 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: 6lo@ietf.org
Cc: Yan Filyurin >; Tony Przygienda 
>; 
draft-ietf-6lo-rfc6775-upd...@ietf.org
Subject: instance ID in rfc6775 update

Dear all :

During a conversation on the RIFT 

Re: [6lo] instance ID in rfc6775 update

[Tony Przygienda]

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:* 6lo@ietf.org
> *Cc:* Yan Filyurin ; 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
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] instance ID in rfc6775 update

[Pascal Thubert (pthubert)]

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: 6lo@ietf.org
Cc: Yan Filyurin ; Tony Przygienda ; 
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
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] instance ID in rfc6775 update

[Pascal Thubert (pthubert)]

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
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo