Subject: [mpls] Consensus poll on Design directive for the MPLS Open DT

From: Loa Andersson <[email-masked]>
Date: Tue, 24 Aug 2021 10:35:41 +0200

Working Group, Design Tean,

The Open DT has discussed the relationship between GAL/G-ACh and the new 
methods for indicating and transporting ancillary data in and after the 
label stack.

We have decided to give the MPLS Open DT the following design directive:

---------------------------- start ---------------------------------

Following the discussion in the MPLS Open DT 2021-08-19 we have have 
decided to give the MPLS Indicator and Open Design team this design 
directive.

RFC 5586 "MPLS Generic Associated Channel" (including the updates by RFC 
7274, RFC 6423, RFC 7214, and RFC 7026) will not be changed by the MPLS 
Open Design Team. The associated channel (GAL/G-ACh) will continue to 
operate as specified. No changes should be made to the associated 
channel, without careful coordination with what will be specified by the 
MPLS Pen design team.

The Open design team will continue define methods bases on indicators 
(e.g. FAI-style SPL) and ancillary data.

A packet can not carry both the associated channel and the new methods 
for transporting ancillary data indicated by the FAI-style SPL, i.e. the 
GAL and the FAI-style SPL can not both be present in a label stack. The 
reason is that the way the ACH is specified there is a high risk of 
collision of "data after the BoS" specified by other methods.

---------------------end --------------------------------------------

The design team will start working according to this design directive, 
but for a period of two weeks we will comments on the directive.

Please send comments to the MPLS wg mailing list ([email-masked]).

/Loa

for the co-chairs
-- 

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

---

From: Haoyu Song <[email-masked]>
Date: Tue, 24 Aug 2021 18:35:57 +0000

Hi WGs and design team,

This was indeed my original position on this issue. However, I remember in one meeting Stewart gave an counter argument against this which I think also makes sense: what if for a packet with GAL/G-Ach,  the forwarding decision is determined by the ancillary data? If they cannot coexist, we may rule out useful use cases.

I understand that one concern is the location conflict of G-ACH and ancillary data especially when G-ACH size may not be easy to decide. If this is the case, can we simply make that G-ACH, if exist, must be located after all ancillary data? After all, we can know the size of ancillary data easily. 

I just raise this point for further discussion. It's fine for me to go either direction.

Best,
Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Tuesday, August 24, 2021 1:36 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Consensus poll on Design directive for the MPLS Open DT

The Open DT has discussed the relationship between GAL/G-ACh and the new methods for indicating and transporting ancillary data in and after the label stack.

---------------------------- start ---------------------------------

Following the discussion in the MPLS Open DT 2021-08-19 we have have decided to give the MPLS Indicator and Open Design team this design directive.

RFC 5586 "MPLS Generic Associated Channel" (including the updates by RFC 7274, RFC 6423, RFC 7214, and RFC 7026) will not be changed by the MPLS Open Design Team. The associated channel (GAL/G-ACh) will continue to operate as specified. No changes should be made to the associated channel, without careful coordination with what will be specified by the MPLS Pen design team.

The Open design team will continue define methods bases on indicators (e.g. FAI-style SPL) and ancillary data.

A packet can not carry both the associated channel and the new methods for transporting ancillary data indicated by the FAI-style SPL, i.e. the GAL and the FAI-style SPL can not both be present in a label stack. The reason is that the way the ACH is specified there is a high risk of collision of "data after the BoS" specified by other methods.

---------------------end --------------------------------------------

The design team will start working according to this design directive, but for a period of two weeks we will comments on the directive.

/Loa

for the co-chairs
-- 

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C8d880f52f56d4375931508d966da3cbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637653909777749156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=AzpuKWTF1eQzHN%2Bu4HhdKX6C%2FGUt0KrZWdd1kL%2BCfbM%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Wed, 25 Aug 2021 03:51:05 +0800 (CST)

Dear Loa, WGs Chairs, et al.,

I've got a couple of questions and much appreciate it if you can help me with clarifications:

Would it be correct to assume that ancillary data apply to MPLS PW?

If the ancillary data apply to MPLS PW, how does it coexists when PW VCCV is used? The case I am considering - using PW ACH (RFC 4385), i.e., PW Control Channel Type 1. The PW ACH includes the Channel Type field that, like G-ACh, defines the format of data that immediately follows it. Possible issues between PW ACH and the ancillary data are similar to questions discussed concerning GAL and the ancillary data in the same packet.

Thank you in advance for sharing your opinions.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: LoaAndersson
To: [email-masked];
CC: [email-masked];[email-masked];DetNet Chairs;
Date: 2021/08/24 01:36
Subject: [mpls] Consensus poll on Design directive for the MPLS Open DT

 

 

 
---------------------end --------------------------------------------

 
/Loa
 
for the co-chairs
--  

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

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 24 Aug 2021 15:54:43 -0700

Hi Loa,

I have reorganized the OpenDT wiki page, added a page for MIAD and added this text below (as provisional).

I suggest using the terms “in-stack data” (ISD) and “post-stack data” (PSD) for in-stack and after BoS MIAD, respectively.

Kireeti.

> On Aug 24, 2021, at 01:35, Loa Andersson <[email-masked]> wrote:
>