Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 30 December 2022 14:44 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55715C14F745 for <idr@ietfa.amsl.com>; Fri, 30 Dec 2022 06:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=OBr24ZAR; dkim=pass (1024-bit key) header.d=juniper.net header.b=M3nJwKib
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Resc3yuBEAVf for <idr@ietfa.amsl.com>; Fri, 30 Dec 2022 06:44:32 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 388CBC14F73A for <idr@ietf.org>; Fri, 30 Dec 2022 06:44:32 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BUA3caG026119; Fri, 30 Dec 2022 06:44:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=4UeXLTWlObY5qxrPTAxJSWDmbez5ERb8IyYHDHHS1eo=; b=OBr24ZAReWPK19R8oZR/8SUMoBcUEGk/5l2fAPZ0mBIuv7I1zGutyol1QfJmze9SBp1P UuS6P+OzG2bWwH7in0Qfu11OO6BAV1vbyAOzcHmdSJ7rbHMX6eQI8MTMHO1hPQexQOH1 ku0TtCBOVzf0La7tWXs46GalqaZwyRDKAjVbBfR/VTULsMFa817IUXMczGg6p15mFgcA IwLlRY4WnlrCfqz3ndOQA4OQf6gaQD7gig6bposxAo744NsGvAfdn5gKu3qcZR2EjcfY /bRKMuKobZzsOu7sU29t0KxSzug9GYMQidNHJlOU5T5GuS5Fy0acZpka0ewGof4dg43j nw==
Received: from mw2pr02cu001-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17012027.outbound.protection.outlook.com [40.93.10.27]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3mrsbka0eu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Dec 2022 06:44:31 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X/KdImLMBSFU+g1G7ZEt5OdGpcmftSvzj8gKXGizUqazeriBkztL3E0jcr4erC2PcqWsf5bErXCra1FcT9F7oJiy7HYBqOBPJ8s+XTxEmIrN2GMp10Ups1ghkBsSRo2q4wQUBuz/7KtSmB2U6Xtwo1r8qKB6/OGb0l+yUC04I3kv2lY44oE5nvZFBCyum9Wz/9OuH8gD7fEyrIuc+4kstFCsWoc3B7hjBfJPFy8IXHER7ogGL9JCPFYBpBKxomiBGHxcaTIVkEbO7BgyefHEB1IE3x+LUVePZFdeH4qCp0KOPWaSUiBquyJODM2i8IC6E9jPV5vfEkM/8SBLl+sWEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4UeXLTWlObY5qxrPTAxJSWDmbez5ERb8IyYHDHHS1eo=; b=Wr/EcM/eoEX2LWHGAOx9B0P7xnEEe44MCMQvQVKNeInlRBYpatAhCI+WdoGvMFw8N+dUfNo9vc32sVdn7rQ63oIrl6Uuqfa7q/644O1JHQd2Vt0xdidqoBYWHBp0at1MemZkplAyRtrGJfGEf1bDbDpWjD80ZTC3EByxnztVX+dYupxFrfn4Z1JudJgkFqvRsPnp7uj/vznDZiJEXj9MLkzeGRsU65QN3azMwu1ij4jZKEhdo1ipD42PjQ6AEfe6xPnYBmC3IL9lCjyCEoZ9RENL7RGRww011alSTjGJZutmzvosuevf9hDnom8A5L36rdxHzgujXaWZpNwgL2K2/A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UeXLTWlObY5qxrPTAxJSWDmbez5ERb8IyYHDHHS1eo=; b=M3nJwKibIUk72GRtKBlaite0yBkiaWpSkNqTiJEb9Dv8Dfs2FiGJHZXvFiXzrcYCBkMOFHFm1V+41l37Irb3l9VmkZ9lyRYNY/LjXYjrd7Q5uaE4LJg21q0z+qF05dU4QnxC+iHVyuMccnmXeyxyiASaLAH5ecWIYcpkfSpFljo=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by DS7PR05MB10090.namprd05.prod.outlook.com (2603:10b6:8:e9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.16; Fri, 30 Dec 2022 14:44:28 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::5e87:b845:992b:d1fa]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::5e87:b845:992b:d1fa%6]) with mapi id 15.20.5944.018; Fri, 30 Dec 2022 14:44:28 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Robert Raszuk <robert@raszuk.net>
CC: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023
Thread-Index: AdkW+/cUE4SSf2yIQG6Qt4kQqqiyjwAF3k4AAMj5uwAAA3IagAAjVdVQAAEeLIAABo8REAABIayAACroT8AAAYrRgAAJelWwAAE2kAAAAGg5EAAZEp0AAAf2SYA=
Date: Fri, 30 Dec 2022 14:44:28 +0000
Message-ID: <BL0PR05MB56524F222415B1E532F1C5B9D4F09@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <BYAPR08MB4872B6B3A9AE7B008463795DB3E99@BYAPR08MB4872.namprd08.prod.outlook.com> <CAOj+MMGkimvyy3kA36Pn=VzbdTB8ZHDeEhzArsFEVE3P8W2Mug@mail.gmail.com> <BL0PR05MB565243B34F92752FA6E8B397D4ED9@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMEbjJaFc-arh4ujfSEtnpACwvN2uofKafO6oWUx3-O_BA@mail.gmail.com> <BL0PR05MB5652CB8141DF3A1CD9FF1A9BD4F29@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMFSP2oThW4C9GezQYK-eU_qRSfNVk+RPib8_spmtWmSzQ@mail.gmail.com> <BL0PR05MB5652D4B1E085D764C57B19E5D4F29@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMFWVrvtF=f+sx+Y6pMUJQL_5MYKPiXXRRcG0WWM05JAjA@mail.gmail.com> <BL0PR05MB56528E59C23486437034818BD4F39@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMG46bQsHFmDJmoc2+CMTCrA6yYV=gMzdSUxe48gB6=StQ@mail.gmail.com> <BL0PR05MB56521C1B92778F7D27A9BA41D4F39@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMGwrUGJOvJ39AoUrjSimYES=O2mHmpaQyN5sj8VV-QwVw@mail.gmail.com> <BL0PR05MB56524EC954218FBDE2622040D4F09@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMEDHJNX5U7tgq3pLr0=FJ9DHzJo_q6_g5qQ4_+ZfgSzwg@mail.gmail.com>
In-Reply-To: <CAOj+MMEDHJNX5U7tgq3pLr0=FJ9DHzJo_q6_g5qQ4_+ZfgSzwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-12-30T14:44:27Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=96888ab5-ba7b-4060-bf34-d37d4cc87f5a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL0PR05MB5652:EE_|DS7PR05MB10090:EE_
x-ms-office365-filtering-correlation-id: 9464c3ba-484f-4d22-1b55-08daea745acd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zmSFJubPOyx1L+s9V0rHt1jtcr/Tq2S+hRBCuuOo4L1gZH5v64naSlyE3rIYeWxiAiCPzT/cRUD/5FVk2y8gARb0NboW4HfXcpjaQ26EG9YMdf+xh5OfeXUqNmABuk8vKcpQ+rkDBvq5od2wjR2D2mvBcH2skXY8w4A8Icvqv9ufCuG3KC36pLn4dHBv4/4DoDMed3XoFj1W9fhpGZ6GOldgH/8jT0rrqB7yWp3CI1iJZD3+CZEuMH538KF7AcO2qsmfc+p2ZL/xuvOI16YZyGzNC6XRKcEvL8OIC75jv/lDIRpgVdUfEkow+ywoz/iIwrza27IgdBuAprd6+0QtCxliyVKIIQrzPMcC5hHQj/UaSlHIPzMuznAwTQHPuqWjSsPla0Vb98N1OtTIIALIz0jPQJCRfVrdcBQWasDfYzBQQj0soApUEk03nN93v7J6fOkEjO3GczdGiTCs3OcVp0XyUKALKU4TK1kzSbLxiuVDyc594WXc1CQe1bub3LdF97IS0NCp1ynyTqU7i2lZBMOLhsvG8RmXkmZqk1WcNTCrWk/rvpMWekx7Ee8BErdUWz46mYcaNxs2FC8ckhbTB8TE1nI7RhglmNfQFPfmY6fwJxwuJpIFCV4VcKpwPwrV+v9dy2hLh9peCPH6fO9uOT6iqIXismO5Y93xnRN9bpXoGukDxR13kpQ9Q77esMbMNOvRYtY+B9uUE8UI/wot+U5bIaimD4YYZ+y72ugUgJ5LBZWPV0oyp2vfHIKfskTM
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(39860400002)(346002)(396003)(366004)(376002)(136003)(451199015)(66476007)(64756008)(8676002)(66446008)(41300700001)(2906002)(66556008)(4326008)(122000001)(38100700002)(8936002)(52536014)(5660300002)(9326002)(38070700005)(33656002)(7696005)(6506007)(53546011)(478600001)(71200400001)(316002)(6916009)(54906003)(76116006)(66946007)(55016003)(86362001)(186003)(9686003)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: lVKJhaEm9deA6nsHH9+OwHVKSZ7ULh34m5NQCXn7A1A+wvFJmAbKKlmrCtuNAv6XwygY3s3FteXWCiMu9siDjj5/zEzru8duo0IiN5kw/mKuamFs58yjiFXo1xN50nf+ea3SZTCsIRdQiSyHVTfjU+24GRqkDxgvKhjl2CRl7fsMqrrSkDwfo970XADrQmkODcn01BayKT2xlNhyTqKcY8vkk7p4+ehpG1V4Kh1Xv5OmnIfmkHQZYzR+Rfo6FEq2l+x5Q6mXelpVj8g4Y3FjhaCeNZVKIKlOOk6wC2kp8QEU6I622wZMMI9KddojPQTq8swLUwD0AsVlyLZShgo6d3mKKmgIu35UaLNnliBDrSX8/QiKCfsxKxExBPYtfQJAZxIU3Ne9O4vDXoPXDAT54AWOltdzPwIHjbDei/gmHTQHlb72QM/Ow80MFltf70qhShWSodtAlqokU9wD+9zbCas2M9WAntEA3bG1ROtA48HcmVmR0okuJbi6Rn0e7vT+U55gjYOj7CAyV8QKPbd1kcpckDRIV0+0MMBQcnzkj2YxvQB9s0ndV6ReT5+rcIEVloekPAZP+NG/pgH36uaqrO2HqXgQcuJba0i4F6NI89ZL7CrAXp7o6tnnnPqLunoQdI1CY8Vq0dvkhayAAjJD1qJjCqEG29yPCyfmwhTO4m/uJc9wgN4Iv1otHSli0+kle9n0q5gkbPXikaIy9rdrdXAf2waAr4BiDnFWHeVysKKQn6j2dG70KQyE55yJ8OkRhijoWplQ2WG/262p/MhgvVbPlEFWca0A88VwSp4I72Vqn60ul1IDduVLkNeUYWDh77qw8lLsHViUf37NsTkeCxJ0XuircGn87Pj+t3ZEx/lrLGsufGVxZ1aY55Fr7GwbKw1VeRj3qM2q5Zv7RPqJnQtC07MG9kgln9xujJwBUqFcaKUJP7jXHvA0JtdrWGaH7UTz5R9lf1M6kElquTDJmHfNo94YWrWCffsTPEhOBPOUCkgN9drgiWmqcFsEPCV+P+MAAmJvEXW8UJ5igBKdhc8Fu5bevWqG7zb/uQ5b/4YYFoA8SjHsdqCicFugiKSHXc28hFb6RZkQFJ6guh0bJSR0pUd4lg/BWdkrGxYwZ16WQDDzkffWTBzLwFSCk8DpZ6Q1sQkbItcaNVAzZidoVYC9LyvccvtqHQXnzECQ7A4jFg7sAfEVYEu1N7PM05iUGGe4kBbIoTyl7Vj1bAf0p5J1d2NWxhGF7GXxiP4JY3VnE45LZzOFLMAHDPihf6BjLyAq+8+C+VsJf0ipxLlbqN5YbfvW4vfoq+L/Yp2wWZWuR/xegmIKlmEMPZwyYXrF9ZpDF7UgSuXEc13mTaF+8SgeygOwutBe4nZ2VxP4ymnAon4UYwc0k15fWghTBy6qDKxtMsIWAyPlO8VrZfGb2HZuShLCS5v32zgaTIr759UPzTrO0iyvykJVMnzmRHvFrzFHFjApPgSV4mne7G/nX75utjwYkS0lfBO/UtMz3oVK36445+7dLMItwhYOh/GceQNGmQ9VkVBsDusbSg9u9gElJzpeWPwZjNUp50LqHeIq1M+1RvlKn9OKrd0c8KH+
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB56524F222415B1E532F1C5B9D4F09BL0PR05MB5652namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9464c3ba-484f-4d22-1b55-08daea745acd
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2022 14:44:28.6218 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hc6ZzmJLAzhEW4ORme+WItI2JzNjPLVHIp/IUvTsINnBweuNnq7bX6vDT1wuwwZpAjiA8OnmbbKB9ucMgJtqXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR05MB10090
X-Proofpoint-GUID: cvK-mpBfxXvj656OejlV7g7ZOj7QjvQR
X-Proofpoint-ORIG-GUID: cvK-mpBfxXvj656OejlV7g7ZOj7QjvQR
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-30_09,2022-12-30_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 clxscore=1015 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 priorityscore=1501 spamscore=0 adultscore=0 mlxscore=0 phishscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212300129
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YijUi0smChSqMCPbbnrboR81P4w>
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2022 14:44:36 -0000

Hi Robert,

Please see zzh7> below.



Juniper Business Use Only
From: Robert Raszuk <robert@raszuk.net>
Sent: Friday, December 30, 2022 5:19 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Susan Hares <shares@ndzh.com>; idr@ietf.org
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that is attached
> to a unicast prefix or a multicast tree route signaled from a controller.

Actually it is precisely what authors of draft-ietf-idr-segment-routing-te-policy considers to be a fit.

You are now mixing "SR Policy" with "SR Policy Color" :)

Zzh7> draft-ietf-idr-segment-routing-te-policy is about "Advertising Segment Routing Policies". In an SR policy, you can have policy color with it:

   +------------------+
   |  NLRI Length     | 1 octet
   +------------------+
   |  Distinguisher   | 4 octets
   +------------------+
   |  Policy Color    | 4 octets
   +------------------+
   |  Endpoint        | 4 or 16 octets
   +------------------+

Zzh7> In my previous email I said "... that draft is for a controller to signal that policy to the root, with the tunnel endpoint/color and candidate path encoded in the NLRI and other information encoded in a TEA with a special "SR Policy" tunnel type". Where did I mix "SR Policy" with "SR Policy Color"?


Take a look at section 2.4.4.2.1.  Segment Type A - it is exactly what you are proposing as new sub-TLV for TEA:

Zzh7> It's clear that you did NOT read the subject draft well. More below.

draft-ietf-idr-segment-routing-te-policy:

   The Type A Segment Sub-TLV encodes a single SR-MPLS SID.  The format
   is as follows and is used to encode MPLS Label fields as specified in
   [RFC3032] [RFC5462].:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Label                        | TC  |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Your draft:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |   Length      |     Flags     |   RESERVED    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Label                        | TC  |S|       TTL     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is clear that this is not efficient on-the-wire encoding format, and it
involves additional encoding/decoding processing.
Zzh7> As the above quoted text (I marked it red) shows, I was pointing out the efficiency issue of existing encoding scheme - that's why the subject draft proposes the compact format:

3.1.  Segment Type L



   The Type L Segment Sub-TLV encodes multiple SR-MPLS SIDs.  The format

   is as follows and is used to encode MPLS Label fields as specified in

   [RFC3032] [RFC5462]:



     0                   1                   2                   3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |     Type TBD1   |   Length      |     Flags     |   RESERVED  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |          Label                        | TC  |S|       TTL    //

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    //          Repeated Label Entries                              |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In fact if you look at section 2.2 of draft-ietf-idr-segment-routing-te-policy you will find exactly the solution to your use case by encoding SR Policy Candidate Path in TEA.

Zzh7> You're not reading my earlier email. Let me quote it here:

Zzh6> ... that draft is for a controller to signal that policy to the root, with the tunnel endpoint/color and candidate path encoded in the NLRI and other information encoded in a TEA with a special "SR Policy" tunnel type.
Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that is attached to a unicast prefix or a multicast tree route signaled from a controller. There is no reason the mix the two use cases.

Zzh7> When a controller advertises a route (e.g. for a VPN prefix), it can attach a TEA to specify the tunnel destination information already. Now we want to be able to specify the explicit path as well. We don't need/want to use a special SR Policy Tunnel for it (as you quoted below it has a lot of policy, candidate path information that are totally irrelevant). All we need to do is to attach this new label stack sub-TLV to the existing "MPLS" tunnel in the TEA.

2.2.  SR Policy and Tunnel Encapsulation Attribute

   The content of the SR Policy Candidate Path is encoded in the Tunnel
   Encapsulation Attribute defined in [RFC9012] using a Tunnel-Type
   called SR Policy Type with codepoint 15.  The use of SR Policy
   Tunnel-type is applicable only for the AFI/SAFI pairs of (1/73,
   2/73).

   The SR Policy Encoding structure is as follows:

   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
   Attributes:
      Tunnel Encapsulation Attribute (23)
         Tunnel Type: SR Policy (15)
             Binding SID
             SRv6 Binding SID
             Preference
             Priority
             Policy Name
             Policy Candidate Path Name
             Explicit NULL Label Policy (ENLP)
             Segment List
                 Weight
                 Segment
                 Segment
                 ...
             ...

   Figure 2: SR Policy Encoding

That is why in my first mail I asked if you are trying to do SR-MPLS-LIGHT here essentially overwriting draft-ietf-idr-segment-routing-te-policy proposal.

Zzh7> It's definitely not "overwriting", and draft-ietf-idr-segment-routing-te-policy is not appropriate for my use case. They are entirely two different things. One is to signal an SR policy, the other is to specify an explicit path in an MPLS tunnel of a TEA attached a route.

Zzh7> Jeffrey

Many thx,
R.



On Fri, Dec 30, 2022 at 3:02 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Please see zzh6> below.



Juniper Business Use Only
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Thursday, December 29, 2022 5:10 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh5> It's "outside the scope" of RFC9012, not that TEAs are *prohibited* with other AFI/SAFI.

What I should say was prohibited without a new spec extending the use of TEA to other AFI/SAFIs. To the best of my reading the subject draft does not extend use of TEA to other AFI/SAFIs.

Zzh6> The subject draft is only defining a new label stack sub-TLV for the purpose of steering traffic to the tunnel endpoint in a TEA that could attached to the routes of the AFI/SAFIs in RFC9012 itself. As you say, the subject draft does not extend use of TEA to other AFI/SAFIs. What's wrong with that?
Zzh6> The same could be used for multicast tree routes as well. That is indeed for a different AFI/SAFI, and there is another draft for that. That draft is not the subject draft here, but what's wrong with that?

Zzh5> That draft is about signaling *policy* - a totally different use case. What this draft does is to allow, for a particular tunnel in a TEA, the steering of traffic to the tunnel endpoint.

Sorry but SR policy is exactly for steering traffic to the tunnel endpoint. Yes the name "policy" is chosen very poorly as it does not reflect what most of us understand by "policy" but it is what it is.

Zzh6> Policy is indeed a poor name to me as well. An SR policy is another name for a named tunnel that may have different candidate paths, and that draft is for a controller to signal that policy to the root, with the tunnel endpoint/color and candidate path encoded in the NLRI and other information encoded in a TEA with a special "SR Policy" tunnel type.
Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that is attached to a unicast prefix or a multicast tree route signaled from a controller. There is no reason the mix the two use cases.
Zzh7> Jeffrey

Thx,
R.