Brian, Answers below.
Le 16 mars 2010 à 03:58, Brian E Carpenter a écrit : > Rémi, > > Let's take it for granted that > > a) it is possible to design a general format for mapping rules, > that would work in a variety of scenarios including map-and-encap > and NAT; > > b) the format and examples in the draft are complete and correct; > > c) tunnel end points and NATs can be "taught" to obey such maps. > > Then consider this: > >> 2.7. Acquisition of Mapping Rules by Customer Nodes >> >> For early experimentations or advanced uses, a customer SAM may >> acquire the SAM rules of its SAM domain by administrative >> configuration. But for extensive deployments, they must be acquired >> automatically. The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can be >> used for this. Alternatively, in particular for scenarios where >> NAT44s have to be traversed, using the DNS as proposed in section 6 >> of [DNS-SD] can be a better approach. > > That implies that the map for a given point is acquired automatically, > but it doesn't explain how the map is created. In customer SAMs, mapping rules are always acquired automatically. In provider SAMs, there are many scenarios where it is reasonable to configure them administratively. (This is like in 6rd, where 6rd parameters are administratively configured in 6rd BRs, and automatically acquired by 6rd CEs). > It seems that for usage > at Internet scale, the maps would have to be generated and propagated > automatically. Isn't this a hard problem I am not sure to understand what you mean by "the map". The hierarchy of exterior prefixes follows the classical model of CIDR prefixes. That's all. The example of section 3.4 (the planned Telecom-Bretagne experiment) shows a 2-layer hierarchy of SAM domains, which may be a partial answer. Besides, deriving provider-SAM rules from locally available parameters is internal to each provider-side BR. Where configuration of mapping rules in provider SAMs should be automated, proprietary solutions are therefore possible. (Having a standard for this can be nice, but is not necessary). > (exactly the same problem > that arises for LISP)? Or have I misunderstood the deployment model? In my understanding, the fact that LISP addresses have a distinct format makes it necessary that LISP be supported both in source and destination domains that communicate across the Internet core. On the contrary, SAM addresses are routable like any native addresses everywhere outside of SAM domains themselves. The deployment can therefore be incremental (similarly to that of 6rd, of which SAM is an extension). RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
