Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt

From: David Freedman <[email-masked]>
Date: Tue, 25 Oct 2016 16:53:32 +0000

Apologies for the ultra-late-last-minute input, but I was discussing this with Job offlist and we felt it should be seen by list participants.

My point was about RFC1997 parity and the length validation. 

 " A Large BGP Communities attribute with a length of zero MUST be ignored upon receipt and removed when sending." 

Later wording here has been discussed to be amended (I understand) to:

" A Large BGP Communities attribute with a length of zero MUST NOT be sent and MUST be ignored upon receipt."

Well, I wanted to point out, that RFC1997 was of course updated by RFC7606.

In (7606), the following two comments are made:

" For all path attributes other than those specified as having an attribute length that may be zero, it SHALL be considered a syntax error for the attribute to have a length of zero." 

And 

" The error handling of [RFC1997] is revised as follows: The Community attribute SHALL be considered malformed if its length is not a non-zero multiple of 4" 

So really, if you apply RFC7606 to RFC1997 you have lost parity if you accept a zero length community (even if you just ignore it). 

My suggestion here is just to drop the passive receive tolerance of the zero length largecomm, since it seems out of place (even if it is harmless). 
and let it be considered malformed and handled by RFC7606. 

Thoughts? 

Dave.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 25 Oct 2016 19:47:57 +0000

We added that as a result of Jeff Haas's email attached.

It actually makes sense.
However, if we want to keep parity with https://tools.ietf.org/html/rfc7606#section-7.8
it's no big deal for me.

Jeff?

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of David Freedman
> Sent: Tuesday, October 25, 2016 9:54 AM
> To: [email-masked]
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt
> 
> " For all path attributes other than those specified as having an attribute length that may be zero, it SHALL be
> considered a syntax error for the attribute to have a length of zero."
> 
> And
> 
> " The error handling of [RFC1997] is revised as follows: The Community attribute SHALL be considered malformed if
> its length is not a non-zero multiple of 4"
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

Subject: Re: [Idr] draft-heitz-idr-large-community-04.txt
From: Jeffrey Haas <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Interminable Discussion Room <[email-masked]>
Date: Wed, 21 Sep 2016 21:04:30 +0000

   On Sep 21, 2016, at 4:31 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

            The attribute consists of a set of Large Communities.

         a bgp update may contain a large community attribute which is composed
         of zero or more large communities.  or one or more if you insist.

      ack.

   zero or one?

   1 or more.

   Implementations may prune empty path attributes (and probably should) when the contents are lists.  However, I don't believe we should standardize sending 0 of these communities as a form of signaling.

   That said, in the error handling section, it should note that a length of zero shall not be treated as a malformed route.

   -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Oct 2016 16:24:38 -0400

Jakob,

> However, if we want to keep parity with https://tools.ietf.org/html/rfc7606#section-7.8

Dave's point on specs is, as usual, right on.  And I think it's generally
reasonable to default to 7606 behaviors.  (Which would be one or more.)

My disagreement is more a disagreement with 7606's zero-length behaviors
with respect to (extended-)communities and the zero length behavior.  In
that spec, it's a syntax error to receive a length 0 attribute and, as such,
you should treat-as-withdraw.

However, that seems to contradict the general intent of the spec which is to
do error handling behaviors better.  Since 0 is semantically clear (no
comms), stripping the attribute and continuing seems to be somewhat more
graceful than treat-as-withdraw.  

That said, 7606 reflects WG consensus.  It seems wise to keep parity with
it.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Wed, 26 Oct 2016 17:47:56 +0200

> That said, 7606 reflects WG consensus.  It seems wise to keep parity with

Thank you gentlemen, I've removed the sentence from the document.

Kind regards,

Job