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

[<[e-mail]>]

Hi Marcelo, all,

Please see inline.

Cheers
Med
 

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

Hi,

thanks for the comments


[e-mail] escribió:
> Dear Marcelo, all
>
> Thank you for these slides. Please find below some comments:
>
> - Slide 4: 
> 1/ To avoid confusion with overlapped port ranges, I suggest to have something like (IP1, PR1), (IP1, PR2) etc, assigned to port restricted devices instead of P1...P2, P2...P2 notation. 
>   
done

> 2/ Port Range Router is not **necessarily** connected to what you call "rest of Internet IPv4".
>   
It, is by definition of the Rest of the Internet :-) No, more seriously, I basically was including there all the rest of the IP world, so, by definition, it is connected to the rest of the internet. But i understand that you find this confusing somehow. If you explain what  bothers you, i can try to fix it.

Med: The location of the PRR in the Service Provider domain (i.e. AS) is not necessarily at interconnection border (i.e. near to an ASBR) even if in some scenarios it can be (e.g. IPv6 context). But at the level of the presentation, this subtleties should be avoided. To avoid confusion, I suggest that a PRR node to be drawn inside the service provider cloud. This cloud is then connected to what you call the rest of Internet.
 

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

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


Cheers,
Med