Re: [spring] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

Adrian Farrel <adrian@olddog.co.uk> Sun, 15 November 2020 12:04 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0BD3A1120; Sun, 15 Nov 2020 04:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 HzfxsLQloNrk; Sun, 15 Nov 2020 04:04:48 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 3494D3A112B; Sun, 15 Nov 2020 04:04:44 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AFC4f3f006034; Sun, 15 Nov 2020 12:04:41 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5FE6122048; Sun, 15 Nov 2020 12:04:41 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 499B922044; Sun, 15 Nov 2020 12:04:41 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.234.140]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AFC4dpW024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Nov 2020 12:04:39 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Gyan Mishra'" <hayabusagsm@gmail.com>
Cc: "'TEAS WG'" <teas@ietf.org>, <pce@ietf.org>, "'IDR List'" <idr@ietf.org>, "'lsr'" <lsr@ietf.org>, "'BESS'" <bess@ietf.org>, "'BIER WG'" <bier@ietf.org>, "'SPRING WG'" <spring@ietf.org>
References: <CABNhwV2hACuvVJxQVihP2ejfq1NHKOwxHLCq=_o9DgoWBZag=w@mail.gmail.com>
In-Reply-To: <CABNhwV2hACuvVJxQVihP2ejfq1NHKOwxHLCq=_o9DgoWBZag=w@mail.gmail.com>
Date: Sun, 15 Nov 2020 12:04:38 -0000
Organization: Old Dog Consulting
Message-ID: <00d501d6bb47$7ee160a0$7ca421e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01D6BB47.7EE27210"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF9YbXHIOSWBk8yeY9fu/naMBX0B6p7sJrg
Content-Language: en-gb
X-Originating-IP: 87.112.234.140
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25790.007
X-TM-AS-Result: No--14.922-10.0-31-10
X-imss-scan-details: No--14.922-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25790.007
X-TMASE-Result: 10--14.921600-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMyx4Q5iE/G4VXFPUrVDm6jtrkGhd90/DD6ysPB8dBBorQkt GlyfnEqw/hPqYBjXRvrPRQhYb82CUWsWrPYGNN4DW4uRcqTgBLkDxXNNkwM2slY9yet6QEd8gXF 85i45Zx5Tycok6DUSPnBV0D37nd4oZb4YJkoMChswiJTf3kjwfauRJbBnR9QZE4klva9z5JyCdz yKMpTh4n0GH8UPE5XGeeOhgmVGz4sS887lpka72zCj6xe3SuezzwGOnesXThUDE8ggmrXnNIE/v INhyffjbALKww3fgKQ+IJsxz6/MG3PH+Ely1RppPE3khmVvHO5rakICcm9AUWNDqjXOO0YeCPIv P3uOlZdZMihSZb4ZQBFBD6+ejtliafdXgMs+pqB2GcWKGZufBQ4m7nrLKGA2JHwDAsNOgHhYXKg fzjvaWW342qvQHtJUfzzZvLDv3Oa2F9mW29B7siT9vTe4FHdQh8Ytn75ClDNhlbn6/nmOL9SE+o oSMqbWa2yjxi6DegzSPy86eVaxBAZzDl2stMKuzLo88rvlvYHR/CLTQxTQNLKeTtOdjMy6Y02UY ybf3M77zimhwE/anR6mA7svqvZCjlwExZ+3TSZfYa9W9OjitdZvZ5Gv+ByDw62uSG5kL1aNLo7J HtqcJUMJm1dGoan80AAsttmoS5lQdboikf/uEGwTEruL9ObTIfyQNHR2naZd9fDYSm945TdZExW GZtg3vRozbZIuTOAuNvTj5Xfp1u3FFtXLEvOmwP5c8K0bHlchjEPz8ZIh1hlLPW+8b7SaCSqvzM Gx6vFvy64TFAGuDliSlwChW1m5XC8g0bRla6SeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyJck9lvx NcntWLHjeGkjh9XKzfM9B6IRt7+efAnnZBiL0OAfBu/XeE86LVkcqC+5HQYK8bS5pq70eGEvXqw fEwp6gc/7grXMri0yp4Dr5imaJLC9paZso429IKhPJLZpaVAdYFEV4Px7Pv1leB13UrM
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/W6eNoVgiVXaSUX5voifZt-Oy_Hk>
Subject: Re: [spring] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2020 12:04:51 -0000

Hi Gyan,

 

Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot of lists :-).

 

> I have noticed that after reviewing many drafts across many WGs it seems in the

> industry that the lines seem to be blurred between a PCE controller, ODL or

> Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X

> provisioning.

 

Yes, blurriness our speciality.

 

You my find RFC 7491 useful in this respect, although it is a little dated. And, of course, RFC 8283 is a good starting point.

 

> As this is a software sitting on a server you can have a swiss army knife server that

> does everything from PCE path computation to  Netconf/Yang ZTP & Day N 

> provisioning as well as any SDN Controller ODL or Openflow controller type

> functions as well.

 

Yes, and this is one of the risks of PCE as a shiny thing: that it be converted from a useful toolkit into some form of god-box. I pontificated on this way back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf

 

> How this comes into play and realization of the lines being blurred is the use of

> BGP-LS in building the IGP topological graph of the network which was designed

> for PCEP and PCE & PCC active & passive off line path computation for both

> RSVP-TE or SR-TE path instantiation.  

 

In some senses, BGP-LS didn’t add anything because a PCE could have snooped on the IGP. But BGP-LS provides an export mechanism and importantly adds to that some policy filters to determine what is exported thus giving the network some control over what is exported.

 

FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ proposes using PCEP for the same function. The argument in favor is that a PCE has to implement PCEP anyway, so why not include the LS export as well. The argument against is that BGP-LS has wider applicability and that it will typically be exported from an ASBR which already supports BGP.

 

> However now BGP-LS can also be used for other functions now such as usage as

> I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to

> gather the elements internals within BIER using the same BGP-LS data structures

> to populate with BIER specific information to graph the BIER topology.  So here

> we are not doing any path computations as we are using in this use case  for

> NMS type function to gather data for ZTP & Day N provisioning.

> 

> Similarly other use cases such as with TEAS TS-Transport slice and being able

> to provision TS and capturing the TS Enhanced VPN RT & resource information

> and leveraging BGP-LS to do the same data gathering & ZTP like controller style

> provisioning. 

 

Is there a fundamental difference between ZTP & Day N provisioning and path computation for traffic engineering provisioning? It’s all determining how to configure the network to best carry traffic.

 

> It does seem as though BGP-LS as its a means of "data gathering" "dump truck"

> of anything with the kitchen sink included to build any type of topological graph

> of literally anything under the sun.

 

Remembering Yakov Rekhter saying you could use BGP to transport Shakespeare. 

This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, further use gets made.

 

BGP-LS was intended to export routing information “northbound” from the network.

 

> I see that is a nice to leverage but it does in fact blur the lines of NMS Netconf/Yang

> Controller based functionality and  PCE path computation functionality and SDN

> controller based ZTP functionality into a single ubiquitous server that can do all of

> the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It does however

> transform BGP to be an NMS tool but a "tool" and not just the original function

> which it was intended NLRI network reachability.

 

Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.

I might argue that BGP distributing policies from installation on PEs is an NMS protocol.

 

> Am I off base and please let me know as its BGP-LS is being way over leveraged. 

> There are pros & cons to everything but I thought I would bring up to the WG as

> an important discussion point.

 

Who are we to argue with real implementations? Assuming that there is a push for implementation and deployment, then the thing to look for is “harm”. Does this use of BGP-LS cause harm, sow confusion, risk destabilising the network? Should it use a different code point to be distinguishable?

 

I think the argument that “there is already another protocol for doing this” is worth examining. But we have to be careful that it doesn’t get us stuck, or force everyone to do something they don’t want to do. After all, we could carry any protocol message using Netconf/YANG, but we don’t do “RSVP-TE over Netconf”.

 

Best,

Adrian