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

["Acee Lindem (acee)" <[e-mail]>]

Hi Ketan, Deborah,

From: mpls <[e-mail]> on behalf of "Ketan Talaulikar (ketant)" <ketant=[e-mail]>
Date: Thursday, April 9, 2020 at 5:00 AM
To: Deborah Brungard <[e-mail]>, "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[e-mail]>, "Nagendra Kumar Nainar (naikumar)" <[e-mail]>, "Carlos Pignataro (cpignata)" <cpignata=[e-mail]>
Cc: mpls <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi All,

We have implementations and existing deployments with OSPFv2 for IPv4 that are using the current codepoint allocated for “OSPF”. Deprecating this codepoint is and introducing new codepoints for OSPFv2 and OSPFv3 would need changes in existing implementations (to handle both values, backward compatibility aspects and interworking). I believe, this is avoidable.

In IETF documents, the use of term “OSPF” has meant to signify both OSPFv2 and OSPFv3 together.

One way forward is as proposed in the draft, to “rename” the current codepoint associated with OSPF to OSPFv2 to be more clear and specific. AFAIK, we have far fewer deployments of OSPFv3 with MPLS as compared to OSPFv2 with MPLS. So the pain is reduced as compared to the previous option above.

Another way is to continue to call it as is (i.e. OSPF) and clarify that it’s use is for OSPFv2 for IPv4 and OSPFv3 for IPv6. We can allocate a new codepoint “OSPFv3 for IPv4” so as to disambiguate from OSPFv2 for IPv4. It is highly improbable that both OSPFv2 and OSPFv3 are being used together for IPv6. While there are few deployments of OSPFv3 for IPv4, I am not sure if any of those use OSPFv3 for IPv4 along with MPLS forwarding. So, we have likely much smaller pain (if at all) with this option. Backward compatibility mode may be possible to allow use for the current code point also for “OSPFv3 for IPv4” in deployments where implementations exist that use the current code-point for all flavours of OSPF.

This option would be the least disruptive. We can keep the current IANA code point and clarity that OSPF implies either OSPFv2 or OSPFv3 for AF IPv4 and OSPFv3 for IPv6.  Then we can add the new OSPFv3 code point for address family IPv4.

Thanks,
Acee

We can poll both the MPLS and LSR WGs for this.

Thanks,
Ketan

From: mpls <[e-mail]> On Behalf Of BRUNGARD, DEBORAH A
Sent: 09 April 2020 03:06
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) <[e-mail]>; Nagendra Kumar Nainar (naikumar) <[e-mail]>; Carlos Pignataro (cpignata) <cpignata=[e-mail]>
Cc: mpls <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi Mustapha,

For OSPFv3, what you have in the draft by assigning a new codepoint does deprecate “OSPF” for OSPFv3 (Section 4’s “MUST”).

For “OSPF”, you can use similar wording to indicate only for IPv4-OSPFv2 going forward (this draft is an update). Then can add a note in the registry saying for IPv4-OSPFv2 with reference to the draft (we can work with Michelle on the note). You do need to include a backwards compatibility section for IPv4 as did for IPv6.

It would be good to get feedback on deployments to address what to do for backwards compatibility. Is the use of “OSPF” for OSPFv3 currently minimal for deployments transitioning (mixed) to OSPFv3? Will networks (both for nodes already deployed and to-be deployed) be able to support the new codepoint? Are there any impacts for operations?

Thanks,
Deborah


From: Aissaoui, Mustapha (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 8, 2020 4:38 PM
To: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>; Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>>; Carlos Pignataro (cpignata) <cpignata=[e-mail]<mailto:cpignata=[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi Deborah,
Option 4 below that we are proposing in effect “deprecates” the use of those two codepoints in OSPFv3 but keeps their use in OSPFv2.

Is there a procedure for handling deprecation of a codepoint within a specific protocol only while keeping it within the other protocol?

As for keeping the name as OSPF, can we change the description to state it is for use in OSPFv2 and that its use in OSPFv3 is deprecated? It is not sufficient to recommend using the current codepoints with OSPFv2, we want to deprecate its use in OSPFv3 such that OSPFv3 Segment Routing implementations will begin using the new codepoint.

It will be useful if members of this mailing list provide feedback on any existing deployment of segment routing with OSPFv3. I believe we have a window for the vendors to fix the ambiguity of the current OSPF codepoint before many deployments occur.

Regards,
Mustapha.

From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, April 8, 2020 12:16 PM
To: Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>>; Carlos Pignataro (cpignata) <cpignata=[e-mail]<mailto:cpignata=[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi Carlos, Nagendra,

Sorry for the couple of days delay, I’ve been talking with my fellow ADs.


Previously you had mentioned this was similar to RFC6829, but it is not. Those IPv4 codepoints were never used in IPv6 deployments. As the document says:

“the fact that the PE IP address family is not explicit in the sub-TLV
definition, this can be inferred indirectly by examining the lengths
of the Sender's/Remote PE Address fields or calculating the length of
the sub-TLVs (see Section 3.2 of [RFC4379]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4379-23section-2D3.2&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=RyLuPUqZ-SJ78mVcvnTOIRB4YWN1tRXENihia4s5_Vg&s=lV-JHDevHDfUMbcpNIHZN8IriHTxl5Qf7ke88FPrKm0&e=>).  When an IPv6 LDP
session is used, these existing sub-TLVs cannot be used since the
addresses will not fit.”

Whereas, here, use for both IPv4 and IPv6 (so it included OSPFv3) was defined in RFC8287. You can not simply “rename”. The process is that codepoints can be deprecated and new ones are added. The other approach is to add a note to the “OSPF” codepoint referring to this draft saying it is recommended for OSPFv2. And providing a compatibility section as was done for OSPFv3.

Thanks,
Deborah
(for unaware folks on the list – speaking as MPLS AD)


From: Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 8, 2020 11:19 AM
To: Carlos Pignataro (cpignata) <cpignata=[e-mail]<mailto:cpignata=[e-mail]>>; BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; IANA <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi,

I share the same thought that option 4 is more appropriate with a consideration section.

Thanks,
Nagendra

From: mpls <[e-mail]<mailto:[e-mail]>> on behalf of "Carlos Pignataro (cpignata)" <cpignata=[e-mail]<mailto:cpignata=[e-mail]>>
Date: Tuesday, April 7, 2020 at 5:57 PM
To: Deborah Brungard <[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]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] early allocations of code points for draft-ietf-mpls-lsp-ping-ospfv3-codepoint-00.txt

Hi, Deborah,

Thank you for updating through the WG.

Since I have seen no response, let me contribute a follow-up encouraging others in the WG to pitch in.

To offer a perspective, draft-ietf-mpls-lsp-ping-ospfv3-codepoint is not deprecating and repurposing a code point. Instead, it intends to rename a code point, to the current (and implicitly intended) use.

The current interpretations, implementations and implementation plans of RFC8287 that I am aware of (please respond if you know of any plans or implementations!) took “OSPF” to mean “OSPFv2”. The intention is that now as the WG thinks about OSPFv3, to formalize the practical use given to the code point.

Deborah, you raise an excellent point about interop or operational considerations. That is a gap in the draft that should be added..

However, as far as code point allocation, options are:
1.       Deprecate OSPF and add new codes fo OSPFv2 and OSPFv3 — this does not concern itself with running code and is disruptive to deployment.
2.       Add new code points for OSPFv2 and OSPFv3 and provide backwards compatibility and transition from OSPF -> OSPFv2 only — this adds lots of forward-looking complexity
3.       Use OSPF for IPv4 OSPFv2 and v3 and a new code point for OSPFv3 — this does not pass the principle of minimum surprise or astonishment.
4.       Use OSPF number fo OSPFv2 and a new one fo OSPFv3 — this needs a considerations section in the doc.

From these, #4 seems the most appropriate. Thoughts?

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=_DGQqHS5OqF40sKDdlaaJkJ2AnB2_bkCmPsPVAxiEps&s=FurTvUxfyXhWig3N0s_r0KNKd5GqFB1m4ysBNThnoaY&e=>