Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Dhruv,

Please check inline below [KT2].

-----Original Message-----
From: Dhruv Dhody <[e-mail]> 
Sent: 10 November 2020 19:21
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: Susan Hares <[e-mail]>; idr wg <[e-mail]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

Thanks for a quick reply and taking my comments into consideration.

On Tue, Nov 10, 2020 at 4:55 PM Ketan Talaulikar (ketant) <[e-mail]> wrote:
>
> Hi Dhruv,
>
> Thanks for your thorough review and feedback/comments. Please check inline below.
>
> -----Original Message-----
> From: Idr <[e-mail]> On Behalf Of Dhruv Dhody
> Sent: 10 November 2020 15:31
> To: Susan Hares <[e-mail]>
> Cc: idr wg <[e-mail]>
> Subject: Re: [Idr] IPR call and WG LC for 
> draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
>
> Hi Sue, WG,
>
> The SRv6 work for BGP-LS is important and I support its publication. I do have some comments which I hope will improve the I-D:
>
> Major
> - Regarding the various flag fields in the I-D. Should we redefine 
> them here or refer to the IGP documents? I see they match with 
> draft-ietf-lsr-isis-srv6-extensions. For the SR-MPLS draft (in
> draft-ietf-idr-bgp-ls-segment-routing-ext) the approach was to use a reference to the ISIS draft.
> [KT] The base RFC7752 has had the odd convention of providing reference to ISIS specifications for TLVs even though the information was applicable to both IGPs. The draft-ietf-idr-bgp-ls-segment-routing-ext points to the respective ISIS, OSPFv2 and OSPFv3 specs for the flags field - it does not point alone to ISIS drafts. Traditionally, there have been minor variations between the IGPs causing the flags to be different for each IGPs in BGP-LS. We've received feedback from the consumer applications of BGP-LS information to abstract and provide a consistent data across IGPs (where possible). That is the reason why the flags are being defined in the BGP-LS specifications here. If we look at RFC7752, we've had a union of flags for TLVs like Node Flags Bits TLV and IGP Flags TLV.
>

Few Observations -
- My main concern is to avoid re-definition and duplication; if you don't want to point to the flag fields as done in draft-ietf-idr-bgp-ls-segment-routing-ext, you can still point to the meaning of each of the flags where they were originally defined (unless there is any change in the context of BGP).
[KT2] The flags for SR-MPLS and SRv6 are different and likely evolve differently. We do not wish to link them up together in the encoding.

- BTW are you making a change in RFC7752bis to handle this concern? Is it right to do this only for SRv6?
[KT2] This is not about base BGP-LS spec and hence not a topic for the RFC7752bis.

<snip>

> - Section 2 provides a good summary; for ease of reader, can you add a forward reference to sections where each of the TLV is defined in this I-D?
> [KT] This will result in each line of this summary pointing to at least one or two (if not more) forward references and IMHO will affect readability. The section headings themselves are organized based on the summary and so are forward references really necessary?
>

The new RFC v3 format makes a pretty HTML rendering. Having a forwarding reference allows a reader to use the reference links to jump directly without looking at the ToC. IMHO it is useful, the readability is a concern perhaps in plain text, but even there section numbers help rather than looking for section headings.
[KT2] Sure. I will add those forward references 😊

> - Section 2, 2nd last paragraph, should this be normative regarding the different behaviour for underlying IGP and BGP-EPE?
> [KT] I am not sure that I understand. Could you please clarify exactly what normative text is required here?
>

I meant, think of using RFC2119 keywords - MUST/SHOULD etc.
[KT2] This document is just adding new information - the procedures for advertising info from IGP and BGP-EPE have been normatively defined in the base RFC7752 and BGP-EPE drafts.

> - Section 4.1, need reference for IGP Algorithm Type registry [KT] The 
> text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.
>

A reference to RFC8665 is useful, as that is the place where this registry is created.
[KT2] The algorithm was defined in RFC8402. RFC8665 only defined the registry for it. Now with Flexible Algorithms and potentially others getting added down the line, the pointer to the registry seems to make more sense to me.

> - Section 4.2, add the tag Neighbor ID in the figure as well to match 
> the text [KT] Ack
>
> - Section 6, we should say Protocol-ID is from RFC 7752, of which the following are applicable for SRV6.
> [KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE draft. So perhaps we can just refer to the IANA registry for Protocol IDs instead and remove the list from this section in the draft?
>

You can say something like -> the Protocol-ID registry was created by [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 -
[KT2] Ack - will update that and remove the references to the list.

<snip>

> - Various MUST conditions in the draft, but no idea what happens when they are not met. Is this the legacy issue with RFC7752 and we need to wait for the RFC7752bis?
> [KT] Ack - the fault management clarifications are being introduced in RFC7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs' contents.
>

Worth adding some text, I am sure directorate/AD reviews might have the same concern.
[KT2] Agree. Will add that text.

Thanks,
Ketan

Thanks!
Dhruv

> Nits
> - s/Segment Routing IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/
> - Expand SR, NLRI, MSD, DR, DIS, on first use.
> [KT] Ack - will fix this.
>
> Thanks,
> Ketan
>
> Thanks!
> Dhruv
>
> On Mon, Nov 2, 2020 at 8:55 AM Susan Hares <[e-mail]> wrote:
> >
> > This begins an IPR call and a 2 week WG LC for
> >
> > draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020)
> >
> >
> >
> > You can access the draft at:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/
> >
> >
> >
> > This draft focus on the BGP-LS support for SRv6.
> >
> > Spring has proposed the SRv6 support in RFC8402
> >
> > (see section 3.1.3 for mechanisms and section 8.2 for
> >
> > Security considerations).
> >
> >
> >
> > There are two implementations: Cisco and GoBGP
> >
> > You can see the implementation report at:
> >
> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20
> > im
> > plementations
> >
> >
> >
> > In your responses, please consider the following questions:
> >
> > a) Is the SRv6 technology ready for deployment or
> >
> > are there known issues?
> >
> >
> >
> > b) Will SRv6 provide valuable support for
> >
> > deployments of BGP-LS in support of source routing
> >
> > (aka spring)?
> >
> >
> >
> > c) Is this draft ready for publication?
> >
> >
> >
> > If you know of additional implementations, please send
> >
> > a note to the idr chairs with the information or
> >
> > respond to this email.
> >
> >
> >
> > Cheers, Susan Hares
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr