Re: [6lo] instance ID in rfc6775 update

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

Re: [6lo] instance ID in rfc6775 update

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

Re: [6lo] instance ID in rfc6775 update

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

Re: [6lo] 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

Re: [6lo] 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 |

[6lo] 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