> The MAP-MIB draft has been updated as -03 version. > > In IETF85@Atlanta, we had a brief discussion, and the main comment was from > Mark Townsley. He pointed out that the tunnel table defined in the draft > would make the BR recording every CEs' addresses connected to it. This > operation would somewhat counterbalance the benefit of stateless design. > Basically, Mark's comment is a real issue, but not that serious. The tunnel > table needs the translation/encapsulation application to provide CE address > to the MIB agent, that might slightly impact the forwarding performance, but > it is far from the weight of "stateful", because the the BR tunnel table is > not for real-time look up, it is just a kind of logging. In the worst > situation, even the MIB crash, the packet forwarding won't be bothered. > > The purpose we defined a tunnel table is to add some statistics of CE > connecting BR. For example, the ISP might want to know how many/what CEs had > been connected to a certain BR. This might be useful for service analysis > and management, e.g. to static percentage of MAP enabled and the traffic, so > that the ISP could learn the status of MAP deployment/usage, then might make > some policies. > Considering the tunnel table might still more or less bring some additional > complexity, we defined it as an optional object in the MIB. We defined two > map-MIB-Compliance, one is basic compliance only containing the rule table, > the other is full compliance containing rule table and tunnel table.
how is the BR supposed to learn the CE addresses? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
