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

[<[e-mail]>]

I'm confused with your explanation.

What is a CGN for you?

Cheers
Med



-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[e-mail]] 
Envoyé : vendredi 20 mars 2009 18:32
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [e-mail]
Objet : Re: [shara] First draft of the shara use cases for review

[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