Re: Several questions about NASS encapsulation

Hello Greg,
    Thanks for the review.
    Please check my response below tagged with [Jags].

Thanx,
Jags

From: Greg Mirsky <[email protected]>
Date: Monday, October 17, 2022 at 1:20 PM
To: [email protected] <[email protected]>, MPLS Working Group <[email protected]>, [email protected] <[email protected]>, DetNet WG <[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



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



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

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

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

Regards,
Greg

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