On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < gcaro...@cisco.com> wrote:
> This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > I don't understand. SRv6 is tunneling technique while hICN is talking about anchoress mobility. Did I get something wrong? Behcet > Giovanna > ------------------------------ > *From:* Int-area <int-area-boun...@ietf.org> on behalf of Behcet Sarikaya > <sarikaya2...@gmail.com> > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscarie...@gmail.com> wrote: > >> I wonder whether this conversation should happen in the intarea wg >> mailing list >> as the main draft was posted there in the first place. I don't know if >> cross posting is welcome >> but I take the risk. >> >> Going back to the question, the transport changes are related to the >> request/reply semantic >> of the architecture. The two distinct forwarding paths described in the >> draft take care >> of forwarding requests or replies.This ends up in the transport layer as >> a unidirectional >> channel to recv data or snd data. The replies carry data originating from >> a transport end-point (snd buffer) >> that binds to an identifier which is location independent, an IPv6 number >> which is not a locator. >> >> The forwarding path of the requests is very close to unmodified IPv6 with >> the DST address carrying the identifier. >> If you check in the draft an hICN node does one additional lookup in a >> local cache though. But you can ignore that >> for now for sake of clarity. What is important is the address rewrite >> operation made on the SRC address >> of the request. A copy of the request is stored in the local cache and >> the locator of the output interface is written in the >> SRC address before transmission. This is used by an upstream hICN or the >> final end-point to know the locator that >> will be used to reply. >> >> Replies coming from the snd end-point are label swapped but not like >> MPLS. >> The label is the identifier itself that is stored in the SRC address of >> the reply, >> whereas the DST address is a locator. In this forwarding path a lookup is >> made in the local cache to >> find a request (one or many) and the associated locator (one or many) >> that matches the identifier. >> The DST addr field of the replies is rewritten with the locator(s) just >> obtained from the lookup. >> This is how the reply is forwarded to the end-points that issued requests >> for this identifier. >> >> For the replies there is no FIB lookup on the identifier (as it is in the >> SRC addr field). >> There can be a lookup in the FIB on the locator stored in the DST of the >> reply to >> reach back the previous hICN node or eventually the original end-point. >> >> >> >> > > Hi, > > My humble question is: are you supporting SRv6 or hICN? > > Regards > Behcet > > >> >> >> >> >> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <t...@quantonium.net> wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> <luca.muscarie...@gmail.com> wrote: >>> > The paragraph you reported is from the draft that describes hICN to >>> enable >>> > several use cases. >>> > Mobility is one of those, not the only one. >>> > To clarify, the draft on hICN mobility deployment options focuses on >>> the 5G >>> > service based architecture. >>> > >>> > You may be asking >>> > 1) is it possible to get all the features provided by hICN w/o updates >>> to >>> > the transport layer? >>> > 2) is changing the transport protocol unnecessary difficult to enable >>> all >>> > the use cases mentioned in the draft? >>> > >>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>> idea of hICN is to put routes in the local routing table and use >>> existing forwarding and routing to forward packets to mobile nodes. So >>> if a node changes location, then the routing tables need to be >>> updated. Effectively this is a bunch of host routes that need to be >>> maintained. At least this is what I gather from the draft: >>> >>> "hICN network layer is about using the IPv6 FIB to determine a next >>> hop router to forward requests or using a local packet cache to >>> determine if an incoming request can be satisfied locally." >>> >>> Is this correct? If it is, then I sort of understand how hICN could be >>> used for mobility or virtualization without network overlays, but then >>> I'm completely lost as to why this would require any changes in the >>> transport layer. >>> >>> Tom >>> >>> >>> >>> >>> >>> > IMO, the answers are no for both. >>> > >>> > Luca >>> > >>> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <t...@quantonium.net> >>> wrote: >>> >> >>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>> >> <luca.muscarie...@gmail.com> wrote: >>> >> > Hi all, >>> >> > >>> >> > the draft below has been posted and describes deployments options >>> for >>> >> > anchorless mobility management by using >>> >> > the hicn network architecture that implements icn semantics in IPv6 >>> >> > networks. >>> >> > >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobilit >>> y-deployment-options >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >>> >> > >>> >> > A background document has been posted to the internet area WG and >>> >> > reported >>> >> > here for your convenience. >>> >> > The core principle behind hicn and mobility management is that data >>> >> > sources >>> >> > are named using location independent names >>> >> > encoded in IPv6 addresses. The transport service sitting on top of >>> the >>> >> > hicn >>> >> > architecture is not based on usual TCP/UDP sockets >>> >> > but on a novel consumer/producer transport service that will be >>> >> > described in >>> >> > another draft. >>> >> >>> >> From the draft: "The transport end-point offers two kinds of services >>> >> to applications: a producer and a consumer service. The service is >>> >> instantiated in the application by opening communication sockets with >>> >> an API to perform basic transport service operations: allocation, >>> >> initialization, configuration, data transmission and reception." >>> >> >>> >> This seems like a pretty dramatic rethink of the transport layer just >>> >> for the purposes of mobility management. Will there be a way to use >>> >> hICN at the network layer with exsiting and unmodified transport >>> >> protocols (i.e. can this be done without boiling the ocean)? >>> >> >>> >> Thanks, >>> >> Tom >>> >> >>> >> >>> >> >>> >> > The current document and a companion document that will be posted >>> soon >>> >> > describe the different deployment options >>> >> > with special care to the 5G service based architecture. >>> >> > Thanks for the comments already received that helped completing >>> this -00 >>> >> > draft. >>> >> > >>> >> > Luca >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > dmm mailing list >>> >> > d...@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/dmm >>> >> > >>> >> >> _______________________________________________ >> dmm mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
