Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

"Acee Lindem (acee)" <acee@cisco.com> Wed, 29 July 2020 11:07 UTC

Return-Path: <acee@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 E932A3A09BA for <lsr@ietfa.amsl.com>; Wed, 29 Jul 2020 04:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=SH6cqsbG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OUnfETMG
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 IrXZVBbCwF5u for <lsr@ietfa.amsl.com>; Wed, 29 Jul 2020 04:07:45 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DBC3A0B51 for <lsr@ietf.org>; Wed, 29 Jul 2020 04:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34669; q=dns/txt; s=iport; t=1596020854; x=1597230454; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OABn0Rz2IUM65GXRkftAq5jbmAZ63gVRw/OwVVEKHik=; b=SH6cqsbGyIHJ8GRvg/JPHxby0iK/DP7oFLzqxeUVlOsU9TQEdqklYfbM AcjNV9YAO/htZqIiKrvV2+TfuUHNf8rUkvLAw+7jwt11EC1P/SLwrKrWe yS5oiZyhl1wE7PGGdqCXW0XEuJpUw+0IYqV2gad6N0+djpiabS2xhBoM3 Y=;
IronPort-PHdr: 9a23:zPfRwB1azHX9Tkq9smDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWGu6dillLFWYjBrftY2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdPFcr6akeUq2HhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DdAQA6VyFf/4UNJK1gGwEBAQEBAQEBBQEBARIBAQEDAwEBAYIKgSMvIy4Hb1gvLAqEK4NGA41OgmmHGY5fglMDVQsBAQEMAQEYAQoKAgQBAYRMAheCDAIkOBMCAwEBCwEBBQEBAQIBBgRthS8HJgyFcQEBAQQBARARHQEBLAsBDwIBBgIRAwECIQMEAwICAiULFAkIAgQBDQUbB4MEAYF+TQMuAQ6Se5BoAoE5iGF2gTKDAQEBBYUYGIIOAwaBOAGCbINchSCBHhqCAIE4HIF9UD6CGkIBAYFHOBaCYDOCLY9XBoMThl2LVpAXTgqCX48ahWuEeAMVCYJ7iUuTLpIgjROSCwIEAgQFAg4BAQWBaiOBV3AVOyoBgj5QFwINhyCGfjeDOoUUhUEBdDcCBgEHAQEDCXyOWwGBEAEB
X-IronPort-AV: E=Sophos;i="5.75,410,1589241600"; d="scan'208,217";a="787843555"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 11:07:30 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TB7UW5008622 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 11:07:30 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 06:07:29 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 06:07:29 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 06:07:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a0fJQ4S+3xHDDpqciCUp4ZCTv1eC6LDMZ0FVunCtRCJCCQYyk1/5awqX1mE8l30OlvejIQK2ccFh52YGH71WWV/3gMBtHbHZrIYXBZkPpiPuliKmqa/l1Hby9I7W4RFURSKv2x/EyCf0+8BoHyTfwkfcWx2LRQI9DA2z6CHV/OwcErQcGGlV1TrqSupREGEum0Jp6HBUCZ8PTI7jOA1YSaed42dCyc9cvj7xewbpbJyO5/PF9cehzqJHesl0dN6tGMQ50RwilIAkN6CvQN5a/5YE+ORa3QjvTzRcckJVWfl9X6dG9sgQx4W6ZG7N8FrxjyWWiwVfbJ3SwAWU31wYLg==
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=OABn0Rz2IUM65GXRkftAq5jbmAZ63gVRw/OwVVEKHik=; b=BRvFJMhBxGLjx226Hth6EzkQjBgSw9u4rEJ6ASgzQ74nLGj2Lq0o2sZGkTnpITW43O+W5OWUmXQpVDjE6wfcN4H/GjEpgeQWSaHkLjDD2VvgL/Mg6/Yx2eD3aT9eigsNnzevqCCRFAhaSwT3cQ27l+DYzvRUGbbnkbdDlXoq56d9OB7QrLLwwHofDuCaaebzXRvbJWk4/Cs+9SjA9FldwVYeQ9WP3kf3krOnlXv53MfiWcLjXbx05o2qHCIeePgFk/UA3G3r370JxTE+/2g10PQbuOKaK7WkbAy/sWWGRSZrFfCYyLxhKFeIPJSFkH22OQu6tn27Q/GZfjdVMgVqoQ==
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=OABn0Rz2IUM65GXRkftAq5jbmAZ63gVRw/OwVVEKHik=; b=OUnfETMGJHs5ApryqMw+W3lkmv3N8CyJMuOekheNBlp4MEckj62rRPVLUGaw64c8lSOKUxeJ1zHR9RmnpMEvseFy3ZNJb3G0kTXxa9W696vwI2wEwZYPvi+bC6WHJ0RKajB+Ud97Abt3TmywRo1za/c8CDKZEE2YT8igX2rxYHc=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2773.namprd11.prod.outlook.com (2603:10b6:a02:c6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 11:07:27 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b%7]) with mapi id 15.20.3216.033; Wed, 29 Jul 2020 11:07:27 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Hannes Gredler <hannes@gredler.at>, "liu.yao71@zte.com.cn" <liu.yao71@zte.com.cn>
CC: "zzhang_ietf@hotmail.com" <zzhang_ietf@hotmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02
Thread-Index: AQHWZXfVc5RpkN8FoUqXeP/PiNf/x6keIuQA
Date: Wed, 29 Jul 2020 11:07:27 +0000
Message-ID: <E63F7A23-064B-450A-B954-1B6EABA61A31@cisco.com>
References: <E58BB9C0-2E74-4924-8117-4D35E534245A@cisco.com> <202007290957472639201@zte.com.cn> <2F45340B-C97C-4C30-BDAF-DB37998EA652@gredler.at>
In-Reply-To: <2F45340B-C97C-4C30-BDAF-DB37998EA652@gredler.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: gredler.at; dkim=none (message not signed) header.d=none;gredler.at; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: de809cc2-4420-44f0-f9b7-08d833af9457
x-ms-traffictypediagnostic: BYAPR11MB2773:
x-microsoft-antispam-prvs: <BYAPR11MB2773F33F2C004C79886A0069C2700@BYAPR11MB2773.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FUHVJNVeFK50W2Yauy3OKurLyL+kDRlg4vD4yXMFngpNRT1fU4U074RDEQQmENex7EbUmEo7Bsbg2FJUjd5S2JoRb0CYEmNUTyNXxAtfDe76DY9tG4NEM76y3fNEjVDIo4SzkGU9oYvTHHuB/cTHhhgPUZA0McNCELmttKJX5Gfsy6Q6Qb2im3WTlBKGliGnImvWV+vbrnquE4FalOp3Aje3CsdParDLc8zYODWIPQUakMKNFvyyWdW0M54LoX4d3nqeZUjZU+3xOenuFfGq/d8kKPHBzldEA7AVpTrpLsGy1igkHSlhRF97RBiP7uvDdY2ME803M/upB4AIMwyhHEwlhJuHxCCqlxXWVcPVPrR0fiQYpWaItNraKU2ld8WgmLQY8SdTFcE7mcQFFX1rOw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(26005)(83380400001)(66946007)(8936002)(6512007)(64756008)(66476007)(66556008)(2906002)(91956017)(66446008)(76116006)(45080400002)(966005)(8676002)(478600001)(186003)(6506007)(316002)(2616005)(6486002)(54906003)(71200400001)(110136005)(5660300002)(4326008)(86362001)(53546011)(33656002)(36756003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LAFwlMHA50eaDEgFs2KDB2bW6elObmEfWbCQ3oNy5qYu/XWFoUHg29CsgUkRfNTfRqPldD3qx7WcVJ5bhJ9Onu1mCUqn5LUydR4Bx08x8SG+M4TO7xvzbKFRdak1tvHhkfUQoBilYm61q/QxyYWTKbDXFKJwiW9Y/hzvFpjAqQhyV13LOIkKtrq7F5TbPTHjrePngyEhwcZ4efZsOxjl3ZJWyPGvfvdxMcKbJBEpaisjI75my86AfVucHpXQMIlQkUxtrq970o8jAETifNpxbM+DqKVXPAREkevqMksMBCGtAjrGH+sRv75YvnNx6gAW9qb9OOA69H5Rl8SPDBHm7cLLoII/jiFSLtTcrFP9Y3UfcFrHHHZEcDpQak/hT5cys6xLycsid4BKQpWzvvdla0xTxejm306HqvoaPOrgc2kEKDWu25LxcZp0A05a6XT6fzw8dqiLWk5J9nOYrPPEAhn9SREjUrOlLSGoHLmrPIJBDhGin0B7YcxyH4ifrrZ4
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E63F7A23064B450AB9541B6EABA61A31ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: de809cc2-4420-44f0-f9b7-08d833af9457
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 11:07:27.2982 (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: 747n1tWu6bAjAjtq70WWUf5TIJLtWS/GXPGHPDQLqRua+UOsa+KoJ/CiOBKQ5+oC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2773
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UCJESn3oEfrz9FzRX0nh_x_S3A8>
Subject: Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02
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: Wed, 29 Jul 2020 11:07:54 -0000

Thanks Hannes – this is exactly what I was suggesting rather than advertising the BGP-LS information in the IGPs.
Acee

From: Hannes Gredler <hannes@gredler.at>
Date: Wednesday, July 29, 2020 at 3:14 AM
To: "liu.yao71@zte.com.cn" <liu.yao71@zte.com.cn>
Cc: Acee Lindem <acee@cisco.com>, "zzhang_ietf@hotmail.com" <zzhang_ietf@hotmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

Yao,

BGP-LS was designed to solve also the distribution of link-state information between BGP speakers (see Figure 1 from RFC 7752 below).
Just ask yourself: why would one want to use a point to multipoint state replication protocol as complex as BGP for *just* client server alike replication ?

We wanted from day-1 to leverage the graph independent replication abilities of BGP - so doing inter BGP-LS graphs is a legit use-case.

HTH,

/hannes

---



   The collection of link-state and TE information and its distribution

   to consumers is shown in the following figure.



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

                           | Consumer  |

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

                                 ^

                                 |

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

                           |    BGP    |               +-----------+

                           |  Speaker  |               | Consumer  |

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

                             ^   ^   ^                       ^

                             |   |   |                       |

             +---------------+   |   +-------------------+   |

             |                   |                       |   |

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

       |    BGP    |       |    BGP    |             |    BGP    |

       |  Speaker  |       |  Speaker  |    . . .    |  Speaker  |

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

             ^                   ^                         ^

             |                   |                         |

            IGP                 IGP                       IGP



           Figure 1: Collection of Link-State and TE Information

---


On 29.07.2020, at 03:57, liu.yao71@zte.com.cn<mailto:liu.yao71@zte.com.cn> wrote:

Hi Acee,
Thanks for reading the draft.
Yes, the main purpose of this draft is to carry the segment segment information via IGP so only one node per AS need to be connected with the controller through BGP-LS.
With the existing BGP-LS extension draft, it is certainly one solution to configure BGP sessions between all the service function nodes and controller, and each node sends the SF information to the controller individually.
And if I get you right, we can also select one node to have a BGP session with the controller and configure BGP sessions between the selected node and SF nodes.
But how the selected node get the SF information from SF nodes via BGP needs to be solved, since BGP-LS is typically used for exchanging information between the south and north rather than nodes of the same level, and there's no other existing BGP extension for distribute SIDs information between nodes .
This draft aims to provide an alternate way if the operators prefer running IGP on SF nodes.
So we would like to collect comments on the WG session to see how others think about it.

Regards,
Yao



原始邮件
发件人:AceeLindem(acee) <acee@cisco.com<mailto:acee@cisco.com>>
收件人:刘尧00165286;zzhang_ietf@hotmail.com<mailto:zzhang_ietf@hotmail.com> <zzhang_ietf@hotmail.com<mailto:zzhang_ietf@hotmail.com>>;
抄送人:lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>>;
日 期 :2020年07月29日 01:53
主 题 :"IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02
Speaking as WG member:

It seems the sole purpose of this draft is to get service segment information from nodes in the IGP domain to the IGP node that has a BGP session with the controller. You don’t need to put this information into the IGP in order to do this. Simply configure BGP sessions for the BGP-LS AF between the nodes with service functions and the node selected to have a BGP session with the controller.

Speaking as WG Chair – please let me know if we can omit this draft from the agenda.

Thanks,
Acee

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr