Subject: [ipfix-info] BGP related Information Elements

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Apr 2005 16:39:17 +0200

Dear all,

As already noted during the internal IPFIX meeting at Washington, there 
are some discrepancies regarding the BGP related Information Element.
Hereafter the list of them

ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-07-pre.txt 
 
| 16 | bgpSourceAsNumber
| 17 | bgpDestinationAsNumber
| 18 | bgpNextHopIpV4Address
| 63 | bgpNextHopIpV6Address
| 128 | bgpNextHopAsNumber
| 129 | ipNextHopAsNumber

I'm trying to answer this simple question: 
Which I.E. should I use if a flow is coming from AS1 to AS5 and observed on a BGP router in AS3?

   AS1 ----- AS2 ------ AS3 -----AS4 ------AS5
  --------------------------------------------> flow

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!!
 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
  Description:
    The autonomous system (AS) number of the next AS in the AS path to 
    which packets of this flow are forwarded.

  Abstract Data Type: unsigned16

  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.

5.4.6  bgpSrcPeerASNumber

  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.

 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.

Does someone have a different view?

Regards, Benoit.

--
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: Eric Ji <[email-masked]>
Date: Tue, 26 Apr 2005 10:47:09 -0700

Benoit,

Very good analysis. My opinion about this, bgp nexthop-self is to use 
the interface bgp runs on as the nexthop in route advertisement. It's to 
tell its peers to use this address, but doesnt affect nexthops in its 
own routing table. Therefore it should not affect the flow ASes.
In your example, AS3 should export AS1 as 16, AS5 as 17, AS4 as 128. I 
know Cisco has option to export either origin AS or peer AS, not both, 
but in reality both are useful. So we may make it consitent to export 
src AS, dest AS, peer AS. As for ipNexthopAs, is that the immediate 
nexthop AS? Normally IGP is used for bgp nexthop reachability, and they 
are in same AS, so it's not so useful as the other three.
As for the name of 128. I agree with you, bgpDstPeerASNumber is more 
clear to describe this. And this depends on the bgp peer session type, 
IBGP or EBGP. For the former, the current router may not know the next 
AS in the AS path to destination. So I'd prefer the following description:

 > 5.4.6  bgpDstPeerASNumber
 >  Description:
 >    The autonomous system (AS) number of bgp peer AS in the path to
 > which packets of this flow are forwarded. If it's IBGP, it's the same
 > as local AS, and if it's EBGP, it's the next AS in AS path.
 >

Similar for 129 if it's changed to bgpSrcPeerASNumber.

Regards,
Eric

Benoit Claise wrote:
> I'm trying to answer this simple question: Which I.E. should I use if a 
> flow is coming from AS1 to AS5 and observed on a BGP router in AS3?
> 
> If I configure the router in AS3 to export the origin AS's (for the one 
> familiar with NetFlow), the flow record contains:
> If I configure the router in AS3 to export the peer AS's (for the one 
> familiar with NetFlow), the flow record contains:
> 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
>  Description:
>     from which packets of this flow arrived. In case of BGP asymmetry, 
> the         bgpPreviousAsNumber might not be able to report the correct 
> value.
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Apr 2005 18:14:29 +0200

Eric,

> the interface bgp runs on as the nexthop in route advertisement. It's 
> to tell its peers to use this address, but doesnt affect nexthops in 
> its own routing table. 

Right, but don't forget that there are other BGP routers in that same 
AS. That will change something for them.

> Therefore it should not affect the flow ASes.
> but in reality both are useful. 

I agree. This is the reason of the new proposed #128 and #129 definitions.

> So we may make it consitent to export src AS, dest AS, peer AS. As for 
> ipNexthopAs, is that the immediate nexthop AS? Normally IGP is used 
> for bgp nexthop reachability, and they are in same AS, so it's not so 
> useful as the other three.

Well. The bgpDstPeerASNumber definition I propose has been specified so 
that,
if the flow goes to a router in AS3:
- you would export AS2  for bgpDstPeerASNumber if you export from R10
- you would export AS2  for bgpDstPeerASNumber if you export from R12
With my proposed definition, this is indepent of the next-hop self 
configured on R12

  R10----R11----R12  --------- R20 -------------R30
 <------AS1--------->           <-AS2->           <-AS3->
 ----------------------flow------------------------------->

Note that with the example above and the #128 I.E. in 
ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-07-pre.txt, 
and with next-hop self on R12
- you would export AS1  for #128  if you export from R10
- you would export AS2  for #128  if you export from R12

> > as local AS, and if it's EBGP, it's the next AS in AS path.

The information element definition should be independent of iBGP or 
eBGP, otherwise the collector has no clue about about the meaning of the 
information elements unless he knows whether this is iBGP or an eBGP. So 
I prefer my proposed definition:
   The autonomous system (AS) number of the next AS in the AS path to 
which packets of this flow are forwarded.

Regards, Benoit.

>> As already noted during the internal IPFIX meeting at Washington, 
>> there are some discrepancies regarding the BGP related Information 
>> Element.
>> I'm trying to answer this simple question: Which I.E. should I use if 
>> a flow is coming from AS1 to AS5 and observed on a BGP router in AS3?
>>
>> If I configure the router in AS3 to export the origin AS's (for the 
>> one familiar with NetFlow), the flow record contains:
>> (** ) attention: according to the current definition, if "bgp 
>> next-hop self" is configured on the router in AS3, this I.E. will 
>> report AS3!!
>> 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
>>  Description:
>>    The autonomous system (AS) number of the next AS in the AS path 
>> to    which packets of this flow are forwarded.
>>
>>     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.
>>

---

From: Eric Ji <[email-masked]>
Date: Wed, 27 Apr 2005 11:57:08 -0700

Benoit,

I agree with your proposed definition. Actually I just think we needn't 
mention nexthop-self at all, it should not affect the flow AS export. 
And same thing for I/EBGP. But the definition need change due to the 
issues as in my comments. I can do this if needed.

Regards,
Eric

> AS. That will change something for them.
--------
comments: If they are in same AS. (1) if full mesh is used, they dont 
exchange routes among themselves, nothing in other routers' routing 
table is affected. (2) if confederation/reflector etc is used, it may 
affect other routers' bgp route nexthop, but ASpath is not affected by 
nexthop-self command.
Therefore, nexthop-self would not affect ASpath in BGP, and it should 
not affect AS export.

> - you would export AS2  for #128  if you export from R12
------
comments: I agree with this. Exporting same AS as local AS may not be 
useful to network admins. The next different AS, in most case it means 
different carriers or networks, are much more useful.

> which packets of this flow are forwarded.
-----
comments:
I think we need look more into this. Current issues:
(1) the next AS may not necessarily be different, it's not uncommon to 
loop AS, i.e, repeat AS in ASpath to make it less preferable in the 
routing calculation. Juniper has option to control that.
(2) For AS_SEQUENCE, it's ok. But for AS_SET, since multiple ASes are 
combined together into a SET, no single AS stands out as the 'peerAS' 
per definition.
My tentative propose is a change to your definition above:
The autonomous system (AS) number of the next AS in the AS path, which 
is different from local AS, to which packets of this flow are forwarded.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 Apr 2005 21:24:06 -0600

> routing calculation. Juniper has option to control that.

The local AS is never added to the AS_PATH until the route is
advertised to an external BGP peer (or BGP confederation peer).
Padding (i.e., typically prepending only occurs on route advertisement
to an external BGP peer).  There are some hacks for this but I
don't believe IPFIX should attempt to accommodate those corner
cases.

> is different from local AS, to which packets of this flow are 

You really don't know whether packets are actually going to be forwarded
along that path (I know, rathole), all that this is really reporting is 
that
the peerAS value represents that of the leftmost AS path segment in the
AS_PATH for the best BGP route associated with the destination prefix 
(i.e.,
the BGP Loc-RIB entry).

Indeed, if the leftmost (first) path segment in the AS_PATH contains an
AS_SET, multiple AS values could be returned.  We should account for 
that
condition.

Finally, while not the case with route reflection, we should perhaps
account for AS_CONFED_SET and AS_CONFED_SEQUENCE in the AS_PATH.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 Apr 2005 21:49:27 -0600

> 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?

> using the a new I.E? Because I think it was the intended goal behind 

I'd prefer a name with bgpDstAdjacentASNumber or the like, as this is 
still a bit
confusing.

> 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.

>    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.
> 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..

>    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

---

From: Eric Ji <[email-masked]>
Date: Thu, 28 Apr 2005 12:13:33 -0700

Hi Danny,

Except your harsh words that I simply ignore, is there any difference 
from my original concerns? the AS fields in ipfix-info draft are 
unsigned16 identifiers, how to report AS_SET etc still needs be 
discussed and resolved. 'Reporting multiple AS values', or 'perhaps 
count this and that', remember we are not writing an application only 
for the use of ourselves, in which case you could do anything no one cares.

Again, I dont want to see this maillist to become a place where you can 
bark others as 'you really dont know this and that', sth like that. You 
can go to online forums if you like that way before you make any 
discussions. To address your question, yes, I used to work on developing 
two bgp stacks, and yes, I am working on sth else now and haven't 
touched bgp for a while.

Regards,
Eric

Danny McPherson wrote:
> AS_SET, multiple AS values could be returned.  We should account for that
> condition.
>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 28 Apr 2005 13:48:43 -0600

On Apr 28, 2005, at 1:13 PM, Eric Ji wrote:
> from my original concerns?

Nope, I believe we were in agreement (not sure what you found harsh 
about
my message).  As a matter of fact, I thought pointing out that an AS_AET
could be returned was quite a keen observation.  The only additional 
points
I had were:

o the local AS segment isn't in the path until the route is
advertised to an external BGP peer

o AS_CONFED_* should be considered as well

o the "leftmost" or "first" AS segment is likely more intuitive 
terminology

o and I didn't quite understand what point there was in IPFIX reporting
here what the value of a recursive lookup for the origin AS value of
the BGP NEXT_HOP IP address.

> the AS fields in ipfix-info draft are unsigned16 identifiers, how to 
> report AS_SET etc still needs be discussed and resolved. 'Reporting 
> multiple AS values', or 'perhaps count this and that', remember we are 
> not writing an application only for the use of ourselves, in which 
> case you could do anything no one cares.

Indeed, I know this quite well :-)

> Again, I dont want to see this maillist to become a place where you 
> can bark others as 'you really dont know this and that', sth like 
> that.

Heh, I didn't think I was barking .. I'm typically the last one to bark 
about
something on a mailing list.  Though I've been lurking here forever I 
rarely
chime in..

>  You can go to online forums if you like that way before you make any 
> discussions. To address your question, yes, I used to work on 
> developing two bgp stacks, and yes, I am working on sth else now and 
> haven't touched bgp for a while.

I never asked for your qualifications, and honestly don't care.  The 
AS_SET
observation was quite keen.

Perhaps you should reread my message with a less sensitive hat on :-)

-danny

---

From: Eric Ji <[email-masked]>
Date: Thu, 28 Apr 2005 14:29:54 -0700

As said in personal email exchanges with Danny, I think I over-acted in 
my previous email. Sorry for that Danny.

Danny McPherson wrote:
> Nope, I believe we were in agreement (not sure what you found harsh about
> could be returned was quite a keen observation.  The only additional points
> I had were:
> 
---
agree on both.
> 
> o the "leftmost" or "first" AS segment is likely more intuitive terminology
> 
---
agree, as said, we may not mention nexthop, just rely on the ASpath to 
figure out peerAS.

> Indeed, I know this quite well :-)
---
Yeah, hope this can be addressed. Use other method to figure out,
or report as 0 which means user needs figure out by themselves, or 
report multiple AS and change AS field definition?

>> can bark others as 'you really dont know this and that', sth like that.
> 
> 
> I never asked for your qualifications, and honestly don't care.  The AS_SET