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

[Tony Li <[e-mail]>]

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?

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


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


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


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


Thank you again for your comments. It was a pleasure.

Regards,
Tony