Subject: Re: [mpls] [Detnet] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

From: Loa Andersson <[email-masked]>
Date: Mon, 5 Apr 2021 05:22:40 +0800

Working Group,

I said four working groups, but this went to the mpls-ads, rather than 
the mpls working group (blush).

/Loa

On 04/04/2021 14:50, Loa Andersson wrote:
> MPLS, PALS, DETNET and SPRING working groups,
> 
> Note: This message is sent to four working groups, please limit 
> responses to the mpls wg mailing list only.
> 
> All members of the four working group are invited to participate in an 
> open MPLS wg design team to address the work that was discussed in the 
> joint meeting at IETF 110
> 
> Below follows "notes" from a meeting between chairs of the four working 
> groups 2021-03-22. It outlines how we initially will take on the work.
> 
> -------------------  meeting notes   -----------------------
> 
> 
> Continue the work the joint meeting at IETF 110.
> ================================================
> 
> Working Group Chairs from MPLS, PALS, SPRING and DETNET met
> 2021-03-22 to discuss how to follow up the joint meeting
> at IETF 110.
> 
> Participation:
> --------------
> 
>   Loa Andersson (mpls)
>   Tarek Saad (mpls)
>   Stewart Bryant (pals)
>   Andy Malis (pals)
>   Joel Halpern (spring)
>   Lou Berger (detnet)
> 
> We discussed three themes
> -------------------------
> 
> - what to do next
> - how to document the output from the joint meeting
> - how to organize the work that starts here
> 
> We agreed
> =========
> 
> - that the work starting here is part of the MPLS architecture  and in
>   the end might lead to updates - that this is work that should be
>   coordinated by the mpls working group and that discussion working
>   group adoption and the discussion should be taken to the MPLS WG
>   mailing list.
> 
> We agreed with the summary from the joint meeting
> -------------------------------------------------
> 
> - that tt is important that MPLS grows and develops to support the new
>   needs of network operators. The alternative to such development is
>   stagnation and a path to obsolescence.
> 
> - that is important that any change does not adversely impact the
>   operation of legacy equipment installed in the same network as the n
>   new functionality.
> 
> - it is important that any change is both forwards and backwards
>   compatible. i.e. that any change does not limit the ability for
>   further future development of MPLS.
> 
> - it is important that any change be practical on the forwarding
>   technology likely to be deployable in the reasonably near future.
> 
> - it is important that we minimize the number of changes needed to
>   support the new needs but making that change an elegant approach
>   that satisfies as many of the new needs as possible.
> 
> - there is sufficient interest and urgency in the need for new features
>   that we need to work on this between meetings to progress at an
>   acceptable rate.
> 
> We also agreed on some practical things
> ---------------------------------------
> 
> - the list (possibly incomplete) of proposals in Stewart's slides
>   has been updated to a short draft to serve as input to this work
>   (draft-bryant-mpls-dev-primer-00.txt).
> 
> - the work will be divided into two "tracks" (1) proposals carrying
>   information after the BoS and; (2) proposals carrying info in the
>   stack.
> 
> - we will hold open design-team meetings, i.e. any member of the four
>   working groups are encouraged to participate
> 
> - the meeting cycle is 5 weeks:
> 
>   -- "week 1" we will have a joint meeting to coordinate between the
>      two tracks
>   -- "week 2" and "week 4" we will have a track 1 meeting
>   -- "week 3" and "week 5" we will have a track 2 meeting
>   -- "week 6" = "week 1"; and we start the count over again
> 
> We will start  with joint (kick off) meeting April 8. The agenda will be 
> prepared during the week of April 5, let us know if there is anything 
> you want to discuss. We already now know that we will want to discuss 
> Stewart's primer.
> 
> Mach will send out WebEx details to all four working groups.
> 
> - the over all coordination of this activity will done by Loa, if
>   you need a slot in any meting or need to put a discussion point
>   on the agenda ping Loa.
> 
> - the meetings will be every Thursday at 3pm Central European Time.
> 
> /Loa
> for(all) the wg-chairs
> 
> 

-- 

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 13 Apr 2021 09:00:59 +0000

Hi MPLS Guru!
Sorry. I did not have a chance to participate in your call.
I do agree to all policies specified below. Could I propose 1 additional?

MPLS had a separate data plane header for services/overlay and separate for transport/underlay since the beginning. "Transport" in IETF has 2 meanings - I am referencing here to forwarding.
TEAS continues to specify VPN+ in the same way: VPN and VTN are separate.
We have seen examples when transport or service headers have been stacked independently, primarily it was the stack of many transport labels with 1 service label, but the opposite is possible too.
I propose the policy:
- It is important to preserve the clear separation of data plane headers for services/overlay and transport/underlay for independent innovation and management by different control plane protocols

IMHO: It is an important and valuable differentiator.

Eduard
> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Loa 
> Andersson
> Sent: Sunday, April 4, 2021 9:51 AM
> To: [email-masked]; [email-masked]; DetNet WG <[email-masked]>; 
> [email-masked]
> Subject: [spring] Invitation to participate in an Open MPLS wg desifn 
> team on how to carry additional forwarding data in MPLS packets
> 
> Below follows "notes" from a meeting between chairs of the four 
> working groups 2021-03-22. It outlines how we initially will take on the work.
> 
> 2021-03-22 to discuss how to follow up the joint meeting at IETF 110.
> 
> Participation:
> --------------
> 
>    Loa Andersson (mpls)
>    Tarek Saad (mpls)
>    Stewart Bryant (pals)
>    Andy Malis (pals)
>    Joel Halpern (spring)
>    Lou Berger (detnet)
> 
> We will start  with joint (kick off) meeting April 8. The agenda will 
> be prepared during the week of April 5, let us know if there is anything you want to discuss.
> We already now know that we will want to discuss Stewart's primer.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 14 Apr 2021 00:40:23 +0000

Hi Eduard,
> MPLS had a separate data plane header for services/overlay and separate for transport/underlay since the beginning.
> - It is important to preserve the clear separation of data plane headers for services/overlay and transport/underlay

Could you elaborate a little bit on that?
In my opinion, almost the opposite is (currently) true - there's no distinction between "service/overlay" and "transport/underlay" headers, and there's no intrinsic semantics of mpls labels (except for special-purpose labels).
MPLS labels have meaning only because of the existence of FEC/NHLFE/ILM mappings.

--
Sergey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Tuesday, April 13, 2021 2:01 AM
To: [email-masked]
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

Hi MPLS Guru!

Eduard

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 14 Apr 2021 12:39:51 +0800

Eduardo,

> MPLS labels have meaning only because of the existence of FEC/NHLFE/ILM mappings.

I'm on the same page Sergey. Would be good to have a bit more meat on 
the bones to understand what you want to do/preserve.

If you pick a label (value, TTL, TC and BoS) I can't see that there is a 
way to tell if it is a transport or service label.

And I don't think that any of the proposals we are currently discussing 
in the DT scope intend to chnge that.

/Loa

--

---

From: Andrey Slastenov <[email-masked]>
Date: Wed, 14 Apr 2021 08:34:21 +0300

Hi, Loa

>way to tell if it is a transport or service label.
As soon as we have a continuous set of labels it's easy to split them into
the transport and service part.
A more interesting question is what we get from this separation, given that
the boundaries between the transport and service layers are often blurred.
(e.g. service labels from one LSR can be used as transport labels by
another LSR).

I look forward to the comments from Eduard.

Best Regards,
Andrey Slastenov

ср, 14 апр. 2021 г. в 07:40, Loa Andersson <[email-masked]>:

> >> MPLS had a separate data plane header for services/overlay and separate
> for transport/underlay since the beginning.
> >> - It is important to preserve the clear separation of data plane
> headers for services/overlay and transport/underlay
> >
> > In my opinion, almost the opposite is (currently) true - there's no
> distinction between "service/overlay" and "transport/underlay" headers, and
> there's no intrinsic semantics of mpls labels (except for special-purpose
> labels).
> > Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS
> wg desifn team on how to carry additional forwarding data in MPLS packets
> >
> > Hi MPLS Guru!
> > MPLS had a separate data plane header for services/overlay and separate
> for transport/underlay since the beginning. "Transport" in IETF has 2
> meanings - I am referencing here to forwarding.
> > We have seen examples when transport or service headers have been
> stacked independently, primarily it was the stack of many transport labels
> with 1 service label, but the opposite is possible too.
> > I propose the policy:
> > - It is important to preserve the clear separation of data plane headers
> for services/overlay and transport/underlay for independent innovation and
> management by different control plane protocols
> >

-- 

*Andrey Slastenov*
Network Expert
CCIE #19983
Email:[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Wed, 14 Apr 2021 13:42:02 +0800

Andrey,

Inline please.

On 14/04/2021 13:34, Andrey Slastenov wrote:
> As soon as we have a continuous set of labels it's easy to split them 
> into the transport and service part.

Yes, this is easy to do and from an operational point of view there is 
no reason why you should not do it.

However, this is not standardized. Nor do I see any reason or good way 
to do it.

> A more interesting question is what we get from this separation, given 
> that the boundaries between the transport and service layers are often 
> blurred.

Are you talking about label values?

/Loa
> ср, 14 апр. 2021 г. в 07:40, Loa Andersson <[email-masked] <mailto:[email-masked]>>:
> 
>     Eduardo,
> 
> 
>      >> MPLS had a separate data plane header for services/overlay and
>     separate for transport/underlay since the beginning.
>      > In my opinion, almost the opposite is (currently) true - there's
>     no distinction between "service/overlay" and "transport/underlay"
>     headers, and there's no intrinsic semantics of mpls labels (except
>     for special-purpose labels).
>      > From: mpls <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of Vasilenko Eduard
>      > To: [email-masked] <mailto:[email-masked]>
>      > Subject: Re: [mpls] [spring] Invitation to participate in an Open
>     MPLS wg desifn team on how to carry additional forwarding data in
>     MPLS packets
>      >
>      > Hi MPLS Guru!
>      > MPLS had a separate data plane header for services/overlay and
>     separate for transport/underlay since the beginning. "Transport" in
>     IETF has 2 meanings - I am referencing here to forwarding.
>     stacked independently, primarily it was the stack of many transport
>     labels with 1 service label, but the opposite is possible too.
>      > I propose the policy:
>     headers for services/overlay and transport/underlay for independent
>     innovation and management by different control plane protocols
>      >
>      >> From: spring [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Loa
>      >> Andersson
>      >> To: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; DetNet WG <[email-masked]
>     <mailto:[email-masked]>>;
>      >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>      >> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>      >> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring>
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>      >
> 
>     -- 
> 
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 
> 
> 
> -- 
> *
> *
> *
> *
> *
> Andrey Slastenov*
> Network Expert
> CCIE #19983
> Email:[email-masked] <mailto:[email-masked]>

--

---

From: Andrey Slastenov <[email-masked]>
Date: Wed, 14 Apr 2021 09:18:59 +0300

Hi, Loa

> However, this is not standardized. Nor do I see any reason or good way
Agree with you, technically, one way to do it, just to use one of the
reserved labels from RFC7274 between the transport and service part in the
labels stack.
But it will require a huge change in label allocation and switching
processes.

> Are you talking about label values?
I am talking about some special scenarios like CsC, when it is very tricky
to distinguish between transport and service layers.

But the more interesting question for me what advantages we get by
implementing such a separation. The first thing that comes to mind is label
processing in a batch, something else?
That's why I am waiting for comments from Eduard.

ср, 14 апр. 2021 г. в 08:42, Loa Andersson <[email-masked]>:

> > ср, 14 апр. 2021 г. в 07:40, Loa Andersson <[email-masked] <mailto:[email-masked]
> >>:
> >
> >     Eduardo,
> >
> >

-- 

*Andrey Slastenov*
Network Expert
CCIE #19983

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 14 Apr 2021 10:20:49 +0000

Hi all,
I am very surprised that you did ask for clarification.
It probably means that you think only about “transport” label innovation.
It would be not good because the “service” label needs innovation as much as “transport”, probably even more.
Moreover, reading your agenda, - I have concluded that you have the intention to add some “metadata” for service chaining. And maybe even to help with MTU discovery or fragmentation.
Probably, I am wrong in my assumptions. I’ve needed to pay more attention that BESS is the separate WG.

Ask any non-guru network professional “MPLS label is what for”. I have hired many engineers – I did this exercise many times.
He would answer you:

-          In the simple scenario MPLS has 2 labels: “service” and “transport”. One is inserted by ISIS/OSPF to find the remote PE loopback, another one is installed by mBGP to point to VRF or Next-hop (implementation-specific) on this PE

-          If any protection or TE is present then could be more “transport” labels because it would create additional tunnels (inside tunnels)

-          If Seamless MPLS is implemented to cross domains then could be additional “transport” label in the middle that is populated by BGP LU

I am not happy that one “not to be named protocol at the hype of Gartner cycle”
Defines one header structure for transport, service, and arguments (parameters for service) in such a way that the boundary between all these components is dynamic and calculated by some rather complex algorithms.
It would splice headers into one structure that would be damn difficult to manage by different protocols (BGP, ISIS, OSPF, PCEP, BGP Policy, whatever). It would need tight coordination between these protocols. Innovation and implementation would be very much blocked.
IMHO: Strategically, it is the dead end for this “not to be named” protocol. Let us see how my prediction would stand in 5 years.
I do not want that our primary transport and network virtualization technology (MPLS) would share the same fate.

But if your scope is not related to MPLS innovation for “service” labels (because it is the different WG or probably WGs) then my request is not relevant. You would not splice it anyway.
Sorry for the interruption. My fault.
Eduard
From: Andrey Slastenov [mailto:[email-masked]]
Sent: Wednesday, April 14, 2021 9:19 AM
To: Loa Andersson <[email-masked]>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]>; Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

Hi, Loa

> However, this is not standardized. Nor do I see any reason or good way
Agree with you, technically, one way to do it, just to use one of the reserved labels from RFC7274 between the transport and service part in the labels stack.
But it will require a huge change in label allocation and switching processes.

> Are you talking about label values?
I am talking about some special scenarios like CsC, when it is very tricky to distinguish between transport and service layers.

But the more interesting question for me what advantages we get by implementing such a separation. The first thing that comes to mind is label processing in a batch, something else?
That's why I am waiting for comments from Eduard.

ср, 14 апр. 2021 г. в 08:42, Loa Andersson <[email-masked]<mailto:[email-masked]>>:
Andrey,

Inline please.

/Loa
> ср, 14 апр. 2021 г. в 07:40, Loa Andersson <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>:
>
>     Eduardo,
>
>
>      > From: mpls <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      > To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> From: spring [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Loa
>      >> Andersson
>      >> To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>;
>      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      >> Senior MPLS Expert [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     Loa Andersson                        email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     Senior MPLS Expert [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> Email:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

--

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

--
[https://docs.google.com/uc?export=download&id=1O2U467AB_tlPYsmGbkQkBpGubHDdxrqy&revid=0By38JsxZNbGZaWlNT2EzQ2VtNlYwWENuV1F2YUVqT0hQOVhZPQ] [https://docs.google.com/uc?export=download&id=1nb9lEKSN49UkjURwC8KDJYrmx4Oztq20&revid=0By38JsxZNbGZK3RyZGY5RW84YUxkRERzMjcreW81QmZ4V1pRPQ] [https://docs.google.com/uc?export=download&id=1gmVy5kCG5wSyQNkdb6opjnkSFHSW-_PV&revid=0By38JsxZNbGZY0tTcm5FVmpiZUUvcU9PTGlSMUgrNkIzQWtnPQ] [https://docs.google.com/uc?export=download&id=1MbqJCX9zkdPmRH2BEYmXFkBoG-HNL7wh&revid=0By38JsxZNbGZK1lHRE1JK1RWTnordks1SnVTRTB4MzVKZVRJPQ] [https://docs.google.com/uc?export=download&id=1QmOEVuFrF_Iv6onQub1v4V6DmgXe1Qnp&revid=0By38JsxZNbGZeXAxUFI4dWFvVnF3MUlndGhBWFl2Sk8vVWh3PQ]

Andrey Slastenov
Network Expert
CCIE #19983
Email:[email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Apr 2021 12:34:24 +0100

I have always had a very simple model for MPLS that has worked well, at least for me:

An MPLS label is a vector to a block of code and some parameters specific to that label.

Unless you are the intended recipient of the label you cannot understand it and have no right to make any assumptions about its meaning.

Thus I do not really see any distinction between transport and application or any other sort of labels other than SPLs. Label are just vectors to code.

- Stewart

> On 14 Apr 2021, at 11:20, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi all,
> ср, 14 апр. 2021 г. в 08:42, Loa Andersson <[email-masked] <mailto:[email-masked]>>:
> Andrey,
> 
> Inline please.
> 
> > ср, 14 апр. 2021 г. в 07:40, Loa Andersson <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>:
> > 
> >     Eduardo,
> > 
> > 
> >      > From: mpls <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >      > To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >      >> From: spring [mailto:[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>] On Behalf Of Loa
> >      >> Andersson
> >      >> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>; DetNet WG <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>;
> >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >      >> Senior MPLS Expert [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >      >> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
> >     <https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>>
> >      >
> >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >      > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> >     <https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>>
> >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >      > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> >     <https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>>
> >      >
> > 
> >     -- 
> > 
> >     Loa Andersson                        email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >     Senior MPLS Expert [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >     https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> >     <https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>>
> > 
> > 
> > 
> > -- 
> > *
> > *
> > *
> > *
> > *
> > Andrey Slastenov*
> > Network Expert
> > CCIE #19983
> > Email:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> 
> -- 
> 
> Email:[email-masked] <mailto:[email-masked]>_______________________________________________
> mpls mailing list
> [email-masked]

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 14 Apr 2021 11:43:18 +0000

It fine.
It is the more innovative terminology (probably the better one). I am using the older terminology (more common yet in the field).
Just keep this “block of code” separate for population by BGP and ISIS. To permit it to be developed independently.
Ed/
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, April 14, 2021 2:34 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Andrey Slastenov <[email-masked]>; loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

- Stewart

On 14 Apr 2021, at 11:20, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

But if your scope is not related to MPLS innovation for “service” labels (because it is the different WG or probably WGs) then my request is not relevant. You would not splice it anyway.
Sorry for the interruption. My fault.
Eduard
From: Andrey Slastenov [mailto:[email-masked]]
Sent: Wednesday, April 14, 2021 9:19 AM
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

Hi, Loa

Inline please.

/Loa

--

Andrey Slastenov
Network Expert
CCIE #19983
Email:[email-masked]<mailto:[email-masked]>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Apr 2021 13:22:29 +0100

Absolutely every label should be installed as a result of the actions of its own “layer” and and there should be not constraints by, or second guessing of, any other “layer”.

Stewart

> On 14 Apr 2021, at 12:43, Vasilenko Eduard <[email-masked]> wrote:
> 
> It fine.
> On 14 Apr 2021, at 11:20, Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi all,
> From: Andrey Slastenov [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Loa Andersson <[email-masked] <mailto:[email-masked]>>
> Cc: Fomin, Sergey (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]>>; Vasilenko Eduard <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 14 Apr 2021 15:16:58 +0000

Good.
Then I would continue to deep dive into the problem.
I am not happy about the latest fashion to call everything “programmable”. One universal name for everything does negate any functional meaning.
Old good times we had the explanation for the functional purpose of the particular label in the name: transport, service, entropy, inter-domain transport, FRR, etc.
It is not good that we have lost it and people even do not understand what I am talking about.
Because we still need to decide on the minimal number of separate “blocks of code” that should be kept separate in the future.
Moreover, these blocks should have different internal structures to better serve their purpose.
For example, let’s say that BGP should manage “service” and “inter-domain transport”. It is already 2 blocks that should be kept separate.
What is next? Let’s say “intra-domain transport”. Who is assumed should manage it? ISIS, OSPF, PCEP, BGP Policy. Who else?
It would be not easy to create the mapping table between independent labels (or blocks if you like this terminology) and all current protocols that are trying to populate all these labels.
We have the history of how it did happen subconsciously. Just every expert does understand what particular protocol could touch a particular label stack.
IMHO: It is time to specify this mapping now. Because Design Team should look into the future and consciously preserve this “layers separation”.
Well, I do not like “layers” terminology because it is not always layers – it is more “functions”.
I am not sure that I am capable to map properly. But I am sure that many people in this alias are capable to do it.
If all labels would get back functional names – I would be happy. Of course, I do agree that all should be “programmable” at the same time.
But it would be too much marketing if we would call “intra-domain transport” data plane header by “programmable intra-domain transport”.

I see here some analogy with the list of IPv6 EHs (extension headers). Different names, different functions, different structures.
I do not see any other way to considerably expand MPLS functionality in a controllable way.

If you would separate labels/blocks by “functions” then would be a big positive debate what is the optimal structure for every function.
Interesting times…
Eduard
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, April 14, 2021 3:22 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Andrey Slastenov <[email-masked]>; loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

Stewart

On 14 Apr 2021, at 12:43, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

It fine.
It is the more innovative terminology (probably the better one). I am using the older terminology (more common yet in the field).
Just keep this “block of code” separate for population by BGP and ISIS. To permit it to be developed independently.
Ed/
From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, April 14, 2021 2:34 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Andrey Slastenov <[email-masked]<mailto:[email-masked]>>; loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [spring] Invitation to participate in an Open MPLS wg desifn team on how to carry additional forwarding data in MPLS packets

- Stewart

Hi all,

Hi, Loa

Inline please.

/Loa

--

Andrey Slastenov
Network Expert
CCIE #19983