Re: [OPSAWG] [IPv6] [mpls] [Detnet] IOAM, iOAM, and oOAM abbreviations

2023-12-18 Thread Stewart Bryant 


> On 16 Dec 2023, at 10:16, Adrian Farrel  wrote:
> 
> Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”. 
> It’s not like it can be said faster (one additional syllable to say it) and 
> it only saves four characters in typing.
> “oob-OAM” is also marginal. Same number of syllables to say (I don’t think 
> anyone pronounces “oob” as a single syllable), and a little more saving in 
> typing.

+ 1 

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

[OPSAWG] Genart telechat review of draft-ietf-opsawg-tacacs-13

2019-05-13 Thread Stewart Bryant via Datatracker 
Reviewer: Stewart Bryant
Review result: Almost 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-tacacs-13
Reviewer: Stewart Bryant
Review Date: 2019-05-13
IETF LC End Date: None
IESG Telechat date: 2019-05-16

Summary:

There are a number of issues called out below that need addressing before 
publication.

Someone needs to micro-check the text to make sure that all terms are defined 
and referenced.
I picked up a few, but there were a lot I did not have time to check.

Major issues:

SB> The IANA section should ask IANA to point to this RFC as a reference
SB> for port 49




   The first MD5 hash is generated by concatenating the session_id, the
   secret key, the version number and the sequence number and then
   running MD5 over that stream.  All of those input values are
   available in the packet header, except for the secret key which is a
   shared secret between the TACACS+ client and server.

SB> MD5 make a good checksum, but I am surprised to see it used in this
SB> application in a new protocol.

=

   All TACACS+ packets begin with the following 12-byte header.  The
   header describes the remainder of the packet:

SB> If ever there was an error in a long term session, how
SB> how would you find in in the following packet structure?
SB> Presumably from an incorrect major version and sequence number?

SB> Some details on the error cases and the unconditional "safety"
SB> of the protocol would be useful.

==

  TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

  TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

  TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

  TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

  TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

  TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06



SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types 
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

===

 The START packet MUST contain a username and the data
   field MUST contain the PAP ASCII password.  A PAP authentication only
   consists of a username and password RFC 1334 [RFC1334] . The REPLY
   from the server MUST be either a PASS, FAIL or ERROR.

SB> Should there note be a note that RFC1334 is obsolete?

===

Minor issues:

The use of the term "packet" as a unit of data is confusing, since the protocol
is carried over TCP which is a streaming protocol.

They are really TACAS+ PDUs

=

(For example, Cisco uses "tty10"
   to denote the tenth tty line and "Async10" to denote the tenth async
   interface).  
SB> Is it correct to quote a particular vendor in an RFC of this type?



  TAC_PLUS_PRIV_LVL_MAX := 0x0f

  TAC_PLUS_PRIV_LVL_ROOT := 0x0f

  TAC_PLUS_PRIV_LVL_USER := 0x01

  TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?


Nits/editorial comments:

  The normative description of Legacy features such as ARAP and
SB> ARAP not expanded anywhere in document.

=

SB> telnet and rlogin need references

=
   is the user is connected via ISDN or a POTS, 
SB> Are ISDN and POTS well known IETF terms?

=

   It is not legal for an attribute name to contain either of the
   separators.  It is legal for attribute values to contain the
   separators.  
SB> Is "legal" the correct term here?


___
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)

2018-12-06 Thread Stewart Bryant 



On 06/12/2018 07:55, Dongjie (Jimmy) wrote:

Hi Spencer, Stewart, Joel,

Thanks for the discussion about the congestion adaptation. We agree the 
reactive congestion adaptation may need further investigation.

Thus in order to solve Mirja's comment, we plan to make that example more 
generic with something like:

"For example, the collected information could be used for traffic monitoring, and 
could optionally be used for traffic optimization according to operator's policy."


Sounds much better.

Stewart



Best regards,
Jie


-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Wednesday, December 05, 2018 12:03 AM
To: Spencer Dawkins at IETF ; Stewart
Bryant 
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind
; IESG ;
draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org
Subject: Re: [OPSAWG] Mirja Kühlewind's No Objection on
draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

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
mailto:stewart.bry...@gmail.com>> 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-communit
y/



 --
 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] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

2018-12-04 Thread Stewart Bryant 



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 > 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.


- Stewart



Spencer



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

Re: [OPSAWG] [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX

2017-06-08 Thread Stewart Bryant 
If you stick with UDP, and there are good reasons to do that, maybe we 
need a fragmentation shim for UDP?


Stewart


On 08/06/2017 04:21, li zhenqiang wrote:

Hello  Mr. Aitken,

Thank you very much for your suggestion.
I have no perfect idea now. Extending the length of IPFIX message is a 
simple method. But do we need to take the transport protocol into 
account? Although SCTP is mandatory, some IPFIX implementations use 
TCP or UDP as their transport protocol. SCTP provides message 
fragmentation and reassembly method, neithor TCP nor UDP. TCP and UDP 
rely on IP to finish this work. IP fragmented packets may be droped by 
some nodes in the network due to security rules or to improve the 
tansport preformance. For the implementations using TCP or UDP as 
their transport protocol, sometimes they may not receive some 
fragmented IPFIX messgaes when we extend the message length to 32 
bits. I think BGP protocol with extended message length as defined in 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ 
 also 
has the same issue. I will send a seperate mail in IDR to ask for 
their opinions.


Best Regards,


li_zhenqi...@hotmail.com

*From:* PJ Aitken 
*Date:* 2017-06-07 17:53
*To:* li zhenqiang ; opsawg
; idr ;
ip...@ietf.org 
*Subject:* Re: [IPFIX] [Idr] discussion about exporting BGP
community information in IPFIX
What IPFIX message splitting method would you propose? Bear in
mind that it must be backwards-compatible with existing collectors
which do not expect message splitting.

Rather than splitting messages, it might be acceptable simply to
send longer messages. I think this would require a new version of
IPFIX (eg, version 11) with the following modifications:

* 32-bit Length in the Message Header (cf. RFC 7011 / Figure F)
* 32 bit Field Length in the Field Specifier Format (cf. RFC 7011
/ Figure G)
* 32 bit Length in the Set Header Format (cf. RFC 7011 / Figure I)

P.


On 07/06/17 10:02, li zhenqiang wrote:

about question 1， the message length.
A WG
draft,https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

,
extends the maximum update message sizeof BGP beyond 4096 bytes to 65535 
bytes. So,
one IPFIX message may not be sufficient to fit all the
communities related to a specific flow. BGP speakers
that support the extended message feature
SHOULD takecare to handle the IPFIX message properly, such as only convey 
as many communities as possible in theIPFIX message. The collector that
receives an IPFIX message with maximum length and BGP communities
contained in its data set SHOULD be aware of the BGP communities may be 
truncated due to limited messagespace. In this case, it is RECOMMENDED to 
configure export policy on the exporter to limit the BGP communitiesto be 
exported, to export only some specific communities, for example, or not to 
export some communities.

To solve this problem completely, we should update
IPFIX Protocol Specification RFC7011 to supportmessage splitting.

Your comments are appreciated.


li_zhenqi...@hotmail.com




___
IPFIX mailing list
ip...@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


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

Re: [OPSAWG] [IPFIX] [GROW] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

2017-02-16 Thread Stewart Bryant 



On 16/02/2017 11:15, PJ Aitken wrote:


IPFIX Collectors might reasonably assume that information in 
subsequent messages supersedes information in earlier messages, so 
splitting a list across multiple messages would not have the desired 
effect.





Hi Paul

Could you not have multiple discrete templates?

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

Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

2017-01-10 Thread Stewart Bryant 
I can see the utility in that case, but I think that we need to set that 
expectation with the reader of the text.


Stewart


On 10/01/2017 19:19, Frank Brockners (fbrockne) wrote:


We probably need to differentiate things based on the use case, i.e.

1) *prove* in a secure way that a packet visited a particular set of nodes

2) *provide some hint* (e.g. to help operations) whether a packet 
visited a particular set of nodes


The POT mechanism in draft-brockners-proof-of-transit-02.txt is very 
much targeted at 1) – and the target box to perform these mechanisms 
is probably more like a firewall or similar, which would have the 
capabilities to do a bunch of operations on a packet – and differ from 
a core/backbone router.


Frank

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of *Stewart 
Bryant

*Sent:* Dienstag, 10. Januar 2017 20:10
*To:* opsawg@ietf.org
*Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

I share that concern.

I think that for this to fly, there needs to be a hardware friendly 
version.


It also seems to me that lots of applications would be satisfied with 
an approach that assumes that all routers are honest, perhaps simply 
setting a bit in a bit field, reserving the ultra-cautious check for 
special faults or special operating environments.


Stewart

On 10/01/2017 17:52, Linda Dunbar wrote:

Frank,

Your suggested approach requires egress node to do the computation
of “(Secret +RND) mod prime” and perform the comparison for every
packet. For a node with hundreds of ports and each with 10G-100G
capacity, the computation & comparison would be very heavy.

Linda

*From:*Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
*Sent:* 2017年1月3日7:43
*To:* Linda Dunbar <linda.dun...@huawei.com>
<mailto:linda.dun...@huawei.com>; Ram Krishnan
<ramkri...@gmail.com> <mailto:ramkri...@gmail.com>; Zhoutianran
<zhoutian...@huawei.com> <mailto:zhoutian...@huawei.com>;
opsawg@ietf.org <mailto:opsawg@ietf.org>
*Subject:* RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
drafts

Hi Linda,

thanks for supporting
https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt.

On
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt:
Could you elaborate a bit more why you believe that the approach
would be too complicated for the egress node? All it takes for the
verifier node is to perform a “(Secret + RND) mod prime” operation
and compare this to the CML number received in the packet (RND and
CML are the two numbers carried within the packet).

Thanks, Frank

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of
*Linda Dunbar
*Sent:* Dienstag, 3. Januar 2017 14:27
*To:* Ram Krishnan <ramkri...@gmail.com
<mailto:ramkri...@gmail.com>>; Zhoutianran <zhoutian...@huawei.com
<mailto:zhoutian...@huawei.com>>; opsawg@ietf.org
<mailto:opsawg@ietf.org>
*Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
drafts

I support WG Adoption of
https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt


But I don’t support the detailed mechanism described in
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txtto
be adopted. I think the approaches described are too complicated
for the egress nodes.

Linda Dunbar

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of *Ram
Krishnan
*Sent:* 2016年12月30日6:41
*To:* Zhoutianran <zhoutian...@huawei.com
<mailto:zhoutian...@huawei.com>>; opsawg@ietf.org
<mailto:opsawg@ietf.org>
*Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
drafts

Hi Tianran,

I can see the new draft playing predominantly a complementary
role. I have summarized some of the key areas and also added
comments, please see below.

1)https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt


-Complementary role of new draft:

oMinimizing of In-band Telemetry Header for a specific use case
such as latency measurement

oData export options

§Summarizing monitoring information to build a scalable solution –
for example, alert the central management system only when 99^th
percentile queue depth exceeds a high threshold for a flow

§Flow mirroring

oService chaining use case (independent and coupled with
underlay/overlay) – describes how network monitoring can help in
identifying server side issues and pave the way to dynamic
resource orchestration to remedy the issue

2)https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt

-Complementary role of new draft:

oMinimizing of In-band Telemetry Header format

oData export options format

-Comments on above draft:

Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

2017-01-10 Thread Stewart Bryant 

I share that concern.

I think that for this to fly, there needs to be a hardware friendly version.

It also seems to me that lots of applications would be satisfied with an 
approach that assumes that all routers are honest, perhaps simply 
setting a bit in a bit field, reserving the ultra-cautious check for 
special faults or special operating environments.


Stewart


On 10/01/2017 17:52, Linda Dunbar wrote:


Frank,

Your suggested approach requires egress node to do the computation of 
“(Secret +RND) mod prime” and perform the comparison for every packet. 
For a node with hundreds of ports and each with 10G-100G capacity, the 
computation & comparison would be very heavy.


Linda

*From:*Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
*Sent:* 2017年1月3日7:43
*To:* Linda Dunbar ; Ram Krishnan 
; Zhoutianran ; 
opsawg@ietf.org

*Subject:* RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Linda,

thanks for supporting 
https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt.


On 
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt: 
Could you elaborate a bit more why you believe that the approach would 
be too complicated for the egress node? All it takes for the verifier 
node is to perform a “(Secret + RND) mod prime” operation and compare 
this to the CML number received in the packet (RND and CML are the two 
numbers carried within the packet).


Thanks, Frank

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of *Linda Dunbar
*Sent:* Dienstag, 3. Januar 2017 14:27
*To:* Ram Krishnan >; 
Zhoutianran >; 
opsawg@ietf.org 

*Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

I support WG Adoption of 
https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt 



But I don’t support the detailed mechanism described in 
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txtto 
be adopted. I think the approaches described are too complicated for 
the egress nodes.

Linda Dunbar

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org] *On Behalf Of *Ram Krishnan
*Sent:* 2016年12月30日6:41
*To:* Zhoutianran >; opsawg@ietf.org 

*Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Tianran,

I can see the new draft playing predominantly a complementary role. I 
have summarized some of the key areas and also added comments, please 
see below.


1)https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt 



-Complementary role of new draft:

oMinimizing of In-band Telemetry Header for a specific use case such 
as latency measurement


oData export options

§Summarizing monitoring information to build a scalable solution – for 
example, alert the central management system only when 99^th 
percentile queue depth exceeds a high threshold for a flow


§Flow mirroring

oService chaining use case (independent and coupled with 
underlay/overlay) – describes how network monitoring can help in 
identifying server side issues and pave the way to dynamic resource 
orchestration to remedy the issue


2)https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt

-Complementary role of new draft:

oMinimizing of In-band Telemetry Header format

oData export options format

-Comments on above draft:
oI am surprised to see 
http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf not 
being referenced.

3)https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01
-Comments on above draft:
oThe above id focusses on injected probe packets. The new draft is 
applicable to all packets including injected probe packets.
4)Mapping in-band telemetry to different transport protocols – new 
contribution (this could be a separate draft or might be input to be 
above drafts)


oComplementary role of new draft:

§IPSEC use case for WAN and DC (beyond internet connectivity) and mapping

§VXLAN-GPE/Geneve/NSH mapping

5)https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt
-Comments on above draft:
oOne of the key reasons for packets following a path different from a 
traffic engineered/service chain path is misconfiguration. With that 
background,
§With an administrative domain, practical service verification 
scheme(s) 
(https://datatracker.ietf.org/doc/draft-irtf-nfvrg-service-verification/?include_text=) 
could suffice
§The elaborate proof of transit scheme suggested in this draft is 
possibly applicable across administrative domains where it may not be 
possible to mandate service verification. Additionally, when the path 
is changed dynamically based on intermediate node state it is not 
clear how this scheme will work.


Thanks,

Ramki

*From:*Zhoutianran [mailto:zhoutian...@huawei.com

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

2016-12-19 Thread Stewart Bryant 



On 15/12/2016 22:09, Adrian Farrel wrote:
As for the proof of transit work, I think it is a bit of a mess at the 
moment. It seems to be growing new approaches and options, each with 
drawbacks and issues. And I'm not clear on the objectives. This might 
be handled as with the previous document by describing and scoping the 
experiment, but as currently written, it would appear that the 
intention is to research a number of potential approaches to proof of 
transit rather than to experiment with a particular protocol solution, 
and that might make the document better suited to the NMRG. So I would 
like to apply a bit more caution to that document.


I think that there are two proof of transit solutions needed. One for 
network operators for simple operational verification and one for 
commercial or regulatory situations. In the first case one can assume a 
benign environment and use a lightweight approach. In the other one must 
assume a hostile environment and apply a more stringent proof. Maybe one 
can be a variant of the other, but this should not be at the cost of 
performance and implementation expense.


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