Re: [Teas] Status update on draft-ietf-teas-yang-sr-te-topo

Hi Tom,

Thanks for your further comments. We are trying to address them with an
updated draft
https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-08. Some of the
answers and discussions are in-line below.

Regards,
- Xufeng

On Wed, Jul 15, 2020 at 7:14 AM tom petch <ietfa@btconnect.com> wrote:

> From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
> Sent: 13 July 2020 02:11
>
> Hi Tom,
>
> Thank you much for the much-needed review. We have posted the updated
> revision
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-sr-te-topo-07,
> trying to address these comments. Please also see the replies in-line below.
> Best regards,
>
> <tp>
> Yes, clearer.
>
> IANA needs updating with the amended prefix
>
[Xufeng]: Fixed (Thanks for noticing)

>
> A recent YANG doctor review said that all feature should have reference
> which sounds right.  Perhaps RFC8476, RFC8491 along with RFC7752 for msd
>
[Xufeng]: Added the references.

>
> Diagrams are useful but ..
> these seem the opposite to e.g.  yang-l3-te-topo
> Does A---> B mean A augments B or B augments A?  Would be nice to be
> consistent.  Perhaps one for the YANG Doctors list.
>
[Xufeng]: Thanks for bringing it up in the netmod WG. I agree with your
instinct, but the arrow direction used in this diagram originally came from
RFC8345, so I’m not sure how we can fix the consistency here.

>
> Another common practice in most TEAS Yang I-D is to have a table in the
> text of prefix used and the corresponding module and reference.
>
[Xufeng]: Added such a section.

>
> Tom Petch
>
> - Xufeng
>
> On Sun, May 3, 2020 at 11:46 AM tom petch <ietfa@btconnect.com<mailto:
> ietfa@btconnect.com>> wrote:
> And while you are at it ..
>
> I don't understand quite a lot of this I-D.
>
> In places it is explicit - MPLS data plane only.  Elsewhere it seems to
> claim to be for all SR as with the choice of prefix srt module name or with
> container SR or with the Abstract.  If this is MPLS data plane only. then I
> think that that needs spelling out in more places starting with the Abstract
> [Xufeng]: As suggested, used MPLS throughout the document and the model,
> including module name, prefixes, and container names.
>
> 2.1 references unicast-igp-topology - I know of no such module
> [Xufeng]: Fixed the typo.
>
> 2.7 Both IGP and BGP are supported ...is this BGP or BGP-LS?
> [Xufeng]: Right. This is BGP-LS. Fixed the term and added some references.
>
> feature msd
> what if one IGP supports msd and another does not, say OSPFv2 does and
> OSPFv3 does not?  I don't know if that will happen or if it should be
> supported but, for once, YANG does have good support for such an approach
> [Xufeng] msd is a device feature, independent of the protocols. In case
> that one particular protocol does not support msd, the corresponding leaf
> msd in the operational datastore will not have a value. Since the user
> knows which protocol provides the information based on the
> information-source, he will understand the reason for it.
>
> grouping sr topology type
> a presence container for SR-MPLS - good
> But how about
> sr node prefix attributes
> a presence container which indicates SR is enabled and
> [Xufeng]: Since a prefix may or may not be configured with a Prefix-SID,
> the "presence" statement will allow such an option.
> sr link attributes
> a presence container which indicates SR is enabled.
> [Xufeng]:  Since an L3 link may or may not be configured with an Adj-SID,
> the "presence" statement will allow such an option.
> That is eight possible combinations of presence containers with eight
> different interpretations - I do not understand what they mean.  I do
> realise that the groupings have different roles.
> [Xufeng]: Two "presence" side effects relevant here are: (1) to assign a
> semantic meaning (non-presence container can be ignored); (2) to stop
> propagating the "mandatory" requirement to the parent container.
>
>
> RFC 7752 is the reference for BGP-LS but
> needs to be in the I-D references.
> [Xufeng]: Added.
> And how about references for OSPFv2 etc?
> [Xufeng]: Also added.
> Currently BGP-LS may be new and different and people want to know where to
> find it but in a year or two they may be wondering what OSPFv2 is or was.
>
> Since you import sr-routing-cmn I cannot see how that can fail to be a
> Normative Reference - I cannot understand the I-D without it!
> [Xufeng]: Fixed.
>
> Tom Petch
> ________________________________________
> From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on
> behalf of tom petch <ietfa@btconnect.com<mailto:ietfa@btconnect.com>>
> Sent: 02 May 2020 12:16
> To: Xufeng Liu; TEAS WG
> Subject: Re: [Teas] Status update on draft-ietf-teas-yang-sr-te-topo
>
> Xufeng
>
> I suggest you respin this I-D lest it expires in four days time.
>
> Tom Petch
>
> ________________________________________
> From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on
> behalf of Xufeng Liu <xufeng.liu.ietf@gmail.com<mailto:
> xufeng.liu.ietf@gmail.com>>
> Sent: 21 April 2020 21:10
>
> Current Status:
>
>   *  No update since IETF106 with last post on November 3, 2019.
>   *  Answered YANG doctor's review comments.
>
> Open Issues:
>
>   *   None.
>
> Next Steps:
>
>   *  Update the model to sync with the referenced models like
> draft-ietf-spring-sr-yang if there are any changes.
>   *  Welcome further reviews and suggestions.
>   *  Working Group Last Call after completing the above.
>
> Thanks,
> - Xufeng
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org<mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas
>