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

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

[e-mail] escribió:
> I'm confused with your explanation.
>
> What is a CGN for you?
>
>   
section 2.1.1. of draft-arkko-townsley-coexistence-00

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