Re: [mpls] draft-ietf-mpls-mna-hdr draft updates

[Loa Andersson <[e-mail]>]

Working Group,

Some of the chairs are on vacation, this that the work is going a little 
bit slower than normal, thanks for your understanding.

However we will discuss how to progress the draft, including polling 
recent changes.

<chair hat off>

I agree with Tone that the changes that has been dome is mostly good.

One small editorial comments. In section 7 the current craft says:

7.  NAS placement in the Label Stack

    Regardless of whether packets are being forwarded based on Segment
    Routing [RFC8662], LDP [RFC5036], or RSVP-TE [RFC3209], the node
    adding an NAS to the label stack will need to place a copy of the NAS
    where it can be read by the relevant nodes.  Each node along the path
    will have Readable Label Depth (RLD) defined as the number of labels,
    starting from the top of the stack, a router can read in an MPLS
    packet received on its incoming interface(s).  If the NAS is to be
    processed by a particular node, then the entire NAS MUST be placed so
    that it is within RLD by the time the packet reaches the node.

    If the label stack is deep, several copies of the NAS may need to be
    encoded in the label stack.

I suggest  the following change in the second sentence of the first 
paragraph

s/Each node along the path will have Readable Label Depth (RLD) defined 
as the number of labels/Each node along the path will have Readable 
Label Depth (RLD) defined as the number of LSEs.

Also LSEs of format B, C and D will need to be counted.

You are using "label" the same way in section 7.1, I don't think it is 
strictly necessary to update section 7.1, but the definition should be 
correct.

Since the RLD should be defined in the framework, the authors of the 
framework need to review the definition.

<chair hat on>

/Loa



On 2023-08-31 02:24, Tony Li wrote:
> 
> These changes look good to me.
> 
> As this is now a WG document, we need to have consensus to publish these 
> changes.  I would ask that the WG chairs start the polling process.
> 
> Regards,
> Tony
> 
> 
>> On Aug 30, 2023, at 10:37 AM, Jaganbabu Rajamanickam 
>> <[e-mail]> wrote:
>>
>> Hello Everyone,
>>   I have updated the RLD specific comments from Tony and Greg.
>>  I am sending the latest draft and the diff.
>>
>> Thanx,
>> Jags
>>
>> On Wed, Aug 30, 2023 at 1:31 PM Jaganbabu Rajamanickam 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Hello Greg,
>>
>>        Thanks for the review.
>>
>>        We could add the text on RLD which you have suggested.
>>
>>        For MSD, How about the below text in section "9.1 -
>>     Encapsulating Node Responsibilities".
>>
>>        The path computation needs to know the Maximum SID Depth (MSD)
>>        that can be imposed at the ingress node of a given SR path
>>     [RFC8664].
>>        This ensures that the label stack depth of a computed path does not
>>        exceed the maximum number of labels (i.e., MSD) the node is
>>     capable of imposing.
>>        The MSD needs to include the MNA Sub-Stacks to be added.
>>
>>     Thanx,
>>     Jags
>>
>>     On Mon, Aug 21, 2023 at 2:52 PM Greg Mirsky <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi Jags,
>>         thank you for sharing the updates. I have a couple
>>         of questions about RLD.
>>
>>           * The updated draft presents RLD as being a newly defined
>>             term introduced in this draft. Although RLD might be
>>             related to ERLD-MSD defined in RFC 9088, that is okay if
>>             the draft provides a clear definition of the new term.
>>             Section 7, in my understanding, describes the usage of RLD
>>             but is rather short on defining it. Would the following
>>             text be acceptable:
>>
>>         Readable Label Depth is defined as the number of
>>         labels, starting from the top of the stack, a router can read
>>         in an MPLS packet received on its incoming interface(s).
>>
>>           * It looks like RLD is presented as a system-wide parameter.
>>             I think that it might be more accurate to consider RLD per
>>             ingress interface (see the proposed definition of RLD above).
>>
>>         Also, do the Editors find it helpful to note that the Base
>>         MPLS Imposition MSD affects the imposition of the label stack
>>         that includes MNA?
>>
>>         Regards,
>>         Greg
>>
>>         On Mon, Aug 21, 2023 at 10:29 AM Jaganbabu Rajamanickam
>>         (jrajaman) <jrajaman=[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>             Hello Everyone, ____
>>
>>                Attaching new attachments and resending.____
>>
>>             __ __
>>
>>             Thanx,____
>>
>>             Jags____
>>
>>             __ __
>>
>>             *From: *Jaganbabu Rajamanickam <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Date: *Monday, August 21, 2023 at 1:21 PM
>>             *To: *mpls <[e-mail] <mailto:[e-mail]>>
>>             *Cc: *mpls-chairs <[e-mail]
>>             <mailto:[e-mail]>>,
>>             [e-mail]
>>             <mailto:[e-mail]>
>>             <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Subject: *draft-ietf-mpls-mna-hdr draft updates____
>>
>>             Hello Everyone,____
>>
>>                Based on the WG discussion and comments, we have
>>             updated the draft. I am attaching the latest draft and the
>>             diff before publishing. Please take a look and provide
>>             feedback.____
>>
>>             __ __
>>
>>             Below are the updates made to the draft.____
>>
>>             __ __
>>
>>              1. Define and use term RLD (Readable Label Depth)____
>>              2. Add MNA Label in Figure 1____
>>              3. Packet format to show bits 0 – 9____
>>              4. Reserved bits are marked as MUST be zero and ignored
>>                 on receipt____
>>              5. Section 7 to clarify PHP node behaviour____
>>              6. Section 7.1 added on “actions on node pushing labels”____
>>              7. Deleted stale section of 13.3 on “Network Actions
>>                 Flags with Ancillary Data”____
>>              8. Designated Editors____
>>              9. Informational References (both moved from normative)____
>>
>>             __ __
>>
>>             __ __
>>
>>             Thanx,____
>>
>>             Jags____
>>
>>             _______________________________________________
>>             mpls mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/mpls
>>             <https://www.ietf.org/mailman/listinfo/mpls>
>>
>> <draft-ietf-mpls-mna-hdr-03.txt><draft-ietf-mpls-mna-hdr-03.diff.html>_______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]