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

gregory.mirsky@ztetx.com Tue, 24 August 2021 19:51 UTC

Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333A3A0FC9; Tue, 24 Aug 2021 12:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_pxqncXX1kZ; Tue, 24 Aug 2021 12:51:19 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E993A0FBF; Tue, 24 Aug 2021 12:51:18 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 15DE47CA44EF43290DC6; Wed, 25 Aug 2021 03:51:17 +0800 (CST)
Received: from mgapp02.zte.com.cn ([10.36.9.143]) by mse-us.zte.com.cn with SMTP id 17OJp5f0032617; Wed, 25 Aug 2021 03:51:05 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Wed, 25 Aug 2021 03:51:05 +0800 (CST)
Date: Wed, 25 Aug 2021 03:51:05 +0800
X-Zmail-TransId: 2afa61254da99ed1f1d6
X-Mailer: Zmail v1.0
Message-ID: <202108250351054689748@zte.com.cn>
In-Reply-To: <6bee310a-0880-4a27-a562-2f048e3c4a6a@pi.nu>
References: 6bee310a-0880-4a27-a562-2f048e3c4a6a@pi.nu
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: loa@pi.nu
Cc: mpls@ietf.org, pals-chairs@ietf.org, mpls-chairs@ietf.org, detnet-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 17OJp5f0032617
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/G5F7pzLlET_YvYewMVro1_S7J8c>
Subject: Re: [mpls] Consensus poll on Design directive for the MPLS Open DT
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Aug 2021 19:51:27 -0000

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: gregory.mirsky@ztetx.com 
www.zte.com.cn






Original Mail



Sender: LoaAndersson
To: mpls@ietf.org;
CC: pals-chairs@ietf.org;mpls-chairs@ietf.org;DetNet Chairs;
Date: 2021/08/24 01:36
Subject: [mpls] Consensus poll on Design directive for the MPLS Open DT


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 (mpls@ietf.org).
 
/Loa
 
for the co-chairs
--  
 
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64
 
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls