Subject: Re: [ipfix-info] BGP related Information Elements

From: Benoit Claise <[email-masked]>
Date: Wed, 04 May 2005 16:14:09 +0200

Danny,

>
> On Apr 26, 2005, at 8:39 AM, Benoit Claise wrote:
>
>>
>> If I configure the router in AS3 to export the origin AS's (for the 
>> one familiar with NetFlow), the flow record contains:
>> AS1 and AS5, exported in #16 and #17 respectively. This is OK.
>>
>> If I configure the router in AS3 to export the peer AS's (for the one 
>> familiar with NetFlow), the flow record contains:
>> - AS2 and AS4 (**), exported in #? (*) and #128 (**) respectively
>>
>> (*) I don't find the respective I.E.
>> (** ) attention: according to the current definition, if "bgp 
>> next-hop self" is configured on the router in AS3, this I.E. will 
>> report AS3!!
>
>
> And indeed the BGP NEXT_HOP is most always most always within
> the local AS, unless on the AS egress border router.  I'm not sure
> I understand why anyone would want to report on the "origin AS"
> value for the BGP NEXT_HOP anyways.  Could someone explain this to
> me?  The BGP NEXT_HOP itself makes sense, but recursive lookups
> for the "origin AS" of the BGP NEXT_HOP seems a bit silly to me -
> perhaps I'm missing something?
>
>> So I don't think the current I.E. #128 is useful as we have to know 
>> on the collector's side whether next-hop self is configured on not!
>
>
>
>> I would like to propose that 1. we change #128 to bgpDstPeerASNumber 
>> with a new definition (to avoid the problem with the next hop-self)
>> 2. we change #129 to bgpSrcPeerASNumber. Why changing #129 and not 
>> using the a new I.E? Because I think it was the intended goal behind 
>> its definition.
>>
>> 5.4.6  bgpDstPeerASNumber
>
>
> I'd prefer a name with bgpDstAdjacentASNumber or the like, as this is 
> still a bit
> confusing.

Make sense.

>
>>  Description:
>>    The autonomous system (AS) number of the next AS in the AS path to 
>> which packets of this flow are forwarded.
>
>
> "next AS" should probably read something like "leftmost" or "first" AS 
> segment
> in the AS_PATH, where the term "segment" is employed to accommodate 
> either
> a single AS or an AS_SET.
>
>>
>>  Abstract Data Type: unsigned16
>
>
> Could be multiple entries with an AS_SET.

I think we have a technical problem right now in IPFIX. We can't report 
an AS_SET. How can we report that the bgpDstAdjacentASNumber is not a 
single unsigned16, but list of unsigned16? This is not possible!
So a quick and dirty solution... why not say: export 0 for AS_SET.
Anyway, reporting the AS_SET is not that useful on the collector. If 
AS_SET = (100, 200, 300), it means that most specific routes of this 
aggregate  prefix comes from either 100, either 200, either 300.

>
>>  Data Type Semantics: identifier
>>
>>  ElementId: 128
>>  Status: current
>>
>>  Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
>>    definition of the AS number.
>
>
> s/BGB-4/BGP-4/
>
> Also, you might want to scrap the RFC 1930 reference and just use
> RFC 1771 or ietf-idr-bgp-26.txt.
>
>>
>> 5.4.6  bgpSrcPeerASNumber
>
>
> Same issue..  Something like bgpSrcAdjacentASNumber or the like.
>
>>
>>  Description:
>>     The autonomous system (AS) number of the previous AS in the AS 
>> path     from which packets of this flow arrived. In case of BGP 
>> asymmetry, the         bgpPreviousAsNumber might not be able to 
>> report the correct value.
>
>
> Note the "Previous" in the name above.  Also, should you say something 
> about
> source and destination prefixes here and above, it might help 
> implementers, per
> this would be a "first" or "leftmost" AS segment in the AS_PATH for 
> the source
> IP prefix in the BGP Loc-RIB that contains the source IP prefix, while 
> above it's
> the destination prefix, etc..

Any proposal?

Regards, Benoit.

>
>>
>> Data Type Semantics: identifier
>>
>> ElementId: 129
>>
>> Status: current
>>
>> Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
>>    definition of the AS number.
>
>
> Also, in addition to accounting for AS_SETs, we should account for 
> AS_CONFED_*
> segments as well.
>
> Same as above..
>
> -danny
>
>
> -- 
> Help        mailto:[email-masked] and say "help" in 
> message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Danny McPherson <[email-masked]>
Date: Fri, 6 May 2005 10:16:56 -0600

On May 4, 2005, at 8:14 AM, Benoit Claise wrote:

> I think we have a technical problem right now in IPFIX. We can't 
> report an AS_SET. How can we report that the bgpDstAdjacentASNumber is 
> not a single unsigned16, but list of unsigned16? This is not possible!

Right..

> aggregate  prefix comes from either 100, either 200, either 300.

This would have to apply uniformly across all these elements, as
any of these could return AS_SET:

16 bgpSourceAsNumber
17 bgpDestinationAsNumber
128 bgpNextAdjacentAsNumber
129 bgpPreviousAdjacentAsNumber
149 ipNextHopAsNumber

I would suspect that 16, 17 and 149 would very frequently
reside within the local AS - which would most intuitively be
represented by '0', I think..  For that matter, any of these
could return local AS (or is it no_adjacent_AS? :-)

Given my admittedly terse review of the draft, I don't see
behavior defined for where these values should be derived,
and in particular, how local AS (or no AS?) should be
reported.  Do you envision local AS being reported as a
function of the router knowing what AS the local BGP process
resides in?  Else that local AS value isn't added to the path
until advertised to an eBGP peer.

I'd be a bit cautious about using '0', and perhaps specify
that local AS (and no AS) always return '0'.  This would
align with the BGP Spec:

[snip from BGP spec]
When a BGP speaker originates a route then:

a) the originating speaker includes its own AS number in a path
   segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE
   messages sent to an external peer. (In this case, the AS number of
   the originating speaker's autonomous system will be the only entry
   the path segment, and this path segment will be the only segment
   in the AS_PATH attribute).

b) the originating speaker includes an empty AS_PATH attribute in
   all UPDATE messages sent to internal peers.  (An empty AS_PATH
   attribute is one whose length field contains the value zero).

[/snip]

So given b) above, returning zero for local AS wold seem intuitive.

As for accommodating AS_SET, I'm not quite sure.  Would it be
unreasonable to report multiple elements of the same type here if
an AS_SET is returned, or is this a bad idea (I expect so)?

To further complicate things, I suspect we'll be seeing
this in deployments within a couple years, per AS number
depletion:

http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt

I'm not sure if we want to worry about it now or define
new elements down the road..

Regarding 149, ipNextHopAsNumber:

-----
5.6.3  ipNextHopAsNumber
    Description:
       The autonomous system (AS) number of the next IP hop to which
       packets of this flow are forwarded.

    ElementId: 149

    Status: current
    Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 a
       definition of the AS number.
-----

Is this element returning the AS number for the IP address reported
in the BGP NEXT_HOP attribute associated with the destination prefix,
or it the RIB/FIB IP "next hop" used to reach that destination?  This
should be stated explicitly.

>>
>> Note the "Previous" in the name above.  Also, should you say 
>> something about
>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, 
>> while above it's

Not sure if these are any better, but:

5.4.4  bgpSourceAsNumber
    Description:
       The first (origin) autonomous system (AS) number for the
       prefix containing the source address in the IP packet header
       in a packet of this flow.

5.4.5  bgpDestinationAsNumber
    Description:
       The first (origin) autonomous system (AS) number for the
       prefix containing the destination address in the IP packet
       header in a packet of this flow.

And I'd still like to see similar information elements added for
AS_CONFED_SET & AS_CONFED_SEQUENCE.

-danny

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 May 2005 13:10:42 +0200

Danny and all,

In order to continue the discussion with a clear basis, here is the list 
of proposed BGP-related I.E.s. I've been trying to insert all suggestions.
This should answer some of your questions below.
Feel free to review and to propose some new text if some improvements 
are required.

| 16 | bgpSourceAsNumber                           
| 17 | bgpDestinationAsNumber
| 18 | bgpNextHopIpV4Address
| 63 | bgpNextHopIpV6Address
| 128 | bgpNextHopAsNumber
| 129 | ipNextHopAsNumber

5.4.4  bgpSourceAsNumber
   Description:
      The autonomous system (AS) number of the source address in the IP
      packet headers of this flow. In case of AS-SET, the value 
      of 0 is reported.

   ElementId: 16

   Status: current
   Reference: See RFC 1771 for a description of BGP-4.

5.4.5  bgpDestinationAsNumber
   Description:
      The autonomous system (AS) number of the destination address in
      the IP packet headers this flow. In case of AS-SET, 
      the value of 0 is reported.

   ElementId: 17

   Status: current
   Reference: See RFC 1771 for a description of BGP-4.

5.4.7  bgpNextHopIpV4Address
   Description:
      The IPv4 address of the next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv4Address

   ElementId: 18

   Status: current
   Reference: See RFC 1771 for a description of BGP-4.

5.4.8  bgpNextHopIpV6Address
   Description:
      The IPv6 address of the next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv6Address

   ElementId: 63

   Status: current
   Reference: See RFC 1771 for a description of BGP-4.  

5.4.6  bgpDstAdjacentASNumber
 Description:
   The autonomous system (AS) number of the first AS in the AS path to 
which packets of this flow are forwarded, deduced by looking up the 
source IP address of the flow in the BGP routing information base. In 
case of AS-SET, the value of 0 is reported.

 ElementId: 128

 Status: current

 Reference: See RFC 1771 for a description of BGP-4.

5.4.6  bgpSrcAdjacentASNumber

 Description:
    The autonomous system (AS) number of the last AS in the AS path from 
which packets of this flow arrived, deduced by looking up the source IP 
address of the flow in the BGP routing information base. In case of BGP 
asymmetry, the bgpSrcAdjacentASNumber might not be able to report the 
correct value. In case of AS-SET, the value of 0 is reported.

ElementId: 129

Status: current

Reference: See RFC 1771 for a description of BGP-4.

See inline.

>> report an AS_SET. How can we report that the bgpDstAdjacentASNumber 
>> is not a single unsigned16, but list of unsigned16? This is not 
>> possible!
>
>
> Right..
>
> reside within the local AS 

BTW, typo 149 -> 129.
I don't see how the local AS would be reported with the definitions of 
16/17.
The definition of 129 has been changed. I guess it's ok now.

> - which would most intuitively be
One solution could be to specify multiple new AS-SET related I.E., such 
mplsLabelStackEntryX in MPLS.

My personal view is that (in order to finish this IPFIX work who has 
been lasting to long IMHO ;)), we should post the draft with the I.E.s 
we require right now, and use the IANA procedure for any other I.E.s. 
Otherwise, I fear the job will never be finished.

> should be stated explicitly.

I hope the new definition above is OK now.

Regards, Benoit.

> AS_CONFED_SET & AS_CONFED_SEQUENCE.

As expressed above, if you require them, make a proposal.

Regards, Benoit.

---

From: Eric Ji <[email-masked]>
Date: Mon, 09 May 2005 11:28:33 -0700

Benoit,

Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not 
uncommon that BGP asymmetry happens a lot in real world, and this 
element may cause problem in real use for applications built on, if it 
reports wrong information. And there's no easy way to verify that inside 
IPFIX itself.

Regards,
Eric

Benoit Claise wrote:
> | 16 | bgpSourceAsNumber                           | 17 | 
> bgpDestinationAsNumber
>      packet headers of this flow. In case of AS-SET, the value      of 0 
> is reported.
> 
>      the IP packet headers this flow. In case of AS-SET,      the value 
> of 0 is reported.
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 May 2005 21:35:45 +0200

Eric,

> reports wrong information. And there's no easy way to verify that 
> inside IPFIX itself.

I share with your concern.
However, I propose to keep this I.E.s for 2 reasons.
1. This BGP asymmetry and peer source AS / asymmetry issue is not new: 
we do already export this value in NetFlow version 9 today.
2. you will have a wrong value for bgpSrcAdjacentASNumber only in the 
case of multi-access interfaces (typically an ethernet interface at an 
IXP). In other interface types, you would be able to deduce if the value 
is correct or not, i.e. if there is some asymmetry

Regards, Benoit.

>
> Regards,
> Eric
>
>
> Benoit Claise wrote:
>
>> Danny and all,
>>
>> In order to continue the discussion with a clear basis, here is the 
>> list of proposed BGP-related I.E.s. I've been trying to insert all 
>> suggestions.
>>      the IP packet headers this flow. In case of AS-SET,      the 
>> value of 0 is reported.
>>
>>    The autonomous system (AS) number of the last AS in the AS path 
>> from which packets of this flow arrived, deduced by looking up the 
>> case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able 
>> to report the correct value. In case of AS-SET, the value of 0 is 
>> reported.
>>
>>>> Anyway, reporting the AS_SET is not that useful on the collector. 
>>>> If AS_SET = (100, 200, 300), it means that most specific routes of 
>>>> this aggregate  prefix comes from either 100, either 200, either 300.
>>>
>>>
>>>
>>>
>> I don't see how the local AS would be reported with the definitions 
>> of 16/17.
>> One solution could be to specify multiple new AS-SET related I.E., 
>> such mplsLabelStackEntryX in MPLS.
>>
>> been lasting to long IMHO ;)), we should post the draft with the 
>> I.E.s we require right now, and use the IANA procedure for any other 
>> I.E.s. Otherwise, I fear the job will never be finished.
>>
>>>  
>>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH 
>>>>> for the source

---

From: Eric Ji <[email-masked]>
Date: Tue, 10 May 2005 14:43:32 -0700

Benoit,

Now that it's already used, I have no issue with keeping it, given that 
its limitation is well documented.

Another minor points, we may change the following wording,
"In case of AS-SET, the value of 0 is reported." to
"In case of AS-SET, and can't be easily retrieved from BGP, the value 0 
is reported."
That leaves space for other ways to get this information now, such as 
through ebgp neighbor AS for edge routers. And it doesnt close the door 
for new ways to discover this later on, such as examining the exit point 
or topology.

Regards,
Eric

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 May 2005 08:30:16 +0200

Eric,

> Benoit,
>
> Now that it's already used, I have no issue with keeping it, given 
> that its limitation is well documented.
>
> "In case of AS-SET, and can't be easily retrieved from BGP, the value 
> 0 is reported."
> through ebgp neighbor AS for edge routers. And it doesnt close the 
> door for new ways to discover this later on, such as examining the 
> exit point or topology.

Do you want to say "In case of AS-SET or can't be easily retrieved from 
BGP, the value 0 is reported."?
Because, even with AS-SET, the AS can be easily retrieved. The issue is 
to export it in IPFIX :)

Regards, Benoit.

>>> element may cause problem in real use for applications built on, if 
>>> it reports wrong information. And there's no easy way to verify that 
>>> inside IPFIX itself.
>>
>>
>>
>> 1. This BGP asymmetry and peer source AS / asymmetry issue is not 
>> new: we do already export this value in NetFlow version 9 today.
>> case of multi-access interfaces (typically an ethernet interface at 
>> an IXP). In other interface types, you would be able to deduce if the 
>> value is correct or not, i.e. if there is some asymmetry
>>
>> Regards, Benoit.
>>
>>>
>>> Regards,
>>> Eric
>>>
>>>
>>> Benoit Claise wrote:
>>>
>>>> Danny and all,
>>>>
>>>> Feel free to review and to propose some new text if some 
>>>> improvements are required.
>>>>
>>>>   The autonomous system (AS) number of the first AS in the AS path 
>>>> to which packets of this flow are forwarded, deduced by looking up 
>>>> the source IP address of the flow in the BGP routing information 
>>>> base. In case of AS-SET, the value of 0 is reported.
>>>>
>>>> source IP address of the flow in the BGP routing information base. 
>>>> In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be 
>>>> able to report the correct value. In case of AS-SET, the value of 0 
>>>> is reported.
>>>>
>>>>>> report an AS_SET. How can we report that the 
>>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of 
>>>>>> unsigned16? This is not possible!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Right..
>>>>>
>>>>>> If AS_SET = (100, 200, 300), it means that most specific routes 
>>>>>> of this aggregate  prefix comes from either 100, either 200, 
>>>>>> either 300.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> My personal view is that (in order to finish this IPFIX work who 
>>>> has been lasting to long IMHO ;)), we should post the draft with 
>>>> the I.E.s we require right now, and use the IANA procedure for any 
>>>> other I.E.s. Otherwise, I fear the job will never be finished.
>>>>
>>>>>

---

From: Eric Ji <[email-masked]>
Date: Wed, 11 May 2005 11:13:49 -0700

Benoit,

I think I didn't express well. What I meant was is to get _the_ AS, 
i.e., the real single adjacent AS. We can't get that from AS_SET. But 
under certain situations, it can be get from BGP other part rather than 
ASpath, as said in previous email, or new ways to discover it later on. 
So I proposed to add that line, to keep the door open for those. Then 
the exporter would do a best effort on this, and report 0 only when all 
current methods fails.

Regards,
Eric

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 May 2005 16:45:04 +0200

Eric,

Then the wording should be something like this:
"In case the BGP AS can't be easily retrieved (for example in case of 
AS-SET), the value 0 is reported."

So this sentence should replace all the instances of "In case of AS-SET, 
the value of 0 is reported." in the proposal at
http://ipfix.doit.wisc.edu/archive/2796.html

Do we all agree? If not, you should propose your own text.

Regards, benoit.

> under certain situations, it can be get from BGP other part rather 
> than ASpath, as said in previous email, or new ways to discover it 
> later on. So I proposed to add that line, to keep the door open for 
> those. Then the exporter would do a best effort on this, and report 0 
> only when all current methods fails.
>
> Regards,
> Eric
>
>
> Benoit Claise wrote:
>
>> Eric,
>>
>>> Benoit,
>>>
>>> "In case of AS-SET, and can't be easily retrieved from BGP, the 
>>> value 0 is reported."
>>> That leaves space for other ways to get this information now, such 
>>> as through ebgp neighbor AS for edge routers. And it doesnt close 
>>> the door for new ways to discover this later on, such as examining 
>>> the exit point or topology.
>>
>>
>>
>> Do you want to say "In case of AS-SET or can't be easily retrieved 
>> from BGP, the value 0 is reported."?
>> Because, even with AS-SET, the AS can be easily retrieved. The issue 
>> is to export it in IPFIX :)
>>
>> Regards, Benoit.
>>
>>>
>>> Regards,
>>> Eric
>>>
>>>
>>> Benoit Claise wrote:
>>>
>>>> Eric,
>>>>
>>>>>
>>>>> element may cause problem in real use for applications built on, 
>>>>> if it reports wrong information. And there's no easy way to verify 
>>>>> that inside IPFIX itself.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in 
>>>> the case of multi-access interfaces (typically an ethernet 
>>>> interface at an IXP). In other interface types, you would be able 
>>>> to deduce if the value is correct or not, i.e. if there is some 
>>>> asymmetry
>>>>
>>>> Regards, Benoit.
>>>>
>>>>>
>>>>> Regards,
>>>>> Eric
>>>>>
>>>>>
>>>>> Benoit Claise wrote:
>>>>>
>>>>>> Danny and all,
>>>>>>
>>>>>> In order to continue the discussion with a clear basis, here is 
>>>>>> the list of proposed BGP-related I.E.s. I've been trying to 
>>>>>> insert all suggestions.
>>>>>>      packet headers of this flow. In case of AS-SET, the 
>>>>>> value      of 0 is reported.
>>>>>>
>>>>>>   The autonomous system (AS) number of the first AS in the AS 
>>>>>> path to which packets of this flow are forwarded, deduced by 
>>>>>> looking up the source IP address of the flow in the BGP routing 
>>>>>> information base. In case of AS-SET, the value of 0 is reported.
>>>>>>
>>>>>>    The autonomous system (AS) number of the last AS in the AS 
>>>>>> path from which packets of this flow arrived, deduced by looking 
>>>>>> up the source IP address of the flow in the BGP routing 
>>>>>> information base. In case of BGP asymmetry, the 
>>>>>> bgpSrcAdjacentASNumber might not be able to report the correct 
>>>>>> value. In case of AS-SET, the value of 0 is reported.
>>>>>>
>>>>>>>> I think we have a technical problem right now in IPFIX. We 
>>>>>>>> can't report an AS_SET. How can we report that the 
>>>>>>>> Anyway, reporting the AS_SET is not that useful on the 
>>>>>>>> collector. If AS_SET = (100, 200, 300), it means that most 
>>>>>>>> specific routes of this aggregate  prefix comes from either 
>>>>>>>> 100, either 200, either 300.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I don't see how the local AS would be reported with the 
>>>>>> definitions of 16/17.
>>>>>> One solution could be to specify multiple new AS-SET related 
>>>>>> I.E., such mplsLabelStackEntryX in MPLS.
>>>>>>
>>>>>> the I.E.s we require right now, and use the IANA procedure for 
>>>>>> any other I.E.s. Otherwise, I fear the job will never be finished.
>>>>>>
>>>>>>>  
>>>>>>>>> this would be a "first" or "leftmost" AS segment in the 
>>>>>>>>> AS_PATH for the source
>>>>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP 
>>>>>>>>> prefix, while above it's

---

From: Eric Ji <[email-masked]>
Date: Fri, 13 May 2005 11:27:18 -0700

Benoit,

That's good. I agree with that.

Regards,
Eric

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 14 May 2005 00:56:24 +0200

Can't we be a bit more elaborate than just stating "in case of AS_SET"?

This is well established slang among experts. But a maybe a more commonly
understood alternative phrasing that is more appropriate for a standard
specification would be "if AS path information for this flow is only available
as unordered AS set (and not as ordered AS sequence)".

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 5/11/2005 8:30 AM +0200 Benoit Claise wrote:

> Do you want to say "In case of AS-SET or can't be easily retrieved from BGP, the value 0 is reported."?
> Because, even with AS-SET, the AS can be easily retrieved. The issue is to export it in IPFIX :)
>
> Regards, Benoit.
>
>>
>> Regards,
>> Eric
>>
>>
>> Benoit Claise wrote:
>>
>>> Eric,
>>>
>>>>

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 14 May 2005 02:06:44 +0200

Dear all,

--On 5/9/2005 1:10 PM +0200 Benoit Claise wrote:

> Danny and all,
>
> In order to continue the discussion with a clear basis, here is the list of proposed BGP-related I.E.s. I've been trying to insert all suggestions.
> Feel free to review and to propose some new text if some improvements are required.
>
>| 16 | bgpSourceAsNumber                           | 17 | bgpDestinationAsNumber
>       packet headers of this flow. In case of AS-SET, the value       of 0 is reported.

If the source IP address is not a flow key, then the source address is potentially
only in one (the first) header.  Therefore "headers" might not be appropriate.

Suggestion:

      The autonomous system (AS) number of the source IP address
      of this flow.  If AS path information for this flow is only
      available as unordered AS set (and not as ordered AS sequence),
      then the value of this Information Element is 0.

>       the IP packet headers this flow. In case of AS-SET,       the value of 0 is reported.

There is an "of" missing in this description.
But anyway, my suggestion is the same then above except the "source" is
replaced by "destination"

>       The IPv4 address of the next BGP hop to which packets of this flow

Coming back to the issue raised by Danny: What if there is no next BGP hop?
We may be measuring in the destination IP address' domain or even at the
destination IP address itself.  Shall we set the value of this IE to 0.0.0.0
in this case?

>       The IPv6 address of the next BGP hop to which packets of this flow

dito.

>    which packets of this flow are forwarded, deduced by looking up the

What is the value of this IE if the path is empty?
If it is 0 there might be confusion with the AS_SET case.

>    source IP address of the flow in the BGP routing information base.

Shouldn't we replace "source IP address" with "destination IP address"?

>    In case of AS-SET, the value of 0 is reported.
>

I am not sure an IE is an actor that is capable of "reporting" something
by itself.  What about replacing

OLD
   "In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able
    to report the correct value."
with NEW
   "If the BGP AS path to the source IP address of this flow is asymmetric,
    then the value of this Information Element may be incorrect."
?

Or, even cleaner:
   "Description:
      The autonomous system (AS) number of the first AS in the AS path
      to the source IP address of this flow.  If the AS path to the source
      IP address of the flow is symmetric, then the value of this
      Information Element indicates the AS number of the AS from which
      packets of this flow arrived.  If AS path information for this flow is
      only available as unordered AS set (and not as ordered AS sequence),
      then the value of this Information Element is 0..

Still remaining: What is the value of this IE when measuring at the source IP
address?

Thanks,

    Juergen

> I don't see how the local AS would be reported with the definitions of 16/17.
> One solution could be to specify multiple new AS-SET related I.E., such mplsLabelStackEntryX in MPLS.
>
> My personal view is that (in order to finish this IPFIX work who has been lasting to long IMHO ;)), we should post the draft with the I.E.s we require right now, and use the IANA procedure for any other I.E.s. Otherwise, I fear the job will never be
> finished.
>
>>