Re: [Pce] Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

["Mike Koldychev (mkoldych)" <[e-mail]>]

Hi Oscar,

See inline with [MK].

Thanks,
Mike.

From: Oscar González de Dios <[e-mail]>
Sent: Friday, September 17, 2021 1:41 PM
To: Mike Koldychev (mkoldych) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

Thanks Mike,

                Another question/comment.

                The color & endpoint are encoded in the Extended Association ID TLV (defined in RFC 8697. The Extended Association ID TLV is an optional TLV for use in the ASSOCIATION object. The meaning and usage of the Extended Association ID TLV are as per Section 4 of [RFC6780] .

                The content of the Extended Association TLV is defined here. Hence, the content of the TLV as expressed in the draft is only valid when the association type is 6 (segment routing). In other cases, the format would be completely different.

[MK] The format of the Extended Association ID TLV is specific to the Association Type and cannot be used outside of the Association Type that it's defined for.

                Typically the content of all PCEP TLVs are well defined without requiring knowledge of the object in which they are carried. Some sort of type is used to determine the content.

                Looking at Section 4 of [RFC6780], the "Extended Association ID: variable, 4-byte aligned
      This field contains data that is additional information to support
      unique identification.  The length and contents of this field is
      scoped by the Association Source.  ".

                There, all association fields are together, so it makes sense. However, as in PCEP RFC 8697 "stripped off" the extended association ID to a TLV... well, we have the problem of having a TLV without any pre-defined format or any way of knowing its content without context...

[MK] It's kept generic on purpose - to allow encoding arbitrary keys. Each application can define its own key format.

                Is there any particular reason for this behavior?  Does color & endpoint absolutely need to be part of the Extended Association TLV or could they have their own TLV?

[MK] In fact, the Color and Endpoint did have their own TLV, but it was decided to move them inside the Extended Association ID TLV. The reason is that every Association needs to have an Association ID value and it was difficult to pick that value for PCE Initiated SR Policies when two different PCEs send PCInitiate messages for two Candidate Paths of the same SR Policy (same Color+Endpoint) at the same time. Each PCE would need to choose what Association ID to send and if they just pick any random values, they would not agree. I.e., you would end up with two Associations on the PCC that have different Association IDs but same Color + Endpoint. On the other hand, if the two PCEs encode the Color + Endpoint as the ID, then this problem goes away, i.e., the two PCEs always agree on the ID. See also IETF 110 PCE WG recording.

                Best Regards,

                                Oscar

De: Mike Koldychev (mkoldych) <[e-mail]<mailto:[e-mail]>>
Enviado el: viernes, 17 de septiembre de 2021 19:01
Para: Oscar González de Dios <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Asunto: RE: Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

Hi Oscar,

Yes, I believe your understanding is correct.

Thanks,
Mike.

From: Oscar González de Dios <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 17, 2021 8:02 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

Dear PCE WG & draft-ietf-pce-segment-routing-policy-cp authors,

        I have one (easy) question about the SR Policy Candidate Path Identifiers TLV in section 5.2.2.
"Originator Address: Represented as 128 bit value where IPv4 address
   are encoded in lowest 32 bits, part of the originator identifier, as
   specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4."
In [I-D.ietf-spring-segment-routing-policy] Section 2.4. :
"Node Address : represented as a 128-bit value.  IPv4 addresses
      MUST be encoded in the lowest 32 bits, and the high-order bits
      MUST be set to zero."

             I guess an IPv4 Originator address would be encoded as follows: (apologies if the lines do not appear properly)

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Proto. Origin |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Originator ASN                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   all zeros                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   all zeros                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   all zeros                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Originator IPv4 Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Discriminator                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        I ask it because in one interoperability test we are carrying out now, in one implementation the IPv4 address is encoded in the bits right after Originator ASN. Hence... I just want to be sure my understanding is correct to avoid a philosophical discussion :)

        Best Regards,

                Oscar


  ________________________________

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

________________________________

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