Thank you Hannu for your comments. I found the word ‘anchor’ 18 times in the draft, and I agree with you that those need to be clarified.
Best regards, --satoru > 2018/09/05 20:53、Flinck, Hannu (Nokia - FI/Espoo) > <hannu.fli...@nokia-bell-labs.com>のメール: > > Hello > > The draft SRv6-mobile-userplane seems to use the term “anchor” or > “anchoring” quite a lot, but what exactly is meant is much unclear. It looks > to me that the meaning changes during the progression of the text, or depends > on the context. As it appears to be such key term of the draft I would > recommend that you define it somewhere in this document. > > In details: > > On page 7 you talk about “anchoring SID” and “next anchoring point”. In the > traditional mobility settings there is one anchoring point. So, I do not know > what is “next anchoring point”.. > > Then on page 17 you mention “anchoring functionality”. What is this > functionality exactly? Has it something to do with mobility anchors as in > “Distributed Mobility Anchoring” and/or “Proxy Mobile IPv6 extensions for > Distributed Mobility Management” drafts that also talk about mobility anchors? > > Finally, the last sentence of the draft “ It's notable that SRv6's network > programming nature allows a flexible > and dynamic anchor placement.” Given all the options of the anchoring in > this draft, I do not know that this means? Flexible mobility anchor > placement? Next anchor placement? Anchoring SID placement maybe? > > What do you mean by saying “All control-plane protocols are expected to > leverage these function type-codes to signal each function” ? Does it mean > that all control planes need to be implemented to use these function types? > Or carry them or what exactly? > > Best regards > Hannu > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
