Hi,
I support adoption.
Just one comment -
In-Packet OAM:
> The OAM messages are carried as part of data traffic. This was sometimes
> referred to as "in-band".
I wonder if "message" is the correct term here. In the example that follow
for IOAM you use the term "information".
Thanks!
Dhruv
Hi,
FWIW my preference would be for (3) and having a clean slate in IVY. Apart
from the technical reasons of including software components from the start,
already laid out by others, it also makes sense to take that as a practical
approach. Authors of both drafts have done a good job and in the
Hi Benoit,
On Tue, Jun 28, 2022 at 7:16 PM Benoit Claise
wrote:
> Hi Dhruv,
>
> Thanks for reviewing the draft.
> See inline.
>
> On 6/26/2022 4:04 PM, Dhruv Dhody wrote:
>
> Hi WG,
>
> I think this work is very useful. I have some comments (also see my re
ew.
> See inline
>
> On 6/26/2022 4:03 PM, Dhruv Dhody wrote:
>
> Hi WG,
>
> I think this work is very useful. I have some comments -
>
> Minor
> - We need a reference or some discussion of what we mean by "intent"
> before we jump into SAIN in the Introd
Hi WG,
I think this work is very useful. I have some comments (also see my review
of the architecture I-D).
Minor
- In the text of the I-D, we should explain that the symptoms are targeted
at humans and not machines.
- Architecture talks about circular dependencies and states that it is
likely
Hi WG,
I think this work is very useful. I have some comments -
Minor
- We need a reference or some discussion of what we mean by "intent" before
we jump into SAIN in the Introduction.
- The statement "Such approaches are mainly suited for greenfield
deployments" about intent is not clear to me.
/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-09
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-09>*
>
>
>
> *Please also see inline for the replies..*
>
>
>
> *Thanks,*
>
> *Bo*
>
>
>
> *From:* Dhruv Dhody [mailto:
comments along with the other last call comments.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Document: draft-ietf-opsawg-yang-vpn-service-pm
Reviewer: Dhruv Dhody
Review Date: 2022-05-12
IETF LC End Date: Unknown
Intended Status
Thanks Med, for taking my comments into consideration!
On Fri, Feb 11, 2022 at 6:38 PM wrote:
> Hi Dhruv,
>
> A candidate version that takes into account your comments can be seen at:
> https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/I-D-sap/draft-ietf-opsawg-sap.txt
>
> As a reminder, your
Hi Qin,
On Fri, Jan 21, 2022 at 6:05 PM Qin Wu wrote:
> Thanks Dhruv for valuable review, see reply inline below.
>
>
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *Dhruv Dhody
> *发送时间:* 2022年1月19日 20:40
> *收件人:* Tianran Zhou
> *抄送:* opsawg@ietf.org; opsawg-ch
Hi Tianran,
I have read the I-D and I support its adoption.
Few comments -
1) Figure 1 uses the term "Service Network Models" which is not defined and
not aligned to RFC 8309.
2) Is the attachment-id the key via which the SAP is linked to the physical
topology? More text on this would be
Hi Haoyu,
Thanks for taking my comments into consideration. Focusing on the open
points...
o Something that I find missing in the document is that the network
> controller could be a valuable source of network telemetry as well.
> Consider a PCE, the controller could be a source of
that you receive, and strive to resolve them through
discussion or by updating the draft.
Document: draft-ietf-opsawg-ntf-10
Reviewer: Dhruv Dhody
Review Date: 2021-11-19
IETF LC End Date: over
Intended Status: Informational
Summary:
Choose from this list…
- I have some minor concerns about
Hi Med,
On Wed, Apr 7, 2021 at 1:23 PM wrote:
> Hi Dhruv,
>
> Thank you for the review.
>
> Focusing on the vpn-common part:
>
> > draft-ietf-opsawg-vpn-common:
> > - Not sure about the difference between the identity "sr-mpls" and
> > "sr-te".
>
> Med: sr-mpls refers to RFC 8660, which states
Hi WG,
I support publication for both the I-Ds. Some minor comments -
==
General:
- I guess the best practice for a section in the reference is "RFC
: The title, Section X" instead of "Section X of RFC "
- Both YANG modules could use more references (Example multicast part in L2NM)
==
Hi,
The work seems to be quite useful. I support adoption by the WG.
A few comments -
(1) If the model supports L2VPN, I think we need to add the L2-level
counters in the vpn-summary-statistics. Currently we only have IPv4 and
IPv6 routes.
(2) Section 3
The performance monitoring
Hi Med,
Thanks for considering my comments.
> - This text
> >
> >To avoid the issues discussed above, this document defines a common
> >YANG module that is meant to be reused by various VPN-related
> > modules
> >such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
> >
Hi Oscar,
> - This text
>
>To avoid the issues discussed above, this document defines a common
>YANG module that is meant to be reused by various VPN-related modules
>such as Layer 3 VPN Service Model (L3SM) [RFC8299], Layer 2 VPN
>Service Model (L2SM) [RFC8466], Layer 3 VPN
Hi WG,
I support adoption. Just a few thoughts...
- This document has "Updates: 8782" in its header. Surely a mistake!
- This text
To avoid the issues discussed above, this document defines a common
YANG module that is meant to be reused by various VPN-related modules
such as Layer 3
Support for adopting this work.
On Fri, Oct 11, 2019 at 3:32 PM li zhenqiang wrote:
>
>
> Support adopting this doc as an operator with the following comments.
>
> We are considering corelating VPN services with tunnels (SR MPLS TE tunnels
> or SRv6 TE tunnels) and SR policies to provide
20 matches
Mail list logo
