Subject: [teas-3272bis-design-team] 3272biss and YANG

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Mar 2019 15:45:19 +0800

All,

When 3272 was published, YANG modelling ws not over the horizon, is
there anything we need to say in 3272bis about YANG?

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 7 Mar 2019 16:41:30 +0800

Yang is not closely related to the TE solution. Should we pay more attention
to other emerged TE solutions for various environments?

Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Loa Andersson [mailto:[email-masked]] 
发送时间: 2019年3月7日 15:45
收件人: [email-masked]
主题: [teas-3272bis-design-team] 3272biss and YANG

All,

When 3272 was published, YANG modelling ws not over the horizon, is there
anything we need to say in 3272bis about YANG?

/Loa
-- 

--
Teas-3272bis-design-team mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas-3272bis-design-team

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Mar 2019 10:33:02 +0000

Well this is not entirely true.
There is plenty of YANG Models for traffic engineering. TE-topology, TE-tunnel, TE-mapping...just to mention some of them.
In hierarchical SDN all the traffic engineering is done with Restconf + YANG.
I agree with Loa, it would be probably good to have at least a section dedicated to YANG.
BR

Daniele  

-----Original Message-----
From: Teas-3272bis-design-team <[email-masked]> On Behalf Of Aijun Wang
Sent: den 7 mars 2019 09:42
To: 'Loa Andersson' <[email-masked]>; [email-masked]
Subject: [teas-3272bis-design-team] 答复: 3272biss and YANG

Yang is not closely related to the TE solution. Should we pay more attention to other emerged TE solutions for various environments?

Best Regards.

Aijun Wang
Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Loa Andersson [mailto:[email-masked]]
发送时间: 2019年3月7日 15:45
收件人: [email-masked]
主题: [teas-3272bis-design-team] 3272biss and YANG

All,

When 3272 was published, YANG modelling ws not over the horizon, is there anything we need to say in 3272bis about YANG?

/Loa
--

---

From: <[email-masked]>
Date: Thu, 7 Mar 2019 12:23:45 +0100

Hi Daniele,

> In hierarchical SDN all the traffic engineering is done with Restconf
+ YANG.

Not entirely true either. Ever read RFC 6805 or 7491? ;-b

Julien

> When 3272 was published, YANG modelling ws not over the horizon, is there anything we need to say in 3272bis about YANG?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 7 Mar 2019 13:35:28 +0000

That's why i said "there is plenty" and not "everyone" 😊

Jokes apart, even if it is 10% it's worth covering it IMO.

Cheers

Daniele  

-----Original Message-----
From: Teas-3272bis-design-team <[email-masked]> On Behalf Of [email-masked]
Sent: den 7 mars 2019 12:24
To: [email-masked]
Subject: Re: [teas-3272bis-design-team] 答复: 3272biss and YANG

Hi Daniele,

Julien

On 07/03/2019 11:33, Daniele Ceccarelli wrote:
> From: Teas-3272bis-design-team 
> <[email-masked]> On Behalf Of Aijun Wang

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Mar 2019 14:48:47 +0000

One benefit of the original document was to provide references. I believe this is what the BIS should do as well. So, we'd provide a brief overview of YANG TE provisioning and then point to the reference models. 

Thanks,
Acee

On 3/7/19, 8:37 AM, "Teas-3272bis-design-team on behalf of Daniele Ceccarelli" <[email-masked] on behalf of [email-masked]> wrote:

    
    Cheers
    
    Daniele  
    
    -----Original Message-----
    From: Teas-3272bis-design-team <[email-masked]> On Behalf Of [email-masked]
    Sent: den 7 mars 2019 12:24
    To: [email-masked]
    Subject: Re: [teas-3272bis-design-team] 答复: 3272biss and YANG
    
    Hi Daniele,

    
    Julien

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Mar 2019 22:54:00 +0800

Daniele,

Happy that you agree with me, though I did not really make a point  ;).
I only asked a simple question, in part based on 3272 itself.
I'm still looking for a response to the question.

My reasoning was that RFC 3272 discusses (at some length) distributed
vs. centralized control plane, what I was thinking about was whether
model driven networking bring something new to the table from a TE
perspective.

I got some responses, but nothing that helps me understand what is
going on.

/Loa

--

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 7 Mar 2019 07:09:19 -0800

+1 YANG

Cheers,
Jeff

> On Mar 7, 2019, at 6:48 AM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Mar 2019 10:17:00 -0500

Hi Loa,

Agree that the "model driven networking" does bring a new perspective to
TE. This is a new technology and methodology, which can be viewed as a
competitive alternative to PCE/PCEP in a way. As Julien mentioned, PCE/PCEP
is also new since RFC3272. Both should be covered in the BIS.

Thanks,
- Xufeng

On Thu, Mar 7, 2019 at 9:54 AM Loa Andersson <[email-masked]> wrote:

> >> There is plenty of YANG Models for traffic engineering. TE-topology,
> TE-tunnel, TE-mapping...just to mention some of them.
> >> From: Teas-3272bis-design-team <
> [email-masked]> On Behalf Of Aijun Wang
> >> Yang is not closely related to the TE solution. Should we pay more
> attention to other emerged TE solutions for various environments?
> >>
> >>
> >> Best Regards.
> >>
> >> Aijun Wang
> >> Network R&D and Operation Support Department China Telecom Corporation
> Limited Beijing Research Institute,Beijing, China.
> >>
> >> -----邮件原件-----
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 7 Mar 2019 07:34:33 -0800

Xufeng,

PCE as computational logic doesn’t change, they way the end result is represented and communicated could, so to be more precise - there are alternatives to PCEP

Cheers,
Jeff

> On Mar 7, 2019, at 7:17 AM, Xufeng Liu <[email-masked]> wrote:
> 
> Hi Loa,
> 
> Agree that the "model driven networking" does bring a new perspective to TE. This is a new technology and methodology, which can be viewed as a competitive alternative to PCE/PCEP in a way. As Julien mentioned, PCE/PCEP is also new since RFC3272. Both should be covered in the BIS.
> 
> Thanks,
> - Xufeng
> 
>> Happy that you agree with me, though I did not really make a point  ;)..

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 7 Mar 2019 10:59:50 -0500

Hi Jeff,
Agree on that.
Thanks,
- Xufeng

On Thu, Mar 7, 2019 at 10:34 AM Jeff Tantsura <[email-masked]>
wrote:

>  Xufeng,
>
> PCE as computational logic doesn’t change, they way the end result is
> represented and communicated could, so to be more precise - there are
> alternatives to PCEP
>
> Cheers,
> Jeff
>
>> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,

---

From: Loa Andersson <[email-masked]>
Date: Fri, 8 Mar 2019 00:48:40 +0800

Acee,

I did take quick look at the references of RFC3272, as you said the 
references are one of the benefits of the document.

However, looking at them today there is still some work to do, 
especially on the IETF documents, they have both been updated,
obsoleted and deprecated, some were not RFCs when 3272 were published,
but are referenced as "work in progress".

One other thing  is that they are not split in "Normative" and
"Informative" (don't know if we need to do the split), but does that
mean that we only have "Informative" references?

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Fri, 8 Mar 2019 11:09:23 +0800

Xufeng,

On 2019-03-07 23:17, Xufeng Liu wrote:
> TE. 

OK - great, now we just need to figure out what it is and what effect it
will have on 3272bis

:)

/Loa

This is a new technology and methodology, which can be viewed as a
> competitive alternative to PCE/PCEP in a way. As Julien mentioned, 
> PCE/PCEP is also new since RFC3272. Both should be covered in the BIS.
> 
> Thanks,
> - Xufeng
> 
> On Thu, Mar 7, 2019 at 9:54 AM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Daniele,
> 
>     On 2019-03-07 19:23, [email-masked]
>     <mailto:[email-masked]> wrote:
>      > Hi Daniele,
>      >
>      >> In hierarchical SDN all the traffic engineering is done with
>     Restconf
>      > + YANG.
>      >
>      >> There is plenty of YANG Models for traffic engineering.
>     TE-topology, TE-tunnel, TE-mapping...just to mention some of them.
>     <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of
>     Aijun Wang
>      >> Yang is not closely related to the TE solution. Should we pay
>     more attention to other emerged TE solutions for various environments?
>      >>
>      >>
>      >> Best Regards.
>      >>
>      >> Aijun Wang
>      >> Network R&D and Operation Support Department China Telecom
>     Corporation Limited Beijing Research Institute,Beijing, China.
>      >>
>      >> -----邮件原件-----
>      >> 发件人: Loa Andersson [mailto:[email-masked] <mailto:[email-masked]>]
>      >> 发送时间: 2019年3月7日 15:45
>      >>
>      >>
>      >> All,
>      >>
>      >> When 3272 was published, YANG modelling ws not over the horizon,
>     is there anything we need to say in 3272bis about YANG?
>      >>
>      >> /Loa
>      >>
>      >
>      >
>      >
>      > Ce message et ses pieces jointes peuvent contenir des
>     informations confidentielles ou privilegiees et ne doivent donc
>      > pas etre diffuses, exploites ou copies sans autorisation. Si vous
>     avez recu ce message par erreur, veuillez le signaler
>      > This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>      > If you have received this email in error, please notify the
>     sender and delete this message and its attachments.
>      > As emails may be altered, Orange is not liable for messages that
>     have been modified, changed or falsified.
>      > Thank you.
>      >
> 
>     -- 
> 
> 
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert
>     <mailto:[email-masked]>

--

---

From: <[email-masked]>
Date: Mon, 11 Mar 2019 08:44:54 +0000

Dear team,

maybe I can add a slightly different view to this question.

While I completely agree that Netconf and model driven technologies are very versatile and useful and the way to go, they should - in my opinion - not fill much space in 3272bis.

During the first call my impression was that we all agreed that:
1) the document should better be shorter than the original 3272, but 
2) still be comprehensive.

As I see it this doesn't do together with discussing too many technologies in details. I would prefer if we concentrated on the actual principles of traffic engineering, on a more abstract level. We do not have to elaborate on all related technology.
IMHO PCEP and Yang would best be mentioned as possible technologies of implementing certain steps of traffic engineering and get short references. But they don't need complete paragraphs each, nor should they be stated as the exclusive technology to achieve certain things.

Best regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Teas-3272bis-design-team <teas-3272bis-design-team-
> [email-masked]> Im Auftrag von Loa Andersson
> Gesendet: Donnerstag, 7. März 2019 08:45
> An: [email-masked]
> Betreff: [teas-3272bis-design-team] 3272biss and YANG
> 
> All,
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Mar 2019 11:58:32 +0000

Hi Marin, 

On 3/11/19, 4:45 AM, "Teas-3272bis-design-team on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Dear team,

I believe I agreed with you here. I think we should have the references to the applicable models but not much detail on precisely how they'd be used. 

Thanks,
Acee

    
    Best regards, Martin