Re: [mpls] Some following questions about ISD

Hi Jie,
Thank you for the additional information. I will summarize my response.

I think that it is useful to consider PSD as a capability separate from ISD
MNA . And if we take such a view, PSD can be advertised using IGP
extensions with per link and node scopes. As a result, the capability to
support PSD may be used as a constraint if processing PSD MNA and AD is
mandatory. Obviously, if processing PSD is optional, that constraint can be
omitted. Thus, "legacy" nodes that support only ISD MNA would be seen as
PSD-incapable by path engineering functions. WDYT?

Regards,
Greg

On Thu, Sep 14, 2023 at 2:28 AM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

> Hi Greg,
>
>
>
> Please see inline:
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Thursday, September 14, 2023 11:47 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Tony Li <tony.li@tony.li>; mpls@ietf.org; MPLS Working Group <
> mpls-chairs@ietf.org>; draft-ietf-mpls-mna-hdr@ietf.org
> *Subject:* Re: [mpls] Some following questions about ISD
>
>
>
> Hi Jie,
>
> thank you for further clarifications. Please find my notes below tagged
> GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Sep 13, 2023 at 7:43 PM Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
>
> Hi Greg,
>
>
>
> My understanding of the WG poll on ISD vs PSD in June of 2022 (quoted in
> my latest response to Tony) is that both ISD and PSD are required in the
> framework, and a specific MNA application may use either one or both of
> them. Do you agree that is the decision made by the WG?
>
> GIM>> It is unclear to me what you mean by "both ISD and PSD are required
> in the framework". The current version of the MNA framework already
> states:
>
> A solution may optionally carry some data as PSD.
>
> Do you consider this being insufficient and not conforming to the outcome
> of the WG poll? Do you propose to add or modify the text?
>
>
>
>
>
> [Jie] Thanks for pointing out this. Since the consensus of the WG poll
> was:
>
>
>
> A packet may carry Ancillary Data using one or both of the following
> methods:
>
>
>
>     (1) in-stack, and
>
>
>
>       (2) post-stack.
>
>
>
>   It shows the current text in the framework draft has a nit, and some
> clarification update would be needed.
>
>
>
> And here we are talking about the general indication of PSD in the MNA
> header, which needs to align with the content in the MNA framework.
>
> GIM>> That is where we differ. I don't see you suggesting that the MNA
> solution MUST specify the presence of PSD as consequential to the text in
> the MNA framework. I understand that text as a future-proofing of the MNA
> solution. AFAICS, because the MNA solution has a sufficient number of
> reserved bits as well as space for new OpCodes, it is future-proof. If and
> when there's a use case that requires the use of PSD, updating MNA to add
> the PSD presence is possible (IMHO, indication is the easiest part, PSD
> disposal should be on the drawing board of the PSD proponents).
>
>
>
> [Jie] As I mentioned in below replies, updating the MNA reserved bits with
> the indicator of PSD later would cause nodes which comply to the first
> version of the MNA header to ignore the PSD indicator and the existence of
> any PSD, this may not be the expected behavior.
>
>
>
> Making the MNA header format future-proof is good, while since the
> reserved bits would be ignored by MNA nodes, not defining the PSD bit in
> the first place may cause problem when behavior other than ignoring is
> required on MNA nodes which cannot parse PSD in the packet.
>
> GIM>> What kind of problems do you foresee? Can you be a bit more
> specific?
>
>
>
> [Jie] For example, if a PSD with select scope is carried in the packet,
> and the MNA node is required to process the PSD before forwarding the
> packet further, or the packet should be dropped (the U bit set to 1). But
> if the MNA node treats the PSD indicator as reserved bits and ignores it,
> the packet may be forwarded incorrectly.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Wednesday, September 13, 2023 12:47 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Tony Li <tony.li@tony.li>; mpls@ietf.org; MPLS Working Group <
> mpls-chairs@ietf.org>; draft-ietf-mpls-mna-hdr@ietf.org
> *Subject:* Re: [mpls] Some following questions about ISD
>
>
>
> Hi Jie,
>
> I believe that in his last note, Tony had answered this question already
> and I concur with him. In my opinion, the MNA header, that the WG adopted
> is already, is future-proof. I believe that whether one or more reserved
> bits should be used to signal the presence of PSD in the packet could be
> decided if and when the WG agrees that the PSD is required (not possible
> but required) to support a valid use case that cannot be reasonably
> supported using ISD MNA.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Sep 12, 2023 at 8:35 PM Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
>
> Hi Greg,
>
>
>
> Please see my reply to Tony on this point:
>
>
>
> “Since PSD is described in the MNA framework draft, it is assumed that it
> is already part of the framework (and remember the WG poll on it last
> year). What haven’t got converged yet is for specific applications (e.g.
> IOAM) whether PSD is needed or not. Then why not making the PSD indicator
> part of the general MNA header encoding in the beginning? The discussion on
> per-application choice of ISD vs PSD can continue.”
>
>
>
> We have had several presentations about the PSD use cases in the past
> interim meetings, and there have been presentations about the limitations
> of ISD both on the interims and IETF 117 meeting. Maybe all of these need
> to be documented to facilitate people’s review and also to avoid reiterated
> arguments.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Tuesday, September 12, 2023 11:57 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Tony Li <tony.li@tony.li>; mpls@ietf.org; MPLS Working Group <
> mpls-chairs@ietf.org>; draft-ietf-mpls-mna-hdr@ietf.org
> *Subject:* Re: [mpls] Some following questions about ISD
>
>
>
> Hi Jie,
>
> top-posting your comment
>
> [Jie] The PSD draft specifies the detailed encoding of the PSD
> information, while whether PSD is needed or not as a part of the MNA
> solution is described in the framework draft. From this perspective we
> don’t need to wait until the PSD draft gets adopted, as long as we know PSD
> would be there anyway, and an indicator for it in the NAS is needed.
>
> I am unsure that "we know that PSD would be there anyway". As I look at the
> list of the MNA use cases
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>, I
> cannot find a single case that cannot be realized using the ISD MNA
> solution. Am I missing something here?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Sep 12, 2023 at 8:36 AM Dongjie (Jimmy) <jie.dong=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Tony,
>
>
>
> Thanks for the response. Please see further inline:
>
>
>
> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li
> *Sent:* Tuesday, September 12, 2023 1:10 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* mpls@ietf.org; MPLS Working Group <mpls-chairs@ietf.org>;
> draft-ietf-mpls-mna-hdr@ietf.org
> *Subject:* Re: [mpls] Some following questions about ISD
>
>
>
>
>
> Hi Jimmy,
>
>
>
>
>
> 1.       Regarding the RLD, one question is: will RLD be considered in
> path computation/selection for packets with NAS?
>
>
>
>
>
> It should be. One approach is to consider RLD to be a constraint for your
> path computation engine.
>
>
>
> *[Jie] OK, then in which document should this be specified? *
>
>
>
>
>
> For example, if it is known that the size of NAS itself (not counting any
> forwarding or service labels) already exceeds the RLD of some network
> nodes, how would the NAS imposing node do?
>
>
>
>
>
> Pick another path with a higher RLD. If none exists, then notify
> management and fail.
>
>
>
> *[Jie] For an ingress node, it could pick another path with a higher RLD.
> But if it is a transit node which adds new actions, it may not have the
> right/capability to choose another path. The behavior in this case also
> needs to be specified. *
>
>
>
>
>
> 2.       Since we are considering duplicating ISDs to accommodate to the
> RLD limitation, one relevant question is: for a node whose RLD can cover
> more than one NAS, how many NAS should it parse and process?
>
>
>
>
>
> As already defined in the framework document, the node should process only
> one NAS per scope.
>
>
>
> *[Jie] This means a node needs be able to locate multiple NAS labels in
> the stack, and parse the corresponding multiple NASes, if they are with
> different scopes. I**’d suggest to add this to the framework document, as
> it is a new behavior to MPLS label stack processing. *
>
>
>
> If it needs to parse all the NAS in the RLD, it may find the following NAS
> are duplicated and this would waste the node’s resource. But if it only
> parses the first NAS, there may be following NAS with another scope which
> also need to be processed by this node.
>
>
>
>
>
> This is correct. Don’t hide your NASes. ;-)
>
>
>
> The key point here is that a node will only need to process the Select and
> I2E scope NASes if they have a single label above them.  Thus, you only
> need to scan to the depth of the first HBH NAS, or the second regular
> label, whichever is greater.
>
>
>
> *[Jie] This may depend on the order of the HBH NAS and the Select/I2E NAS,
> for example, can HBH NAS precede an select/I2E NAS due to RLD
> consideration? I don**’t recall the order of NASes with different scopes
> has been specified in the framework document or somewhere else. But clearly
> both the order and the parsing procedure need to be documented if it is no
> there yet. *
>
>
>
>
>
> 3.       Regarding the reserved bits in the MNA header (, one of the bits
> has been defined as the indicator of PSD by the PSD draft. But if the ISD
> draft says the reserved bits “MUST be transmitted as zero and ignored upon
> receipt”, it will make node unable to identify the existence of PSD in the
> packet. Since we have already considered that PSD would be needed, it would
> be better to move the definition of the PSD indicator flag to the ISD
> draft, so that we can have a relative stable MNA header format in one place.
>
>
>
>
> As discussed, if we choose to adopt the PSD draft, then it can ‘update’
> the ISD draft. This is not a conflict and is the normal way that we make
> use of reserved bits.
>
>
>
> *[Jie] The PSD draft specifies the detailed encoding of the PSD
> information, while whether PSD is needed or not as a part of the MNA
> solution is described in the framework draft. From this perspective we don**’t
> need to wait until the PSD draft gets adopted, as long as we know PSD would
> be there anyway, and an indicator for it in the NAS is needed. *
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> Tony
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>