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

[Greg Mirsky <[e-mail]>]

Hi Tony,
thank you for your quick and thoughtful responses. I've added more notes
under the GIM2>> tag.

Regards,
Greg

On Fri, Jan 6, 2023 at 5:48 PM Tony Li <[e-mail]> wrote:

>
> Hi Greg,
>
> Please see inline.
>
>
> 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.

>
>
>>    - 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.

>
>
>
>>    - 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.

>
>
> GIM>> Thank you for pointing out to me that I2E might be considered a
> special case of the Select scope. As that is the case, is it practical not
> to introduce the I2E scope at all?
>
>
>
> That would be fine with me.  I think it warrants broader discussion first.
>
GIM2>> Agree, that is not a show-stopper

>
>
>
>>    -
>>    As I understand it, MNA can be used in SR-MPLS. In that case,
>>    multiple NASes may be present in the label stack. Since I couldn't find any
>>    restrictions for use of multiple NASes, these might be different, i.e.,
>>    include different NAI and/or different ADs. Is that right?
>>
>>
>> The use of multiple NASes is not restricted to SR.  Yes, you COULD do
>> some very strange things. We are trying to write a minimalist
>> specification, so that these odd things are not precluded.
>>
> GIM>> I wonder if the definition of a PSD belongs in
> draft-jags-mpls-mna-hdr or draft-song-mpls-extension-header. WDYT?
>
>
>
> PSD is defined in the requirements and framework drafts.  The
> specification is in draft-song, of course.  I’m happy with that.  If you
> are proposing that we combine draft-jags and draft-song, that is a much
> broader discussion.  As draft-jags is already 30 pages long, I’m not in a
> rush to combine things.
>
GIM2>> I don't see a benefit in merging two drafts. There might be
interdependencies that we'll identify and document. Disposing of a PSD
seems like one of them.

>
>
> Thank you again for your comments. It was a pleasure.
>
> Regards,
> Tony
>
>
>