Subject: [mpls] YANG for MPLS-TP?

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jun 2016 10:22:09 +0000

Hi all,
I wonder what are the WG plans (if any) regarding YANG data models for MPLS-TP.

While it is obviously true that static MPLS and MPLS-TP are different (neither is the subset of the other), MPLS-TP is today the most important application of static MPLS.

However, after looking up  draft-ietf-mpls-static-yang<https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/?include_text=1> I did not find there any mention of MPLS-TP-specific issues.

One example that comes to mind is co-routed bi-directional and associated bi-directional MPLS-TP LSPs. Other issues include:

1.       MPLS-TP Identifiers (i.e. YANG model for RFC 6370<https://tools.ietf.org/html/rfc6370>). From my POV such a data model is a pre-requisite for all MPLS-TP-related work

2.       MPLS-TP protection mechanisms

3.       MPLS-TP OAM mechanisms. There is an individual draft<https://datatracker.ietf.org/doc/draft-zhang-mpls-tp-yang-oam/?include_text=1> that tries to address these issues, but it looks to me like very much incomplete. E.g.:

o   It does not even mention RFC 6428<https://tools.ietf.org/html/rfc6428>

o   While RFC 6427<https://tools.ietf.org/html/rfc6427> appears in the list of Normative references in this draft, there are no actual references to this document.

Any inputs in this regard would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 14 Jun 2016 13:19:55 +0200

Hello Sacha,

For MPLS-TP OAM there is draft-zhang-mpls-tp-oam.

Regards, Huub.

sent from Huawei Nexus
On 14 Jun 2016 12:22 p.m., "Alexander Vainshtein" <
[email-masked]> wrote:

> While it is obviously true that static MPLS and MPLS-TP are different
> (neither is the subset of the other), MPLS-TP is today the most important
> application of static MPLS.
>
>
>
> However, after looking up  draft-ietf-mpls-static-yang
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/?include_text=1>
> I did not find there any mention of MPLS-TP-specific issues.
>
>
>
> One example that comes to mind is co-routed bi-directional and associated
> bi-directional MPLS-TP LSPs. Other issues include:
>
> 1.       MPLS-TP Identifiers (i.e. YANG model for RFC 6370
> <https://tools.ietf.org/html/rfc6370>). From my POV such a data model is
> a pre-requisite for all MPLS-TP-related work
>
> 3.       MPLS-TP OAM mechanisms. There is an individual draft
> <https://datatracker.ietf.org/doc/draft-zhang-mpls-tp-yang-oam/?include_text=1>
> that tries to address these issues, but it looks to me like very much
> incomplete. E.g.:
>
> o   While RFC 6427 <https://tools.ietf.org/html/rfc6427> appears in the
> list of Normative references in this draft, there are no actual references
> to this document.
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 14 Jun 2016 13:28:41 +0200

Hello Sacha,

In the IETF91 proceedings there is a slideset slides-91-mpls-13.pdf which
provides details of work on MPLS and MPLS-TP yang models .

Cheers, Huub.

sent from Huawei Nexus

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jun 2016 11:29:25 +0000

Huub hi!

Lots of thanks for a prompt response.

I have mentioned draft-zhang and even provided a link to it. I have also commented that it seems very much incomplete.

But what is even more important, I do not understand how MPLS-TP OAM can be modeled without an MPLS-TP data model being defined.
E.g., if I want to apply an OAM operation (say, LSP-Ping on an MPLS-TP LSP), how can I do it if MPLS-TP LSP itself is not defined?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Huub van Helvoort [mailto:[email-masked]]
Sent: Tuesday, June 14, 2016 2:20 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; Michael Gorokhovsky <[email-masked]>
Subject: Re: [mpls] YANG for MPLS-TP?

Hello Sacha,

Regards, Huub.

sent from Huawei Nexus
On 14 Jun 2016 12:22 p.m., "Alexander Vainshtein" <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I wonder what are the WG plans (if any) regarding YANG data models for MPLS-TP.

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jun 2016 11:36:30 +0000

Huub, hi again!

I have looked up the presentation (that is 1.5 years old).
It looks good, but it seems that not too much has happened in the 1.5 years that have passed☹.
In particular, it speaks about MPLS-TP YANG as augmenting MPLS-TP base YANG – but, AFAIK, this did not happen yet.

Has there been any change in the plans?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Tuesday, June 14, 2016 2:29 PM

Hello Sacha,

In the IETF91 proceedings there is a slideset slides-91-mpls-13.pdf which provides details of work on MPLS and MPLS-TP yang models .

Cheers, Huub.

sent from Huawei Nexus

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jun 2016 13:35:22 +0000

Huub hi (again)!
I have looked up all the MPLS WG proceedings from IETF-91 to IETF-95 inclusive.

I have not found any specific work on MPLS-TP YANG.

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hello Sacha,

Cheers, Huub.

sent from Huawei Nexus

Office: +972-39266302
Cell:      +972-549266302

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 15 Jun 2016 07:29:27 +0200

Hello Sasha,

> I have not found any specific work on MPLS-TP YANG.

I did check the lists MPLS and LIME too.
I don't think you missed anything.

Based on the presentation in IETF91 You may have expected that
draft-ietf-mpls-static-yang
and
draft-ietf-mpls-base-yang
would also cover MPLS-TP, but they don't.

So it looks like separate drafts have to be written for MPLS-TP
base and static or MPLS-TP should be added to them.

Are there any other options?

Cheers, Huub.

> *From:*Huub van Helvoort [mailto:[email-masked]]
> *Sent:* Tuesday, June 14, 2016 2:29 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Michael
> Gorokhovsky <[email-masked]>
> *Subject:* Re: [mpls] YANG for MPLS-TP?
>
> Hello Sacha,
>
> In the IETF91 proceedings there is a slideset slides-91-mpls-13.pdf
> which provides details of work on MPLS and MPLS-TP yang models .
>
> Cheers, Huub.
>
> sent from Huawei Nexus
>
> On 14 Jun 2016 12:22 p.m., "Alexander Vainshtein"
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     While it is obviously true that static MPLS and MPLS-TP are
>     different (neither is the subset of the other), MPLS-TP is today the
>     most important application of static MPLS.
>
>     One example that comes to mind is co-routed bi-directional and
>     associated bi-directional MPLS-TP LSPs. Other issues include:
>
>     1.MPLS-TP Identifiers (i.e. YANG model for RFC 6370
>     <https://tools.ietf.org/html/rfc6370>). From my POV such a data
>     model is a pre-requisite for all MPLS-TP-related work
>
>     2.MPLS-TP protection mechanisms
>
>     3.MPLS-TP OAM mechanisms. There is an individual draft
>     that tries to address these issues, but it looks to me like very
>     much incomplete. E.g.:
>
>     oIt does not even mention RFC 6428 <https://tools.ietf.org/html/rfc6428>
>
>     oWhile RFC 6427 <https://tools.ietf.org/html/rfc6427> appears in the
>     list of Normative references in this draft, there are no actual
>     references to this document.
>
>     <mailto:[email-masked]>
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
================================================================
Always remember that you are unique...just like everyone else...