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, -- Tomohiko Kurahashi <[email protected]> Internet Initiative Japan Inc. From: [email protected] Date: Fri Mar 13 2009 20:47:18 JST > > 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. > > > 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, _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
