Thanks Pascal, just integrated your suggestions to the latest version. On Sat, Dec 7, 2019 at 12:00 AM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote:
> Very good Tengfei > > This addresses my comments. > > Note that the uppercase NOT is not a valid BCP14 term by itself. I’d > reword to say that the distribution of traffic over multiple parents is a > routing decision that is out of scope for MSF... > > > Regards, > > Pascal > > Le 6 déc. 2019 à 12:01, Tengfei Chang <tengfei.ch...@gmail.com> a écrit : > > > I will add the following text at the intro part of MSF draft: > > > > > > > * MSF works closely with RPL, specifically the routing > parent defined in <xref target="RFC6550" format="default"/>. > This specification only describes how MSF works with one routing parent, > which is phrased as "selected parent". The activity of MSF > towards to single routing parent is called as a "MSF session". > Though the performance of MSF is evaluated only when the "selected > parent" represents node's preferred parent, there should be no restrictions > to go multiple MSF sessions, one per parent. In case that > traffic goes into multiple parents, MSF is NOT in charge of deciding how > many traffic to assign or to which parent. This should be > decided by either upper layer or some other entity in charge of traffic > distributing.* > > Then replace the sentence in the draft from "preferred parent" to > "selected parent". > > What are your comments on this, Pascal, Yatch? > > On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) < > pthub...@cisco.com> wrote: > >> Hello Yatch >> >> >> >> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> a >> écrit : >> > >> > Thank you, Pascal for your comment. >> > >> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote: >> >> RPL underneath is designed to operate with multiple parents, and for a >> good reason. >> > >> > I understand that point. >> > >> > My point is, rephrasing the word alone couldn't be enough. >> > >> >> Bandwidth allocation doesn’t care what traffic that is or it’s >> direction. It cares about the amount of traffic that needs to circulate >> over the hop. >> > >> > In general, yes. According to the current text of MSF, the direction is >> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just >> after recognizing it. For a downward neighbor, it doesn't. >> > >> > On parent switch, the number of negotiated cells is carried over to a >> new parent. But what if a node has one parents at some point, then it >> selects an additional parent to handle some portion of traffic? How many >> negotiated cells should be scheduled with the new (additional) parent? MSF >> would have no idea. >> > >> > To me, this seems a totally new thing to MSF. >> > >> >> Not that new just the logical continuation. >> >> If a child has 2 parents a and b these are independent links, each with a >> number of cells. If it loses one parent a then the traffic on that link is >> rerouted. The cells on that link have to be moved to other parents which >> can include b. >> >> The existing cells to the parent b are not touched. If some traffic is >> rerouted to parent b then new cells are allocated there. >> >> >> > Again, having multiple MSF instances could be a solution, which doesn't >> need the rephrasing. >> >> For me instance is related to RPL I do not want to run multiple instances >> of RPL with one preferred parent each. >> >> What I want is to run what the draft describes but several times in >> parallel once per active parent. >> >> That’s what I called session. RPL says that a node can run separate >> instances like ship in the night and then describes the operw of one >> instance. Similarly MSF can run multiple sessions one per link as ship in >> the night. pretty much the draft needs to do is say that in introduction >> and then say that the rest of the draft describes one session with one >> parent. >> >> >> And it is possible to run an MSF session at L2 with each of them >> totally independently. >> > >> > What do you mean by "MSF session"? If you have multiple MSF instances >> with different SFIDs or values for the Metadata field, they can be >> associated with different RPL DODAGsm and they will work independently. >> > >> >> The draft describes a session between a parent and a child. They start >> the session, allocate resources in unison and when the session is broken >> they release the resources on each side. This happens within a L2 link. >> Sessions can live independently on different L2 links. >> >> >> >> > On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote: >> > > Would it be then a neighbour instead of a parent? (Assuming the >> > > neighbour has joined the network) >> > >> > I don't think so. >> > >> >> As Yatch said the draft describes a child handling both sides so the link >> is directional, there’s a master and a slave. >> >> This may become a problem for east west traffic with PDAO. But there’s >> still a direction so it’s doable just need to agree that the parent is >> towards the destination. >> >> All the best, >> >> Pascal >> >> >> > Best, >> > Yatch >> > >> > _______________________________________________ >> > 6tisch mailing list >> > 6tisch@ietf.org >> > https://www.ietf.org/mailman/listinfo/6tisch >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > -- > —————————————————————————————————————— > > Dr. Tengfei, Chang > Postdoctoral Research Engineer, Inria > > www.tchang.org/ > —————————————————————————————————————— > > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
