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,

On your comment below:

- Section 10/11, is some text missing here? Section 10 says it is structured as per RFC5706 and has nothing. Section 11 has Operational Considerations saying nothing new here! Missing  Management Considerations as per RFC 5706.

I meant to say that Management Considerations section needs to be updated/fixed and the Operational Consideration section is not required since it inherits from the base BGP-LS spec.

I will post the update once the submission window re-opens.

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: 10 November 2020 16:55
To: Dhruv Dhody <[e-mail]>; 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 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.

Minor
- Section 2, use of normative SHALL for the restatting the text coming from RFC 7752 is incorrect.
[KT] Ack - will fix.

- Section 2, add reference for "MSD types introduced for SRv6" in this section (on first use).
[KT] Ack - will expand MSD.

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

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

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

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

- Section 10/11, is some text missing here? Section 10 says it is structured as per RFC5706 and has nothing. Section 11 has Operational Considerations saying nothing new here! Missing  Management Considerations as per RFC 5706.
[KT] Ack - Section 10 and 11 should be removed since these aspects are derived from the base RFC7752. 

- For reserved fields we use a mix of MUST and SHOULD regarding setting it to zero, better to use MUST in all instances.
[KT] Ack - will fix this.

Query
- What is the best practice for the term End.X: Expand to Layer-3 Cross-Connect on first use or put a reference to draft-ietf-spring-srv6-network-programming? Or is it considered well-known in the context to be used directly.
[KT] While it is well-known in the context, I think you are right that a reference to draft-ietf-spring-srv6-network-programming would be good to have. 

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

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%20im
> 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