Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

["Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[e-mail]>]

Dear all,
To add a bit more context to the request in this draft, the issue with the original OSPF name was that when processing the Segment ID sub-TLV or the Downstream Detailed Mapping TLV, there was no way to tell if the protocol was OSPFv2 or OSPFv3 for the IPv4 family. There is no ambiguity for the IPv6 family since it is always OSPFv3.

We (the authors of the draft) proposed allocating new codepoints for OSPFv3 and renaming the current ones from OSPF to OSPFv2. This is just reflecting the fact that current implementations and deployments of Segment Routing are OSPFv2. We believe the risk is very low but of course feedback on this list should hopefully provide some indication.

We do not want to deprecate the existing codepoints because many implementations are already deployed and as recently as last month, we have tested interop of Segment Routing with OSPFv2 among vendors at EANTC.

Regards,
Mustapha.
Sent from my iPhone

had with the original OSPF name was that for IPv4 family, we could not tell if it was an OSPFv2 or an OSPFv3 protocol.

On Apr 3, 2020, at 10:53 PM, Carlos Pignataro (cpignata) <cpignata=[e-mail]> wrote:

 Deborah,

Thanks for this follow-up.

Strictly, draft-ietf-mpls-lsp-ping-ospfv3-codepoint does not deprecate and reassign a code point — it merely renames it to match usage.

Similar renaming has been done as e.g, https://tools.ietf.org/html/rfc6829#section-2.

I agree that a more detailed operational considerations is needed on this explaining it.

I really do not think this applies to RFC8690 since that only clarifies the Length and has no mention of the Protocol field. But if you think so, it can be added.

Thanks,

Carlos.


2020/04/03 午後2:17、BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>のメール:

Hi MPLS WG, MPLS Chairs,

Here's an update on these early allocations. IANA has finished the early allocation for OSPFv3 codepoints. They responded they could not rename the OSPF codepoint as OSPFv2 until the draft was approved. The chairs asked if a note could be added to the OSPF codepoint saying it will be renamed. IANA asked for my approval to add such a note.

When asked for my initial approval on this IANA early allocation, I only looked at the draft itself and not at RFC8287 which it "updates". It was my error to assume RFC8287's OSPF codepoint was for OSPFv2 and this draft updated to add a codepoint for OSPFv3. Reviewing RFC8287, the OSPF codepoint is used by IPv4 and IPv6, so it currently represents both OSPFv2 and v3. Codepoints are usually deprecated (obsoleted), but they are not reassigned when in use. Especially if there are no registry limitations.

Before approving adding this note, I requested the authors to add information on interoperability aspects and rationale on renaming as the best solution. As this is a working group draft, I encourage the working group to engage on the solution.

Note, the document not only impacts RFC8287 but also RFC8690.

Thanks,
Deborah


-----Original Message-----
From: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 25, 2020 3:18 PM
To: Loa Andersson <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; IANA <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi Loa, IANA,

I approve these early allocations-
Thanks-
Deborah


-----Original Message-----
From: Loa Andersson <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 24, 2020 6:37 AM
To: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; IANA <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Deborah,

This is the process for early allocations of IANA codepoints as
described in RFC 7120. The comments preceded with (-) are mine
describing how the current draft meet the requirements for early
allocation,

   1.  The authors (editors) of the document submit a request for early
       allocation to the Working Group chairs, specifying which code
       points require early allocation and to which document they should
       be assigned.

       - This has been done, though the authors actually requested the
         code points to be made to an individual draft (draft-nainar-
         mpls-lsp-ping-ospfv3-codepoint)

       - The wg chair responded that early code point allocations can
         only be made to working group documents.

       - The working group document is no at hand and the working group
         chairs are prepared to go ahead and request the allocations.

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly
       conditions (c) and (d).

      - the working group chairs has reviewed the draft in the light
        of section 2 of RFC 7120.

      - the wg chairs are convinced that draft-ietf-mpls-lsp-ping-
        ospfv3-codepoint all the criteria listed in section 2 of
        RFC 7120.

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

       - the wg chairs are convinced that the har consensus in the wg
         to go ahead and do the early allocation.

   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
       from the Area Director(s).  The Area Director(s) may apply
       judgement to the request, especially if there is a risk of
       registry depletion.

       - This mail is the request according to step for in the process
         for early allocation.

       - the mail is sent to Deborah Brungard as responsible AD, with a
         copy to the the other rtg-ads.

       - we request support for early allocation of the codes as
         requested in Sectioon 7 (IANA considerations) in draft-ietf-
         mpls-lsp-ping-ospfv3-codepoint, i.e.:
         One new code point for OSPFv3 in the "Protocol in the Segment
         ID sub-TLV"
         Renaming of the existing OSPF code point in the same registry
         to "OSPFv3".

         and

         One new code point for OSPFv3 in the "Protocol in Label Stack
         Sub-TLV of Downstream Detailed Mapping TLV"
         Renaming of the existing OSPF code point in the same registry
         to "OSPFv3".

       - we will wait for the response from the responsible AD before
         going ahead with step 5 in this process.

   5.  If the Area Directors approve step 4), the WG chairs request IANA
       to make an early allocation.

   6.  IANA makes an allocation from the appropriate registry, marking
       it as "Temporary", valid for a period of one year from the date
       of allocation.  The date of first allocation and the date of
       expiry are also recorded in the registry and made visible to the
       public.


/Loa
for the MPLS wg co-chairs.

PS
This mail is sent to IANA, even though IANA do not need to take any
action until the formal request.
--


Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls

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