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

[John Scudder <[e-mail]>]

And thanks for all your work on the spec!

—John

> On Aug 13, 2024, at 9:13 AM, Chandrasekar Ramachandran <[e-mail]> wrote:
> 
> Hi John,
> As stated in the responses to all the comments prefixed [CR2] and [CR3] in previous mails, the comments are addressed in https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr-22.
> 
> Thanks for your detailed and patient reviews.
> 
> Thanks,
> Chandra.
> 
> 
> Juniper Business Use Only
>> -----Original Message-----
>> From: Chandrasekar Ramachandran <[e-mail]>
>> Sent: Monday, August 5, 2024 8:43 PM
>> To: John Scudder <[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 John,
>> Please see inline (prefixed [CR3]) for responses.
>> 
>> Thanks,
>> Chandra.
>> 
>>> -----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.
>