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,

Once again, thanks for your thorough review and comments as also your clarifications. Based on our discussions, the draft has been updated (also including some nits and editorial changes pointed by others).

https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-05

Thanks,
Ketan

-----Original Message-----
From: Dhruv Dhody <[e-mail]> 
Sent: 11 November 2020 15:09
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,

Maybe we are not understanding each other. At this stage instead of repeating myself and going in circles I would let the document shepherd take the call for an issue that is editorial in nature.

Thanks!
Dhruv


On Wed, Nov 11, 2020 at 2:50 PM Ketan Talaulikar (ketant) <[e-mail]> wrote:
>
> Hi Dhruv,
>
> Please check inline below [KT3]
>
> -----Original Message-----
> From: Dhruv Dhody <[e-mail]>
> Sent: 11 November 2020 09:22
> 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,
>
> On Wed, Nov 11, 2020 at 8:44 AM Ketan Talaulikar (ketant) <[e-mail]> wrote:
> >
> > 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.
> >
>
> I never asked that. I was looking at
> draft-ietf-idr-bgp-ls-segment-routing-ext as an example of how the flags fields are described by pointing to the IGP documents. Further I said that if you don't want to do that, then list the flags but for the description/meaning of these flags point to the IGP documents.
>
> This is a general practice we use to make sure there is a single source of truth and avoid making mistakes in cut-copy-paste, further if there is ever an errata or changes it is in a single place rather than searching for the same text across our documents.
> [KT3] These flags are defined for BGP-LS encoding. I don't see the issue you describe.
>
> > - 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.
> >
>
> Hmm, in your reply you said there is an issue with the convention in
> RFC7752 and thus the question above. I am not asking for a change in RFC7752bis but questioning the reasoning given by you.
>
> Perhaps the guidance from the document shepherd would be the best approach to make progress.
> [KT3] I am not sure that I understand your point here. Are you asking for changing the protocol encodings during this WGLC?
>
>  <snip>
>
> > > - 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.
> >
>
> Your current text is -
>
>    When the BGP-LS router is advertising topology information that it
>    sources from the underlying link-state routing protocol, then it maps
>    the corresponding SRv6 information from the SRv6 extensions for IS-IS
>    [I-D.ietf-lsr-isis-srv6-extensions] and OSPFv3
>    [I-D.ietf-lsr-ospfv3-srv6-extensions] protocols to their BGP-LS TLVs/
>    sub-TLVs for all SRv6 capable nodes in that routing protocol domain.
>    When the BGP-LS router is advertising topology information from the
>    BGP routing protocol [I-D.ietf-idr-bgpls-segment-routing-epe], then
>    it advertises the SRv6 information from the local node alone (e.g.
>    BGP EPE topology information or in the case of a data center network
>    running BGP as the only routing protocol).
>
> In my reading, the two "when" statements look like providing conditions on when to apply the underlying procedure. If this is not new information, perhaps rephrase them to say "As specified in [REF],..."?
> [KT3] The first statement is base BGP-LS RFC7752. The second one already has the reference to the BGP-LS EPE.
>
>
> > > - 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.
> >
>
> The current text is -
>
> Algorithm values are defined in the IGP Algorithm Type registry.
>
> I find this lacking. Just mentioning the name of the registry with no reference is not right, especially when the registry is not created in this document (or in any IDR document). I find that the RFC that created the registry is the easiest reference and that would be RFC8665.
> [KT3] I disagree - it makes no sense to put a reference to OSPFv2 SR-MPLS extensions spec in here.
>
> The use of RFC8402 reference would make sense if you add some description to the meaning of the algorithm!
> [KT3] OK. Will not add that reference since it does not make sense to describe all the current algorithms in this document.
>
> Thanks,
> Ketan
>
> Thanks!
> Dhruv
>
> > > - 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-ex
> > > > t%
> > > > 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