Re: [IPFIX] [GROW] [OPSAWG] WG adoption poll fordraft-li-opsawg-ipfix-bgp-community-02

PJ Aitken <[email protected]> Thu, 16 Feb 2017 12:17:25 +0000
Newsgroups gmane.ietf.ipfix
Message-ID <286d611d-32ae-7401-9790-a58f95301410__3606.6735782244$1487248084$gmane$org@brocade.com> 
--===============4830770214159870851==
Content-Type: multipart/alternative;
 boundary="------------4FFBB7D44CD467F5C1E090E3"

--------------4FFBB7D44CD467F5C1E090E3
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

If the list would be longer than can be accommodated in a single IPFIX 
message, then some mechanism would need to be defined to allow the list 
to be exported.

Ideally this should be a generic mechanism allowing the export of any 
large IPFIX content. However, it might be simpler to define a mechanism 
that's specific to the export of long lists.

There may be several solutions. eg, it might be a compression mechanism 
allowing the content to fit into a single message. Or the content might 
be carried across multiple messages.

If you feel it's an issue - especially if it would block your current 
work - then please start the discussion in the OPSAWG because the IPFIX 
WG is closed.

Thanks,
P.

On 16/02/17 12:02, 李振强 wrote:
> The length of IPFIX message is sufficient for BGP standard 
> communities, since the length of standard community is 4 octets. But 
> the sizes of extended community, large community and wide community 
> are bigger than the size of standard community. If the working group 
> agrees to cover the above all kinds of communities in this draft, do 
> you think we should open the discussion for IPFIX and basicList 
> message splitting?


--------------4FFBB7D44CD467F5C1E090E3
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    If the list would be longer than can be accommodated in a single
    IPFIX message, then some mechanism would need to be defined to allow
    the list to be exported.<br>
    <br>
    Ideally this should be a generic mechanism allowing the export of
    any large IPFIX content. However, it might be simpler to define a
    mechanism that's specific to the export of long lists.<br>
    <br>
    There may be several solutions. eg, it might be a compression
    mechanism allowing the content to fit into a single message. Or the
    content might be carried across multiple messages.<br>
    <br>
    If you feel it's an issue - especially if it would block your
    current work - then please start the discussion in the OPSAWG
    because the IPFIX WG is closed.<br>
    <br>
    Thanks,<br>
    P.<br>
    <br>
    <div class="moz-cite-prefix">On 16/02/17 12:02, 李振强 wrote:<br>
    </div>
    <blockquote
      cite="mid:2d89235f-bbd2-4774-9472-4c4cea99a0e4@Tims-iPhone"
      type="cite"><font size="3"><span
          style="-webkit-tap-highlight-color: rgba(26, 26, 26,
          0.301961); -webkit-text-size-adjust: auto; background-color:
          rgba(255, 255, 255, 0);">The length of IPFIX message is
          sufficient for BGP standard communities, since the length of
          standard community is 4 octets. But the sizes of extended
          community, large community and wide community are bigger than
          the size of standard community. If the working group agrees to
          cover the above all kinds of communities in this draft, do you
          think we should open the discussion for IPFIX and basicList
          message splitting?</span></font></blockquote>
    <br>
  </body>
</html>

--------------4FFBB7D44CD467F5C1E090E3--


--===============4830770214159870851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix

--===============4830770214159870851==--