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?
   - 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.
   - Next, the encapsulation that is displayed in Figure 4:
      - What is the significance of 1 in bit0 preceding the Ancillary Data
      field?
      - Do you suggest that the value of the NASL field must be set to 1
      when NAI Opcode is 3?
      - Will the format for encoding the Ancillary Data field be defined in
      the future version of the draft?
   - What is the interpretation of the Post-Stack-NAI field? Is that
   flag-based or something else?


Regards,
Greg

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