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

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 <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> on behalf of tom petch <
> 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> on behalf of Xufeng Liu <
> 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
> https://www.ietf.org/mailman/listinfo/teas
>