Re: [shara] First draft of the shara use cases for review

[<[e-mail]>]

 
>>     
> I understand that you have a hierarchy of Port routers, so that a port
router on the top of the hierarchy delegates a  port raneg to another
port router, which in turn delegated sub ranges of this initial port
range to other port routers or to port resticted nats or to end hosts,
and that is what i want to describe by including multiple port routers
and the tunnel technology between them... makes sense?
>
> Med: Several PRRs are required to be deployed inside a service domain
realm. The current proposed solution does not assume a hierarchy between
these PRRs. But in some scenarios, two PRRs **may** intervene in the
delivery of connectivity services. These cascaded PRRs is required
because the involved parties are not managed by the same PRR. BTW, we
can imagine a hierarchy between PRRs, but this is solution specific and
should IMHO avoided in this slot.
>
>   

by hierarchy i meant that a PRR1 has IP1 and PR1 and there is another
PRR2 which gets IP1 and PR2 from PRR1, so that PR2 is included in PR1. I
understnad that all approaches support this, so that i why i thought
this was solution agnostic... am i wrong?


Med: What your are describing can be supported, but this is not
recommended from an operational perspective. Only one level of PRRs is
required. Solutions should be easier and simple to manage. O&M should be
taken into account. Having this hierarchy may introduce some complexity.
I believe this is solution oriented discussion, and if required, should
be covered at the solution space preso.


> Do you think i am missing something?
>
>
> Med: Fine. The translation mode is not covered. See the following flow
example:
>
>         +--+             +---+            +-----+               +--+
>         |M1|             |CPE|            |i-PRR|               |RM|
>         +--+             +---+            +-----+               +--+
>           |                |                 |                    |
>           |==(1)IPv6_Out==>|==(2)IPv6_Out===>|==(3)Pub_IPv4_Out==>|
>           |                |                 |                    |
>           |<==(6)IPv6_In===|<==(5)IPv6_In====|<===(4)Pub_IPv4_In==|
>           |                |                 |                    |
>
>                         Figure 19: Translation Mode
>
>
>   

but this is covered in use case 3 afacis. The main difference is that
the v4 v6 translator is located deeper into the ISP network. Now, i fail
to see how this fits in the shara case, since i guess this would be the
CGN variation of the v4 v6 translator, rather than the share variations,
if you see what i mean.

Med: IPv4-inferred IPv6 prefixes are assigned to end-users. The enclosed
IPv4 addresses are shared between several customers. Only an IPv6
connectivity is offered. The core and the CPE/Home gateway/terminal are
IPv6-only. The interconnection between IPv6 and IPv4 realms are
stateless.


In other words, in the v4v6 transaltor case, you can either place it
near the customer, whoch would be the sahra flavor of it, or you can
place it in the ISP network, which would be the CGN flavor of it.


Med: This is a terminology issue: both CGN and port range are shared IP
address solutions.


What you depict in the figure seems the CGN flavor, i.e. the translator
is far from the client, so i would assume this is not partof the shara
effort.


Med: It is not a CGN flavor. It is a port range one.


what am i missing?


Med: Instead of enabling IPv4-in-IPv6 encapsulation to reach devices
sharing the same IPv4 address, all internal communications are
IPv6-only. Communications issued from IPv4 world are translated to IPv6.
The traffic is then routed, owing to IGP capabilities, to the device
among those having the same IPv4 address. Note that the shared IPv4
address is not used to send or to received traffic but it is used to
build an IPv4-inferred IPv6 prefix.  
Please refer to the draft for more information.