Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

["Adrian Farrel" <[e-mail]>]

Robert, 

 

Coincidence is a mighty thing, but attributing coincidence to planning is the slippery slope you spoke of.

 

Drawing conclusions about an “overall strategy” that I might be part of is potentially offensive. Should I be offended?

 

Let’s just do the work and stop second guessing anything shall we? It is so much easier to do good technical work than it is to guess motivations and assign them to people.

 

Thanks,

Adrian

 

From: Robert Raszuk <[e-mail]> 
Sent: 27 April 2019 16:15
To: [e-mail]
Cc: Robert Raszuk <[e-mail]>; SPRING WG <[e-mail]>; [e-mail]
Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

 

Hey Adrian,

 

> Well for one let's observe that interface can be both physical and logical

> entity and as such especially being a logical one can be tight with a 

> service switching vector in any network element. So even based on all

> IPv6 related RFCs you have quoted it does not violate any. 

 

This is certainly one way around the concern. If we define “interfaces to functions” (such as an interface to a VRF) then we may be done. That would be relatively easy to achieve with a simple section in the network programming draft.

 

So it seems we have a solution to your concern. If WG decides to augement the WG doc with such defintion it seems to be done deal. 

 

Just to repeat (since it has apparently been repeatedly missed in reading my emails on this topic, and was even the cause of some heat in a face-to-face conversation I had in Prague) I am not seeking to block anything. What I want to do is get everything aligned. I want to be sure that we have agreement early rather than having a “fight” late in the day when pressures will be more severe.

 I simply don’t understand any reluctance to bring this discussion into the open and make sure we understand how the architectures and terminology line up.

 

Well as an observer I see the interesting coincidence of such comments popping up in the same time as alternative proposals to define yet one more new mapping scheme of IDs to service functions and to not embed them as part of 128 bits. So the conclusions are coming out pretty automatically about overall strategy :) 

 

Cheers,
R.