Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Thank you. Those edits do the job nicely. Joel On 5/6/2024 5:49 AM, mohamed.boucad...@orange.com wrote: Hi Joel, Thank you for the review. You got it right. Please see more context at [1]. I updated the text to address your review. Please check the diff [1] and let me know if any further change is needed. Thanks. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/opsawg/g-cXqAHzazaA_gOf7Woxv2SiVJ4/ [2] https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt -Message d'origine- De : Joel Halpern via Datatracker Envoyé : vendredi 3 mai 2024 05:01 À : gen-...@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last- c...@ietf.org; opsawg@ietf.org Objet : Genart last call review of draft-ietf-opsawg-ipfix-tcpo- v6eh-11 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 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ=05%7C02%7Cmoh amed.boucadair%40orange.com%7Cbfb8988782a541c5816808dc6b1d5145%7C 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503020857412204%7CU nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=WIsBdbKOD9ZyF0j%2BZKnq6 ke79zktUZ9q%2B5n2iW34U%2Fs%3D=0>. Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11 Reviewer: Joel Halpern Review Date: 2024-05-02 IETF LC End Date: 2024-05-10 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: None Minor issues: The document uses the phrasing "If several extension header chains are observed in a Flow" in several places. While I believe I figured out what was intended, it caused me difficulty. Assuming I understood the intent, I would suggest defining a term "flow with varying header chain" as "a flow wherein different packets in the flow have a different sequence of extension header types codes." And then use that term in the suitable places in the document. Nits/editorial comments: None 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
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 <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11 Reviewer: Joel Halpern Review Date: 2024-05-02 IETF LC End Date: 2024-05-10 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: None Minor issues: The document uses the phrasing "If several extension header chains are observed in a Flow" in several places. While I believe I figured out what was intended, it caused me difficulty. Assuming I understood the intent, I would suggest defining a term "flow with varying header chain" as "a flow wherein different packets in the flow have a different sequence of extension header types codes." And then use that term in the suitable places in the document. Nits/editorial comments: None ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Fwd: [mpls] New Liaison Statement, "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) Requirements and Reference Model for optimized traceroute of joint Internet Pro
I checked with the IETF's liaison manager for ITU-T. It turns out, process-wise, that the underlying document this refers to was fully approved by ITU-T in December. So there is nothing to respond to and no benefit for the IETF in generating a response. Yours, Joel On 2/17/2024 12:13 AM, l...@pi.nu wrote: Greg, I'm not the expert on ICMP, but as far as I see you are correct. I very much would like an ICMP expert to look at this, but I don't know who to contact. Can anyone help me? /Loa Hi Loa, thank you for bringing to the discussion this liaison. I've looked through the prescribed processing and I have concerns about the scenario when an ICMP packet arrives at PE1 with the TTL=3. If I understand the process correctly, IP TTL is decremented and since it is non-zero, the ICMP packet is encapsulated in MPLS with MPLS TTL set to 2. If the MPLS network has more than one P node, that MPLS TTL expires at the second downstream P node. That node discovers the ICMP packet with TTL=2. And here I see two cases: - IP Dst is unknown to the P node - IP Dst is, somehow, known to the P node In the latter case, the P node will route the ICMP packet. In the former, as I understand it, will drop its ICMP Host unreachable. Either case is troublesome. Am I missing something in the process described in the liaison? Do you see a mistake in my thinking? Regards, Greg On Fri, Feb 16, 2024 at 2:08 AM wrote: All, We have the liaison: "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) Requirements and Reference Model for optimized traceroute of joint Internet Protocol/Multi-Protocol Label Switching". I have tried to read the Recommendation, still have some concerns and questions. The liaison was addressed to the OPSAWG, but Tianran (OPSAWG co-chair) sent this to the MPLS WG that seem better fitted to respond if we want to. One questions for the OPSAWG is that if the MPLS WG decides to respond would the OPSAWG want to join in on the response? My concerns at moment are (possible there will be more) are rather high level. The consented document is about "IP/MPLS" traceroute. This is core IETF/IP areas, and within the IETF design authority.. If the intention is to align SG-11 protocols with IETF technology that is OK. If it is it is a bit odd that neither STD5 (which include ICMP) nor RFC 8029 are mentioned. In fact a consented Recommendation on IETF core technology does not mention a single RFC. If the intention is to create an ITU-T owned version of traceroute we are back in the discussion on honoring design authorities. The terminology is not well aligned with the IETF RFC. There are "MultiProtocol Label Switch" rather than "MultiProtocol Label Switching", MPLS tags (sic!), CE is said to be expanded as "Customer Equipment", while the common IETF usage is "Customer Edge", and there is more. Figure 6-1 deserves some scrutiny - the PEs seem to belong to both carrier and enterprise network - half of the CE seem to belong to the enterprise network and the other half to something undefined. Also figure 6-1, a normal MPLS network deployment would have IP connectivity end to end and traceroute would just work over IP. Havin said that there is not always IP, e.g. MPLS-TP is built on the assumption. that IP connectivity is not necessary. I think we have good reason to respond even though the Liaison is "For Information". I don't know where the responsibility for STD5/ICMP lies, but possibly someone that know could forward. And I think it would be a good idea to call on Scott to coordinate a response. /Loa Sent from my iPhoneBegin forwarded message: dir="ltr">From: Greg Mirsky gregimir...@gmail.comDate: 29 October 2023 at 04:21:17 GMT+8To: Tony Li tony...@tony.liCc: m...@ietf.org, Henk Birkholz henk.birkh...@sit.fraunhofer.de, liaison-coordinat...@iab.org, Tianran Zhou zhoutianran=40huawei@dmarc.ietf.org, Warren Kumari war...@kumari.net, Joe Clarke jcla...@cisco.com, mpls-cha...@ietf.org, Robert Wilton rwil...@cisco.com, itu-t-liai...@iab.org, rtg-...@ietf.orgSubject: Re: [mpls] New Liaison Statement, "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) “Requirements and Reference Model for optimized traceroute of joint Internet Protocol/Multi-Protocol Label Switchingâ€" type="cite">Hi Tony,it appears to me that what this recommendations describes is Uniform tunneling model ( href="https://datatracker.ietf.org/doc/html/rfc3443;>RFC 3443) for treatingICMP over MPLS (not sure whether the proponents of the recommendation argue for using the uniform model for subscriber traffic in general).Regards,GregOn Sat, Oct 28, 2023 at 10:35 AM Tony Li mailto:tony...@tony.li;>tony...@tony.li wrote: 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Perhaps a pointer to IOAM-DEX and a “thanks, already doneâ€? T On Oct 28, 2023, at 10:14 AM, Adrian Farrel mailto:adr...@olddog.co.uk;
Re: [OPSAWG] Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)
I would add that the text about processing such things seems to me to be the typical (and appropriate) use of the Postel Principle, from which we can tell that the important part is the rule earlier in the text that says that EHs occur once each, except for destination options which may occur exactly twice (before and after a source routing header. The fact that 8200 doesn't use our now preferred normative language does not mean we should ignore its requirements. Yours, Joel On 5/25/2023 1:28 PM, James Guichard wrote: Hi Rob, [adding spring chairs as my comment is directly related to SRv6] I did some digging on this from an SRv6 perspective, and no documents explicitly prohibit using multiple SRH in a packet. However, it is also true that no documents define what a node is supposed to do if it encounters another SRH after the topmost SRH has completed processing. While 8200 might say that IPv6 nodes must accept and attempt to process EHs occurring any number of times, SRv6 has no standardized mechanism defined to process multiple SRH. Hope this helps. Jim *From:*iesg *On Behalf Of *Rob Wilton (rwilton) *Sent:* Thursday, May 25, 2023 12:31 PM *To:* Andrew Alston - IETF ; John Scudder ; mohamed.boucad...@orange.com *Cc:* The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org *Subject:* RE: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS) Hi, I don’t think that John’s example is quite the same. The IPv6 packet header format only has a space for a single source address and it is 16 bytes long. Two source addresses or a 20-byte address is clearly an invalid IPv6 packet because it doesn’t match the IPv6 packet format. But I don’t think that this is quite true for IPv6 extension headers, where the text states: Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header). But it also states in the same section: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. This second paragraph, which is just as normative as the first, seems to clearly indicate that IPv6 nodes are expected to handle and process extension headers occurring multiple times, implying that they could occur. Hence, I suspect that it is this second paragraph as to why Thomas was trying to define how IPFIX works if this scenario is encountered in the wild. E.g., operationally, it is better to report what you actually see rather report what the operator/client ideally wants to believe is in the packet. I.e., if your IPv6 node does receive a packet with two SRv6 headers (which I still believe RFC 8200 allows for), and modulo Jim’s argument that this is invalid, then I would still argue that it is more helpful to report that they are both there than just reporting the first one and ignoring the second. YANG NMDA, RFC 8342 is designed similarly. Even if a YANG list states that it can only contain 2 elements, but due to some (presumably buggy) reason, the device actually has 3, it is better to report all three than just pretend that there are only 2 elements, because it helps the operator debug that something is going wrong (section 5.3). I would argue that Jim’s argument that another SRv6 related RFC (I don’t know which one) clearly indicates that a v6 header can only ever contain a single SRH header holds a little more sway and is perhaps more relevant. Having said all that, I think that point is somewhat moot because I think that the authors have agreed to remove this paragraph anyway – even if IMO it possibly makes the spec a bit less robust/helpful. Regards, Rob *From:*iesg *On Behalf Of *Andrew Alston - IETF *Sent:* 25 May 2023 16:54 *To:* John Scudder ; mohamed.boucad...@orange.com *Cc:* The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org *Subject:* Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS) Hi Med, Firstly – I need to second what John said below. Secondly, while we can agree that IPFIX supporting this doesn’t violate the RFC – what it does do – is cater explicitly for what I believe is a violation of RFC8200, and that is where I have a problem. While there could be **many** things that are done out of spec – unless there is a very specific and solid reason to cater for such out of spec behavior, this doesn’t make sense to pick and choose the out of spec we are agreeing to suddenly
Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-tlstm-update-11
Thank you. Joel On 2/15/2023 10:50 AM, Kenneth Vaughn wrote: I have uploaded an update that more accurately indicates that a "session" is a secure association between two /_instances of_ /the TLSTM. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com <http://www.trevilon.com/> On Feb 9, 2023, at 6:56 PM, Joel Halpern via Datatracker wrote: Reviewer: Joel Halpern Review result: Ready 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-tlstm-update-11 Reviewer: Joel Halpern Review Date: 2023-02-09 IETF LC End Date: 2023-02-20 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: In the fourth paragraph of section 1.1, the text refers to "a secure association between two TLS Transport Models (TLSTMs)". As I understand the terminology, there is one TLSTM. There are two instances of / realizations of the model. Should the sentence refer to instances or realizations, rather than two models? (i-d nits gets confused by the references to rfc 5953 in the revision description. After looking at it, I realized there was no problem here, rather it is accurate. A comment on this in item 14 of the shepherd writeup would have been helpful.) Nits/editorial comments: N/A ___ 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] Genart last call review of draft-ietf-opsawg-tlstm-update-11
Reviewer: Joel Halpern Review result: Ready 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-tlstm-update-11 Reviewer: Joel Halpern Review Date: 2023-02-09 IETF LC End Date: 2023-02-20 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: In the fourth paragraph of section 1.1, the text refers to "a secure association between two TLS Transport Models (TLSTMs)". As I understand the terminology, there is one TLSTM. There are two instances of / realizations of the model. Should the sentence refer to instances or realizations, rather than two models? (i-d nits gets confused by the references to rfc 5953 in the revision description. After looking at it, I realized there was no problem here, rather it is accurate. A comment on this in item 14 of the shepherd writeup would have been helpful.) Nits/editorial comments: N/A ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. 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? 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? 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. 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? Nits/editorial comments: The "customer-application" identity seems to be asking for problems in two regards.It seems that it is a shorthand way of expressing some combination of protocols and ports. 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 mean the same thing when using them. (For example, just what filer corresponds to "voice"?) As a lesser issue, the current IAB work on path signals and the care that should be taken with them would seem to suggest that this is a less than desirable approach to the problem. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Genart telechat review of draft-ietf-opsawg-ipfix-bgp-community-11
Reviewer: Joel Halpern Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-ipfix-bgp-community-11 Reviewer: Joel Halpern Review Date: 2018-11-29 IETF LC End Date: 2018-09-24 IESG Telechat date: 2018-12-06 Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: As id-nits notes, references should not be included in the abstract. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-bgp-community-07
Reviewer: Joel Halpern Review result: Ready 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-ipfix-bgp-community-07 Reviewer: Joel Halpern Review Date: 2018-09-14 IETF LC End Date: 2018-09-24 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: While I am still concerned (see my previous reviews) that this may well be the wrong answer to the wrong question, the authors have done a good job of explaining what they are doing and justifying why in some situations it will be useful. That seems the appropriate standard, and thus the document is ready for publication. Minor issues: Nits/editorial comments: ___ 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
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] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04
ern <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 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 informatio
[OPSAWG] 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. 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. 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
