Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Luca Muscariello <[e-mail]>]

I am sorry but I'm not sure I get your question right.
I am not sure SRv6 is just a tunnelling technique but I am not right person
to talk about that.

We do mention SRv6 in the draft to show how hICN can use it to steer the
next-hop path for the request
carrying the ID in the DST addr field and  for the reply to steer the
next-hop path carrying the locator
in the DST addr field.

In the first place hICN makes use of the IPv6 FIB. This is the default. But
there are several
interoperable protocols that might be included in the next-hop pipeline
processing.

Does it clarify your doubts?

Luca



On Wed, Jun 20, 2018 at 4:54 PM Behcet Sarikaya <[e-mail]>
wrote:

>
>
> On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) <
> [e-mail]> 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 <[e-mail]> on behalf of Behcet
>> Sarikaya <[e-mail]>
>> *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 <
>> [e-mail]> 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 <[e-mail]> wrote:
>>>
>>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>>>> <[e-mail]> 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 <[e-mail]>
>>>> wrote:
>>>> >>
>>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>>>> >> <[e-mail]> 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-mobility-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
>>>> >> > [e-mail]
>>>> >> > https://www.ietf.org/mailman/listinfo/dmm
>>>> >> >
>>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>
>