Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-vpn-common-09

[Joel M. Halpern]

Thank you for the clarifications Med.  That all seems good.

Yours,
Joel

On 9/3/2021 8:38 AM, mohamed.boucad...@orange.com wrote:

Hi Joel,

Thank you for the review.

Please see inline.

Cheers,
Med


-Message d'origine-
De : Joel Halpern via Datatracker [mailto:nore...@ietf.org]
Envoyé : vendredi 30 juillet 2021 18:38
À : gen-...@ietf.org
Cc : draft-ietf-opsawg-vpn-common@ietf.org; last-c...@ietf.org;
opsawg@ietf.org
Objet : Genart last call review of draft-ietf-opsawg-vpn-common-09

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-vpn-common-09
Reviewer: Joel Halpern
Review Date: 2021-07-30
IETF LC End Date: 2021-08-06
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed
Standard RFC

Major issues: N/A

Minor issues:
 I just want to confirm that one form of reference is normal for
YANG
 models?  There are a few identities whose meaning is defined by
I-Ds that
 are under way.  The references section of the identity gives the
I-D name.
 Which is fine.  The references at the bottom of the document
makes those
 informative references.  That seems a little odd since those
references are
 necessary to understand the meaning of those identities.  Is
this a normal
 practice for YANG models?


[Med] I confirm. We are following this part from RFC8407:

 " If a YANG module
   contains reference or "description" statements that refer to an
   I-D, then the I-D is included as an informative reference. "


  I am a little confused as to why the srv6 identity includes in
its
  references clause RFC 8663 (MPLS SR).  Is this a copy-and-paste
error?


[Med] Please note that we are referring RFC8663, not RFC8660. This is because 
we assumed that RFC8663 uses IPv6 as an underlay, but that's may be confusing.

I suggest to go with this change:

OLD:
   identity srv6 {
 base sr;
 description
   "Transport is based on SR over IPv6.";
 reference
   "RFC 8663: MPLS Segment Routing over IP
RFC 8754: IPv6 Segment Routing Header (SRH)";
   }

NEW:
   identity srv6 {
 base sr;
 description
   "Transport is based on SR over IPv6.";
 reference
   "RFC 8754: IPv6 Segment Routing Header (SRH)";
   }

   identity sr-mpls-over-ip {
 base sr;
 description
   "Transport is based on SR over MPLS over IP.";
 reference
   "RFC 8663: MPLS Segment Routing over IP";
   }

Please let me know if this is better. Thanks.


 I hope I am misreading the qos-classification-policy definition.
It
 appears to have an id, a match rule, and a match action.   The
match rule
 can be a match-flow or a match-application.  So far, so good.
(putting
 aside the nit below on customer-application.)   But the match
rule is a
 choice between an L3 and an L4 rule.


[Med] This is not a choice between these two, but each of them is a choice in 
its own. FWIW, here is an excerpt from RFC8340 to distinguish between choices 
and cases:

==
 is the name of the node
  () means that the node is a choice node
 :() means that the node is a case node
==

Things would be problematic if we defined L3/L4 as "cases" of the same choice, 
but we aren't.

   As I understand it, there

are many
 cases where the actual classification is based on a combination
of l3 and
 l4 information.  How is that to be represented?


[Med] An example to illustrate how both can be included in shown below (DNS 
traffic destined to 2001:db8::/32)

A valid rule for DNS traffic for example is shown below:

{
   "id": "a-rule-id",
   "ipv6": {
 "destination-ipv6-network": "2001:db8::/32"
   },
   "udp": {
 "destination-port-range-or-operator": {
   "operator": "eq",
   "port": 53
 }
   }
}



Nits/editorial comments:
 The "customer-application" identity seems to be asking for
problems in two
 regards.


[Med] FYI, we inherited this from service modules (RFC8299 and RFC8466) where 
these common identities are used.

 It seems that it is a shorthand way of expressing

some
 combination of protocols and ports.


[Med] This can be indeed expressed as such, but at more likely at the network 
level. We are covering both as the common module can be used by both service 
and network models.

The larger concern I have

is that
 there is no reference that explains what classification rules
should be
 used for any of the derived identities.   Which means that for
an
 interoperable implementation, there seems to be some difficulty
in ensuring
 that the client and server 

Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?

[Joel M. Halpern]

We have many times had WGs whose goals included "produce RFC to document 
have  currently works.?   The way we make that stick process-wise 
historically is to write that into the charter.  Since the IESG signs 
off on the charter, generally later ADs understand and work with the 
agreement.

Whether that is necessary here is unclear.
But we do have lots of precedent for doing this kind of thing in working 
groups.


Yours,
Joel

On 11/11/2020 6:14 PM, Toerless Eckert wrote:

On Wed, Nov 11, 2020 at 06:06:11PM -0500, Michael Richardson wrote:


Toerless Eckert  wrote:
 > I am mostly worried to figure out if we can try to lock in the 
admissable changes to
 > the document as early as possible.

You can change anything you want as long as a 2018-era release of wireshark
and tcpdump can read the result.


Right. thats a good cutoff point. But that was not my discussion point:

My discussion point is that i want to prohibit IETF/IESG review later on to 
force
for whatever reasons changes to the doc that would violate your cutoff point - 
by
pointing to "this document was accepted to OPSAWG under exactly the aboe 
condition,
violating it would render the document useless. Please reserve your suggestions
for improvement for followup work".

Cheers
 Toerless

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



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

Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

[Joel M. Halpern]

Are you really simultaneously saying
1) As far as you know, the existing draft is not being used
2) You do not want the working group to work on the replacement a number 
of operators need

3) And you oppose the AD sponsoring the work

You are not even saying you don't like it, as you also say you would not 
want to work on the problem.  Even ADs don't get to say "this should not 
go forward even though there is no technical objection."


Huh?
Yours,
Joel

On 5/16/2020 9:02 AM, Mehmet Ersue wrote:

Hi All,

although technically (and surprisingly) allowed I would like to state my
discomfort for publishing this draft as AD sponsored document. I believe a
draft which is proposed to replace a standard-track RFC developed with long
discussions and reviews in an IETF WG should be again re-discussed and
reviewed with its changes in a WG before publishing. Otherwise it feels like
bypassing IETF process.

I personally have no big interest in this draft as I assume RFC 6728 has not
been used in the industry widely. Though if there is strong support in
OPSAWG for the changes in this draft and updating RFC 6728 I would be
supportive too. However I did not see such strong support in OPSAWG yet. I
think we also should clarify on the maillist whether the changes in the
draft are only technically interesting or sufficient amount of people in the
WG (excluding draft authors) are planning to implement and use.

If ever the WG decides to develop such a draft replacing RFC 6728 I believe
it should be divided in parts where the WG should at the first place focus
on changes related to RFC 6728. The decision on developing a draft on bulk
data transfer should be provided separately as I assume the interest on this
part would be less than updating the existing RFC. Dividing into parts makes
it indeed more manageable.

My 2 cents.

Cheers,
Mehmet


-Original Message-
From: OPSAWG  On Behalf Of Rob Wilton
(rwilton)
Sent: Friday, May 15, 2020 6:09 PM
To: Joe Clarke (jclarke) ; opsawg ;
draft-boydseda-ipfix-psamp-bulk-data-yang-mo...@ietf.org
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-
data-yang-model

[With AD hat on]

Hi,

I was really hoping that there would be more support for adopting this

work

in OPSAWG, given it covers both YANG and IPFIX it does seem like the
correct home for it.

In general, I am keen that IETF continues to flesh out and improve YANG
models for the protocols standardized in IETF.

I'm also not sure whether I would realistically be able to AD sponsor this
document, given that I am new in the AD role, and this is currently a long
document.  The document and YANG model both look like they are in
reasonable shape, but probably could do with some more reviews.

I have a question for the authors:

Would it be feasible to split this work up into smaller chunks that would

make

it easier to review.  E.g. to put the packet-sampling and bulk-data-export

into

separate drafts?  Perhaps pare back some optional functionality.


And a question for the WG:

2) If this work was split up, and if I ask very nicely ;-), then is it

possible that a

few more people would be willing to help review a smaller shorter version

of

this document?

Regards,
Rob



-Original Message-
From: OPSAWG  On Behalf Of Joe Clarke
(jclarke)
Sent: 18 April 2020 22:13
To: opsawg 
Subject: [OPSAWG] Call for adoption:
draft-boydseda-ipfix-psamp-bulk-data-
yang-model

As was discussed in the April 7 virtual interim, we are doing a
three-week call for opsawg adoption for this work.

This draft was an AD-sponsored work with Ignas and has now moved under
Rob.  It has received a number of reviews (some thorough, some more
cursory), and it is destined to obsolete 6728 (Configuration Data
Model for the IP Flow Information Export (IPFIX) and Packet Sampling
(PSAMP)
Protocols) if ratified.  Because of that latter point, making this a
WG item seems more appropriate than pushing it through as an
AD-sponsored document.

To that end, does the WG feel this work is important and wants to take
it up?  In a nutshell, this document breaks up the original YANG
module into three for the IPFIX collector and exporter functions, the
PSAMP functions, and the templates for bulk data exports.  While it
preserves the SCTP support, SCTP is no longer mandatory.  It also adds
support for ietf- interfaces and hardware management (those did not
exist at the time of 6728).

The reason for the three-week call is to give people enough time to
read through and digest this document.  Please reply with support (or
objections) as well as comments by May 10, 2020.

Thanks.

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


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


___
OPSAWG mailing list
OPSAWG@ietf.org

Re: [OPSAWG] [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Joel M. Halpern]

Actually Joe, the rules clearly allow the case wehre an Independent 
Stream I-D disagrees with the IETF rough consensus.  Many such have been 
published.  Some of them were held so that they were not published until 
the relevant IETF work was published.


To be explicit, while the IESG can request that the ISE not publish 
something, and can provide a note they wish to have included if it is 
published, they do not have the power to enforce a do-not-publish if the 
ISE disagrees.
And Joe, you have lived aspects of this more closely than I have, so I 
am sure you are aware of it.


Yours,
Joel

On 11/4/2019 9:48 PM, Joe Touch wrote:




On Nov 4, 2019, at 6:39 PM, Joel M. Halpern  wrote:

If the authors want to publish it as an RFC so as to comment on other RFCs, 
they could approach the Independent Stream Editor.  That sort of publication is 
one of the explicit purposes of the Independent Stream.


That only happens if the WG and IESG say this is out of scope for the IETF. 
I.e., the ISE isn’t an end-run.

IMO, given the fact that this is squarely within TSVWG and there’s no 
consensus, the way forward is clear.

Not every ID turns into an RFC, nor should it.

Joe



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

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Joel M. Halpern]

If the authors want to publish it as an RFC so as to comment on other 
RFCs, they could approach the Independent Stream Editor.  That sort of 
publication is one of the explicit purposes of the Independent Stream.


Yours,
Joel

On 11/4/2019 9:34 PM, Eric Rescorla wrote:



On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann > wrote:


I actually think it's a pretty good summary, and delivers exactly what's
promised in the title.  OTOH I can also see that it's going to get
bikeshedded
to death, and will probably never be editable into a form where
people won't
complain about it no matter how many changes are made. 
Alternatively, it'll

end up watered down to a point where no-one can complain any more
but it won't
say anything terribly useful by then.

Perhaps it could be published as is with a comment that it
represents the
opinions of the authors?  Although given that it's Informational and not
Standards-track or a BCP, that should be a given anyway.


Actually, no. Most IETF documents, even informational ones, bear a 
statement that they have IETF Consensus.


See: https://tools.ietf.org/html/rfc5741#section-3.2.1 



-Ekr


Peter.




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



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

Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Joel M. Halpern]

The conclusion earlier work on congestive response routing reached was 
that one needed to pin the specific routing decision until the selected 
path became infeasible.


Yours,
Joel

On 12/4/18 10:59 AM, Spencer Dawkins at IETF wrote:

Hi, Stewart,

On Tue, Dec 4, 2018 at 6:07 AM Stewart Bryant > wrote:




On 30/11/2018 19:23, Spencer Dawkins at IETF wrote:

This is Mirja's comment, but ...

On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind
mailto:i...@kuehlewind.net>> wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-opsawg-ipfix-bgp-community-11: No Objection

When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found
here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/



--
COMMENT:
--

One comment on section 1:
"For example, they can shift some flows
  from congested links to low utilized links through an SDN
controller
   or PCE [RFC4655]."
I'm not aware that ipfix information is commonly used for
dynamic traffic
adaptation and I'm not sure that is recommendable. C


I'm agreeing with Mirja here.

We've spent a LOT of time not recommending dynamic traffic
adaptation. Probably half my responsibility as AD for ALTO was
repeating "you can't react based on changes to that attribute
without taking chances on oscillation" like it was a mystical
incantation, and I wasn't the first AD to have that conversation
repeatedly.


Yes, I understand the ARPA net had exactly that problem at one stage
and had to be converted from using a delay based metric to a fixed
metric.



I would be happy to hear that all those problems are solved, but I
haven't heard that yet. Do the right thing, of course.

Even "can shift some flows from persistently congested links to
underutilized links" would cause me less heartburn.


There is no such thing as permanent in network paths!

Like many control problems the first order solution is to damp with
a suitably long time constant, but  infinity, i.e. permanent, is not
a satisfactory choice either.


Yeah, that's where I was headed (stated more coherently).

Saying "I should do something, because the network path is STILL 
congested" is safer than "I should do something because the network path 
is congested", so now we're talking about suitable definitions of 
"STILL". I was shooting for that with "persistent", and agree that 
"permanent" path characteristics is a happy idea we aren't likely to see 
in practice.


Do the right thing, of course ;-)

Spencer

- Stewart



Spencer





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



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

Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

[Joel M. Halpern]

As far as I can tell, the formal IPR disclosure with IPR terms was not 
filed until several days after that request.

Thus, the WG can not have considered it in the light of the actual terms.

When I asked one WG participant, he was quite surprised by the terms.

Given the difficulty both Huawei and Ericsson have gotten from IETF 
participants over similar terms, I do not think this can be ignored.


Yours,
Joel

On 4/17/18 1:12 AM, Tianran Zhou wrote:

Hi Joel,

Thanks for reminding this important information.
Yes, we did the IPR poll when it became a WG draft. The IPR was disclosed then. 
Please see
https://www.ietf.org/mail-archive/web/opsawg/current/msg04792.html
We did not received any objection based on this.

Thanks,
Tianran

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Tuesday, April 17, 2018 8:25 AM
To: opsawg-cha...@ietf.org
Subject: regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

Is the working group aware of the IPR disclosure China Mobile made against
this document?  Specifically, that the IPR disclosure says that a license
may be required?

Normally, I would not even comment on that, and as you can see, I am not
commenting on the list about it.

But I note that this is a case where there is a clear workaround (just don't
do this).  So I would expect that the shepherd report, whenever that is
produced, will need to discuss the IPR disclosure.

Yours,
Joel


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

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

[Joel M. Halpern]

Thank you Jimmy.
While I disagree, I think this states the case clearly enough for it to 
be up to the working group and relevant ADs.


Yours,
Joel

On 4/15/18 11:40 PM, Dongjie (Jimmy) wrote:

Hi Joel,

Thanks a lot for your review comments.

Regarding your first problem, I don't think this draft introduces "significant new 
processing load on the router", as similar processing has already been done for the 
BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the 
BGP-community based traffic collection is done by BGP lookup and correlating the BGP 
community with the flow data to be exported. Whether it is done in data plane or control 
plane is implementation specific and IMO does not belong to a IETF document.

As for your second problem, as many operators have pointed out, it is a common 
case to use BGP communities to represent geo locations at various 
granularities. So we need to provide them the tools to meet their requirements. 
Standardizing the IEs for BGP community is a good start.

Best regards,
Jie


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Friday, April 13, 2018 10:44 PM
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

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

[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

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

[Joel M. Halpern]

randy, noting that the IETF has trouble with the geo-tagging of its 
addresses does not seem to have ANYTHING to do with demonstrating how 
widely used the geo-communities are.


If you want to make that case, make it.  But don't bring up red herrings.

As you note, it is up to the WG, not to me, what to ask for regarding 
this draft.  And it is up to the ADs to judge whether this is a good 
thing to standardize.


Yours,
Joel

On 4/15/18 6:53 PM, Randy Bush wrote:

Thus, again, you are not making a case for why the existing techniques
which are easier to implement and deploy are not sufficie3nt for the
problem.


correct.  i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
granularities.  you are not required to agree.

and you can argue the rest with someone else.



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

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

[Joel M. Halpern]

Randy, I did suggest that one would update the offline data.
My point was that the draft claims taht extreme timliness is needed. 
For IP block geolocation, timeliness on the order of a day (much shorter 
than the several days before the IETF when the IETF block gets turned on 
somewhere.)


Thus, again, you are not making a case for why the existing techniques 
which are easier to implement and deploy are not sufficie3nt for the 
problem.


Yours,
Joel

On 4/15/18 6:28 PM, Randy Bush wrote:

I fone has geo-information, it is unlikely to change.


i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever.  it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.

when you find yourself in a hole, first thing is to stop digging.

___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



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

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

[Joel M. Halpern]

Thank you for that pointer.  It is informative.
I looked at a number of the entries (trying to pick larger ISPs as more 
likely to need more information.)
What i see is some ISPs doing what Randy Bush mentioned, marking 
regions.  I see a few ISPs that explicitly mark country (or in one case 
city).  I see some that mix several pieces of information including 
country in the same community, making it hard to perform what this I-D 
calls for (not impossible, just harder).  I do not see any indication of 
wide-spread consistency.


It appears that this is of use to a few ISPs.  I have never argued that 
no one wants this (the authors would not have written it if no one 
wanted it.)


From what I can tell reading this, the value requires significantly 
more precision than "region".


Also, one of the arguments for doing this in the router is that you can 
get more timely and precise correlation.  Except that for geolocation of 
address blocks, upstream correlation seems to be quite sufficiently 
stable and precise.  NLRI may come and go.  I fone has geo-information, 
it is unlikely to change.


Yours,
Joel


On 4/15/18 12:09 PM, heasley wrote:

Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang:

Why do you think this is unusual and not common?


Possibly, with due respect, because he is not an operator?  While ASes often
do so internally, not all reveal it externally or not ubiquitously.  Browse
https://onestep.net/communities/ to find the geo tag values of various ASes.



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

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel M. Halpern]

Is this for one operator (still important, but not necessarily for 
standardization) or are there several operators who have expressed 
interest in this?


Yes, we do proactive standards.  But the IDR group, for example, tends 
to be very careful to see if interest is reflected in implementation.


In this case, given that what is proposed is a completely different use 
of the BGP communities, I think at least more clarity that this is only 
expected to be used for communities that match the purpose, and of how 
and why the vendors would implement the router-side logic.


To get back to the points I made in the review:

1) The document needs to be much clearer that it is about new 
communities whcih are expected to be defined for this use.  It needs to 
be clear if this is expected to be applied to communities put on by 
other AS, or only to communities provided by routers of the collecting 
AS.  The later leads to understandable configuration.  The former leads 
to questions about hos the meaning will be known.


2) The document needs to be clear and explicit about what processing it 
is expecting the router to provide, and how much configuration is needed 
to get the right things to happen.


Yours,
Joel

On 2/27/18 8:54 PM, li zhenqiang wrote:

Hi Joel,

This is Zhenqiang Li from China Mobile. The purpose of this doc is not 
to report the well-known communities, but the operator planed 
communities represent the groups of the customers, peers, 
the geographical and topological related information as stated in 
RFC4384, which is a common practice and also used in our field network.


When the exporter, i.e. router, receives the templete to report the 
communities, the exporter gets the information through BGP lookup using 
the corresponding source or destination IP of a traffic flow. The 
procedure for the exporter to get the community informaiton of a traffic 
flow is the same as it gets the AS information.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2018-02-12 00:37
*To:* Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; gen-...@ietf.org
<mailto:gen-...@ietf.org>
*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>;
opsawg@ietf.org <mailto:opsawg@ietf.org>
*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
This was a requested early review.  You folks can do as you deem best.
 From where I sit, it seems odd.  Most well-known communities do not
fit
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other
than
the one originating the communities.  Which makes it even harder to see
when it would apply.
I presume this is driven by having found that it would have helped in
some real-world situation?
I think the document would be helped by a clearer description of
when it
applies and what behavior is expected of the router (not just "the same
as that over there.")
Yours,
Joel
On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:
 > Hi Joel,
 >
 > Thanks for your review comments. Please see my replies inline:
 >
 >> -Original Message-
 >> From: Joel Halpern [mailto:j...@joelhalpern.com]
 >> Sent: Saturday, February 10, 2018 1:27 AM
 >> To: gen-...@ietf.org
 >> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
opsawg@ietf.org
 >> Subject: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
 >>
 >> Reviewer: Joel Halpern
 >> Review result: Not Ready
 >>
 >> This is an early gen-art review of draft-ietf-opsawg-ipfix-bgp-04.
 >>
 >> The document is clear about what it is trying to do, and
readable.  It is not
 >> clear about how it expects this to actually work.
 >>
 >> However, I find the underlying concept confusing.
 >> 1) BGP Communities may sometimes represent subsets of traffic. 
But usually

 >> they represent tagging intended to influence routing which is
only indirectly
 >> related to meaningful subsets of traffic for TE purposes.  One
may be able to
 >> make an argument that this could better enable monitoring the
effects of some
 >> BGP communities.  But the draft does not make that argument.
 >
 > This depends on how the BGP communities are used by the
operators. Except some well-known communities, BGP communities are
used in a customized manner. In some cases, BGP communities indicate
the source and destination information of a group of tra

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Joel M. Halpern]

This was a requested early review.  You folks can do as you deem best.

From where I sit, it seems odd.  Most well-known communities do not fit 
the pattern of representing groups of sources or groups of destinations.
I presume the intent here is for this to be useful in some AS other than 
the one originating the communities.  Which makes it even harder to see 
when it would apply.
I presume this is driven by having found that it would have helped in 
some real-world situation?


I think the document would be helped by a clearer description of when it 
applies and what behavior is expected of the router (not just "the same 
as that over there.")


Yours,
Joel

On 2/11/18 1:32 AM, Dongjie (Jimmy) wrote:

Hi Joel,

Thanks for your review comments. Please see my replies inline:


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Saturday, February 10, 2018 1:27 AM
To: gen-...@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg@ietf.org
Subject: Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

Reviewer: Joel Halpern
Review result: Not Ready

This is an early gen-art review of draft-ietf-opsawg-ipfix-bgp-04.

The document is clear about what it is trying to do, and readable.  It is not
clear about how it expects this to actually work.

However, I find the underlying concept confusing.
1) BGP Communities may sometimes represent subsets of traffic.  But usually
they represent tagging intended to influence routing which is only indirectly
related to meaningful subsets of traffic for TE purposes.  One may be able to
make an argument that this could better enable monitoring the effects of some
BGP communities.  But the draft does not make that argument.


This depends on how the BGP communities are used by the operators. Except some 
well-known communities, BGP communities are used in a customized manner. In 
some cases, BGP communities indicate the source and destination information of 
a group of traffic flows. These are the major case this document is focusing 
on, as it would be helpful for operator to collect the traffic statistics based 
on BGP communities. Using BGP communities to influence routing is another 
popular use case. In that case, it may also be helpful to collect traffic 
statistic information related to the BGP communities, while the purpose may not 
be just for TE.

2) It is

unclear what this actually expects the router to do in generating this
information.
Reading between the lines, it seems that what is desired is for the router
control process to go through the IPFIX collected information before it is
exported, and add BGP community tags to the export information.
(Generating such information directly from the forwarding plane would place
significant load on the forwarding representation and processing, and on the
control logic to generate FIB information.)  Given that off-line BGP information
collection is a common practice, and that such information is common across
the AS, it would actually seem simpler to perform such processing and
aggregation offline rather than in the router.


The behavior of a router would be similar to its behavior with the existing BGP 
relevant IEs, e.g. bgpSourceAsNumber, bgpDestinationAsNumber, 
bgpNextHopIPv4Address, etc. Basically this is the aggregated traffic 
information collection model, in which the router aggregates the collected 
traffic information based on the IEs specified in the template, so that it can 
export much less information to the collector without losing the information 
the collector really cares about. Exporting aggregated traffic statistics has 
been widely used in the networks.
  
Note that the purpose of this mechanism is to export the aggregated traffic statistics information at the granularity specified by BGP communities, while BMP can used to collect the detailed information of BGP RIBs and BGP events, IMO they are designed for different purposes. Although it is possible to export all the non-aggregated traffic information to the collector, and let the collector to correlate them with the BGP communities, this can bring heavy burden to both the exporter and the collector.




If the IDR working group has not been consulted about this, I would strongly
recommend working with them as to whether this is actually useful information
to collect, and how and where to collect it. If the IDR working group does not
consider important to work on this, then that gives you useful information in
and of itself.


The IDR WG has been notified about the LC of this document, so far there is no 
objection received from them. We would like to encourage IDR people to review 
and give feedbacks to help improve this document. Whether the new IEs are 
useful or not should be determined in the OPSAWG.

Best regards,
Jie



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

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Joel M. Halpern]

Let me ask a different version of Carlos (and maybe Randy's) point.

If the IETF as a community objected to the content of this draft, 
presumably there would ahve been significant dissent during the IETF 
last call.

It looked to me like the consensus in support of this was rough but clear.

More importantly, if you think the demonstrated consensus was not in 
support of the document, that is a specific process problem.
If you are saying that in spite of the demonstrated rough consensus, you 
still say that this violates your understanding of the IETF agreement, 
I do not understand how, at this stage of the process, that is your call 
to make?
As Carlos quotes, the existing documents make it clear that their must 
be judgment calls about these issues.
And such a personal consensus interpretation seems even less grounded 
for an informational document aimed, as the abstract states at:


   discusses current security and network operations and management
   practices that may be impacted by the shift to increased use of
   encryption to help guide protocol development in support of
   manageable, secure networks.

If you feel the document does not match its abstract, that is a VERY 
different objection than claiming that the document violates your 
personal take (not demonstrated during IETF last call) on the IETF rough 
consensus.


Yours,
Joel

On 2/8/18 9:08 PM, Carlos Pignataro (cpignata) wrote:



On Feb 8, 2018, at 5:17 AM, Randy Bush  wrote:


Unfortunately, the fundamental concern that motivated my DISCUSS
remains: I do not believe that this document matches the consensus
of the IETF community.

That's an interesting claim.
If the process has not been followed, this requires facts as opposed
to "believes".
We should make sure to make a distinction between the IETF community
views and your own views.


Eric: I’m also interested in understanding your claim regarding consensus — can 
you please expand?



1984 7258


"  Making
networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here.  An
appropriate balance will emerge over time as real instances of this
tension are considered.”


7625 ... and dogged comments on this draft; though some of us
have grew a bit weary of the denial game and allowed ourselves to be
shut up.


Or a DDoS against the ideas on this document?



randy



—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis.”



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


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



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