Subject: [Idr] BGP Header Marker field

From: Jithu Arun Sreedhar <[email-masked]>
Date: Fri, 12 Sep 2008 17:00:36 +0530

Hi,

Why is it that we still have to add the marker to the BGP message header. Isn't it time for the marker to be taken off. This is what the latest RFC tells about the marker.

Marker:
         This 16-octet field is included for compatibility; it MUST be set to all ones.

If it is so, why not add a capability telling the peer that you do not expect the marker or is not using it for authentication and take it out. 
Why do i have to keep my keepalive at 19 octets while it can be a happy 3 octet message. :-)

Thanks and Regards,
 Jithu Arun Sreedhar
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Sep 2008 09:58:52 -0400

Jithu,

> If it is so, why not add a capability telling the peer that you do not expect the marker or is not using it for authentication and take it out. 

How exactly are they going to understand your capability when they're
busy dropping your BGP packets for being malformed?  :-)

-- Jeff

---

From: "Cayle Spandon" <[email-masked]>
Date: Fri, 12 Sep 2008 10:16:40 -0400

The header wouldn't be dropped until the capability negotiation is
complete. In other words, the OPEN will still contain the header.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Sep 2008 13:31:36 -0400

> complete. In other words, the OPEN will still contain the header.

[With a little less humor this time.]

The amount of overhead of the header compared to modern circuits is so
small I'm surprised anyone is even vaguely concerned about it.  I would
find it hard to believe you'd gather working group consensus to add a
capability that causes a fundamental change in packet parsing code, even
a small one, with no significant return on functionality.

If one were concerned about bandwidth, they'd be better off suggesting
a compressed TCP data stream.  BGP implementations tend to be bound on
update processing, not on bandwidth nor on packet parsing overhead.

-- Jeff

---

From: "Cayle Spandon" <[email-masked]>
Date: Fri, 12 Sep 2008 15:50:51 -0400

Yep, I'll buy that argument.