From nobody Tue Nov 24 20:56:57 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6CF3A0D84 for ; Tue, 24 Nov 2020 20:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kG9WaU11; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XJj2C8Om 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 dUrrG0DxeBoh for ; Tue, 24 Nov 2020 20:56:53 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ED83A0994 for ; Tue, 24 Nov 2020 20:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15854; q=dns/txt; s=iport; t=1606280213; x=1607489813; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uDPNNmvomyXH5pWIcWFULKxPfneSY9GGaMX9C/ERBVo=; b=kG9WaU113ETkQzDG6JbIwD3+omNEtJO0f0HAFPQTx9lkstTnaSCJb0n6 Cn0n+8eYHV8E/SFhLBUdU0/j2fA8Cox+i3inP1oMegZu46C89d/ccnMY7 yrnAB8v76wnCdc6HWWySe/CVLv3kKmnang0flMLZ2zlhSaUg+VB18ipO7 s=; X-IPAS-Result: =?us-ascii?q?A0DZCAC4471ffZxdJa1igQmCci9Re1kvLogGA41fkH6DF?= =?us-ascii?q?oRwgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIsAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhjwMhXIBAQEEEi4BASUTDwIBCBEBAgEBAR4RMhcGCAEBBBMIG?= =?us-ascii?q?oMFgX5XAy4BDqMNAoE8iGh0gTSDBAEBBYE3BAxBgzEYghADBoE4gnOCZk6HG?= =?us-ascii?q?YIbgRBEgVFQLj6BBIFZAgMBgSEcIB4GB4MdgiyBRgGPNYoXnToGBIJuiRSJX?= =?us-ascii?q?IhSgxqKGZRTnmGRJ4Q4AgQCBAUCDgEBBYFrIYFZcFCBHoFLUBcCDZIQhRSFR?= =?us-ascii?q?HQ3AgYKAQEDCXyMTS2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AjBPUPBBmGuN1v4QO5o36UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,368,1599523200"; d="scan'208,217";a="636629272" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 04:56:51 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AP4upB5013374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 04:56:51 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 22:56:50 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 23:56:49 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 22:56:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aCv4R4JYbAsD5Fk56R172sX/kEC4UkgU4vOgWSMV1Km1AAJxy33bMgzOm5iNhIi/qntbusPojOqxpwPfTVZsmokWNSQJEn6ZYSMdoSUWpmjRjpfnfnFhip3IUYkSSbJpX1RoiXU9S5SEHAV5rCnJYv72GYJVQTYh7gJnyIzr4mvGkO5ZLkbo5rS5hL6gNMnlWeYhGuTi8fu76yIXad/0FdNBHTtq5n0l9Tb3lGnqraMmOm8u8xsUHDqbnoKoS0s56tkPFpkSgMAjOSIkBPHMAl1+/fu6xZwEB8xYpC8dn5hae5besNP/0aaVtSJroDuCBpxsh0WZAWLHjCy69SUChg== 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-SenderADCheck; bh=JfoQvThGjwyvh1RVXItubu7TOJi93w2PohwXXexzeSs=; b=lIFl1N0/FBgdwMTZvEYRSPS5TIecFYpoqrTYswGQiioTp61uMfrW+ut8V6JeFKsUrbLxVwPHjp375mliJmkHfUuN+NJAlSOl1yuJDgHSAwZR/OiR0Un7hnpnbx7sxbenuBcMqqc0G+zV67TQF/P6Cazjb9CmI+s2jPrg0XeMsGBDrjIAVzO+q+m8gTeGLKzLQHZQRR2dH2Pf3xjMffWFmTqj8FQ/MkuKYknpLn2X6iRrwBZDc1AWWbI+CtNYrgEZE7/VT6QUik0aY0Yf3NV/G9IGuAHm9fSWuMqE9Awy7mDAaMVdMmIwgS35MxXI53Fr+uxy3QQt0j+4GCjk0APuhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JfoQvThGjwyvh1RVXItubu7TOJi93w2PohwXXexzeSs=; b=XJj2C8Omb3RSDoKAY/nTn7d8rfJr5wF6He3fq5eNHmFS/pk7RGRKB8MTNJa4h6LPOlyaRAhsijC5iQ0LGDh/FOGaww9az/CB8dEKDffttLpR+OQ3UZw7Pv8GL3pEhqiTxSKvOjryVI2IC5xstqSisdZ9pia0cjdlrZVvU/DhIfA= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by CO1PR11MB4978.namprd11.prod.outlook.com (2603:10b6:303:91::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Wed, 25 Nov 2020 04:56:49 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a%9]) with mapi id 15.20.3589.030; Wed, 25 Nov 2020 04:56:48 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIO Date: Wed, 25 Nov 2020 04:56:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c33cd4b6-6169-4422-0017-08d890fe845e x-ms-traffictypediagnostic: CO1PR11MB4978: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dVB80S3acI12YIUDrWbmTrCR9UCtZfLWIExrLaHEA2db92J2z4tOhQV8y/Ela/PC/B6TxisnoWCbiI4q7FX+83ML/d6Rwx6zeMTq+VOVInAtt2QC13ou7lTkrGI4dVEv+xaYirOY7lu5La0KJZ80mBJx92/8vqJbMeWhZ2t/qFxF0rK1L7+IXwm46FnFbq/wY/lkY4d+1LX2GwwoxwzvjnosTw4M7rWW00wngjL8czBJ9EwWRzKBymbLhV+tFX52hLzA6c9NasLfCl738QooBYROHmaPelrgzmIZbExfN7xMLFBpvON7ceYr8sNIm/oNfEDWzcLeUAJaBVn3nXkFOS8Uv6m35vmHdElyc0ox3muoU0dgYCz42crk0M6hxZKMIwTD7FH2ydMfbZ5D8JqSIskz2Tk3vK8Gzco5XQPomqb3Rrzwn/nwfuoJFhI7ro5M5s61Pj0/xlOMU8QZHI3Ruw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(346002)(366004)(396003)(7696005)(5660300002)(53546011)(186003)(478600001)(83380400001)(2906002)(66556008)(52536014)(6506007)(76116006)(316002)(33656002)(71200400001)(86362001)(55016002)(166002)(66446008)(6916009)(9686003)(64756008)(8936002)(66476007)(66946007)(8676002)(91956017)(966005)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?6sdhBBJrv78TjvihIYiwPDDZJvuMljGOANcUYJfu4tVtD0x53VK5GYxX?= =?Windows-1252?Q?Xf9+RB7Im+1A9LU0tVK9iUv287jCRN4G61wTvw6ewNTkwtL9lOeQ48n/?= =?Windows-1252?Q?5pwsAinSgE3xuItOVWJSaAx2E9ZeKp471icPphBnjnB3lhUX0VgwcmHZ?= =?Windows-1252?Q?fOlKQ58SyaqIweqGHL5l39ik0LmBguVsF46aq3z0zuWV2iavLZ3KvzWb?= =?Windows-1252?Q?NI98DTUQYKjcIXsBmhGdOu9yiRrhgK0Bl87CV+9dYIsRmmGQjCek0Idp?= =?Windows-1252?Q?pMX4Y2vYbFtJK7RRwLSjluEhcn3aUvMp3xgIcFsv/3djhSBWh03xTHCa?= =?Windows-1252?Q?HO3PQaPbcDyB2w2VoOax6V4fkdP4kHWc398Np+qooUE7GdBU5RMiAYOV?= =?Windows-1252?Q?U94uYyXkremlrao2A7zYrEz86VSdysX/bTUVIifDiGj1ZHNHv4aeWbuf?= =?Windows-1252?Q?jM6eI8K66X63mFCh0yw1hM09zeNmqcM8YvOJtmCXqOScd80EjVgdJuch?= =?Windows-1252?Q?sQ5yNTH4ePBfQH3QWdEN44YUxLoYltRahlRehDILbAhaQUztyAMnIoHY?= =?Windows-1252?Q?IEuPsieJm7sWE/DaGGGeFFhdAxjcoTgC1HqI4PESIYurPPZcs7nb/fB/?= =?Windows-1252?Q?LnxRNouSPkEcJkxwnEjC1JxcXHoQDv8SIRikFzpFDd/pnv1YScD7+C3U?= =?Windows-1252?Q?Y5pexy+Y82CY2PBDGSRigHm43tKYtjHg+HmkyXUlFpSG8zcJufxnLqh7?= =?Windows-1252?Q?wKcD3gsp7Qit6wQPKiTQKEuWnniuL1/JYCU3vEjFSuS7LSycv9MSvlYX?= =?Windows-1252?Q?9X6BC0Vjuc4qIQAiK/KczQmDvaGXkPRyxVGUjiu1Y+rHwTo1+MlkLVfN?= =?Windows-1252?Q?1GwfpPmkQMll8/8n71Oa0VohmK/S8r0D1xjRxun5/LD2UVsZkEzxC8kz?= =?Windows-1252?Q?/oRNK7G0z/QVt0Jsfz2iIKzCDZvs0oSk1pN4CR2iYWQ839HMn90TjW5v?= =?Windows-1252?Q?hdh1+R+pNvI/4oSJfHqaftdemxdYvjLiIvDU627tiEf/XLR0lGRCeTx+?= =?Windows-1252?Q?NH+ArQ5jk2ClhoASat85zEDlTIOooK9Kt5JEVqxxkIIPyWP7ljVNfa0i?= =?Windows-1252?Q?oxTeYPYJSbXnO4u6nWIV7qn/gTmxkSNrAqteTy7mXWNzag=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c33cd4b6-6169-4422-0017-08d890fe845e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 04:56:48.8511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JPJh5QrTLvajG/ls3XQmb4Daum9vVhMpWKmnmcRxtZQT+5uJM/WhzGVtV1MhzDuZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4978 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 04:56:56 -0000 --_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I=92d like = to progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,=

 

Ingress as Root looks better be= cause

1.  It is consistent with = the way RPL usually works. RPL Local instance, = aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P= -DAO, currently ingress sends upward traffic to egress(root) with SR header= . But in RPL, only downward traffic carries SR header.

3.  Only ingress can = send PDR makes sense. Behavior of TrackId is similar as Local Instance ID. Ingress as root can propose TrackId from its namespace.

 

 

And for storing-mode P-DAO, if = we make ingress as root and ingress sends PDR, can PCE send P-DAO to egress= then egress forwards it towards predecessor to ingress?

Maybe it helps to make P-DAO lo= oks like a DAO message.

 

 

Best regards,=

Li

 

 

From: Roll <roll-bounc= es@ietf.org>
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Que= stions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intrig= uing question. It could be done, just like we can send packets DOWN a class= ical DODAG.

But if we take that path, we reopen the question of = who is root and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root?= How does it matter?

 

At the moment the Root is the egress and the storing= -mode P-DAO flies from the Track egress to the track ingress, and the track= egress is the root. This is not the way RPL usually works as the DAO flies= towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. I= f we wanted to build multicast Tracks the root should logically be the ingr= ess. And for bidirectional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingre= ss to be root. I changed in the latest to map we do here, that it is the eg= ress; maybe a flag in the DAO would indicate which direction the flow, from= root, to root, or both?

 

Also if we build bidir Tracks in storing mode, the n= odes that forward the DAO will have to build routes in both directions base= d on the P-DAO, both towards egress and ingress; but only the path from whi= ch the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up o= ne way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] IETF 109 open Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are = available here:

 

https://datatracker.ietf.org/doc/slides-109-roll-d= ao-projection/

 

There are a number of open questions that we startin= g discussing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from = Huimin She. I=92d like to progress on them all with individual threads.

The questions are:

 

  1. Lifetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance;= new flag?
  3. Make P-DAO bidirectional?
    4. Who sends the PDR? Does it have to be the ingress? If it was egress it = could propose a TrackId from its namespace. Else could the ingress be the r= oot?
  4. Maintaining the sibling state. Should we have tex= t on using RFC 8505 there?
  5. Whether ingress and egress = are listed in NPO? Today they are both, ingress to indicate the packet sour= ce in case of encapsulation and for SRH-6LoRH compression reference and egr= ess to build the full SRH-6LoRH. Note that the ingress must consume the first = entry and use it as source.
  6. Track in Track vs. SR Head= er reload models, see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_--