Re: [OPSAWG] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

2018-04-15 Thread Joel M. Halpern 

There seem to be two separate issues.

The first issue is what information from BGP would one like to correlate 
with the traffic flows.  I understand that there is useful information. 
The motivation given in the draft seems to apply to more cases than I 
thought, but still it is of limited applicability.


More importantly is the question of whether the proposed method is the 
right way to get the information.  As the draft acknowledges, there are 
other ways to get the information.  Ways that do not need new router 
software much less modifications of the fast path.
There is an argument in the draft about timeliness.  At least for the 
use case document in the draft, that argument does not hold water.


Yours,
Joel

On 4/15/18 10:45 PM, Aijun Wang wrote:

Hi, Joel:

Can we consider this draft from other viewpoints? If the router can
report and correlate the traffic with its associated community, the
usage of the community to differentiate the customer, the service
category that be accessed and the geographical region etc. will be
flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

Best Regards.

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research
Institute,Beijing, China.

*From:*Joel Halpern 

*Date:* 2018-04-13 22:44

*To:*rtg-...@ietf.org 

*CC:*draft-ietf-opsawg-ipfix-bgp-community@ietf.org 
; 
i...@ietf.org ; opsawg@ietf.org 
; gen-...@ietf.org 


*Subject:* Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add 
complexity) or


one has to give up and move all the information through the control 
plane.  And


even the control plane likely has to add complexity to its RIB logic, as 
it has


to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the 
router


by the claim that the unusual usage of applying community tags for 
geographical


location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for 
it.   But


it is not common.

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

2018-04-15 Thread Aijun Wang 
Hi, Joel:

Can we consider this draft from other viewpoints? If the router can report
and correlate the traffic with its associated community, the usage of the
community to differentiate the customer, the service category that be
accessed and the geographical region etc. will be flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

 

 

Best Regards.

 

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

From: Joel Halpern  

Date: 2018-04-13 22:44

To: rtg-...@ietf.org

CC: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
opsawg@ietf.org; gen-...@ietf.org

Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

 

This is both a gen-art re-review and a routing directorate requested review.

 

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

 

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add complexity)
or

one has to give up and move all the information through the control plane.
And

even the control plane likely has to add complexity to its RIB logic, as it
has

to move additional information from BGP to the common structures.

 

The secondary problem is that this additional work is justified for the
router

by the claim that the unusual usage of applying community tags for
geographical

location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for it.
But

it is not common.

 

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.

 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg