Re: Several questions about NASS encapsulation

Hello Greg,

   Sorry for the delayed response.

   Sure We will add more examples for PSD without ISD, reserved In-stack opcodes and different scopes etc..

Thanx,
Jags


From: Greg Mirsky <[email protected]>
Date: Tuesday, October 18, 2022 at 3:22 PM
To: Jaganbabu Rajamanickam (jrajaman) <[email protected]>
Cc: [email protected] <[email protected]>, MPLS Working Group <[email protected]>, [email protected] <[email protected]>, DetNet WG <[email protected]>
Subject: Re: Several questions about NASS encapsulation
Hi Jags,
thank you for your quick response. I have added my follow-up notes in-line under the GIM>> tag.

Regards,
Greg

On Mon, Oct 17, 2022 at 1:35 PM Jaganbabu Rajamanickam (jrajaman) <[email protected]<mailto:[email protected]>> wrote:
Hello Greg,
    Thanks for the review.
    Please check my response below tagged with [Jags].

Thanx,
Jags

From: Greg Mirsky <[email protected]<mailto:[email protected]>>
Date: Monday, October 17, 2022 at 1:20 PM
To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, MPLS Working Group <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, DetNet WG <[email protected]<mailto:[email protected]>>
Subject: Several questions about NASS encapsulation
Dear Authors, Contributors, and All,
I have several questions about the encapsulations proposed in the -02<https://datatracker.ietf.org/doc/draft-jags-mpls-mna-hdr/02/> version of the draft:


  *   What do you see as a benefit of defining P and H flags in the NASS Header and not for, for example, NAI-Opcode 4 which is reserved for the PSD Network Actions?

        [Jags] "P" Bit is to indicate the presence of Post-Stack NAI's

                    "H" - Since we already have the NASS encoded, we would be removing this "H" in our new draft version

                    "NAI-Opcode-4" - This is only used for maintaining the ordering between the In-Stack and Post-Stack NA's

                                                     If we don't need the ordering, then this opcode need not be encoded even if there is a Post-Stack NA's present in the packet
GIM>> Could you give an example of how an LSR is expected to process NASS that has P flag set to 1 and also includes NAI-Option-4?
GIM>> Furthermore, as shown in Figure 7, IHS has NASS scope. Is that correct? I imagine that some NAs can have different scope, e.g., HbH and E2E. If the scope of the IHS is for the entire NASS, how the case of different NA scope's can be handled with the proposed encoding?



  *   Relationship between NASL and NAL. As I understand the definitions of these fields, the maximum length of a NASS is 68 octets, but the maximum length of a Network Action with its ancillary data is only 20 octets. It seems like a limitation of the length of ancillary data associated with the network action. Consider NAI-Opcode 3 (Flag-based NAI with Ancillary data), which can signal up to 12 network actions. But all these actions have only up to 16 octets for their ancillary data. Of course, the same NAI-Opcode can be used multiple times in the NASS, but that appears to me as unnecessary overhead and a waste of precious resources in the label stack.

       [Jags] "NASL" (Network Action Sub-Stack Length) - This includes the length of all encoded In-stack Network Actions (opcode + AD) in that specific NASS in #LSE's. Maximum Length of NASS is 15 LSE's

                   "NAL" (Network Action Length) - This is the length of a single In-Stack Network Action (Opcode + AD) in #LSE's. Maximum Length of NAL is 3 LSE's. (i.e) additional 3 LSE’s could be encoded.

                           First LSE carries 20 bits of AD

                           Second, third and Fourth carries 30 bits of AD each.

                   "Opcode-3" (Flag-Based NAI with Ancillary Data) - This is a special case NAI's. Not all the Flags and AD MUST be populated every-time. Depending on the needs this will be populated and expected to have a combination of bit-flags with their corresponding data.

                    "Same-Opcode Multiple Times" - This is a special case where we need an ordering between the Flag-Based NAI's. If there is no order required then the Flag-Based NAIs could be carried using a single opcode.

                      If Network Action requires an AD with more data then those NA’s Must be encoded in the Post-Stack Data.
GIM>> Can you give a rationale for such a limitation? If NASS can include up to 15 LSEs, why an NAI-Option encoding is limited to four LSE's? I think that there's no logic for such a limitation. In my opinion, it makes sense to allow for an NAI-Option encoding to use all of the NASS space, i.e., up to 15 LSEs.



  *   Next, the encapsulation that is displayed in Figure 4:

     *   What is the significance of 1 in bit0 preceding the Ancillary Data field

[Jags] The AD encoded could be any value, so Bit0 Must be "1" to prevent aliasing with the bSPLs.

        For example if we say that a node does not understand MNA and if it understands ELI. For some reasons, if the AD encoded value matches with ELI (Label value 7). Then that legacy node will consider that AD as an ELI and will start hashing based on the next Label field. If this Bit0 is “1”, then this will prevent the legacy node from more miss-interpreting the AD for ELI.
GIM>> Thank you for the explanation. I agree that that is a plausible scenario but I think that we should consider plans to support Entropy as part of the MNA solution. If that is the case, then, at some point in time, ELI might be deprecated. With all that it mind, it might be sufficient to describe the scenario and inform about the possible result while using bit0 for Ancillary Data.

     *   Do you suggest that the value of the NASL field must be set to 1 when NAI Opcode is 3?

[Jags] No,  In the example shown in the figure-4, we have encoded only one additional LSE as an AD, that is the reason the NASL value is set to "1". If we encode two more LSE then the NASL value will be "3".
GIM>> It might be helpful to update the caption(s) to reflect them as examples.

     *   Will the format for encoding the Ancillary Data field be defined in the future version of the draft?

[Jags] The format for encoding the Ancillary Data Must be defined by the application which is allocating the opcode for its use. This format will not be defined by our draft.

  *   What is the interpretation of the Post-Stack-NAI field? Is that flag-based or something else?

[Jags] The Post-Stack-NAI field indicate the value of the 8-bit value of NH defined in the draft draft-song-mpls-extension-header.
GIM>> Thank you for the clarification. It seems like it would be helpful to clarify that in the draft.

Regards,
Greg

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals