Hi SM, We can clarify this - the 2 and 4 come from the length in octets of a 16 bit or 32 bit unsigned integer.
Basically when reading the NLRI from the packet - think of it in code terms: Attribute is set to two - when reading the NLRI: Length is 2 octets - which tells you how large the NLRI is Then you read the X octets to get the SID, following by 16 octets to get the v6 address - and repeat until (X+16)*Y = Length, as referred to above. If that attribute isn't there, or is not set to either 2 or 4 - your ability to read the NLRI is impaired. So yes, the update is malformed if you are carrying the SAFI and either missing that attribute or that attribute is not set to 2 or 4. We'll look at clarifying the wording - thanks for the input. Thanks Andrew -----Original Message----- From: S Moonesamy <[email protected]> Sent: Wednesday, 10 July 2019 12:10 To: Andrew Alston <[email protected]>; [email protected] Subject: Comment on draft-alston-spring-crh-bgp-signalling-00 Hi Andrew, I took a quick look at draft-alston-spring-crh-bgp-signalling-00. In Section 3.1, there is the following: "Since SIDs in the context of a compressed routing header can be either 16bit of 32bit, the attribute value MUST be either 2 or 4 and the attribute MUST be ignored if this is not the case." Where does the 2 or 4 come from? Is the draft trying to specify that the compressed routing header is malformed if the attribute value is not 2 or 4? Regards, S. Moonesamy _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
