Subject: [Idr] draft-ymbk-bgp-extended-messages-01, size

From: Jakob Heitz <[email-masked]>
Date: Thu, 17 Mar 2011 21:49:49 -0400

The draft states:
>   All BGP extended messages have maximum message size of 65535 octets.

Could we make that just a little shorter, perhaps 65000 or 64000.
It would make implementation a little more efficient
when storing it or shunting it around in the code with headers on it.

--
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Mar 2011 08:42:59 +0100

Hello,

Many thx for everyone's opinion so far. This was exactly the point of my 
question. Other people are welcome to express their opinion on the list 
reg the below three points:

*A* Since we do agree that sending malformed UPDATE message back to a 
peer is a good thing what is really required is to make BGP UPDATE 
message smaller then any other message. How much smaller is debatable. 
For Diagnostic Message type 15 it would be 19 bytes (min BGP message 
size) + 12 (TLV header) so 31 extra octets would be needed. In the spec 
today we make it to be on the safe side for any future TLVs and 
recommend that Diag message is bigger then Update Msg of 128 octets. If 
you think that there are valid reasons to recommend even smaller value I 
have no opinion.

*B* When defining any protocol's type or length (even going beyond 
routing) utilizing all usable fields to the original intended value is
not to good of a practice.

The bgp message length is encoded in 2 octets. That in dec is equal
65535. Allowing max massage size of that value closes doors for future 
extension. Value of 56535 should be reserved for future extension !

At most any BGP message size can be 65534.

When BGP message size is 65535 it will have a special indication meaning 
to just like what is known in IPv6 world an entity called "Next Header". 
It will be fixed size by definition and would allow for including any 
subsequent header when needed. Each atomic header format will not change 
either.

It will just allow flexible nesting of messages without any hard message 
boundary. So while we are at extending BGP message size I hope we will 
do it right.

*C* I also agree with points that the capability should be symmetrical. 
Otherwise it will not be possible to replay back the bigger message. I 
am not sure I see a value of send/receive split here. What is defined in 
the draft is implicit "receive" and this seems what matters. But I 
should be sending bigger if I understand this capability from the peer 
which for all practical purposes mean I can parse bigger message too ;-)

Many thx,
R.

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Mar 2011 08:05:49 -0700

Hi Jakob,

I am sorry I didn¹t get it. What sort of implementation optimizations are we
talking about?

Regards,
Keyur

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Mar 2011 08:15:29 -0700

Robert,

Comments inlined. #Keyur

> peer is a good thing what is really required is to make BGP UPDATE

#Keyur: Malformed updates as sent today as well as part of notifications.
They are truncated if required.

> extension. Value of 56535 should be reserved for future extension !

#Keyur: Umm future extensions wrt to message sizes? :)
> subsequent header when needed. Each atomic header format will not change

#Keyur: We can reserve 65535 value. However it would be best to have a new
message type with its own length if you need to encap messages. That should
achieve the same goal in a bit more cleaner way rather than looking at the
message types. 

> Otherwise it will not be possible to replay back the bigger message.

#Keyur: If replay is required then capability should be exchanged both the
ways. :)

Regards,
Keyur

> I

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 18 Mar 2011 13:41:28 -0400

I like to fit things nicely into memory pages.
No big deal really.

--
Jakob Heitz.

________________________________
From: Keyur Patel [mailto:[email-masked]]
Sent: Friday, March 18, 2011 8:06 AM
To: Jakob Heitz; [email-masked]
Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size

Hi Jakob,

I am sorry I didn't get it. What sort of implementation optimizations are we talking about?

Regards,
Keyur

--
Jakob Heitz.

________________________________
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Saikat Ray <[email-masked]>
Date: Sun, 20 Mar 2011 17:08:11 -0700

Hi All:

I am seeking clarifications on the draft with respect to the proposed 
behavior of an RR (and Confed ASBR).

================
1. A path from a non-client internal peer is considered "external". Is 
such a path considered a "path received via EBGP" in the step 
[9.1.2.2(d); RFC 4271] in overall (or "best internal" or "best 
external") bestpath computation?

2. Is there an assumption that an RR does not have a true eBGP peer?

If an RR is allowed to have true EBGP peers:
3. Does the RR always send the overall-bestpath to a true EBGP peer?

4. If the overall-bestpath is a true EBGP path, is it sent to both RR 
clients and RR non-clients?

5. If the overall bestpath is an internal path received from an 
RR-client peer, does the "best external" path computation include true 
EBGP paths in its set of "external" paths?

6. If the overall bestpath is an internal path received from a 
non-client internal peer, does the "best internal" path computation 
include true EBGP paths in its set of "internal" paths (as the true EBGP 
paths are external to the set of non-client peers)?

7. Is there an assumption that RR's in the AS are fully meshed (no 
hierarchical RR)?

8. Is there an assumption that Confed ASBR's are fully meshed?

If Confed ASBR's may not be fully meshed, then
9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi 
is the Confed ASBR of member-AS i.
At ASBR1, the path from ASBR2 is the overall-bestpath. Does ASBR1 send 
the overall bestpath to ASBR3 or does ASBR1 send the "best internal" 
path to ASBR3? Also does the computation for "best internal" path, that 
ASBR1 sends to ASBR2, include paths from ASBR3 in its set of "internal" 
paths?
================

The current draft language is open to interpretations. The previous 
drafts that seem to be basis of the current one also do not clarify the 
above points.

http://tools.ietf.org/id/draft-chen-confed-oscillation-reduce-01.txt
http://tools.ietf.org/id/draft-chen-rr-oscillation-reduce-01.txt
http://tools.ietf.org/id/draft-chen-route-oscillation-avoid-00.txt

Any pointers will be appreciated.

Thanks.

---

From: Pedro Marques <[email-masked]>
Date: Mon, 21 Mar 2011 11:40:06 -0700

Saikat,

On Sun, Mar 20, 2011 at 5:08 PM, Saikat Ray <[email-masked]> wrote:
> 1. A path from a non-client internal peer is considered "external". Is such
> a path considered a "path received via EBGP" in the step [9.1.2.2(d); RFC
> 4271] in overall (or "best internal" or "best external") bestpath
> computation?

A path received from a non-client peer is an IBGP path; thus not an EBGP path.

> 2. Is there an assumption that an RR does not have a true eBGP peer?

No. RRs may have EBGP peers.

The best-external doc modifies the behavior of an RR such that when an
RR selects an IBGP path from another cluster it will also advertise
out of the cluster its best cluster local route (including direct eBGP
routes) rather than the current behavior of not advertising any
information.

> 3. Does the RR always send the overall-bestpath to a true EBGP peer?

Yes.

> clients and RR non-clients?

Yes. No modification in that behavior.

>
> 5. If the overall bestpath is an internal path received from an RR-client
> peer, does the "best external" path computation include true EBGP paths in
> its set of "external" paths?

An EBGP path is considered to be local to the cluster; it was not
received from an IBGP peer.

>
> 6. If the overall bestpath is an internal path received from a non-client
> internal peer, does the "best internal" path computation include true EBGP
> paths in its set of "internal" paths (as the true EBGP paths are external to
> the set of non-client peers)?

Yes.

> 7. Is there an assumption that RR's in the AS are fully meshed (no

No.

> 8. Is there an assumption that Confed ASBR's are fully meshed?

No.

> 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi is
> the Confed ASBR of member-AS i.
> At ASBR1, the path from ASBR2 is the overall-bestpath. Does ASBR1 send the
> overall bestpath to ASBR3 or does ASBR1 send the "best internal" path to
> ASBR3?

The best overall.

> Also does the computation for "best internal" path, that ASBR1 sends
> to ASBR2, include paths from ASBR3 in its set of "internal" paths?
> ================
>
> The current draft language is open to interpretations. The previous drafts
> that seem to be basis of the current one also do not clarify the above
> points.

Would the document be clearer if one where to use the terms
"intra-cluster" and "inter-cluster" route ?

  Pedro.

---

From: Saikat Ray <[email-masked]>
Date: Mon, 21 Mar 2011 17:15:41 -0700

Hi Pedro:

Thanks much for the response. It clears things up a lot. Could you 
please also answer the one question you missed ...

    9. Suppose we have three member AS - 1, 2, 3 - in a confederation;
       ASBRi is the Confed ASBR of member-AS i. At ASBR1, the path from
       ASBR2 is the overall-bestpath.
             Does the computation for "best internal" path, that ASBR1
             sends to ASBR2, include paths from ASBR3 in its set of
             "internal" paths?

I think the document should define the terms it is using more clearly. 
Even terms like "AS Domain" and "RR Domain" are open to interpretations. 
E.g., a RR can have true EBGP peers. Then is it in an AS Domain or is it 
in an RR Domain? Maybe the best thing would be to have a paragraph in 
the appendix that describes the task of a given BGP speaker considering 
the full set of paths and all possible types of peers that can co-exist. 
E.g., a BGP speaker can have: (i) true EBGP peers, (ii) RR-client peers, 
(iii) non-client IBGP peers, (iv) member-AS IBGP peers, (v) 
non-member-AS confed EBGP peers. All such peers can co-exist (when the 
BGP speaker is both an RR and a Confed ASBR). If the behavior is 
undefined in some cases (e.g., RR+Confed ASBR combination), then that 
should be said. The total set of paths are divided similarly based on 
the peer that sends the path. Then the paragraph would describe, given 
the overall bestpath lies in set 'k', which path the BGP speaker sends 
to a peer in set 'j'. For non-overall-bestpath, e.g., denoting the set 
of true EBGP paths as 'E' and the set of RR-client paths as 'R', a 
notation like 'best(E U R)' may be clearer than calling it "internal".

With regards,

Saikat

On 03/21/2011 11:40 AM, Pedro Marques wrote:
> Saikat,
>
> On Sun, Mar 20, 2011 at 5:08 PM, Saikat Ray<[email-masked]>  wrote:
>> Hi All:
>>

---

From: Pedro Marques <[email-masked]>
Date: Mon, 21 Mar 2011 18:47:48 -0700

Saikat,

On Mon, Mar 21, 2011 at 5:15 PM, Saikat Ray <[email-masked]> wrote:
> Hi Pedro:
>
> Thanks much for the response. It clears things up a lot. Could you please
> also answer the one question you missed ...
>

Yes. In this scenario, when ASBR1 generates an update to ASBR2 it is
selecting the best of all its known paths that where not received from
member AS 2.

The same rule applies for route reflection. Consider the top level
iBGP mesh to be cluster-id 0; When advertising to a specific set of
peers, "best-external" selects the best route from the set of known
routes that has not been received from the same cluster-id as the
"target".

> I think the document should define the terms it is using more clearly.

I agree.

> Even
> terms like "AS Domain" and "RR Domain" are open to interpretations. E.g., a
> RR can have true EBGP peers. Then is it in an AS Domain or is it in an RR
> Domain? Maybe the best thing would be to have a paragraph in the appendix
> that describes the task of a given BGP speaker considering the full set of
> paths and all possible types of peers that can co-exist. E.g., a BGP speaker
> can have: (i) true EBGP peers, (ii) RR-client peers, (iii) non-client IBGP
> peers, (iv) member-AS IBGP peers, (v) non-member-AS confed EBGP peers. All
> such peers can co-exist (when the BGP speaker is both an RR and a Confed
> ASBR). If the behavior is undefined in some cases (e.g., RR+Confed ASBR
> combination), then that should be said.

The behavior is easy to define in pseudo-code:
   eligible-routes = RIB-In routes Excluding { cluster-id and
confed-as of peer }
   select the best of eligible routes.

Assuming that cluster-id of a non-client peer is 0; confed-as of non
confed eibgp peer is 0.

I agree with you. The existing text sort of mumbles it all together.

  Pedro.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 21 Mar 2011 22:40:20 -0400

Pedro,

Suppose 3 RR clusters in an AS.
Overall bestpath is in cluster 2.
Cluster 1 will calculate the best-external
to send to cluster 2.
He will use the paths from cluster 3 and
cluster 1 to calculate the best external.
If the best from that set is in cluster 3,
he will send nothing to cluster 2.

Is that right?

--
Jakob Heitz. 510-566-2901

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pedro Marques
> Sent: Monday, March 21, 2011 6:48 PM
> To: Ray Saikat
> Cc: [email-masked]
> Subject: Re: [Idr] draft-ietf-idr-best-external-03
> 
> Saikat,
>

---

From: Pedro Marques <[email-masked]>
Date: Mon, 21 Mar 2011 22:30:08 -0700

> he will send nothing to cluster 2.

That is a feasible and correct approach. It will provide a overall
second best path across the AS in a scenario where the intent is to
have a failover path ready and routes are being selected on
MED/local-pref.

It is also possible to eliminate from consideration all the iBGP
received paths before selecting the best-external (among routes that
have been received from the cluster only); this would yield a scenario
where each cluster advertises its local path. Which may be an overkill
in many deployments.

The current language of the draft suggests the latter approach. Which
doesn't necessarily mean it is the most adequate in all situations.

  Pedro.