Subject: [Pce] RFC7150 implementations?

From: Robert Varga <[email-masked]>
Date: Mon, 21 Jul 2014 15:41:06 +0200

Hello everyone,

as some of you may have noticed, the draft-ietf-pce-stateful-pce's 
definition of LSP object conflicts with that of RFC7150 
(VENDOR-INFORMATION/Vendor-Specific Constraints), as both specify the 
object to be 32/1. This is obviously bad, and resolving it requires one 
of the specifications to move.

Given that the stateful draft is being shipped by multiple vendors for 
quite some time now, this puts us in a tight spot of having to choose 
which implementations to break by moving their codepoint allocation.

With that, I would like to as the WG the following three incremental 
questions:

Are there any RFC7150 implementations fielded?

If so, are they using the Vendor-Specific Contraints object?

If so, how much breakage would ensue should the object codepoint be moved?

Thanks,
Robert

---

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Mon, 21 Jul 2014 14:01:48 +0000

Hi Robert,

    The assignment of code-points is handled by IANA (see RFC 2434). To
prevent conflicts, and avoid situations like this, there is a procedure
for Early IANA Allocation of Standards Track Code Points (defined in RFC
7120, which obsoletes 4020). Using this procedure, a widely spread pre-RFC
implementation has the guarantee of non-collision of code-points.

    I would suggest that to solve the conflict you contact directly IANA,
who would guide you properly.

    And to prevent situations like this in the future, I would suggest
following RFC 7120 procedure in other widely implemented pre-RFC
documents.

    Best Regards,

        Óscar

El 21/07/14 09:41, "Robert Varga" <[email-masked]> escribió:

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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Robert Varga <[email-masked]>
Date: Mon, 21 Jul 2014 16:36:16 +0200

Hello Oscar,
Yes, clearly the codepoint allocation is handled by IANA and we are well 
aware of the early allocation procedures. What we are looking for is a 
fix for a mistake we made some two years ago and which went undiscovered 
until the addition of RFC7150.

As you may be aware, we are talking about touching a registry governed 
by "IETF Review" policy, which according to RFC is there to

	ensure that the proposed assignment will not negatively
	impact interoperability or otherwise extend IETF protocols
         in an inappropriate or damaging manner.

So before initiating a change to this registry, we are seeking input 
from field, specifically on the existence of active deployments of 7150.

Thanks,
Robert

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 21 Jul 2014 15:37:12 +0100

Oscar,

You are completely right about how this happened and how it should have been
avoided. No question of where the fault is, and lessons learned for the future.

We have been talking with IANA and have their guidance.
The preferred approach is to change the code point in 7150, but we can only do
that if the damage in deployed networks is not significant.
Hence the request posted by Robert.

If it turns out that there is a cost to changing the 7150 code point then we
have to think again.

AFAICS, a change to a software stack is annoying, but not much more than a
compilation. But a change to a widely deployed network might be a pain.

A

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of OSCAR GONZALEZ DE
> DIOS
> Sent: 21 July 2014 15:02
> To: Robert Varga; [email-masked]
> Subject: Re: [Pce] RFC7150 implementations?
> 
> Hi Robert,
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
> contener información privilegiada o confidencial y es para uso exclusivo de la
> persona o entidad de destino. Si no es usted. el destinatario indicado, queda
> notificado de que la lectura, utilización, divulgación y/o copia sin
autorización
> puede estar prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta
> misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential
> information intended only for the use of the individual or entity named above.
If
> the reader of this message is not the intended recipient, you are hereby
notified
> that any dissemination, distribution or copying of this communication is
strictly
> prohibited. If you have received this transmission in error, do not read it.
Please
> immediately reply to the sender that you have received this communication in
> error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
indicado,
> fica notificado de que a leitura, utilização, divulgação e/ou cópia sem
autorização
> pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
> por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via
> e proceda a sua destruição
>