Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[Alexander Vainshtein <[e-mail]>]

John,
Regarding your question "Do you think that it would be safe to re-use the RFC 8662 techniques for GAL?  I.e., a node indicates whether it can receive a GAL at the top of an MPLS label stack and the ingress LSR constructs MPLS label stacks in which a GAL rises to the top of the stack only at such nodes":

IMHO the answer depends on what the node that detects GAL at ToS but not BoS is handing this. I see two options:

1.       Option 1: Pop GAL, process the ACH and forward based on the next label in the stack. This would be safe but probably useless for the specific applications people are trying to address

2.       Option 2:  Same as above, but push GAL on top of the new label stack when forwarding the packet based on the next label in the stack) - i.e., similar to what is defined or the Router Alert label. This would probably work for the targeted applications, but would not be safe - unless you only pass thru the new nodes that understand GAL at ToS but not BoS.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: John E Drake <[e-mail]>
Sent: Tuesday, June 22, 2021 6:35 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; Haoyu Song <[e-mail]>; Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>; Loa Andersson <[e-mail]>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Hi,

Snipped, comment inline [JD1}.

Yours Irrespectively,

John


1.         I have sent the previous email as a response to your aside claim that "RFC 8662 does not define what a transit LSR should do when it finds an [ELI, EL] pair at the top of the MPLS label stack, either when it understands the label pair or when it doesn't". As I see it, both Bruno and I have demonstrated that this behavior is defined

[JD]  Perhaps I missed it, but nowhere in RFC 8662 do I see a statement of the form:  "This document updates the transit LSR behavior defined in RFC 6790 to allow a transit LSR that understands entropy labels to remove an [ELI, EL] pair that it sees at the top of an MPLS label stack.  This requires a transit LSR to indicate this capability to other LSRs in the SR domain and it requires the ingress LSR to ensure that when it inserts [ELI, EL] pairs in the MPLS label stack they will only be at the top of the MPLS label stack when received by a transit LSR with this capability."
[[Sasha]] I have not seen any such statement either. However, I think that we may be dealing with a terminology issue. I believe that in SR a node that originates advertisement, say, of an IGP Prefix SID, is considered as the egress node for the segment represented by this SID, even if it is a transit node for an LSP that includes this SID in the middle of the stack of SIDs. This is why they have assumed that considerations of 6790 pertaining to egress LERs are sufficient.

[JD1]  This seems like quite a stretch.  Also, as I mentioned in my first email, there is no discussion of how an [ELI, EL] pair at the top on a MPLS label stack is to be processed or ensuring, when building an MPLS label stack, that [ELI, EL] pairs need to be inserted such that they rise to the top of an MPLS label stack only when they are received by a transit LSR that understands entropy labels.

[JD1}  Do you think that it would be safe to re-use the RFC 8662 techniques for GAL?  I.e., a node indicates whether it can receive a GAL at the top of an MPLS label stack and the ingress LSR constructs MPLS label stacks in which a GAL rises to the top of the stack only at such nodes.  Or do implementations of RFC 5586 explicitly scan an MPLS label stack for GAL labels that are not at the bottom of the stack?  This seems like silly behavior but one never knows.



Juniper Business Use Only

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.