Re: [BEHAVE] draft-chen-behave-rsnat-01

[Chen Gang <[e-mail]>]

Hello lijitsch van,

Please see my reply in line.


2009/7/29 Iljitsch van Beijnum <[e-mail]>

> I have reread the draft.
>
> If I understand correctly, the idea is to use BGP to synchronize state
> between multiple stateful translators, where each translator handles a part
> of the address space used in translation at any time. Many people will argue
> that this deviates too far from BGP's purpose.


=>The intention choosing BGP is targeting to IPX Internet to IPY Internet
scenario, in which BGP is quite suitable.

>
>
> I can see that argument, but rather than convince you to not use BGP for
> this, I would like to explain that _if_ you're going to use BGP for this,
> you'll have to think about how to do that.


=>Thanks


>
>
> What you need is for mapping information to be exchanged that consists of
> IPv4 and IPv6 source and destination addresses and ports and the protocol.
> That's 9 items. You can probably optimize a few of them away, but using the
> normal IPv4 address family would require you to encode the remaining
> information in a new path attribute. However, this doesn't work: if
> translator A has a mapping from 2001::2001 to 192.0.2.1 and translator B
> from 2002::2002 to 192.0.2.1, then if they both announce this to translator
> C, C would not combine this information but rather select either the info
> from A or from B.


=>  New defined attribute processing will guarantee the synchronization work
done. Why can't translator C do the combination things?


>
>
> (And you define the attribute as transitive, which means that it would be
> propagated in eBGP, which is unnecessary and has the potential for problems
> when the information leaks.)

=> For avoiding information leaks, how about define new capability
attribute?


>
>
> What would work better here if you defined a new address family that
> consists of the concatenation of source address, source port, destination
> address, destination port. This could be either IPv4 or IPv6. Then the other
> protocol version addresses and ports plus the protocol number would be
> encoded in a path attribute. This way, each mapping would be a separate NLRI
> in the new AFI and there would be no problem merging the information.


=> Extending BGP might be a light-weight way to do mapping thing. Could you
provide more detailed explanations for defining a new address family?

Thanks for the discussion.

BRs

Gang