Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

[Stewart Bryant <[e-mail]>]

> On 6 Aug 2021, at 23:33, [e-mail] wrote:
> 
> Hi Rakesh,
> 
> I don't think any IETF document dictates that an MPLS packet with GAL/G-ACh must be "punted out of the fast path in forwarding”.
> 
Correct as far as I know also.
> I always thought that how a packet is processed is entirely implementation detail, which is also applicable to packets with GAL/G-ACh.
> 

Also correct although it is a simplification that I understand that at least one major vendor adopted.

- Stewart
> For example, for many years now, BFD is supported using HW, whether over IP or MPLS data planes. I can imagine that in an MPLS-TP environment with non-IP encapsulation, BFD control messages over the Continuity Check G-ACh channel (0x0022), still be processed in HW without being punted to the slow-path processing.
> 
> 
> 
> Regards,
> 
> Greg Mirsky
> 
> 
> 
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
> 
> 
> 
> 
> <9ae3e214c17d49ed935d87c674ba3ee2.jpg>	<24242e5637af428891c4db731e7765ad.jpg>
> E: [e-mail] <mailto:[e-mail]> 
> www.zte.com.cn <http://www.zte.com.cn/>
> Original Mail
> Sender: RakeshGandhi
> To: Loa Andersson;
> CC: [e-mail];[e-mail];[e-mail];DetNet Chairs;
> Date: 2021/08/06 07:01
> Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> Hi WG,
> 
> One comment on the following text with <RG>:
> We have a standardized associated channel, the GAL/GACH. We are not going to change the associated channel in anyway that breaks existing implementations. The ACH is found immediately after the label carrying the Bottom of Stack (BoS) bit. Currently, there is no defined method to carry multiple ACHs in the same MPLS packet. GAL/GACH will only be an OAM or instrumentation tool and will not be used to carry meta-data with user-traffic.
> 
> <RG> The last sentence needs some clarification. The packet with GAL is punted out of the fast path in forwarding, so user-traffic does not carry it, so it makes sense. However, packets could carry GACH without GAL. The user-traffic could also carry a GACH without GAL if use-case makes sense. I am not sure we are ready to add this restriction just yet.
> 
> Thanks,
> Rakesh
> 
> 
> 
> 
> 
> 
> On Thu, Aug 5, 2021 at 10:52 AM Loa Andersson <[e-mail] <mailto:[e-mail]>> wrote:
> Working Group, MPLS Open DT,
> 
> The week before IETF 111 the Open DT met and agreed upon a text on 
> "indicators". The terminology we use is that somewhere in the label 
> stack there is an indicator tell the processing node that a specific 
> packet needs a certain set of Forwarding Actions, for example some iOAM 
> action might be required. To support the forwarding action there is 
> often ancillary data with the packet.
> 
> The text the DT produced is about the indicators, a companion text on 
> ancillary data will follow.
> 
> The text was discussed in the Joint meeting and reported to the MPLS 
> working group at IETF 111. The Open DT itself can only propose, the text 
> is therefore now sent out to the working group for review and consensus 
> call.
> 
> The proposed text is found at:
> https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda <https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda>
> 
> Please review the proposed text and comment on the MPLS wg mailing list 
> ([e-mail] <mailto:[e-mail]>).
> 
> We plan to keep the consensus call open until 2021-08-20.
> 
> /Loa
> Open DT Co-ordinator / MPLS wg co-chair
> 
> 
> -- 
> 
> Loa Andersson                        email: [e-mail] <mailto:[e-mail]>
> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
> Bronze Dragon Consulting             phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>