Re: [mpls] Some following questions about ISD

[Joel Halpern <[e-mail]>]

The working group poll you cite does not lead to the conclusion you 
claim.  The poll did not consider the alternative of not supporting PSD 
at all.  One can not conclude that the WG supports keeping PSD when the 
quesiton was not asked.  As I recalled, the chairs thought at one point 
that it did cover it, but further conversation with the WG lead to the 
conclusion that further investigation and discussion of PSD was needed.  
As such, my understanding is that the WG has not agreed that we need 
PSD. (Obviously, the chairs can correct me.)

Given that you agree that not all nodes will process PSD, it is not at 
all clear that all nodes need an indication of PSD.  Having optional 
support for PSD does mean that we need to take care with regard to 
terminal nodes and PSD.  This could mean that PSD is only usable if the 
terminal node supports PSD, or it could mean that we need a mechanism to 
clean up PSD.  Or there may be other alternatives to handle it.  That 
will be part of the discussion if the WG finds persuasive cases for 
evaluating PSD and its value / complexity tradeoff.

Yours,

Joel

On 9/15/2023 4:27 AM, Dongjie (Jimmy) wrote:
>
> Hi Joel,
>
> Thanks for the analysis. Please see some further thoughts inline:
>
> *From:*Joel Halpern [mailto:[e-mail]]
> *Sent:* Thursday, September 14, 2023 10:03 PM
> *To:* Dongjie (Jimmy) <[e-mail]>; Greg Mirsky 
> <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [mpls] Some following questions about ISD
>
> I see two problems with your assumption taht we need to define the PSD 
> bit so that PSD gets properly proessed.
>
> Let us assume that the WG does conclude at some point that we need 
> PSD.  That conclusion has not been reached, but for purposes of this 
> email let us assume that comes to pass.
>
> [Jie] Please review the WG poll on ISD vs PSD in June 2022. My 
> interpretation to it is that the framework needs to cover both ISD and 
> PSD, thus PSD is needed as a component of MNA. What we haven’t reach 
> conclusion is whether PSD is needed or preferred for some specific use 
> cases. It seems people have different understanding about that poll 
> result.
>
> the first problem I have with your assumption is the need for ALL 
> nodes to understand the presence of PSD.  Any node that does not 
> support PSD doesn't need to understand it.  ANy node that has been 
> enhanced to support PSD (once we have an agreed definition) will 
> understand whatever marker we adopt at that time.  So there is no need 
> to define the indicator now.
>
> [Jie] It does not require every node to support the parsing and 
> processing of PSD, it just requires MNA nodes to not simply ignore the 
> existence of PSD. If some nodes cannot process the PSD, they could 
> behave accordingly (ignore or drop, etc.). This is similar to the 
> flags used in IPv6 options to specify the action to be performed when 
> the node does not recognize an IPv6 option type.
>
> Second, it is not obvious that a bit is the right way to indicate the 
> presence and placement of PSD.  It may be.  It may not be.  At the 
> point that we agree we need PSD, we will work out what marker we chose 
> for it.   Whereas there is no reason to hold up the current draft 
> while we work out a marker for an undefined PSD case.
>
> [Jie] This is a valid point: whether one bit is enough or not for PSD 
> indication, some further discussion is needed. While we may just focus 
> on how much information about PSD is needed in the common MNA header, 
> so that it will not have too much impact to the progress of the MNA 
> header draft.
>
> Best regards,
>
> Jie
>
> Yours,
>
> Joel
>
> On 9/13/2023 10:43 PM, Dongjie (Jimmy) 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?
>
>     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.
>
>     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.
>
>     Best regards,
>
>     Jie
>
>     *From:*Greg Mirsky [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Wednesday, September 13, 2023 12:47 PM
>     *To:* Dongjie (Jimmy) <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* Tony Li <[e-mail]> <mailto:[e-mail]>;
>     [e-mail]; MPLS Working Group <[e-mail]>
>     <mailto:[e-mail]>; [e-mail]
>     *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)
>     <[e-mail]> 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:[e-mail]]
>         *Sent:* Tuesday, September 12, 2023 11:57 PM
>         *To:* Dongjie (Jimmy) <[e-mail]>
>         *Cc:* Tony Li <[e-mail]>; [e-mail]; MPLS Working
>         Group <[e-mail]>; [e-mail]
>         *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=[e-mail]> wrote:
>
>             Hi Tony,
>
>             Thanks for the response. Please see further inline:
>
>             *From:*Tony Li <[e-mail]> *On Behalf Of *Tony Li
>             *Sent:* Tuesday, September 12, 2023 1:10 PM
>             *To:* Dongjie (Jimmy) <[e-mail]>
>             *Cc:* [e-mail]; MPLS Working Group
>             <[e-mail]>; [e-mail]
>             *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
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>     _______________________________________________
>
>     mpls mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/mpls
>