Re: [spring] RFC8200 update?

[Robert Raszuk <[e-mail]>]

Hi Mark,

I actually fully agree with your below note.

However my reasoning to agree perhaps is slightly different then yours :).

I agree on the basis that as defined today in spite huge efforts and good
will by all involved in IPv6 definition it is just not flexible enough to
accommodate current and future needs.

Your reasoning seems to be the opposite - IPv6 is great as is or "it is
what it is: enjoy as served" - and just applications looking for transport
need to be trimmed down to fit it.

Clearly we have different opinions here - but in my books networks are to
serve user needs and carry modern applications as opposed to act as an
emperor telling everyone around how and what can be carried.

And to be very clear - I am not saying you are wrong. Perhaps you look at
train analogy - sure if each passenger would start messing with train
car/wagons construction the train would clearly not go far. But if so we
just need a new train architecture rather then saying - oh no Mr. SR you
can not travel at all.

Many thx,
R.

On Sat, Feb 29, 2020 at 2:13 AM Mark Smith <[e-mail]> wrote:

>
>
> On Sat, 29 Feb 2020, 06:55 Warren Kumari, <[e-mail]> wrote:
>
>> On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <[e-mail]> wrote:
>> >
>> > > interestingly enough MPLS took the same approach
>> >
>> > Well not really. As you know, MPLS unicast and multicast have a new
>> ethertype.
>>
>> And this is a critical distinction -- Brian Carpenter's limited domain
>> document (draft-carpenter-limited-domains) says:
>> "Domain boundaries that are defined administratively (e.g. by address
>> filtering rules in routers) are prone to leakage caused by human
>> error, especially if the limited domain traffic appears otherwise
>> normal to the boundary routers. In this case, the network operator
>> needs to take active steps to protect the boundary. This form of
>> leakage is much less likely if nodes must be explicitly configured to
>> handle a given limited domain protocol, for example by installing a
>> specific protocol handler."
>>
>
> Using IPv6 for SR is fundamentally using the wrong tool for the job.
>
> IPv6 is an internetworking protocol used to network networks and to
> internetwork all hosts attached to all of those networks.
>
> The SR problem space is typically limited to local network or sub-network,
> and usually only between network elements, rather than out to end hosts.
>
> It does make sense to try to use a internetworking protocol to solve a
> local sub-network problem when the internetworking protocol has become
> commodity. The benefits of the cheapness of the commodity protocol should
> outweigh the costs of the drawbacks and compromises that need to be made to
> use it.
>
> However, the moment customising the commodity to better suit the problem
> starts is the moment the benefits of using the existing commodity start
> being lost. Customise too much and all of the benefits of choosing a
> commodity in the first place disappear.
>
> That's why I fundamentally think changing IPv6 to suit SR should be
> avoided as much as possible.
>
> Compromising SR to suit and fit within existing IPv6 would retain the
> benefits of using existing commodity IPv6. Customising IPv6 to suit SR
> risks throwing the commodity benefits "baby out with the bathwater", with
> the more radical the customising, the greater risk.
>
> Regards,
> Mark.
>