Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Sat, 15 August 2020 05:09 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C43A0593; Fri, 14 Aug 2020 22:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.487
X-Spam-Level:
X-Spam-Status: No, score=-9.487 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=VouzZLP7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wPfWbKl3
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 9vDIcB0eIVGw; Fri, 14 Aug 2020 22:09:00 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434213A053E; Fri, 14 Aug 2020 22:09:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54555; q=dns/txt; s=iport; t=1597468140; x=1598677740; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=juGqy2eElryLK+CSWhBncJW7yjim34P9vBmyKdOHEtI=; b=VouzZLP7unay/VTF3yKr526kvP1/fxhayUqpovtTKjldUJxEOGkNSjl/ wdhft16KiR08wvwqmdOWQpZqt6tn/lrSx0gAuiv2xHo3Eo6ZHgwDXEIjD 4Hl6Wzj3VHfcOdIiyKJa+mehgO+4pNONVGW55LrH7UNkpzZdaENjfwoks 8=;
IronPort-PHdr: 9a23:tEJ4kRUQpeEMVTxav5ONeVjYapbV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSBN+DuelbivHNuKflH2cH5MXJvHMDdclKUBkIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry6p8j8JAR74MEx+IeGmUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwRrSqXwOcONTlm4=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DECQD3bDdf/5NdJa1eHgEBCxIMQIJtLyMuB3BYLywKhgqBaQONVphngUKBEQNQBQsBAQEMAQEYAQkLAgQBAYFtgl8CgkcCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAgIBARALEBMBASoBAQgDAQ8CAQgRAQMBASEBBgcnCxQDBggBAQQBDQUIEQmCfwQCgX5NAy4BDqhYAoE5iGF0gTSDAQEBBYEzAQMCAoNPAxWCDgMGgTiCcYosGoFBP4EQAUOCTT6COiIBAQEBARaBDAU3DBgHCQKDEoItj1YhIQOJSZxOCoJiiGORXYJ/iVsFk0CSOIFsiFaUegIEAgQFAg4BAQWBaiMNWnBwFTuCaRM9FwINjXwjDBeDToUUhUJ0AgEBATICBgoBAQMJfI80AYEQAQE
X-IronPort-AV: E=Sophos;i="5.76,315,1592870400"; d="scan'208,217";a="539066753"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Aug 2020 05:08:58 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07F58wEU015047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Aug 2020 05:08:58 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 15 Aug 2020 00:08:58 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 15 Aug 2020 01:08:57 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 15 Aug 2020 01:08:57 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jA6qvRAKVWBE2giRsTM6KjcyQX8KEItpgJJ9PPC7vRQ1OQVHntUxjDBsvRUumKbi3O/F+ZpYC0E41uVrkLfLfk/YdXYi88MKpKNwwtiit8XdKI2USNF1oh0onk2bNi1HdzlYLLfRWHfQYOd7I8IS5zYsi900KNLxkz2DeNoQnZ/ja/+s1U3utHIWEuxCZ2kP9/W1gpDz8cwYfBuGwVZEx8hPIZ6C9LeeFNTnELyL7dRo1BY/quwMRbvZGu5eoKdL0Q/uLBpqelL/3jRjXZu9ZgNh6R2pzFauSobzq0lmbVl3RqZLA0n4a13CvBCYcbedfAwnjMwVMEh8L+LIa0GuOw==
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=Ixbx9zlBTaBWK5Jvzz85gTje+VwzmqT56hTTOd02jG0=; b=lrbm4AOJgwzjwv2Ra9AHlfz0Fyo+eS20QfL5WB4KlDtDMS/B+nU7Np4pApnFVVvYftFAifespuY3LAlPv/9KU4BPSy+ZHYpwFZPtEC5bGuCOn0qDWP7gHsI/rBc8NAnJDrlcpS1q5I5ru3J3zLGzYsUXgFxs5NI8WKhzvUlc4FvUEmhrMav80A4S3aDulQPBGBR/vz7kfD8M8kTh8QCdKNTfIDrUq2R5dXxcuhfOnaidmgizGv5Ad8aGeKSfnoDZX6gAazZq2lDzAmb/83Mmel61NpgnyqvIF8vp2OhE4Qe1Bu91M47iUXP/DFHmI8gzOVQtDpkMdcc0CgKIXXy+JA==
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=Ixbx9zlBTaBWK5Jvzz85gTje+VwzmqT56hTTOd02jG0=; b=wPfWbKl3hp+dhrpXAInFLQIkmtLt6FK/uclpCHDYV8uZmJvvEBc6rhQRMo2g5AM7H+b0v11EM5d54ee5E2b+HuVfz2EJKHrxoGxsc/MeSdcXSRJc0W6Fkoz3bk/ZELruVWhOHyvEjky/YREA0AxJFF998woP7uJFhchbUbKN69k=
Received: from SA0PR11MB4576.namprd11.prod.outlook.com (2603:10b6:806:97::10) by SN6PR11MB3086.namprd11.prod.outlook.com (2603:10b6:805:d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Sat, 15 Aug 2020 05:08:55 +0000
Received: from SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::b58e:83c8:5174:e727]) by SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::b58e:83c8:5174:e727%2]) with mapi id 15.20.3283.022; Sat, 15 Aug 2020 05:08:55 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Thomas.Graf@swisscom.com" <Thomas.Graf@swisscom.com>, "hannes@gredler.at" <hannes@gredler.at>
CC: "lsr@ietf.org" <lsr@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesAAduZCAAAG4RsA=
Date: Sat, 15 Aug 2020 05:08:55 +0000
Message-ID: <SA0PR11MB45763F383D707E5B6873963DC1410@SA0PR11MB4576.namprd11.prod.outlook.com>
References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400@MW3PR11MB4570.namprd11.prod.outlook.com> <2022615026.3001869.1597464620979@ss002889>
In-Reply-To: <2022615026.3001869.1597464620979@ss002889>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic
authentication-results: swisscom.com; dkim=none (message not signed) header.d=none;swisscom.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7b4ba8b7-9e23-49d7-b07e-08d840d94f62
x-ms-traffictypediagnostic: SN6PR11MB3086:
x-microsoft-antispam-prvs: <SN6PR11MB3086E5A2F9FA456B94742C1CC1410@SN6PR11MB3086.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RMCZ+skfPaBLozHC2HfncYNq84F1a7mXwmE7mTHAzL56hU1TAf6tlnvqYxwJsWH9t2OtN3bNoBl09gtPz2ZsD6mncTWhnNJz5t6Gck0XzHZ72vi997OE/Jg1sxLRfFlH3FIvfS7AFfaptEvwUTfGPNy8yoMMNt/qjqx1OPhv9HEQRRKdsgV9e6kkCWaks2JabdRF/0wh4pMJflw/vRbn3+eWrENdbRMObFOw83m2nUcV5G0nXeIlGZMcmFAuZg4/RYkW621xCnEMQNd70dOoxJzeU+XC6DhAZOYU7z5lCLKAY3bG2Nz5ORDf7dbfKYI8KAcfyJMLcTfB0UiKD060sy+9iDj/OeqSYAu4brvQUciMsZHDcmSroECkhKQpCpNDh0pDPNYD0odA/+yQs1PO2g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR11MB4576.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(33656002)(55016002)(186003)(110136005)(19627235002)(54906003)(9686003)(166002)(9326002)(71200400001)(6506007)(76116006)(966005)(2906002)(53546011)(66574015)(66946007)(86362001)(8936002)(64756008)(5660300002)(8676002)(4326008)(26005)(316002)(83380400001)(66476007)(66446008)(478600001)(66556008)(52536014)(7696005)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 2ohrc4sV0K/qUm1K9fsyr7P+LcoBOYkONvEd5h9+fQS8wn1xpdPNv/nE++kGnaixBp5XxuVfhlRn2XkMX4ll226k3vIigWiutBmYgStS0/lXod7CZhYX1142no8kjjXMuWXtUaU4DfK6lW38WUhjrEw14C9u9qySMT5vw8bSndI4sURiUPMObmpW/Jd+siDpTv2GnIhfxtSxyzEoH3ioH7F+jFtcKD9mSkNBTDrcthZD6dlZNidfSy62cjdYceUfGT9CjPf04wRkMAfT49eIpOiWema9bJ6ui9UWAI/M8jry9LgHip/9mCG5XT+fkhGeIREgaw8QIk9SnbO7C3gRrtq/mhcNunKQUkxx08geiZ7GgnzXGfOgetwYRpFq3W9gvNFSxfN04Vf3eL+1Nmm74IWViEVoNZZ0mhWLBwyCMgupTMLd/iDFxzoiPHEC6y6UZ/ucD5FORY8/rqkG04RXnN63PWuixFk2uZTJ7zWb28EKxgplOPl+vSrTgQzUcr/Pc4eYCJ4mwCVP8IxgL0tLrah0epMfcq2+pFXiAEIgak0z9FZtwkw4YX3BcWOI9zoY7yf5FJF9u/CgpJs+iCZfqje/6+qf03Nd95XLskCBga025MwP449OAn8yPGOGwRc8S3/og0ct1YuKZUJYoFqouQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SA0PR11MB45763F383D707E5B6873963DC1410SA0PR11MB4576namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR11MB4576.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4ba8b7-9e23-49d7-b07e-08d840d94f62
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 05:08:55.3797 (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: EtwGqiaTxrc8JdKNZaqZK6ibzpkuNGNEgi+kuKkV2jOvaG/Amz+0e5VmyoqQ+/RtsDrl7xECa1gqxIvMozYBrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3086
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qg0PgILDVdHhhIlp_KN6joeIWcE>
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Aug 2020 05:09:04 -0000

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type identifier registry:

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

This helps identification of specific SR-MPLS segment types as well as differentiating them from LDP, RSVP-TE, etc.

And my questions were:

  1.  What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?
  2.  What value is provided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?

I am asking for WG to weigh the implementation complexities and overheads with the proposed details of SR-MPLS segments in IPFIX against the benefit (if any) that they provide for the flow analysis and monitoring.

Thanks,
Ketan

From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Thank you very much for the review and feedback.


  *   What or how much value be there on determining whether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same prefix from different IGPs.

As Jeff already pointed out. Multiple IGP labelling protocols are used  in networks when migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom when we first discovered this shortcoming in vendor implementations. The key point here, with these additional IPFIX MPLS Label Type identifiers we enable the possibility to verify the label protocol migration without taking the label value into the consideration.


  *   IPFIX may be picking this information from a FIB in some implementation where the protocol does not matter and this information is not available therein.

I am not sure if you have seen the presentation in IETF 108 at OPSAWG and SPRING.
https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label Type identifier. There is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

I do understand your point that not all the vendors are capable to implement IE 46. But that's not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementation can refer to the right code point. With RFC 5102 the decision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends the IE 46 registry with the Segment Routing label protocol code points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX implementation can point to the right code point.


  *   On some nodes, the same Prefix SID may be learnt via both BGP and IGP - what would we use/show?

In this case the IE 46 shows the label protocol which was used to program the FIB.


  *   For that table proposal, it is very difficult and in some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements and we can be sure more get added.

I fully agree. As a network operator its still hard to understand the architecture and constraints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make sense. By purpose, all available SID types are listed in the draft. This with the aim to start the discussion in the working groups what is possible what makes sense. I would be interested to get your and also Jeff's feedback.

In above mentioned slides I described how TI-LFA application would benefit of visibility in the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which label protocol was used to forward a particular packet, but also which SID type to further understand the intend why this label is being pushed.

I hope this makes all sense. Looking forward for reply.

Best wishes
Thomas

From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>>; hannes@gredler.at<mailto:hannes@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

< also copying Spring WG for their review/inputs >

Hi Thomas/All,

I have reviewed the draft and would like to share a different perspective.

What or how much value be there on determining whether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same prefix from different IGPs. IPFIX may be picking this information from a FIB in some implementation where the protocol does not matter and this information is not available therein.

On some nodes, the same Prefix SID may be learnt via both BGP and IGP - what would we use/show?

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peering SID and so on ... for the MPLS Label Type.

This also takes away the need for the second table that is being proposed to a large extent. For that table proposal, it is very difficult and in some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements and we can be sure more get added. Is there really much value in differentiation between say an Adjacency SID and LAN Adjacency SID?

Could we evaluate the implementation overhead and complexity of this level of categorization/information in IPFIX against their value in flow analysis to perhaps consider a middle ground?

Thanks,
Ketan

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>
Sent: 31 July 2020 20:52
To: hannes@gredler.at<mailto:hannes@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for the next update..

Best Wishes
Thomas


From: Hannes Gredler <hannes@gredler.at<mailto:hannes@gredler.at>>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Thomas,

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

Please add also a code point for BGP Prefix-SID - it's quite popular in DC deployments.
https://tools.ietf.org/html/rfc8669<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8669&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200615130&sdata=Fp1WH4uMm3oxp8GGzt3IfexyzHzflHA3FC5QE5DixBk%3D&reserved=0>

thanks,

/hannes

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com> wrote:

Dear lsr,

I presented the following draft

Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-type-04&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=q9GCxkzGIMx9p4WsXwITL4t1GMaP6dj6H4gu7hJAROY%3D&reserved=0>

at the spring working group at IETF 108 yesterday
https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-spring-ip-flow-information-export-ipfix-00.pdf&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=%2FNT6dZ%2F6vsv69oW3g3iirmzygDI4UPn7a2VyGkwYCYo%3D&reserved=0>

and today at OPSAWG where I call for adoption.

This draft adds additional segment routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

I have been asked to not only gather feedback from spring and opsawg but also from lsr and mpls working groups since these code points are related to link state routing protocols and mpls data plane.

I am looking forward to your feedback and input.

Best Wishes
Thomas Graf
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200635044&sdata=TsgdeCEH3Y5f%2BeHrPpANrK%2Bl5qT2TfSre2rPJZvoOuQ%3D&reserved=0>