Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Dhruv,
Thanks a lot for your comments. I have noted them and we will apply in the next revision.
In particular, I agree, in Section 5 we need to describe what happens for the error conditions you mentioned. We will specify the error handling actions to be aligned with draft-ietf-idr-segment-routing-te-policy.

Regards,

Giuseppe

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Wednesday, November 11, 2020 12:09 PM
To: Susan Hares <shares@ndzh.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, WG,

I support adoption of this draft. Thanks the authors to maintain parity and sync with PCEP draft as well. Some non-blocking comments that could be useful to the authors -

Minor
- Update to RFC 8174 requirement language (from RFC 2119)
- Section 3, last paragraph only mentions SRv6. Should this also include SR-MPLS as done in other places?
- Section 4, Sync it with the latest encoding structure at
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-10#section-2.2
(SRv6 Binding SID is missing)
- Section 5, what happens in case of empty IFIT Attributes Sub-TLV i.e. no further IOAM sub-TLV and Length=0?
- Section 5, what happens if two conflicting IOAM sub-TLVs are present? Say both Pre-allocated and incremental are included.
- Section 5, what happens if there is more than one instance of the sub-TLV of the same type? More text for these error conditions is required.
- Section 5.1, Add "and ignored on receipt" for the description of the Rsvd field. (applicable at other instances as well)
- Some description about stopping IOAM or about modifying IOAM techniques should also be added.
- Some text on backward compatibility i.e. an implementation that does not understand IFIT Attributes Sub-TLV should be added

Nits
- Expand OAM, PCEP, on first use!
- Section 5.3, fields should be listed in the same order as the figure.
- Section 8, s/SHOULD not/SHOULD NOT/

Thanks!
Dhruv

On Mon, Nov 2, 2020 at 11:27 AM Susan Hares <shares@ndzh.com> wrote:
>
> This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).
>
>
>
> The draft can be accessed at:
>
> https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/
>
>
>
> The authors should provide IPR statements by 11/5/2020 so the IDR WG 
> can consider the IPR status in their
>
> decision.
>
>
>
> This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).
>
>
>
> The IDR co-chairs thank the authors for their patience.  The WG adoption call for this draft has been delayed by the process of switching shepherds for BGP Tunnel Encaps draft.  Many BESS and IDR drafts currently refer to the BGP tunnel encapsulation drafts.
>
>
>
> In your review of this draft, please differentiate between the following:
>
> ·         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,
>
> ·         Support/rejection of alternate marking as a IP routing technology,
>
> ·         Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and
>
> ·         Specific issues with the descriptions of these features in the draft.
>
>
>
> Cheers, Susan Hares
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr