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

[marcelo bagnulo braun <[e-mail]>]

[e-mail] escribió:
>  
>   
>>>     
>>>       
>> 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.
right, i am not assuming it neither, i am just stating that it is possible

>  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.
>
>   
maybe, imho, this is just to keep the scenario generic, as i said, it is 
not required, but possible

>   
>> 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.

right, this is what is provided in use case 3
>  The core and the CPE/Home gateway/terminal are
> IPv6-only.

this is why i think this is a CGN use case rahter than a shara use case

>  The interconnection between IPv6 and IPv4 realms are
> stateless.
>
>   
this seems to be solution space to me

> 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.
>
>   
if, the only difference between CGN and port range is a terminology one, 
i am afraid i fail to see the point of this work

> 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.
>
>
>   
i guess we simply disagree here

> 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.
>
>   
right, but you achieve all this by moving the NAT deeper into the network.

regards, marcelo