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

From: Xufeng Liu <[email-masked]>
Date: Sun, 12 Jul 2020 21:11:42 -0400

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,
- Xufeng

On Sun, May 3, 2020 at 11:46 AM tom petch <[email-masked]> 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 <[email-masked]> on behalf of tom petch <
> [email-masked]>
> 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 <[email-masked]> on behalf of Xufeng Liu <
> [email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: tom petch <[email-masked]>
Date: Wed, 15 Jul 2020 11:14:42 +0000

From: Xufeng Liu <[email-masked]>
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

A recent YANG doctor review said that all feature should have reference which sounds right.  Perhaps RFC8476, RFC8491 along with RFC7752 for msd

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.

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.

Tom Petch

- Xufeng

On Sun, May 3, 2020 at 11:46 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
And while you are at it ..

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.

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 <[email-masked]<mailto:[email-masked]>> on behalf of tom petch <[email-masked]<mailto:[email-masked]>>
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

Tom Petch

________________________________________
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Sent: 21 April 2020 21:10

Current Status:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas