Subject: Re: [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 14 Feb 2017 13:46:17 +0000

Hi there,

[Copying GROW WG as this might be relevant to their coverage areas]

The document seems to be a good start but covers only standard 
communities. This is not sufficient given the universal deployment of 4 
octet ASNs. Both extended communities [RFC4360] and large communities 
[RFC8092] are needed and are used to address the signalling requirements 
for AS4 ASNs. Having separate documents each addressing only a specific 
type of community does not seem practical and rational. The document 
should include the definitions for IEs covering extended and large 
communities.

What is the logic of selecting multiple communities for export that a 
prefix may have been decorated with? Is it all of them all the time? The 
upper limit may be reaching 16000 standard communities per prefix - 
would that fit into resulting IPFIX IE? If there is a limit, how does it 
work? Is there any interpretation done on the values of the communities 
(all types, not just standard ones)? Those all are operational 
considerations aspects and should be covered in the document, appendix A 
likely could be a good place for it.

Security considerations on the privacy aspects would to be covered.

Ignas

On 13/02/2017 03:36, Tianran Zhou wrote:
> Dear OPSAWG,
>
> In Seoul, we got enough interest and positive response on this IPFIX IE extension draft.
> By the authors' request, this email starts a formal poll. The chairs would like to know if the WG participants agree that the following document should be adopted as a WG document in OPSAWG.
>
> Export BGP community information in IP Flow Information Export (IPFIX)
> https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-02
>
> The adoption poll will take two weeks. Please let us know your opinion by Feb 27. It would also be good to hear who is willing to review and/or implement or deploy the extension described in the document.
>
> Since we already found that the majority of the f2f participants at our IETF97 session like this idea, please do speak up now if you do not agree or have serious objections (with explanation of course).
>
> Regards,
> Tianran
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 16 Feb 2017 11:15:17 +0800

Dear Ignas,

Thank you very much for your support and suggestion.

Since the problem to be solved in this draft comes from the field network, we only provide the method to carry standard BGP commmunities in IPFIX. Extended communities are ususlly used for other purposes than standard communities, such as route target, actions for BGP flowspec etc. Whether or not we really need to cover entended communities, I want to see more comments. Large communities are relavitely new. RFC8092 was published recentlly.  Anyway, however, it is easy for us to cover both extended communities [RFC4360] and large communities [RFC8092] after the adoption and further comment consensus. Text contribution is welcome. By the way, I want to know the opinions about the wide communities. Do we need to cover them together?

As you said, this draft was a good start. It has value to be a working group item. We can continue the comments and discussion after the adoption and we will improve the document according to the consensus. Operational considerations will be covered in the next version.

Best Regards,
Zhenqiang Li
China Mobile
 
-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Ignas Bagdonas
Sent: Tuesday, February 14, 2017 9:46 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked] [email-masked] <[email-masked]>
Subject: Re: [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02
 
Hi there,

The document seems to be a good start but covers only standard communities. This is not sufficient given the universal deployment of 4 octet ASNs. Both extended communities [RFC4360] and large communities [RFC8092] are needed and are used to address the signalling requirements for AS4 ASNs. Having separate documents each addressing only a specific type of community does not seem practical and rational. The document should include the definitions for IEs covering extended and large communities.
 
What is the logic of selecting multiple communities for export that a prefix may have been decorated with? Is it all of them all the time? The upper limit may be reaching 16000 standard communities per prefix - would that fit into resulting IPFIX IE? If there is a limit, how does it work? Is there any interpretation done on the values of the communities (all types, not just standard ones)? Those all are operational considerations aspects and should be covered in the document, appendix A likely could be a good place for it.

Ignas

 
 
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: PJ Aitken <[email-masked]>
Date: Thu, 16 Feb 2017 11:15:24 +0000

Ignas Bagdonas wrote:

 > The upper limit may be reaching 16000 standard communities per prefix 
- would that fit into resulting IPFIX IE? If there is a limit, how does 
it work?

A quick calculation suggests that the maximum would be 16376 x 4-octet 
ASNs. See the figure below.

The constraining factor is the RFC7011 IPFIX Message Header "Length" 
field, since this is only 16 bits.

Splitting a list across multiple IPFIX messagesis a question which the 
IPFIX community hasn't discussed.Unfortunately the basicList "Semantic" 
field only defines the relationship among the different values within a 
single message; the relationship among values in different messages is 
not defined.

IPFIX Collectors might reasonably assume that information in subsequent 
messages supersedes information in earlier messages, so splitting a list 
across multiple messages would not have the desired effect.

      0                   1                   2                   3      
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|       Version Number          |        Length = 65532         |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|                           Export Time                         |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|                       Sequence Number                         |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|                    Observation Domain ID                      |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|          Set ID = 256         |         Length = 65516        |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
|      255      |      List Length = 65509      | semantic=allOf|     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | 
      bSCL FieldId = 459       |      bSCL Field Length=4      |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | 
              bgpSourceCommunityList value 1 = x               |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | 
              bgpSourceCommunityList value 2 = x               |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      
                               ...     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | 
              bgpSourceCommunityList value 16376 = x           |     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Feb 2017 16:14:20 +0000

On 16/02/2017 11:15, PJ Aitken wrote:
>
> IPFIX Collectors might reasonably assume that information in 
> subsequent messages supersedes information in earlier messages, so 
> splitting a list across multiple messages would not have the desired 
> effect.
>
>

Hi Paul

Could you not have multiple discrete templates?

Stewart

---

From: PJ Aitken <[email-masked]>
Date: Thu, 16 Feb 2017 21:10:00 +0000

Stewart: yes, there could be multiple templates with multiple data records.

However there's nothing to provide the necessary "All of <these>" 
semantics to allow the collector to join up the lists in a meaningful 
way - ie, specifying which lists to use / not to use, and in which order 
if that's important.

Also, the data held by the collector may be indeterminate as the data 
records change - eg if list#1 and list#4 were updated, but updates 
hadn't yet been received for list#2 and list#3. So there'd have to be a 
"hold" time when nothing is changing and/or a signal that the current 
state is good - which then leads to questions of how to handle data loss 
(eg, if the update for list#2 wasn't received in time, or arrived late.

If single packet data export is no longer sufficient - as seems likely - 
then, since we already have several ideas, it'd be worth some IPFIX 
experts pondering what the correct solution should be.

P.

---

From: Paolo Lucente <[email-masked]>
Date: Thu, 16 Feb 2017 23:52:23 +0100

Hi,

I support Ignas comment with regards to Extended and Large communities.

Can you make evident the role, ie. via an example, of the bgpCommunity
IE compared to the one of bgpDestinationCommunityList?

Also, i'm puzzled by the presence of bgpSourceCommunityList: i see that
in "1. Introduction" you kind of close that up saying that there is a
Mediator that would take care of the correlation - understandable but
then again we all know with a (loosely determined) level of indirection
any problem can be addressed; since you also say the draft comes "comes
from the field network", i was wondering whether you were subtending to
reverse BGP lookups to make this work in practice. In which case, i'd
say warning flag: BGP lookups against the source IP address/prefix of a
flow would be of no general applicability at all - think, for example,
to the common case of an ISP (remotely) connected to an IXP where you
have N BGP peers and hence potentially multiple advertisements per
prefix, which one you pick for correlation would not be a deterministic
exercise.

Paolo

> On 16 Feb 2017, at 04:15, [email-masked] wrote:
> 
> Dear Ignas,
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 20 Feb 2017 16:58:32 +0800

Hi Paolo，

Thank you for you opinion. The extended and large communities will be considered after the adoption and according to the working group consensus.

Please see the appendix  in the draft for the example. bgpDestinationCommunityList is a basicList of bgpCommunity.

If you don't like the BGP communities according to the source IP of a specific flow, you can indicate it in the templete, i.e. do not specify bgpSourceCommunityList IE in the templete set. Then the exporter will not export the information. 

bgpSourceCommunityList does have values in some network environments. For example,  the overalll network of China Mobile consists of a backbone network and several province networks. Each component network is configured with a few communities. BGP anounces those communities among the component networks. When one province wants to know where (i.e. from which provinces) its incoming traffic comes from, it can use bgpSourceCommunityList.

Best Regards,
Zhenqiang

[email-masked]
 
From: Paolo Lucente
Date: 2017-02-17 06:52
To: lizhenqiang
CC: zhoutianran; opsawg; opsawg-chairs; grow; [email-masked]
Subject: Re: [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02
 
Hi,

 
 
Paolo