Subject: [GROW] comment for draft-ietf-grow-bmp-00

From: [email-masked]
Date: Fri, 13 Mar 2009 20:02:26 +0900 (JST)

Hello,

I have a comment for draft-ietf-grow-bmp-00. It is about adding a
bit flag to Peer Flags field in BMP common header. 

The new bit is used in order to indicate whether AS numbers (ASNs)
in AS_PATH (and AGGREGATOR) attribute, which must be included in
Route Monitoring messages, are 4-octet or 2-octet. I think the
information of ASN size will be needed on monitoring stations when
parsing BGP UPDATE PDUs.
 
Regards,
-- 
Tomohiko Kurahashi <[email-masked]>
Internet Initiative Japan Inc.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Mar 2009 04:47:18 -0700

Hello Tomohiko-san,

Would you consider instead of adding the new flag in the BMP wrapper to 
just parse by the management station the "Peer AS" 4 octet field and in 
the case where 2 octets of the most significant bits of this field are 
zero assume this is a two byte AS ?

It seems that such assumption can be safe based on the definition of the 
Peer AS field already specified in the draft:

    o  Peer AS: The Autonomous System number of the peer from which the
       encapsulated PDU was received.  If a 16 bit AS number is stored in
       this field [RFC4893], it should be padded with zeroes in the most
       significant bits.

Cheers,
R.

---

From: [email-masked]
Date: Mon, 16 Mar 2009 20:26:47 +0900 (JST)

Hello Robert,

Are you saying, "When the value of 'Peer AS' field is 2-octet
(i.e. less than 65536), ASNs in AS_PATH (and AGGREGATOR)
attribute can be considered as 2-octet value" ?

Regards,

From: [email-masked]
Date: Fri Mar 13 2009 20:47:18 JST

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Mar 2009 09:46:58 -0700

Hi Tomohiko-san,

Yes.

But if I would be writing the server side I would just use 4 octet and 
store all AS_PATHs values received as such.

Regards,
R.