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-rfc677
12 bit field would be more than enough plus it maps to all the schemas for
802.1q based topology separation. This started out as an enterprise
networking discussion and it would be at the right scale for anyone in that
business without complaints and an easy way to scale with 2547, EVPN or
even Lo
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 n
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 opaq
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
correla
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 |O
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 i
