Re: [Idr] draft-li-idr-congestion-status-extended-community

[li zhenqiang <[e-mail]>]

Hello Bruno,

Thank you very much for your constructive comments. Please see my reply inline, begins with Reply. Sorry for the late response.

Best Regards,
________________________________
[e-mail]

From: [e-mail]<mailto:[e-mail]>
Date: 2017-07-11 21:20
To: [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>
Subject: draft-li-idr-congestion-status-extended-community
Hi authors,

Please find below some minor comments.

§2  Congestion Status Extended Community

> The "Utilization" field is 1 octet.  Its value is the utilization of the exit link in unit of percent

- Is this the utilization on the link or before the link (i.e. before dropping the traffic in excess) ? IOW, can this be greater than 100%? I think I'd prefer the latter, but in all cases, I like to see a text detailing the handling of numbers > 100%.
Reply: If it is easy to get the utilization before the link, we can use it. But I am not sure about it. If you can, please contribute some text that I will incorporate in the next version.

- In order to offer more granularity, sometimes the traffic is rate limited to a capacity smaller than the physical link. e.g. the physical link has 10G of traffic, but only 3G is available to the user. Please explicit whether you are referring to physical or "real"/"offered"/"available" capacity. On my side, I'd prefer the latter.
Reply: I agree that the bandwidth should be the configured  available capacity of the link. I will explicit it in the next version.

> The "Bandwidth" field is 1 octet.  Its value is the bandwidth of the exit link in unit of 10 gbps (gigabits per second).

I don't see that this is extremely future proof, as the usable range is 1-255. When this proposition gets used (in years from now), 100G links would presumably be the default. Meaning we would already have consumed *10 from the budget. Only leaving *25 for the future. I'd prefer a wider range with less precision. e.g. bandwidth is 10^^bandwidth in gbps. (or 2^^).
Reply: Indeed this is one of the key points we should consider during the design of the mechanism. In unit of 10 gbps, one octet can express the bandwidth from 10gbps to 2550gbps. I think it should be ok for the future. Your suggestion is difficult to express 40gbps, 100gbps and 400gbps etc. Anyway we will think about your suggestion and try to find a better solution. Your further suggestion is welcome.

> The link with bandwidth less than 10 gbps is not suitable to use this feature.

Why not? It looks to me that the %Utilization could be useful even if the bandwidth is not advertised. Possibly a "Bandwidth" reserved value (e.g. 0) could be specified to indicate that the bandwidth is not advertised. This would also fit the case where some ASes do not want to advertise their link capacity.
Reply: Agree. We will revise the draft to reflect this.

§3.  Application Considerations

> The SDN controller uses the exit link utilization information to steer the Internet access traffic among all the exit links from the perspective of the whole network.

Indeed, presumably this information is used to influence the routing behavior. May be the document should indicate that the reception of such community over IBGP session should not influence routing decision unless tunneling is used to reach the BGP Next-Hop. (to avoid forwarding loops, incremental deployment issues, complications in error handling).
Reply: Thanks for pointing out this. We will add some description in next revision.

In addition, what are the interactions with the BGP Link Bandwidth Extended communities? https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth  (I know that the draft expired, but still it's a WG document and an official IANA code point)
Ships in the night?
Reply: So far this draft didn’t consider the interaction with the link bandwidth Ext. community. As the link bandwidth Ext. community is non-ransitive, and the global administrator subfield is only 2-octets, it may not be applicable to all the scenarios described in this document.

>   To avoid route oscillation, the exit router SHOULD set a threshold.   When the utilization change reaches the threshold, the exit router  SHOULD generate a BGP update message with congestion status extended  community.

I think that the document should better evaluate the churn introduced. In particular the churn is cumulative as the number of ASes crossed increase. e.g. if we assume that each AS use the community quite carefully by not advertising more than 1 update per hour, if we have 5 ASes on the way, the ingress AS can receive 5 (additional) updates per prefix per hour.
Reply: We will think about it further. Something like TTL (time to live) to be introduced? To have larger space to fit this, use BGP community container instead? Or do  you  have  some  suggestions?

4.  Security Considerations
> This new extended community does not directly introduce any new security issues.

What about trust/cheating considerations? Especially from remote ASes with which you have zero relationship?
e.g. advertising alleged congestion in order to TE/influence routing of others ASes, advertising plenty of fake capacity to attract more traffic/customers, advertising that they are never experiencing any congestion for commercial reasons, fake advertisement on "behalf" of other ASes...
Reply: The trust/cheating problem you mentioned is a general issue for BGP. Can we make sure that the routes advertised by a BGP peer should be advertised by it? The BGP peer can generate some routes maliciously. Anyway,  we will add some analysis to this problem in next revision. For example,  the BGP receiver may choose to only trust the congestion  information advertised by some particular ASes, or ASes within particular hops. Any suggestion from you?

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.