HI Sri,

On Mon, Feb 5, 2018 at 10:25 PM, Sri Gundavelli (sgundave) <
sgund...@cisco.com> wrote:

> Tom:
>
> Thanks! That sounds like some  interesting trick. But, let me make sure I
> understood this correctly.  So, the
>
identifier space for the MN is encoded in the upper 64-bits. Now, the UE
> can use those bits to generate any Identifier from that space, and use it
> with the SIR prefix to form the 128 bit address.  Bear with me, let me use
> an example
>
> MN1 is assigned a prefix  *2001:ABCD:CAFÉ*:   / 48
> MN2 is assigned a prefix  *2001:ABCD:FOOD*:  /48
>
> The SIR Prefix for that ILA domain is  2001:DB8::/64
>
> So, the SIR Addresses can be formed using the  16-bit identifier space
> left from the /48 prefix assignment? UE can form any identifier from bit
> space?
>
> No, we want allow a full /64 assignment since that is being already
deployed.


> I can’t figure out the scheme from this below text in 6.3.2. I think I am
> missing the context here. May be you guys discussed this before.
>

>
----
>
>    To support /64 prefix assignment with ILA, the ILA identifier can be
>    encoded in the the upper sixty-four bits of an address and the lower
>
>    sixty-four bits are ignored by ILA. Since only a subset of bits are
>    available, a level of indirection can be used so that ILA transforms
>    the upper sixty four bits to contain both a locator and an index into
>    a locator (ILA-N) specific table. The entry in the table provides the
>    original sixty-four bit prefix so that ILA to SIR address
>    transformation can be done.
>
> -----
>
>
The SIR prefix and identifier are encoded in the upper 64 bits. Assuming
the network has a /24, and address for /64 assignment might have this
format.

Network                    SIR/identifier                 IID
    24 bits                   40 bits                           64 bits
------------------------|------------------------------|--------------------------------------------------|

The IID part is arbitrarily assigned by the device, so that is ignored by
ILA. All routing, lookups, and transformations (excepting checksum neutral
mapping)  are based in upper sixty-four bits.

For SIR->ILA  transformation, a lookup is done on the upper sixty four
bits. That returns a locator that would have format something like:

 Network                   Locator                 Locator_index

    24 bits                   20 bits                  20 bits
------------------------|-----------------------|--------------------------|

The packet is forwarded and routed to the ILA addressed by locator (/44
route). ILA, the locator index is used as a key to an ILA-N specific  table
that returns the 40 bit SIR/identifier. This value is then written in the
packet do ILA->SIR transformation thereby restoring the original address.

The locator index is not globally unique, it is specific to each ILA-N.
When a node attaches to an ILA-N, an index is chosen so that the table is
populated at the ILA-N and the ILA mapping includes the locator and index.
When a node detaches from on ILA, it's entry in the table is removed and
the index can be reused after a holddown period to purge stale mappings.

Tom



> From: Tom Herbert <t...@quantonium.net>
> Date: Monday, February 5, 2018 at 9:13 PM
> To: Sri Gundavelli <sgund...@cisco.com>
> Cc: Lorenzo Colitti <lore...@google.com>, "i...@ietf.org" <i...@ietf.org>,
> dmm <dmm@ietf.org>
> Subject: Re: [DMM] Fwd: New Version Notification for
> draft-herbert-ila-mobile-00.txt
>
>
>
> On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) <
> sgund...@cisco.com> wrote:
>
>> > best practice is not to use singleton addresses, but always to provide
>> a /64 prefix.
>>
>> But, how does that work with ILA's approach of identifier management?
>> With the previously IETF recommended approaches in RFC5213 and even in 3GPP
>> architecture, per RFC3315, the network assigned  a set of unique prefixes
>> for each MN, allowed the MN to generate the identifiers.  Even CGA
>> addressing worked with the per-MN prefix model.
>>
>> But, with ILA there is no concept of prefix assignment. Will ILA network
>> now generate a identifier block for each MN?  Is DHCPv6 the only approach?
>>
>> Sri, see section 6.3.2. That describes encoding the identifier in the
> upper sixty-four bits and using an indirection table to accommodate network
> prefixes.
>
> Tom
>
> If that block is not summarizable, will it not result in mapping table
>> size getting multiple many times?
>>
>>
>> Sri
>>
>>
>>
>>
>>
>> From: dmm <dmm-boun...@ietf.org> on behalf of Lorenzo Colitti <
>> lore...@google.com>
>> Date: Monday, February 5, 2018 at 8:52 PM
>> To: Tom Herbert <t...@quantonium.net>
>> Cc: "i...@ietf.org" <i...@ietf.org>, dmm <dmm@ietf.org>
>> Subject: Re: [DMM] Fwd: New Version Notification for
>> draft-herbert-ila-mobile-00.txt
>>
>> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <t...@quantonium.net> wrote:
>>
>>> We like like to request that the dmm WG consider ILA as a candidate
>>> protocol for the 3GPP "Study on User Plane Protocol in 5GC".
>>>
>>
>> Echoing Tom's earlier comment about this: I think the address assignment
>> sections (6.3 and 8.3) should be reworded to clarify that for general
>> purpose hosts, best practice is not to use singleton addresses, but always
>> to provide a /64 prefix.
>>
>
>
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to