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

Eduardo,

On 14/04/2021 08:40, Fomin, Sergey (Nokia - US/Mountain View) wrote:
> 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.

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

> 
> --
> Sergey
> 
> -----Original Message-----
> From: mpls <mpls-bounces@ietf.org> On Behalf Of Vasilenko Eduard
> Sent: Tuesday, April 13, 2021 2:01 AM
> To: mpls@ietf.org
> 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!
> 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:spring-bounces@ietf.org] On Behalf Of Loa
>> Andersson
>> Sent: Sunday, April 4, 2021 9:51 AM
>> To: mpls-ads@ietf.org; pals@ietf.org; DetNet WG <detnet@ietf.org>;
>> spring@ietf.org
>> Subject: [spring] Invitation to participate in an Open MPLS wg desifn
>> team on how to carry additional forwarding data in MPLS packets
>>
>> 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: loa@pi.nu
>> Senior MPLS Expert                          loa.pi.nu@gmail.com
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64