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]> wrote:

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