Re: [teas-3272bis-design-team] OMG he's done some work

Hi Adrian,

Thanks for the updates and the draft, which look good to me.

I intended to push some proposal to Github, but was also let down by
Markdown. The followings were what I'd like to propose. You may check if
they are appropriate.

Sec 6.

Add:

6.8. Network TE State Definition and Presentation

The network states that are relevant to the traffic engineering need to be
stored in the system and presented to the user. The Traffic
Engineering Database (TED) is a collection of all TE information
about all TE nodes and TE links in the network, which is
an essential component of a TE system, such as MPLS-TE [RFC2702]
and GMPLS [RFC3945]. In order to formally define the data in TED and
present the data to the user with high usability, the data modeling
language YANG [RFC7950] can be used [draft-ietf-teas-yang-te-topo].

6.9. System Management and Control Interfaces

The traffic engineering control system needs to have a management
interface that is human-friendly and a control interfaces that is
programable for automation. Network Configuration Protocol (NETCONF)
[RFC6241] or RESTCONF Protocol [RFC8040] provide programmable
interfaces that are also human-friendly. These protocols use XML Or
JSON encoded messages. When message compactness or protocol bandwidth
consumption needs to be optimized for the control interface, other
protocols, such as Group Communication for the Constrained Application
Protocol (CoAP) [RFC7390] or gRPC, are available, especially when the
protocol messages are encoded in the binary format. Along with any of
these protocols, the data modeling language YANG [RFC7950] can be used
to formally and precisely define the interface data.

Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440]
is another protocol that has evolved to be an option for the TE system
control interface. The messages of PCEP are TLV-based, not defined by
a data modeling language such as YANG.

Thanks,
- Xufeng

On Wed, Oct 30, 2019 at 10:35 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello people who like to call themselves "team".
>
> I finally did some work.
>
> I believe I have successfully bullied GI-thub into letting me see the
> "best"
> version of the work in progress.
>
> I took this and massaged it because the mkd-to-XML tool is imperfect. This
> gave me some clean XML which I have run through xml2rfc, idspell, and
> idnits.
>
> That gives the attached.
>
> It's a starting point.
>
> I propose...
>
> 1. I post this on or before Friday (before if >2 of you say go-ahead
> sooner)
> 2. I see whether there is any low-hanging fruit for further changes
> 3. I receive any further suggestions for changes from you (direct email,
> please)
> 4. I post a new revision before the cut-off on the 4th
> 5. I ask the chairs for a slot on the agenda in Singapore
>      Report will be that we plan more work, but happy for anyone to help
> 6. We all continue to make updates, but...
>     I don't think that either mkd or github has been working for this team
>     From here on, we should just work old school: send me changes and I
> will
> edit
> 7. We meet in Singapore to see whether we can agree to make progress
>      Doodle poll to follow
>
> OK?
> Adrian
> --
> Teas-3272bis-design-team mailing list
> Teas-3272bis-design-team@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-3272bis-design-team
>