Subject: Re: [Idr] Status of BGP OPERATIONAL Message

From: Rob Shakir <[email-masked]>
Date: Thu, 5 May 2016 17:44:01 -0600

Hi Marco,

> On 5 Apr, 2016, at 5:58 AM, [email-masked] wrote:
> 
> I have read the threads regarding draft-frs-bgp-operational-message and i wonder if there are actual plans for deploying the it or not.
> 
> The reason I am asking is that I see value in a mechanism that advertises the value of MAXPREFIX to the BGP peer which the above can handle with the ADVISE TLVs.
> 
> My feeling is that BGP OPERATIONAL Message goes behind the scope and transforms BGP in a general-purpose network messaging queue, but if there are plans to implement that I would prefer to wait than to suggest to re-invent the wheel.

At the time, there was some interest in implementing this mechanism, and I believe that it was implemented in Quagga (or at least a patch exists). Our intention with this draft was to introduce a message type that allowed for information that related to the state of a session, not necessarily to a set of NLRI to be advertised across a BGP session. Robert, David and I have discussed resuscitating this draft, and if you have a use-case that would fit into it, we could definitely try and include that.

If you were to be advertising the value of a maximum prefix using an alternate mechanism, how would this be carried? It seems strange to do it in an OPEN message, since the value may change throughout the lifetime of the session, and including it in an UPDATE message would also be somewhat strange because it is not clear that it would be linked to any particular NLRI. We have rather overloaded the semantics of an UPDATE message with null NLRI already, so I’m not clear there would be a neat way that you could transmit this information in a way that did not end up declaring something that looked like the OPERATIONAL message and subsequent NLRIs.

Best,
r.

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 6 May 2016 00:04:20 +0000

Hi,

About the following requirement:
"> The reason I am asking is that I see value in a mechanism that advertises the value of MAXPREFIX to the BGP peer which the above can handle with the ADVISE TLVs."

If a BGP speaker wants to advertise the value of MAXPREFIX to its peer, I notice that there had been 2 expired drafts to address such requirement:
https://tools.ietf.org/id/draft-chavali-bgp-prefixlimit-02.txt
https://tools.ietf.org/id/draft-keyur-prefixlimit-orf-00.txt

Do we really need such a feature?

Best Regards,
Shunwan

-----邮件原件-----
发件人: Idr [mailto:[email-masked]] 代表 Rob Shakir
发送时间: 2016年5月6日 7:44
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [Idr] Status of BGP OPERATIONAL Message

Hi Marco,

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

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 06 May 2016 12:45:16 +0200

On 2016-05-06 01:44, Rob Shakir wrote:
>> I have read the threads regarding draft-frs-bgp-operational-message 
>> and i wonder if there are actual plans for deploying the it or not.
>> 
>> The reason I am asking is that I see value in a mechanism that 
>> advertises the value of MAXPREFIX to the BGP peer which the above can 
>> handle with the ADVISE TLVs.
>> 
>> My feeling is that BGP OPERATIONAL Message goes behind the scope and 
>> transforms BGP in a general-purpose network messaging queue, but if 
>> there are plans to implement that I would prefer to wait than to 
>> suggest to re-invent the wheel.
> 
> At the time, there was some interest in implementing this mechanism,
> and I believe that it was implemented in Quagga (or at least a patch
> exists). Our intention with this draft was to introduce a message type
> that allowed for information that related to the state of a session,
> not necessarily to a set of NLRI to be advertised across a BGP
> session. Robert, David and I have discussed resuscitating this draft,
> and if you have a use-case that would fit into it, we could definitely
> try and include that.
> 

Hello Rob,

I have three cases in my mind:
1) Standard peering (not customer) relationship between two ASes.
    The value of MAXPREFIX is usually exchanged by email (or if it is 
very urgent by IRC or phone call) between the NOCs or the peering 
departments.

2) MPLS-VPN:
  This is a more interesting scenario because of the strict SLAs and the 
fact that MAXPREFIX (at least in some cases) is a commercial value
  a) NNI: Same as of #1
  b) UNI: Even if triggered by the customer that sends more than allowed, 
a down is always perceived as a symptom of bad service.

3) Flowspec:
  My feeling is that the market will adapt to a discrete number of rules 
per port or per customer.
  Triggering MAXPREFIX in this case may be catastrophic because it will 
remove all the active "rules" until the protection is cleared.

For all of the above transmitting the value of MAXPREFIX would improve 
the quality of the service because:
  1) The peer could check the values of the sent/allowed prefixes before 
sending more.
  2) The router could raise an alarm for the advertised prefixes as it 
does for the received

> If you were to be advertising the value of a maximum prefix using an
> alternate mechanism, how would this be carried? It seems strange to do
> it in an OPEN message, since the value may change throughout the
> lifetime of the session, and including it in an UPDATE message would
> also be somewhat strange because it is not clear that it would be
> linked to any particular NLRI. We have rather overloaded the semantics
> of an UPDATE message with null NLRI already, so I’m not clear there
> would be a neat way that you could transmit this information in a way
> that did not end up declaring something that looked like the
> OPERATIONAL message and subsequent NLRIs.
> 
> Best,
> r.

I agree that you can't send MAXPREFIX within OPEN.

I like the idea to make of use RFC5291 (Outbound Route Filtering 
Capability for BGP-4) by defining a new ORF Type as suggested in 
https://tools.ietf.org/id/draft-keyur-prefixlimit-orf-00.txt , but i'd 
retain all the behaviors described in RFC5291 except for "Action" that 
i'd implement as follows:
  DENY: Prevent the router from advertising more prefixes when the amount 
of advertised-prefixes is equal to MAXPREFIX
  PERMIT: Do nothing (the advertised value is purely informational)

Regards

-- 
Marco