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

[Chandrasekar Ramachandran <[e-mail]>]

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.