[mpls] Re: Working Group Last Call on draft-ietf-mpls-1stnibble

[Dhruv Dhody <[e-mail]>]

Hi Greg,

On Sat, Jun 15, 2024 at 2:36 AM Greg Mirsky <[e-mail]> wrote:

> Hi Dhruv,
> thank you for your comments and suggestions. Please find my notes below
> tagged GIM>>. Attached, please find the new working version and the diff
> that highlights the updates applied.
>
> Regards,
> Greg
>
> On Thu, Jun 13, 2024 at 5:42 AM Dhruv Dhody <[e-mail]> wrote:
>
>> Hi,
>>
>> Support Adoption! A few comments/nits -
>>
>> # Comments
>>
>> - Suggest to not use normative text in Introduction and this could be
>> better suited to section 2.2. Also that section says "..while it must not
>> be part of new implementations or deployments", which is different from
>> SHOULD in the introduction.
>>
> GIM>> Thank you for pointing that ambiguity out. Would the following
> updates address your concern?
> OLD TEXT:
>    *  To stress the importance that any MPLS packet not carrying plain
>       IPv4 or IPv6 packets MUST contain a PSH.
> NEW TEXT:
>    *  To stress the importance that any MPLS packet not carrying plain
>       IPv4 or IPv6 packets contains a PSH.
> END
> And one more:
> OLD TEXT:
>    This memo introduces a requirement and a recommendation, the first
>    building on the Section 2.1.1; the second deprecating the use of the
>    heuristic in Section 2.1.1.1.  The intent of both of these is that
>    legacy routers continue to operate as they have, with no new problems
>    introduced as a result of this memo.  However, new implementations
>    SHOULD follow these recommendations for a more robust operation.
> NEW TEXT:
>    This memo introduces a requirement and a recommendation.  The first
>    builds on Section 2.1.1, and the second deprecates the use of the
>    heuristic in Section 2.1.1.1 and recommends using a dedicated label
>    value for load balancing.  The intent of both is for legacy routers
>    to continue operating as they have, with no new problems introduced
>    as a result of this memo.  However, new implementations that follow
>    this memo enable a more robust network operation.
>
>>
>>
Dhruv: Perfect!



>
>> - Can you add some description in the IANA table to highlight that the
>> same PSN values can mean multiple things and thus the context of the
>> protocol is needed? Or highlight it in some other way...
>>
> GIM>> We've stressed that the type of the payload cannot be safely deduced
> only on the PFN value. For example, in Introduction is stated that:
>     Although some existing network
>    devices may use such a method, it needs to be stressed that the
>    correct interpretation of the Post-stack First Nibble (PFN) in a PSH
>    can be made only in the context of the Label Stack Element (LSE) or
>    group of LSEs in the preceding label stack that characterize the type
>    of the PSH, and that any attempt to rely on the value in any other
>    context is unreliable.
> and at the closing:
>    This document clearly states that the type of encapsulated
>    packet cannot be determined based on the PFN alone.
>
> Furthermore, as an example in Section 2.3:
>    Consider that the PFN value
>    of 0x0 has two different formats, depending on whether the PSH is a
>    pseudowire control word or a DetNet control word; disambiguation
>    requires the context of the service label.
>
> Would you suggest additional text to emphasize that message?
>

Dhruv: I saw those but I feel some text is needed in the IANA section as
well. IANA sections should be enough for both IANA and any reader who is
interested in the use of the codepoints and since this is a bit unusual
registry, it make sense to provide explicit icontext even if you would
simply put in a reference to the earlier section!



>
>>
>> - What happens incase of an unknown PSN is received? Let's add text pointing
>> to relevant RFC for completeness.
>>
> GIM>> Perhaps you mean PFN.
>

Dhruv: yes!



> I imagine that unknown PFN value is a part of unsupported PSH. AFAICS,
> before a node realizes that the received PSH is unsupported, it finds the
> unknown label that is associated with that type of PSH via control or
> management plane. If that is the case, the node will drop received packet
> with the unknown label, which is common behavior for an LSR that encounters
> an unknown label at the top of the label stack.
>

Dhruv: Makes sense, maybe add a text with reference to base MPLS RFC if you
think that would be useful?


>> # Nits
>>
>> - Suggest changing "This memo, if published, would update RFC 4928." to
>> "This memo updates RFC 4928 <explanation>". Make a similar change in
>> Section 1.
>>
> GIM>> I think the current text is correct for the state the document is in
> now, and will be updated by the RFC Editor. In Abstract we note the
> relationship to RFC 4928 and give a more elaborate explanation in the
> Introduction section.
>

Dhruv: I feel in the WGLC and IESG review stages we could remove "if
published" while it was appropriate before.
I would also think having a one line summary on what is being updated makes
sense.



>
>>
>> - [I-D.ietf-mpls-1stnibble]  should be replaced with 'RFC XXXX' or 'this
>> document' as appropriate. Also add a RFC editor note to update XXXX with
>> the RFC number assigned.
>>
> GIM>> I think that by referencing the draft directly we can avoid an
> additional note to the RFC Editor. AFAIK, 'RFC XXXX' was used as part of
> the name, not as a reference before the publication of RFC 9543
> <https://datatracker.ietf.org/doc/html/rfc9543>.
>

Dhruv: I find the self reference to be a bit weird. To make this work you
also added a Normative reference to yourself which is also unusual.

6.  References

6.1.  Normative References

   [I-D.ietf-mpls-1stnibble]
              Kompella, K., Bryant, S., Bocci, M., Mirsky, G.,
              Andersson, L., and J. Dong, "IANA Registry for the First
              Nibble Following a Label Stack", Work in Progress,
              Internet-Draft, draft-ietf-mpls-1stnibble-06, 6 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              1stnibble-06>.


The general practice is to use [This-I.D] as usually seen in the IANA
sections of the draft.
In the YANG models you see the practice of RFC XXXX with an explicit note
to RFC editor (my preference in this case).




>
>>
>> - In the NEW TEXT, use of "At the time of this document," is unclear. It
>> could mean RFC 4928 or [I-D.ietf-mpls-1stnibble], better to be explicit.
>>
> GIM>> Yes, the reference is to the draft. We can make it explicit by the
> following update:
> OLD TEXT:
> At the time of this document,
> NEW TEXT:
> At the time [I-D.ietf-mpls-1stnibble] was written
> END
>

Dhruv: See above.

Thanks!
Dhruv



>
>>
>
>> Thanks!
>> Dhruv
>>
>> On Sun, Jun 9, 2024 at 8:35 AM Tarek Saad <[e-mail]> wrote:
>>
>>> Dear WG,
>>>
>>>
>>>
>>> There were minimal responses regarding this LC on whether the WG is
>>> interested in progressing this document to publication.
>>>
>>> Chairs have decided to extend this WG LC till Friday June 14th to allow
>>> for more responses from the WG on whether to support or not progressing
>>> this document to publication.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Tarek (as MPLS WG co-chair)
>>>
>>>
>>>
>>>
>>>
>>> *From: *Tarek Saad <[e-mail]>
>>> *Date: *Monday, May 20, 2024 at 11:53 PM
>>> *To: *[e-mail] <[e-mail]>
>>> *Cc: *MPLS Working Chairs <[e-mail]>,
>>> [e-mail] <[e-mail]>
>>> *Subject: *Working Group Last Call on draft-ietf-mpls-1stnibble
>>>
>>> Dear WG,
>>>
>>>
>>>
>>> This email starts a two-week working group last call for
>>> draft-ietf-mpls-1stnibble
>>> <https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble/>.
>>>
>>>
>>>
>>> Please indicate your support or concern for this draft. If you are
>>> opposed to the progression of the draft to RFC, please articulate your
>>> concern. If you support it, please indicate that you have read the latest
>>> version, and it is ready for publication in your opinion. As always, review
>>> comments and nits are most welcome.
>>>
>>>
>>>
>>> Please send your comments to the mpls wg mailing list ([e-mail])
>>>
>>> If necessary, comments may be sent unidirectional to the WG chairs.
>>>
>>>
>>>
>>> This poll runs until June 4, 2024.
>>>
>>>
>>>
>>> Thank you,
>>>
>>> Tarek (for the MPLS WG co-chairs)
>>> _______________________________________________
>>> mpls mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>