Subject: [spring] Comment on draft-alston-spring-crh-bgp-signalling-00

From: S Moonesamy <[email-masked]>
Date: Wed, 10 Jul 2019 02:10:27 -0700

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

---

From: Andrew Alston <[email-masked]>
Date: Wed, 10 Jul 2019 10:26:28 +0000

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-masked]> 
Sent: Wednesday, 10 July 2019 12:10
To: Andrew Alston <[email-masked]>; [email-masked]
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:

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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 10 Jul 2019 11:14:59 -0700

Hi Andrew,
>Basically when reading the NLRI from the packet - think of it in code terms:

Thanks for elaborating on how it would work in terms of code.

I read the draft again and I noticed the following in Section 1: "It 
is envisaged that such signalling will be required to signal, among 
other things, deep packet inspection systems ..."  Will RFC 7258 be 
considered for this proposed BGP extension given that it is related 
to deep packet inspection?

Regards,
S. Moonesamy