Subject: [Softwires] MAP-MIB request for comments

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Feb 2013 12:39:32 +0000

Hi, All

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. 

We expect your comments. Thanks a lot!

All the best,
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 07, 2013 8:01 PM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]; Fuyu (Eleven); Sheng Jiang
Subject: New Version Notification for draft-fu-softwire-map-mib-03.txt

A new version of I-D, draft-fu-softwire-map-mib-03.txt
has been successfully submitted by Bing Liu and posted to the
IETF repository.

Filename:	 draft-fu-softwire-map-mib
Revision:	 03
Title:		 Definitions of Managed Objects for MAP-E
Creation date:	 2013-02-07
WG ID:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-fu-softwire-map-mib-03.txt
Status:          http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib
Htmlized:        http://tools.ietf.org/html/draft-fu-softwire-map-mib-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-fu-softwire-map-mib-03

Abstract:
   This memo defines a portion of the Management Information Base (MIB)
   for using with network management protocols in the Internet
   community. In particular, it defines managed objects for MAP
   encapsulation mode.

The IETF Secretariat

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Feb 2013 13:48:57 +0100

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

how is the BR supposed to learn the CE addresses?

cheers,
Ole

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 8 Feb 2013 06:56:33 +0000

Hi, Ole

Thanks for your quick reply.

In order to do the statistics, the BR need a bit more codes to extract the CE IPv6 addresses when doing de-encapsulation.
That is what we said in the last mail the operation might slightly impact the performance, so we defined this MIB function as optional.  

All the best,
Bing

> From: Ole Troan [mailto:[email-masked]]
> Sent: Thursday, February 07, 2013 8:49 PM
> To: Liubing (Leo)
> Cc: Softwires WG; [email-masked]; Yong Cui
> Subject: Re: [Softwires] MAP-MIB request for comments
> 
> > 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.
>