[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with DISCUSS and COMMENT)

[Chandrasekar Ramachandran <[e-mail]>]

Hi John,
Please see inline (prefixed [CR3]) for responses.

Thanks,
Chandra.


Juniper Business Use Only
> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Tuesday, July 23, 2024 8:59 PM
> To: Chandrasekar Ramachandran <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; mpls-
> [e-mail]; [e-mail]; Nicolai Leymann <[e-mail]>
> Subject: Re: John Scudder's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with
> DISCUSS and COMMENT)
>
> Hi Chandra,
>
> My replies are inline.
>
> Thanks,
>
> —John

<snipped>

> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>> COMMENT:
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>> ## COMMENT
> >>
> >> Thanks for resolving my previous comments. I have one new comment,
> >> related to the changes made since my last review.
> >>
> >> ### Section 4.4.3, what other bits could there be?
> >>
> >> Version 21 has,
> >>
> >>      If no bit is set, then the PathTear message MUST be processed as a
> >>      normal PathTear message for the LSP.
> >>
> >> I see this was introduced after my last review. I'm curious as to the
> >> reason for the change (I suppose it was the result of somebody else's
> >> review). I ask because, the previous text spoke specifically about
> >> "the M-bit" but now you speak generically about "no bit", presumably
> >> to include the M-bit, but not exclusively. The problem is, I don't
> >> see any other bit flags in the object header, even potentially. The
> >> fields are Length, Class, C–type, a one-bit field called M- bit, and a field 31
> bits wide, called "Reserved", but notably, not called "flags"
> >> or something like that.
> >>
> >> So, what is the difference between the old text, and the new? As far
> >> as I can tell the new text while correct, is less transparent than
> >> the old text without bringing any benefit.
> >>
> >
> > [CR2] The above change was made to address the following questions from
> IANA:
> > **
> > RFC 3936 says that new Class Types registries have 256 values. The current
> version of this document assigns value 1, but doesn't tell us what to do with
> value 0. Should it be reserved?
>
> I’m curious what your resolution to that question from IANA was? In version
> 21 I still see nothing about value 0 or for that matter values 2-255. I do see
> that other class types registries are also silent about value 0 and unassigned
> values, so maybe you decided that’s fine. I’m also curious what the
> registration policy is for the c-types conditions sub-registry. The header before
> all the c-types, https://www.iana.org/assignments/rsvp-parameters/rsvp-
> parameters.xhtml#rsvp-parameters-4 says that "any new Class Number
> definition must specify an appropriate IANA Considerations policy for
> assigning additional Class Type values” so it seems you’re supposed to supply
> one (although I don’t see them for the other conditions sub-registries).
>

[CR3] The following is the response that was given to IANA (which was accepted) regarding the usage of value 0 for “Class-Types” –
**
Yes, it is true that RFC 3936 is silent on the usage of value 0 for Class Types (it just calls out that there are 8 bits to use for the Class Type). But, there has never been any RSVP Class Object defined (since inception) for which a Class Type of 0 was allocated (please see https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml) The convention has always been to start with C-Type 1. This is because it is extremely unlikely to ever have a large number of flavors of the same object (the most we have ever used is 24 values for the SESSION object). Traditionally, there has never been any guidance given to IANA on C-Type 0 when a new RSVP object is defined. You can refer to any RFC where a new object is defined (examples – RFC5063, RFC8149, RFC4874, RFC7417) – so, I don’t see the reason to do that now. Just having a table with description for Value “1” should be sufficient.
**
[CR3] With regards to the specification of an appropriate IANA Considerations policy for assigning additional Class Type values, we did not come across any precedent for this. That said, we can add the following statement in Section 6.1  -
Assignment of additional Class Type values for Class Name “CONDITIONS” are to be performed via “IETF Review” [RFC8126].

> > Can you confirm that the new CONDITIONS Objects Flags registry shouldn't
> have a registration or reservation that has the value 0x000?
> > **
> > Please also refer to the corresponding changes in the IANA Considerations
> Section (Section 6.1).
> >
> > This document defines just one bit flag, but our intent was to leave room for
> other bit flags to be introduced in future documents. In case, some
> implementation includes the CONDITIONS object in a Tear message and does
> not set any flag, then it should be treated like a regular unconditional Tear
> message. That was the motivation behind saying – “If no bit is set..”.
> >
> > Would the following changes address your concern?
> >
> > In Section 4.4.3:
> > Class: TBA1
> > C-type: 1
> > Reserved bits: Reserved bits MUST be set to zero on transmission and
> MUST be ignored on receipt.
>
> That’s good enough. IMO if you intend that the entire field marked
> “Reserved” is a flags field, it’s even better to write it like,
>
> ```
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Length | Class | C-type |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Flags (Reserved) |M|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     • Class: TBA1
> • C-type: 1
> • Flags is a 32-bit field. Bit 31 is the Merge-point condition (M) bit: If the M bit
> is set, then the PathTear message MUST be processed according to the
> receiver router role, i.e. if the receiving router is an MP or not for the LSP. If it
> is not set, then the PathTear message MUST be processed as a normal
> PathTear message for the LSP. Bits 0-30 are reserved, they MUST be set to zero
> on transmission and MUST be ignored on receipt.
> ```
>
> The point of the suggested revision is to clarify that the field isn’t just 31
> unstructured bits with no intended use, but that it’s all flags. (And knowing
> that sometimes these decisions get revised in the future, too — at some point
> if bits 0-15 remain unallocated, some later RFC could be written to redefine
> them as a 16-bit integer field, for example. But that’s OK, we should
> document your current intent as well as we can.)
>

[CR3] We’ll make the suggested change in the next revision.

> By the way, I noticed you left off the customary bit number ruler at the top of
> the figure. The RFCEd would probably fix this, but you should do so in your
> next rev.
>

[CR3] We’ll fix this in the next revision.

> > Merge-point condition (M) bit: If the M bit is set to 1, then the PathTear
> message MUST be processed according to the receiver router role, i.e. if the
> receiving router is an MP or not for the LSP.  If the M bit is set to 0, then the
> PathTear message MUST be processed as a normal PathTear message for the
> LSP.
> >
> > In Section 6.1:
> > s/sub-registry for "CONDITIONS Object Flags"/sub-registry for "CONDITIONS
> Object Values"
>
> I think it makes better sense as flags, again based on your statement that "our
> intent was to leave room for other bit flags to be introduced”. Your current
> text is,
>
> OLD:
> Bit Number Hex Value Name Reference
> - 0x0000 No Condition This document
> 31 0x0001 Merge-point This document
>
> It seems to me as though the actual confusion arises from the “-“ line, so
> possibly, imitating the convention used by the other flags sub-registry already
> under RSVP parameters, https://www.iana.org/assignments/rsvp-
> parameters/rsvp-parameters.xhtml#rsvp-parameters-119,
>
> NEW:
> Bit Number  32-Bit Value  Name  Reference
> 0-30  Unassigned
> 31 0x0001 Merge-point This document
>

[CR3] We’ll make the suggested change in the next revision.