Subject: [spring] Managing "global" SIDs

From: Kireeti Kompella <[email-masked]>
Date: Wed, 24 Jul 2019 10:55:15 -0400

Hi All,

Two questions:
a) should the SPRING WG work on ways to manage global SIDs of various types?
b) if yes, what is the best-suited protocol to do this?  I suggested DHCP;
others have suggested PCEP, SRMS, LISP mapping, etc.

-- 
Kireeti

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 17:09:01 +0200

Hi Kireeti,

I would like to challenge a bit your fundamental assumption which is to
state that while loopbacks are very important and locally significant and
warrant manual/nms provisioning SIDs are not.

Well let me clarify - SIDs are NOT MPLS labels (regardless if we think
local MPLS labels or global/domain wide MPLS labels). So I am of the
opinion that provisioning at least node SIDs should be an NMS function.

If I am building my path segment chain my abstraction to uniquely identify
nodes it traverses may just use SID abstraction without need of mapping
loopbacks to SIDs. Mapping is good, but too much mapping is not a feature.

Perhaps for other SID types some way of mapping is OK .. and such mapping
has been already implemented in SR controllers so why do we need a new
mechanism here for that?

Thx,
R.

On Wed, Jul 24, 2019 at 4:55 PM Kireeti Kompella <[email-masked]>
wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 24 Jul 2019 11:36:16 -0400

Hi Robert,

> warrant manual/nms provisioning SIDs are not.

Actually, what I said at the mike is that I believe that both loopbacks and
global SIDs should be managed by DHCP.  But that's a distraction; the point
at hand is whether global SIDs should be managed "manually" (or by NMS or
equivalent) (i.e., static), or by a protocol (say DHCP) (i.e., dynamic).
You say the former ... thanks for the feedback.

 --
Kireeti

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Jul 2019 15:52:59 +0000

Robert, Kireeti and all,
I think that both loopbacks and their association with SIDs should be kept persistent.

Whether such persistency is provided by the means of static configuration, or by the means that are external to some dynamic protocol is a different question.
E.g., a “normal” DHCP client (like my office computer) may think that it obtains a dynamic IP address in the company network from the DHCP server every time I turn it on, but the DHCP server actually takes care to assign to it the same IP address every time.

Does this help in any way?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring <[email-masked]> On Behalf Of Kireeti Kompella
Sent: Wednesday, July 24, 2019 6:36 PM
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] Managing "global" SIDs

Hi Robert,

On Wed, Jul 24, 2019 at 11:09 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kireeti,

I would like to challenge a bit your fundamental assumption which is to state that while loopbacks are very important and locally significant and warrant manual/nms provisioning SIDs are not.

Actually, what I said at the mike is that I believe that both loopbacks and global SIDs should be managed by DHCP.  But that's a distraction; the point at hand is whether global SIDs should be managed "manually" (or by NMS or equivalent) (i.e., static), or by a protocol (say DHCP) (i.e., dynamic).  You say the former ... thanks for the feedback.

 --
Kireeti

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 24 Jul 2019 12:38:00 -0400

Sasha,

Most "normal" DHCP servers require manual configuration of some sort if you
want to guarantee persistence of the assigned IP address (i.e. "static"
DHCP). So we're back to "manual" management, even if the results of the
manual management are conveyed by a dynamic protocol.

Cheers,
Andy

On Wed, Jul 24, 2019 at 11:53 AM Alexander Vainshtein <
[email-masked]> wrote:

> Robert, Kireeti and all,
>
> I think that both loopbacks and their association with SIDs should be kept
> *persistent*.
>
>
>
> Whether such persistency is provided by the means of static configuration,
> or by the means that are external to some dynamic protocol is a different
> question.
>
> E.g., a “normal” DHCP client (like my office computer) may think that it
> obtains a dynamic IP address in the company network from the DHCP server
> every time I turn it on, but the DHCP server actually takes care to assign
> to it the same IP address every time.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Kireeti Kompella
> *Sent:* Wednesday, July 24, 2019 6:36 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* SPRING WG List <[email-masked]>
> *Subject:* Re: [spring] Managing "global" SIDs
>
>
>
> Hi Robert,
>
>
>
> Actually, what I said at the mike is that I believe that both loopbacks
> and global SIDs should be managed by DHCP.  But that's a distraction; the
> point at hand is whether global SIDs should be managed "manually" (or by
> NMS or equivalent) (i.e., static), or by a protocol (say DHCP) (i.e.,
> dynamic).  You say the former ... thanks for the feedback.
>
>
>
>  --
>
> Kireeti
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 19:54:21 +0200

So if you have to manually configure it what is the point to introduce
another layer of dependency ?

Moreover let's please keep reality check in mind where in a lot of networks
DHCP servers are managed by application folks which is completely different
org then networking people.  Now good luck going and telling server folks
what is SID and that they need to program static bindings for DHCP
management system every time such need arise in network group :)

Cheers,
R.

On Wed, Jul 24, 2019 at 6:38 PM Andrew G. Malis <[email-masked]> wrote:

> Sasha,
>
> Most "normal" DHCP servers require manual configuration of some sort if
> you want to guarantee persistence of the assigned IP address (i.e. "static"
>> I think that both loopbacks and their association with SIDs should be
>> kept *persistent*.
>>
>>
>>
>> Whether such persistency is provided by the means of static
>> configuration, or by the means that are external to some dynamic protocol
>> is a different question.
>>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 24 Jul 2019 13:55:41 -0400

Hi Kireeti,

Just as a data point for comparison, the drafts in PCE WG were discussed in
the past. As part of use of PCE as a central controller PCECC (RFC 8283)
work items -

https://tools.ietf.org/html/draft-zhao-pce-pcep-extension-pce-controller-sr-05
https://tools.ietf.org/html/draft-dhody-pce-pcep-extension-pce-controller-srv6-01

The focus was on the controller to instruct the node with the SID
allocations when the controller learns about the existence of node and the
PCEP session is in place. We could also evaluate a request/reply from the
node as well if that approach is required.

Thanks!
Dhruv

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 Jul 2019 14:02:02 -0400

All of the tasks described belong in management plane, while I’m not particularly fond of using DHCP, having single source of truth for configurational state is better than configuring box by box (and excel to manage it :))
Most SP’s (and as Stephane alluded) already have a centralized management entity that takes care of configuration management and soft resource (such as IP’s, SID’s, RT/RDs, etc allocation.

Cheers,
Jeff
On Jul 24, 2019, 12:38 PM -0400, Andrew G. Malis <[email-masked]>, wrote:
> Sasha,
>
> Most "normal" DHCP servers require manual configuration of some sort if you want to guarantee persistence of the assigned IP address (i.e. "static" DHCP). So we're back to "manual" management, even if the results of the manual management are conveyed by a dynamic protocol.
>
> Cheers,
> Andy
>
>
> > On Wed, Jul 24, 2019 at 11:53 AM Alexander Vainshtein <[email-masked]> wrote:
> > > Robert, Kireeti and all,

---

From: vahid tavajjohi <[email-masked]>
Date: Wed, 24 Jul 2019 22:55:27 +0430

Hi all,

I think each vendor will uses its own NMS. So, it can’t be easy to manage global SID allocation with multi-vendor environment alongside multi-NMS. Therefore, PCE (standard) is better choice.

Regards,
Vahid

[email-masked]

> On Jul 24, 2019, at 10:32 PM, Jeff Tantsura <[email-masked]> wrote:
> 
>> On Wed, Jul 24, 2019 at 11:53 AM Alexander Vainshtein <[email-masked] <mailto:[email-masked]>> wrote:
>> Robert, Kireeti and all,
>> 
>> Email:   [email-masked] <mailto:[email-masked]>
>>  
>> 
>> From: spring <[email-masked] <mailto:[email-masked]>> On Behalf Of Kireeti Kompella
>> To: Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>> Cc: SPRING WG List <[email-masked] <mailto:[email-masked]>>
>> On Wed, Jul 24, 2019 at 11:09 AM Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Kireeti,
>> 
>>  
>> 
>> Actually, what I said at the mike is that I believe that both loopbacks and global SIDs should be managed by DHCP.  But that's a distraction; the point at hand is whether global SIDs should be managed "manually" (or by NMS or equivalent) (i.e., static), or by a protocol (say DHCP) (i.e., dynamic).  You say the former .... thanks for the feedback.
>> 
>>  
>> 
>>  -- 
>> 
>> Kireeti
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 24 Jul 2019 15:33:55 -0400

Sasha,

Yes, this helps, but let’s separate persistent and deterministic.  (The latter is probably better terminology than “static” and “dynamic”.)  Deterministic means the operator knows a priori what SID stouter will get.  

DHCP servers support persistence (my phone gets the same IP, even after being away for several hours).  This doesn’t require configuration.

DHCP also allows for determinism, to Andy’s point.  That requires lots of configuration.

A simple reply to the list on whether or not you believe that global SIDs need to be persistent and/or deterministic would be helpful to hone in on the best protocol for allocation.

So far, the count is, 1 for persistent but not necessarily deterministic (me), 1 for persistent and deterministic (Robert).

Kireeti

> On Jul 24, 2019, at 12:38, Andrew G. Malis <[email-masked]> wrote:
> 
> Sasha,
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 22:04:15 +0200

Hey Kireeti,

Just one observation on your informal pool :)

> So far, the count is, 1 for persistent but not necessarily deterministic
(me), 1 for persistent and deterministic (Robert).

As deterministic really requires persistence, a better pool would be to
just see who thinks SIDs need to be deterministic or not.

And with that if you are doing such pool it may make sense to ask for this
separately for node SIDs vs adj SIDs vs other locally significant SIDs.

Putting all such SID types into one basket may not result in meaningful
survey :)

To restate my opinion was that node SIDs should be deterministic and
provisioned by given network's NMS system of the local choice. In the case
of SRv6 node SID maybe it's loopback's address.

Adj. SIDs IMHO could be algorithmically derived.

Special app/use SIDs - hard to tell as it really depands on the use case.

Cheers,
R.

On Wed, Jul 24, 2019 at 9:34 PM Kireeti Kompella <[email-masked]>
wrote:

> Sasha,
>
> Yes, this helps, but let’s separate *persistent* and *deterministic.  *(The
> latter is probably better terminology than “static” and “dynamic”.)
>  Deterministic means the operator knows a priori what SID stouter will get.
>
>
> DHCP servers support persistence (my phone gets the same IP, even after
> being away for several hours).  This doesn’t require configuration.
>
> A simple reply to the list on whether or not you believe that global SIDs
> need to be persistent and/or deterministic would be helpful to hone in on
> the best protocol for allocation.
>
> So far, the count is, 1 for persistent but not necessarily deterministic
> (me), 1 for persistent and deterministic (Robert).
>
> Kireeti
>
>> <[email-masked]>
>>
>>
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 Jul 2019 16:04:56 -0400

Vahid,

I think (sincerely hope) you are wrong, there’s a reason we have spent last 7 or so years working on YANG.

Cheers,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 22:21:15 +0200

Jeff,

> I think (sincerely hope) you are wrong, there’s a reason we have spent
last 7 or so years working on YANG.

Even if in the perfect universe all devices would support Yang models
uniformly - customers are still going to use their private NMS systems
except instead of CLI or xml as NNI to network elements they will use YANG
models.

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 Jul 2019 16:29:12 -0400

Robert,

Sure, my point was that you won’t need a “NMS per vendor” and hence a need to agree on control plane protocol (PCEP). Abusing control plane for configuration… been there :)
Specifically to PCEP point - PCEP creates ephemeral state, (not persistent across reboots), and hence rather unsuitable for configuration.

Cheers,
Jeff
On Jul 24, 2019, 4:21 PM -0400, Robert Raszuk <[email-masked]>, wrote:
> Even if in the perfect universe all devices would support Yang models uniformly - customers are still going to use their private NMS systems except instead of CLI or xml as NNI to network elements they will use YANG models.
>
> r.
>
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 22:35:00 +0200

> Sure, my point was that you won’t need a “NMS per vendor”

I don't know any network which would use "NMS per vendor" today. In fact
the entire reason to develop your own NMS is to have your own interface to
the network provisioning to be vendor agnostic.

Best,
R.

On Wed, Jul 24, 2019 at 10:29 PM Jeff Tantsura <[email-masked]>
wrote:

> Robert,
>
> Sure, my point was that you won’t need a “NMS per vendor” and hence a need
> to agree on control plane protocol (PCEP). Abusing control plane for
> configuration… been there :)
> Specifically to PCEP point - PCEP creates ephemeral state, (not persistent
> across reboots), and hence rather unsuitable for configuration.
>
> Cheers,
> Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 Jul 2019 16:36:43 -0400

some disagree:

"Hi all,

Regards,
Vahid
"

Cheers,
Jeff
On Jul 24, 2019, 4:35 PM -0400, Robert Raszuk <[email-masked]>, wrote:
> I don't know any network which would use "NMS per vendor" today. In fact the entire reason to develop your own NMS is to have your own interface to the network provisioning to be vendor agnostic.
>
> Best,
> R.
>
> > On Wed, Jul 24, 2019 at 10:29 PM Jeff Tantsura <[email-masked]> wrote:
> > > Robert,
> > >

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Jul 2019 22:41:25 +0200

Jeff,

Please re-read my msg :)

I said that regardless what vendors will offer - those who actually run the
network will have their own *single* NMS to configure it in a fully vendor
independent way.

Take care,
R.

On Wed, Jul 24, 2019 at 10:36 PM Jeff Tantsura <[email-masked]>
wrote:

> some disagree:
>
> "Hi all,
>
> I think each vendor will uses its own NMS. So, it can’t be easy to manage
> global SID allocation with multi-vendor environment alongside multi-NMS.
> Therefore, PCE (standard) is better choice.
>
> Regards,
> Vahid
> "
>
> Cheers,
> Jeff

---

From: vahid tavajjohi <[email-masked]>
Date: Thu, 25 Jul 2019 02:11:18 +0430

Jeff and Robert,

Yes, I agree with you but I am still seeing networks that uses multi-NMS(in my region). So, my point is it will be better to provide options that customers decide about it depend on their network not strict option. NMS, PCE, YANG, and etc. SID allocation are all options that needs to be in market.

Regards,
Vahid

> On Jul 25, 2019, at 1:11 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff,
> 
> Please re-read my msg :) 
> 
> I said that regardless what vendors will offer - those who actually run the network will have their own *single* NMS to configure it in a fully vendor independent way. 
> 
> Take care,
> R.
> 
> On Wed, Jul 24, 2019 at 10:36 PM Jeff Tantsura <[email-masked] <mailto:[email-masked]>> wrote:
> some disagree:
> 
> "Hi all,
> 
> On Jul 24, 2019, 4:35 PM -0400, Robert Raszuk <[email-masked] <mailto:[email-masked]>>, wrote:
>> 
>> On Wed, Jul 24, 2019 at 10:29 PM Jeff Tantsura <[email-masked] <mailto:[email-masked]>> wrote:
>> Robert,
>> 
>> On Jul 24, 2019, 4:21 PM -0400, Robert Raszuk <[email-masked] <mailto:[email-masked]>>, wrote:
>>> Jeff,
>>>