Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04

[Greg Mirsky <[e-mail]>]

Hi Tony,
thank you for your kind consideration of my notes. I agree with the
proposed text. I greatly appreciate our discussion.

Regards,
Greg

On Tue, Jan 10, 2023, 08:17 Tony Li <[e-mail]> wrote:

>
> Hi Greg,
>
>
> How about we add this:
>>>
>>> A node that removes the last NAS that references post-stack
>>> data MUST also remove the post-stack data.
>>>
>> GIM>> It is clearer. Do you think that a small tweak will help a bit more:
>> Tony's text:
>> A node that removes the last NAS that references post-stack
>> data MUST also remove the post-stack data.
>> Greg's text:
>> A node that removes the last NAS that references post-stack
>> data MUST also remove that post-stack data.
>>
>>
>>
>> That begs the question, if it’s not removing all of the PSD, which parts
>> does it remove?
>>
> GIM2>> Great question, thank you. I imagine that if a NAS that references
> a PSD is removed, then only the PSD that is referenced may be removed.
> Would an additional word-tweaking help:
> NEW TEXT:
> A node that removes a NAS that references PSD MUST
> remove the PSD if no other NAS references it.
>
>
>
> After consulting with others, I would like to propose something similar:
>
> A node that removes the only NAS that has the P bit set MUST remove all
> PSD.
>
>
>>>    - s/OAM logging/OAM action/?
>>>
>>>
>>> I think you’re referring to the text in the introduction. The intent
>>> here was to refer to the actual result of the OAM action, not the action
>>> itself.
>>>
>> GIM>> Although sometimes an OAM action triggers logging a message, that
>> is not always the case. Was it in reference to a specific OAM action?
>>
>>
>>
>> No.  This was just an example.  We’re talking about sentence 2 in the
>> introduction:
>>
>> Forthcoming applications require MPLS packets to perform special network
>> actions
>> and carry optional Ancillary Data (AD) that can affect the packet
>> forwarding decision or trigger OAM logging.
>>
>> I would be happy to change ‘can’ to ‘could’, or add the words ‘, for
>> example’ at the end, if that would help.
>>
> GIM2>> Personally, I prefer the latter but either works.
>
>
>
> Agreed. Done.
>
>
>
>>>    - User-defined actions are mentioned twice in the document.
>>>    Considering the extent of the document, a new document documenting
>>>    user-defined actions, their scope, etc., would be a reasonable format. What
>>>    do you think?
>>>
>>>
>>> I don’t understand the concern. This document reserves code points for
>>> user-defined actions.  Beyond that, it’s completely up to the users to
>>> document such actions. It’s a completely blank slate and I’m not sure what
>>> more can be said. The whole point it to leave it as open as possible.
>>>
>> GIM>> As Loa suggested, having a new document is reasonable. I'd be happy
>> to note that the user-defined actions are outside the scope of this
>> document and are for further study.
>>
>>
>>
>> User defined actions need to be documented here at least a little bit.
>> At the very least, we need to mention them and then we need the allocation
>> for some code points in the IANA considerations section (where they’re
>> labelled ‘private use’ to match IANA conventions), so I don’t think we can
>> wholesale remove them.
>>
>> I still don’t understand what more needs to be said.
>>
> GIM2>> I'll leave that to the group discussion. I have some uneasy
> feelings toward user-defined MNAs, but yet nothing that I can put my finger
> at.
>
>
>
> I concur with the uneasy feelings. :-)
>
>
> Regards,
> Tony
>
>