Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

["Carlos Pignataro (cpignata)" <[e-mail]>]

Adrian,

My view and preference is that, as per truth #12 in [1]:

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

We can support existing and future uses with Experimental ranges only.

That said, if you find solid arguments to keep both, I’m also OK.

Thanks,

Carlos.

[1] https://tools.ietf.org/html/rfc1925#section-2



2020/04/08 午前4:39、Adrian Farrel <[e-mail]<mailto:[e-mail]>>のメール:

Hi Mach,

I thought the whole reason we had this document was because what we have had
for so many years is wrong.

If the argument is that "we have been doing it for a long time and it hasn't
caused any problems" then let's abandon this draft and spend our time more
profitably!

However, I believe that Loa makes a good argument that the draft is needed,
and we should take that opportunity to work out what we really want.

Now, a very strong argument from anyone would be "we're already using code
points from this part of the registry, please don't mess with it".

Best,
Adrian

-----Original Message-----
From: Mach Chen <[e-mail]<mailto:[e-mail]>>
Sent: 08 April 2020 03:10
To: Loa Andersson <[e-mail]<mailto:[e-mail]>>; tom petch <[e-mail]<mailto:[e-mail]>>; Carlos
Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>>; Adrian Farrel
<[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>;
[e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Hi all,

Although I think the probability of using "Private Use" is low, I incline to
agree with Tom here. It's safer to keep both the "Private Use" and
"Experimental Use". And since we have been along with them for so many
years, seems it's no harm to keep keeping them.

Regards,
Mach

-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]
Sent: Monday, April 6, 2020 1:15 PM
To: tom petch <[e-mail]>; Carlos Pignataro (cpignata)
<[e-mail]>; Adrian Farrel <[e-mail]>
Cc: mpls <[e-mail]>; draft-ietf-mpls-lsp-ping-registries-update@ietf.
org
Subject: Re: [mpls] Review of
draft-ietf-mpls-lsp-ping-registries-update-01

Tom,

Interesting, looks like we need to continue the discussion on this for a
while.

Working group,

Please respond to this question:

For the LSP Ping registries do we need both the "Experimental Use" and
"Private Use" allocation policies? If we do not need both, which can be
dropped?

/Loa

PS

I have had a DOS attack against my mail server, it took us three days to
fix
everything.

On 04/04/2020 00:00, tom petch wrote:

From: mpls <[e-mail]> on behalf of Loa Andersson
<[e-mail]>
Sent: 03 April 2020 07:23

Carlos and Adrian,

So for the current draft I'll use "Experimental Use" and remove
"Private Use", my rationale for that is that I get questions about
"Experimental Use", but so far has had no question of "Private Use".

Working Group,

Please comment on this, either support or objections.

<tp>

I think that you should keep both since they have different uses.
Experimental is for us, the IETF, if we cannot quite make up our minds how
to
proceed yet.
Private use is for an organisation or group thereof to go their own way
and
fork from the work of the IETF.  This is not desirable but history shows
that
it happens and I think that MPLS OAM is an area where the chances of this
are higher than with some IETF protocols.
If there is no private use, then such an organisation will camp on the
Experimental which generates a problem for deployed code.

TP

/Loa
for the co-authors

On 03/04/2020 02:38, Carlos Pignataro (cpignata) wrote:


2020/04/02 午前7:13、Adrian Farrel <[e-mail]>のメール:

Thanks Loa,

I agree with your interpretation of 8126.

I think that the challenge with "experiments on the open Internet" is
that the experiments have to have built into them some way to protect
against two experiments using the same codepoint. That's not usually done
in my experience, meaning that the two allocation classes are often pretty
similar. Maybe there is some difference in duration of the use of a code
point.

I'd certainly be happy with collapsing these registries to use just
one
range. I would say that keeping the resulting range small (just a few code
points) is desirable.


+1

Thanks,

Carlos.

Best,
Adrian

-----Original Message-----
From: Loa Andersson <[e-mail]>
Sent: 02 April 2020 11:31
To: [e-mail];
[e-mail]
Cc: [e-mail]
Subject: Re: Review of draft-ietf-mpls-lsp-ping-registries-update-01

Adrian,

This is to address your comment on "Private Use" and "Experimental
Use", we will review the rest of the comments and update as needed.

On 02/04/2020 01:06, Adrian Farrel wrote:
Hi all,

<snip>

I have a number of small editorials and some larger questions and
issues set out below. I also have one question that has broader
scope:

For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and
'Experimental Use'. I struggle to see how this makes sense. The
uses decribed in RFC 8126 are sufficiently similar that it is
unusual to have both categories defined for a single registry. I
don't see anything in the descriptive text in this document that
makes clear why you need both categories and how an implementation
would decide which range to select a code point from.
<snip>

You are right I've been struggling with these two type of code
points also, but came to a slightly different conclusion than you did.

RFC 8126 says:

4.1.  Private Use

    Private Use is for private or local use only, with the type and
    purpose defined by the local site.  No attempt is made to prevent
    multiple sites from using the same value in different (and
    incompatible) ways.  IANA does not record assignments from
registries
    or ranges with this policy (and therefore there is no need for
IANA
    to review them) and assignments are not generally useful for
broad
    interoperability.  It is the responsibility of the sites making
use
    of the Private Use range to ensure that no conflicts occur
(within
    the intended scope of use).

    Examples:

       Site-specific options in DHCP [RFC2939]
       Fibre Channel Port Type Registry [RFC4044]
       TLS ClientCertificateType Identifiers 224-255 [RFC5246]

4.2.  Experimental Use

    Experimental Use is similar to Private Use, but with the purpose
    being to facilitate experimentation.  See [RFC3692] for details.
    IANA does not record assignments from registries or ranges with
this
    policy (and therefore there is no need for IANA to review them)
and
    assignments are not generally useful for broad interoperability.
    Unless the registry explicitly allows it, it is not appropriate
for
    documents to select explicit values from registries or ranges
with
    this policy.  Specific experiments will select a value to use
during
    the experiment.

    When code points are set aside for Experimental Use, it's
important
    to make clear any expected restrictions on experimental scope.
For
    example, say whether it's acceptable to run experiments using
those
    code points over the open Internet or whether such experiments
should
    be confined to more closed environments.  See [RFC6994] for an
    example of such considerations.

    Example:

       Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and
TCP
       Headers [RFC4727]


It seems to me that "Private Use" are intended for private networks,
where care is taken that the code points are not leaked into the
Internet, but there the network itself is a production network, that
will be run for an unforeseeable amount of time. And that
"Experimental Use" code points are for short lived experiments.


This is different.

I'm very uncertain whether it is sufficiently different to motivate
two different types. If the working group thinks there should be
only one code point, I would argue to keep the code points for
"Experimental Use". If we converge on "one type of code point only,
I think this has a wider impact than this document, and we should
probably update RFC
8126 (again).

I'd like to invite comments on this on the mpls wg list.

/Loa

--


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]



--


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls


--


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]