Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
bruno.decraene@orange.com Fri, 01 April 2022 17:56 UTC
Return-Path: <bruno.decraene@orange.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C203A1164; Fri, 1 Apr 2022 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.994
X-Spam-Level:
X-Spam-Status: No, score=-1.994 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 PI-qJTIm13Jp; Fri, 1 Apr 2022 10:56:18 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874AC3A113D; Fri, 1 Apr 2022 10:56:17 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4KVSXJ0xr7zFqS0; Fri, 1 Apr 2022 19:56:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1648835776; bh=PMGdX4stv2lvu7ErKporewaAh++K5/96lKg7SauusIM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=bds0xyYDhYlgfgiL579DvyigVV+cEw3LZHTMvNtvbLbtTkKqggMIEXnp6LTPrsanb pSdMNx2/aq73Acx0GrN9DZZeC4hiFh4GTNry6GjazJM/hVeMfWuShLw8tI052TZDAV NtEfC0T+bimgC8Cck1aRm2y5LXC7jVQDFyyKPrqEOcH0pywzFeIzpQa+q9C0gPmSrq rdnERYDdZQfXklavpNsQTwxDgzILpaUukaE+88zSbbxMoFNSDn+oaDl0FSTKY41zsY tjmrA13uFX/xX6/xorWJpx+bDkTNbOhJWTeTwgexmVOhGRMqglft9rofYytphjKlC7 bNG9saCuhJTdw==
From: bruno.decraene@orange.com
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, John E Drake <jdrake@juniper.net>, detnet WG <detnet@ietf.org>, mpls <mpls@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Thread-Topic: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Thread-Index: AQHYRQ/HUYwdZ+tOtECAp2f3YarUZqzbU8RQ
Date: Fri, 01 Apr 2022 17:56:15 +0000
Message-ID: <2116_1648835775_62473CBF_2116_391_1_e4fdd9350d384122a600630cc1a906a9@orange.com>
References: <14219_1648628199_624411E7_14219_65_1_c11c63ca0c7649a1ba55d96c03910cd5@orange.com> <DCC3C232-0C45-4541-BDD5-0EF51333F41E@tony.li> <22915_1648659581_62448C7D_22915_418_1_8ef3862f86024a26952e0b183e921360@orange.com> <B33092F8-5417-4E66-9616-A1FD17485B2A@juniper.net> <AM0PR07MB4497D16A36BCAF86C0906457831F9@AM0PR07MB4497.eurprd07.prod.outlook.com> <CO1PR05MB8088A3BB0625E31EA00A3825C71F9@CO1PR05MB8088.namprd05.prod.outlook.com> <CABNhwV31cfLVZfQVc2M=WHN0-Funha9TTFNZ1iKDe+5QY9N58Q@mail.gmail.com> <CABNhwV1Z3-TU0-oFvYq3UJnibaPQLi2az3ZQFWf7toFe1Lju+A@mail.gmail.com>
In-Reply-To: <CABNhwV1Z3-TU0-oFvYq3UJnibaPQLi2az3ZQFWf7toFe1Lju+A@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-04-01T17:56:13Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ActionId=d5fde793-24c3-427b-a1b4-86eecf9141ee; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_e4fdd9350d384122a600630cc1a906a9orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/K1Vy6vEd2naaNM4hbgFQEqVUKgg>
Subject: Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2022 17:56:23 -0000
Hi Gyan, Thanks for the clarifications questions. I’ll take the liberty to top post to re-organize in two distinct points. 1. RFC 6790 specification of the use the EL’s TTL field. You have correctly highlighted the two relevant text: On the receiver side, §4.1 says “The EL's TTL MUST be ignored.” On the sender side, §4.2 says “The TTL for the EL MUST be zero” “a” So do we agree that RFC 6790 says “MUST be sent as zero and MUST ignored on receipt” ? “b” Do we agree that this how reserved field are defined at the IETF (e.g. https://datatracker.ietf.org/doc/html/rfc7176#section-2.1.1) ? “c” Do we agree that the way this field is specified (cf “a”) has always allowed the IETF to further extend this field? 2) Implicit null /PHP In case of PHP, the transport label is removed by the PHP and the ultimate node (egress LER) receives a label stack with the ELI, EL as top two labels. As per MPLS architecture, LER looks at the top label (ELI) and either: - supports RFC 6790 and then applies “Y then recognizes the ELI and pops two labels: the ELI and the EL.” In no way the EL is exposed and used for forwarding. - does not support RFC 6790 and hence will drop the packet as per RFC 3031 (§3.18). In no way the EL is exposed and used for forwarding. So in summary, the EL is never exposed (as top label) and can never be used for forwarding. Regards, --Bruno Orange Restricted From: Gyan Mishra <hayabusagsm@gmail.com> Sent: Thursday, March 31, 2022 4:58 PM To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com> Cc: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; John E Drake <jdrake@juniper.net>; detnet WG <detnet@ietf.org>; mpls <mpls@ietf.org>; pals@ietf.org Subject: Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes) Hi Bruno Please provide clarification on how existing implementations using Entropy Label ELI/EL RFC 6790 with your proposal to reuse the entropy label. In section 2 you talk about the new entropy label control field in your proposal to reuse the TTL field as the entropy label control field. I have some questions related below that are concerning with your proposal. RFC 6790 section 4 talks about the TTL processing below excerpt. If an ingress LSR X chooses to impose an EL, then Y will receive a tunnel termination packet with label stack <TL, ELI, EL> <remaining packet header>. Y recognizes TL as the label it distributed to its upstreams for the tunnel and pops it. (Note that TL may be the implicit null label, in which case it doesn't appear in the label stack.) Y then recognizes the ELI and pops two labels: the ELI and the EL. Y then processes the remaining packet header as normal; this may require further processing of tunnel termination, perhaps with further ELI+EL pairs. When processing the final tunnel termination, Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the remaining packet header. The EL's TTL MUST be ignored. So the TL or ELI is used to compute the TTL of the remaining packet header. States that EL’s TTL is ignored. Section 4.2 mentions that the TTL for the EL MUST be set to 0 so it’s not used for forwarding. The issue here is related to implicit null PHP case where the TL is popped and ELI,EL are exposed and to ensure that the EL is not used for forwarding the EL MUST be set to 0. 4. If, for the chosen tunnel, Y has not indicated that it can process ELs, push <TL> onto the packet. If Y has indicated that it can process ELs for the tunnel, push <TL, ELI, EL> onto the packet. X SHOULD put the same TTL and TC fields for the ELI as it does for TL. X MAY choose different values for the TTL and TC fields if it is known that the ELI will not be exposed as the top label at any point along the LSP (as may happen in cases where PHP is used and the ELI and EL are not stripped at the penultimate hop (see Section 4.4<https://datatracker.ietf.org/doc/html/rfc6790#section-4.4>). The BoS bit for the ELI MUST be zero (i.e., BoS is not set). The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the EL may be any value. The BoS bit for the EL depends on whether or not there are more labels in the label stack. The EL is not used for forwarding as long as the field is set to 0 which is a MUST. However if you reuse the TTL field as the entropy label control field it will not be set to 0 and thus that could break implementations in the PHP case where the ELI/EL are exposed. Also the TTL being set to 0 is different then the field being actually a Reserved or not applicable field. I disagree with sentence below in section 2. Hence essentially the TTL field of the EL behaves as a reserved field which must be set to zero when sent and ignored when received. The TTL field as I stated MUST be set to 0 so it’s not used for forwarding. So it’s not reserved and it’s read by the LSR looking for the field to be set to 0 so it’s not used for forwarding. I can’t see how that won’t break existing implementations. Kind Regards Gyan On Thu, Mar 31, 2022 at 12:30 AM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote: I like Bruno’s idea of reusing the entropy label as indicator of MEH in the label stack and is backwards compatibility for devices not supporting can continue to use for ECMP load balancing. I think this is a solid interim solution to get the ball rolling with minimal software updates and being able to support ancillary data in the label stack and as other solutions are progressed that may take longer or implement and deploy at least in the near term we have a quick solution that could be promising for operators. I think we do have to vett out the backwards compatibility and scenario I can think of is if you want to be able to use the entropy label for ECMP load balancing and simultaneously want to also use as ancillary data indicator I am guessing won’t work and that is something we would have to be cognizant of if deployed. Kind Regards Gyan On Wed, Mar 30, 2022 at 4:04 PM John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote: Wim, I think I would term it a thought experiment. An RFC 6790 compliant node will take the value in the EL label field and use it to select an outgoing interface. If the value in the EL field is a slice ID, such an node will select an outgoing interface which is not necessarily part of the slice in question and that outgoing interface will be to a node which is not necessarily part of the slice in question. Yours Irrespectively, John Juniper Business Use Only From: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>> Sent: Wednesday, March 30, 2022 3:21 PM To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; detnet WG <detnet@ietf.org<mailto:detnet@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org> Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes) [External Email. Be cautious of content] John, do you have evidence of this or is this a theoretical claim ? From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>> Date: Wednesday, 30 March 2022 at 19:13 To: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>, detnet WG <detnet@ietf.org<mailto:detnet@ietf.org>>, pals@ietf.org<mailto:pals@ietf.org> <pals@ietf.org<mailto:pals@ietf.org>> Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes) Except that putting a slice ID in the Entropy Label field will break existing ELI/EL Implementations because their hashing of the slice ID won’t necessarily place a packet on the correct outgoing I/F Sent from my iPhone On Mar 30, 2022, at 1:00 PM, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote: [External Email. Be cautious of content] From: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> On Behalf Of Tony Li Sent: Wednesday, March 30, 2022 4:08 PM > [Kireeti]: suggest attending talk by Tony on danger of reusing ELI before making any decision. https://notes.ietf.org/notes-ietf-113-pals<https://urldefense.com/v3/__https:/notes.ietf.org/notes-ietf-113-pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcqrP3gOo$> Done. The talk raised no “danger of reusing ELI” for draft draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary. I quote: “claims of backward compatibility apply to draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on slide 18 https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcNEC7QKk$> Yes, the issue with this proposal is that it has no space for in-stack data and not enough space for possible expansion of additional actions. [Bruno] There are two steps: - This proposal allows for carrying 8 Indicators and a slice ID while been backward compatible with egress LER hance providing faster deployment with incremental benefit. - If more in-stack data is required the proposal is extensible (e.g. draft-jags-mpls-ext-hdr) but at the cost of losing the above benefits for the ASes & uses-cases requiring more than 8 Indicators per AS or In-Stack Data. So we can have both worlds: simple first step and extensibility for those who need it. Independently, we also/already have the post stack data option to carry ancillary data, which may limit the need for In-Stack data extension. --Bruno Tony Orange Restricted _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Pals mailing list Pals@ietf.org<mailto:Pals@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$> _______________________________________________ detnet mailing list detnet@ietf.org<mailto:detnet@ietf.org> https://www.ietf.org/mailman/listinfo/detnet -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com> M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com> M 301 502-1347 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [Detnet] draft-decraene-mpls-slid-encoded-entropy… bruno.decraene
- Re: [Detnet] [mpls] draft-decraene-mpls-slid-enco… Tony Li
- Re: [Detnet] [mpls] draft-decraene-mpls-slid-enco… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Gyan Mishra
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… Rajesh Pandey
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Gyan Mishra
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Haoyu Song
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… Gyan Mishra
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Tony Li
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… Greg Mirsky
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… John E Drake
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Robert Raszuk
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Gyan Mishra
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Gyan Mishra
- Re: [Detnet] [Pals] [mpls] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… bruno.decraene
- Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-sl… Gyan Mishra