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

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

[e-mail] escribió:
>
>   
>> 3/ What is the role of the two represented PRRs? 
>>
>> - Slide 5: Idem as slide 4
>>
>>   
>>     
> 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?

>> - Slide 7: 
>> 1/ Why you need a tunnel between represented two routers? 
>>
>>
>>   
>>     
> see the answer above
>
>   
>> FYI, additional IPv6-related use cases are defined in draft-boucadair-behave-ipv6-portrange-01. Two modes are defined: encapsulation and translation mode:
>>   
>>     
> AFAIU, the encapsulation mode is covered in Use case #2 and the translation mode is covered in Use case #3 I mean, in use case #2, IPv4 over IPv6 tunnels are considered and in the use case#3 we cover the case where the IPv6 client wants to connect to an IPv4 server.
>
> I agree that the NAT64 function can be located in different parts of the network, but i understand than the closer we keep the nat function tothe customer, the better.
>
> 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.

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.

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.

what am i missing?

Regards, marcelo


> Cheers,
>   



> Med
>
>