Re: [mpls] [EXTERNAL] Re: [Errata Held for Document Update] RFC3031 (6450)

[Stewart Bryant <[e-mail]>]

Duane

I checked every instance of L1 (only used for labels in the stack and not in the glossary), L2 (again as I remember I could only find instances where it was used for labels in the label stack though not always prefixed by “label") and L3 where it was mainly used on its own to indicate network layer as per the glossary and mainly used in conjunction with the prefix “label” to indicate that it was label 3. Including the term “Label” to make “Label L3” in a tiny number of cases removed any possibility of ambiguity.

Stewart

> On 15 Aug 2022, at 15:06, Duane Anderson <[e-mail]> wrote:
> 
> Stewart,
>  
> I did not write an Errata proposal. I was merely pointing out what I saw as ambiguities in the RFC-3031 to the IETF MPLS group. There may be more possible ambiguates. I didn’t and don’t want to be a member of the IETF MPLS because my business is not regarding the TCP/IP or OSI model routing protocols for internetworking between independent networks.
>  
> My business is regarding high-performance data bus networks that are deterministic, hard-real-time, statically scheduled, time-triggered, polynomial (P) time validated and so P time verifiable, safety-critical, and mission-critical computer networks that have highly efficient, work-conserving protocols that inherently have the graceful degradation property. Accordingly, certain internetworking hop-by-hop, routes must be pre-engineered and prioritized thus avoiding internetwork broadcasts and allowing high utilization. The MPLS fulfills the necessary requirements.  
>  
> I have not re-read RFC-3031 and only re-reading what I wrote in my original e-mail, labels L1, L2, L3 are used to refer to a) OSI protocol layers, b) labels attached to packets, and c) packet stacks. In my original e-mail I had attached a PDF of RFC-3031, which I have not re-read, that had 44 ambiguous L1, L2, L3 references. The changes you proposed in your e-mail below, seems to be a good start.
>  
> This is a matter for the IETF MPLS group to decide.
>  
> Regards, 
>  
> Duane
>  
> From: Stewart Bryant <[e-mail]> 
> Sent: August 15, 2022 4:59 AM
> To: Duane Anderson <[e-mail]>
> Cc: Stewart Bryant <[e-mail]>; Greg Mirsky <[e-mail]>; Alexander Vainshtein <[e-mail]>; mpls <[e-mail]>; Chris Smiley <[e-mail]>; Andrew Alston <Andrew.Alston=[e-mail]>; The IESG <[e-mail]>; Andrew Alston - IETF <[e-mail]>; [e-mail]; Acee Lindem (acee) <acee=[e-mail]>; Ross Callon <[e-mail]>; [e-mail]; RFC Errata System <[e-mail]>
> Subject: Re: [mpls] [EXTERNAL] Re: [Errata Held for Document Update] RFC3031 (6450)
>  
>  
> Duane
>  
> You wrote a complex and incomplete Errata proposal.
>  
> I remain of the view that the changes are not necessary as we have experimental evidence that engineers correctly implement the design, and that context within the next is sufficient to provide adequate disambiguation of the terms.
>  
> (Apologies for the editorial ordering not matching the text ordering)
>  
> I think that the errata that you mean to propose is:
>  
> OLD
>    A given LSR Rd may bind label L1 to FEC F, and distribute that
>    binding to label distribution peer Ru1.  Rd may also bind label L2 to
>    FEC F, and distribute that binding to label distribution peer Ru2.
>    Whether or not L1 == L2 is not determined by the architecture; this
>    is a local matter.
> NEW
>    A given LSR Rd may bind label L1 to FEC F, and distribute that
>    binding to label distribution peer Ru1.  Rd may also bind label L2 to
>    FEC F, and distribute that binding to label distribution peer Ru2.
>    Whether or not label L1 == label L2 is not determined by the architecture; this
>    is a local matter.
>  
>  
> =======
> OLD
>    Consider the case of packets P1 and P2, each of which has a
>    destination address whose longest match, throughout a particular
>    routing domain, is address prefix X.  Suppose that the Hop-by-hop
>    path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4,
>    R2, R3>.   Let's suppose that R3 binds label L3 to X, and distributes
>    this binding to R2.  R2 binds label L2 to X, and distributes this
>    binding to both R1 and R4.  When R2 receives packet P1, its incoming
>    label will be L2.  R2 will overwrite L2 with L3, and send P1 to R3.
>    When R2 receives packet P2, its incoming label will also be L2.  R2
>    again overwrites L2 with L3, and send P2 on to R3.
> NEW
>    Consider the case of packets P1 and P2, each of which has a
>    destination address whose longest match, throughout a particular
>    routing domain, is address prefix X.  Suppose that the Hop-by-hop
>    path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4,
>    R2, R3>.   Let's suppose that R3 binds label L3 to X, and distributes
>    this binding to R2.  R2 binds label L2 to X, and distributes this
>    binding to both R1 and R4.  When R2 receives packet P1, its incoming
>    label will be L2.  R2 will overwrite label L2 with label L3, and send P1 to R3.
>    When R2 receives packet P2, its incoming label will also be label L2.  R2
>    again overwrites label L2 with label L3, and send P2 on to R3.
>  
> ========
> OLD
>       -  When LSR Ru initially labels a hitherto unlabeled packet, if
>          the longest match for the packet's destination address is X,
>          and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru
>          a binding of label L1 to X, along with a stack attribute of L2,
>          then
>  
>          1. Ru must push L2 and then L1 onto the packet's label stack,
>             and then forward the packet to Rd;
>  
>          2. When Ru distributes label bindings for X to its label
>             distribution peers, it must include L2 as the stack
>             attribute.
> NEW
>       -  When LSR Ru initially labels a hitherto unlabeled packet, if
>          the longest match for the packet's destination address is X,
>          and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru
>          a binding of label L1 to X, along with a stack attribute of label L2,
>          then
>  
>          1. Ru must push label L2 and then label L1 onto the packet's label stack,
>             and then forward the packet to Rd;
>  
>          2. When Ru distributes label bindings for X to its label
>             distribution peers, it must include label L2 as the stack
>             attribute.
>  
>  
> ========
> OLD
>      4. Suppose that BGP Border Router B1 receives a labeled Packet P,
>          where the label on the top of the label stack corresponds to an
>          address prefix, X, to which the route is a BGP route, and that
>          conditions 3b, 3c, 3d, and 3e all hold.  Then before sending
>          packet P to I1, B1 must replace the label at the top of the
>          label stack with L1, and then push on label L2.
> NEW
>      4. Suppose that BGP Border Router B1 receives a labeled Packet P,
>          where the label on the top of the label stack corresponds to an
>          address prefix, X, to which the route is a BGP route, and that
>          conditions 3b, 3c, 3d, and 3e all hold.  Then before sending
>          packet P to I1, B1 must replace the label at the top of the
>          label stack with label L1, and then push on label L2.
>  
> ========
> And whilst we are at it
>  
> OLD
>    L2                        Layer 2 L3                        Layer 3
> NEW
>    L2                        Layer 2 (datalink layer)
>    L3                        Layer 3 (Network layer)
> END
>  
> Is that correct?
>  
> Regards
>  
> Stewart
>  
> On 12 Aug 2022, at 15:51, Duane Anderson <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Ladies and Gentlemen, 
>   
> I first reported the issue re RFC-3031 because IETF RFC-3031 MPLS (a.k.a. Layer 2.5) is has been specified as a part of a NATO standard real-time computer LAN system, where LANs can be internetworked and connected to a WAN. The LAN/WAN will follow IEEE 802, 802.1, and 802.2 (ISO/IEC 8802-2). For hard-real-time and safety-critical reasons, these the LANs and WAN will have static virtual circuits, using private MAC addressing to identify data terminal equipment (DTE) and data communication equipment (DCE). 
>   
> The issue re RFC-3031 is its ambiguities. In the conversations Re: [mpls] [Errata Held for Document Update] RFC3031 (6450), some express the opinion that because those participating in the conversation have become accustomed to the ambiguities and because “It is also not local to RFC 3031, the MPLS working group or the IETF”, that there is no need nor responsibility for RFC-3031 be held for document update.
>   
> The IETF cannot control who will use its standard for purposes other than the Internet. Safety-critical and mission-critical systems use IEEE, ISO, MIL, ANSI, SAE, etc., standards for systems that must be certified to be complain with the standards, which is possible because these standards are necessarily well written. The ambiguity of RFC-3031 will make it difficult for any developer of a product compliant to the NATO standard, which is derived from many industry standards. 
>   
> An implementation of a product based upon an ambiguous specification is not erroneous. The specification is erroneous and a failure of the product to perform as required during operation due to a latent defect in the design due to an ambiguity in the specification will be the the fault of the IETF, even though it or any member cannot be held responsible.  
>   
> Sincerely, 
>   
> Duane L. Anderson, President 
> Edgewater Computer Systems, Inc.
> 50 Hines Road, Suite 200 
> Ottawa, ON K2K 2M5 Canada 
> Telephone: [phone] 
> Facsimile: [phone] 
> ________________________________________________________________________
>    
> This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you are not the intended recipient, please notify me at the telephone number shown above or by return e-mail and immediately delete this communication and any copy. Thank you.
>    
> Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si ce message vous est parvenu par erreur, vous êtes en conséquence prié de nous aviser immédiatement par téléphone ou par courriel. De plus veuillez détruire ce message immédiatement. Merci. 
>   
> From: Greg Mirsky <[e-mail] <mailto:[e-mail]>> 
> Sent: August 4, 2022 5:38 PM
> To: Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>
> Cc: Andrew G. Malis <[e-mail] <mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail] <mailto:acee=[e-mail]>>; mpls <[e-mail] <mailto:[e-mail]>>; Chris Smiley <[e-mail] <mailto:[e-mail]>>; Andrew Alston <Andrew.Alston=[e-mail] <mailto:Andrew.Alston=[e-mail]>>; Duane Anderson <[e-mail] <mailto:[e-mail]>>; Andrew Alston - IETF <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Ross Callon <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; RFC Errata System <[e-mail] <mailto:[e-mail]>>; The IESG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [mpls] [EXTERNAL] Re: [Errata Held for Document Update] RFC3031 (6450)
>   
> I concur with the previously stated opinion that the errata has not affect the correctness of the interpretation and we have no evidence that it lead to a erroneous implementation. 
>   
> Regards, 
> Greg 
>   
> On Thu, Aug 4, 2022, 03:11 Alexander Vainshtein <[e-mail] <mailto:[e-mail]>> wrote:
> Andy, Acee, and all, 
> +1. 
>   
>   
>   
> Regards, 
> Sasha 
>   
> Office: [phone] 
> Cell:      [phone] 
> Email:   [e-mail] <mailto:[e-mail]>
>   
> From: mpls <[e-mail] <mailto:[e-mail]>> On Behalf Of Andrew G. Malis
> Sent: Thursday, August 4, 2022 1:53 PM
> To: Acee Lindem (acee) <acee=[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Chris Smiley <[e-mail] <mailto:[e-mail]>>; Andrew Alston <Andrew.Alston=[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]>; Andrew Alston - IETF <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; RFC Errata System <[e-mail] <mailto:[e-mail]>>; The IESG <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>   
> I also agree. 
>   
> Cheers, 
> Andy 
>   
>   
> On Wed, Aug 3, 2022 at 7:13 AM Acee Lindem (acee) <acee=[e-mail] <mailto:[e-mail]>> wrote:
> Agree with Stewart. I’ve never had problems with the ambiguity of the acronyms when they are consumed in context. 
> Acee 
>   
> From: mpls <[e-mail] <mailto:[e-mail]>> on behalf of Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Date: Wednesday, August 3, 2022 at 2:46 AM
> To: Andrew Alston <Andrew.Alston=[e-mail] <mailto:[e-mail]>>
> Cc: Chris Smiley <[e-mail] <mailto:[e-mail]>>, Andrew Alston - IETF <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Ross Callon <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, RFC Errata System <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>   
> Hi Andrew, 
>   
> I agree with what you say, and that it should be held for update.
>   
> However I think that this is an editorial rather than a technical change.
>   
> Stewart 
>   
> Sent from my iPad 
>   
> 
> On 2 Aug 2022, at 22:37, Andrew Alston <Andrew.Alston=[e-mail] <mailto:[e-mail]>> wrote:
> 
> As I said in my notes, while I do believe that this errata contains things that probably should be rectified, considering the wide number of changes this would entail within the document, I do not consider this a simple errata, and hence believe that if these changes are to be made, they need to be done when and if there is a BIS document published to update this and not a simple errata.
>   
> Hence, I believe that holding this for an update and if at some point someone chooses to push through a BIS to update this – along with any other potential changes – these fixes can be incorporated at that point, until then – I’m going to stand by my hold for update status on this one. 
>   
> Thanks 
>   
> Andrew 
>   
>   
> From: mpls <[e-mail] <mailto:[e-mail]>> On Behalf Of Chris Smiley
> Sent: Wednesday, August 3, 2022 12:29 AM
> To: Andrew Alston - IETF <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; RFC Errata System <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [mpls] [Errata Held for Document Update] RFC3031 (6450)
>   
> 
> Hi Andrew,
> 
> We note that this erratum has already been marked as "Held for Document Update”. Please let us know if you would like us to set it back to “Reported” so you can make further updates. 
> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> > On Jul 28, 2022, at 4:45 AM, Loa Andersson <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Andrew,
> > 
> > I think we should reject this errata, it has been running code for 25 years or more, no problems reported. It is also not local to RFC 3031, the MPLS working group or the IETF.
> > 
> > RFC Editor (Errata System),
> > 
> > I think Andrew need to OK this, but if not necessary just go and reject.
> > 
> > /Loa
> > 
> > PS
> > 
> > THe addresses to Eric, Ross and Arun are likely not current, but I don't think we need to consult them.
> > 
> > On 2022-05-26 15:56, RFC Errata System wrote:
> >> The following errata report has been held for document update
> >> for RFC3031, "Multiprotocol Label Switching Architecture".
> >> --------------------------------------
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid6450 <https://clicktime.symantec.com/15t69fu7iJ4ozjCnNYtuw?h=5JH45E3EUZ_b5nvXomLlENEgrlmEg8OA7bUkJPB4Smc=&u=https://www.rfc-editor.org/errata/eid6450>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Technical
> >> Reported by: Duane L. Anderson <[e-mail] <mailto:[e-mail]>>
> >> Date Reported: 2021-03-0
> >> Held by: Andrew Alston (IESG)
> >> Section: GLOBAL
> >> Original Text
> >> -------------
> >> 2.2. Terminology defines the terms
> >> Layer 2 layer 2 the protocol layer under layer 3
> >> (which therefore offers the services used by layer 3)
> >> Layer 3 the protocol layer at which IP and its associated
> >> routing protocols operate
> >> 2.3. Acronyms and Abbreviations defines
> >> L2 Layer 2
> >> L3 Layer 3
> >> However, in 3.14. Scope and Uniqueness of Labels, 4.3. Label Stacks and Implicit Peering, 4.5. LSP Trees as Multipoint-to-Point Entities, and 4.6. LSP Tunneling between BGP Border Routers, L1, L2 and L3 are used as differentiating names for certain labels attached to packets.
> >> Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 frame header and to a layer 2 switch, which is correct.
> >> However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is used to refer to the LIFO (stack) ordinal number of a label then named L1 and given a protocol layer 2 protocol of layer 2 (L2). Furthermore, labels named L2 and then L1 are pushed onto the stack of labels prefixed to the packet. To top it all off the packet's stack attribute as protocol level 2 (L2).
> >> Of course, in 3.17. LSP Next Hop, 4.1.5. The Implicit NULL Label, 5.1.1.2 <https://clicktime.symantec.com/15t5egjQxbyFX4FF7CW2D?h=TYSmGQoWczYDkVZeae2uwlvLN5DG1GmH8K2W7EZzP_o=&u=http://5.1.1.2>. PushConditional, 5.1.1.4 <https://clicktime.symantec.com/15t5jWvhRDeqw15AekuAq?h=yMu6Xscy2Ue3c3FXuqIw0L55aBo3uyF7459ZPdexD4k=&u=http://5.1.1.4>. PulledConditional, 5.1.2.2 <https://clicktime.symantec.com/15t5pM7ysqLSLwu6CKJKT?h=rO_OhPVxxMIqRoJqmqsmtS4sGEt9xZH38_-0S79V_NU=&u=http://5.1.2.2>. RequestWhenNeeded, 5.1.3. Upstream LSR: NotAvailable Procedure, 5.1.4. Upstream LSR: Release Procedure,5.1.4.2 <https://clicktime.symantec.com/15t5uBKGLT22ktj1jshU5?h=Fg4deNeYkNs31F0pY9NPB3uRdpexIUXsj9g1YRzGv5c=&u=http://5.1.4.2>. NoReleaseOnChange, 5.1.5. Upstream LSR: labelUse Procedure, 5.2.2. Schemes for LSRs that do not Support Label Merging, refer to L3 meaning level 3, which is correct.
> >> Furthermore, in 3.1. Labels, 3.2. Upstream and Downstream LSRs, 3.4. Label Assignment and Distribution, 3.5. Attributes of a Label Binding, 3.14. Scope and Uniqueness of Labels, 4.1.2.2 <https://clicktime.symantec.com/15t5ZrY8VzHf77RKZe6sb?h=L4L-YSEaq8hRiqCsfa-OpImQ3ThaOAUjJ9y0Mx4lV1A=&u=http://4.1.2.2>. Distributing Labels, 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2 <https://clicktime.symantec.com/15t5z1WYo4hdAqYwHS6ch?h=3UH5xrmv5TLLY6Q1zHHZkbuxHS8QmekRxNN3TKocVTI=&u=http://5.1.5.2>. UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure
> >> * L is used as a name for a certain label attached to packet, and
> >> * L is used as a arbitrary value assigned to a label attached to a packet
> >> Corrected Text
> >> --------------
> >> I have not provided any corrected text as I've literally "highlighted" 44 places in a pdf format file of RFC 3031 that are ambiguous.
> >> As there is no facility to attach a file to this Report Errata for RFC3031 form, i will send the file commented pdf file upon request.
> >> Notes
> >> -----
> >> My rational for highlighting (no pun intended) these problems is that the overloading of the L2, L3 abbreviations layer 2 and layer 3, with the names L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names for the ordinal position of a label prefixed to a payload, then to use L2 and L3 as to actually mean layer 2 and layer is uh ... sloppy.
> >> Honestly, I can't understand how RFC 3031 has been posted for twenty years and that it is on the Standards Track and no one has found these problems.
> >> Its similar to when someone publishes a mathematical treatise and use the same set of variable names {x, y, z, t} over and over again in different contexts spread throughout the paper. Its intractable and practically gibberish.
> >> I apologize if my criticism is harsh regarding this problem but I spent a considerable amount of my time reading this document trying to make sense of it before I realized that the fault is not mine but it is of the document.
> >> [Andrew] This seems to wide and generalized to be a simple errata, as such I am marking this as held for document update.
> >> --------------------------------------
> >> RFC3031 (draft-ietf-mpls-arch-06)
> >> --------------------------------------
> >> Title : Multiprotocol Label Switching Architecture
> >> Publication Date : January 2001
> >> Author(s) : E. Rosen, A. Viswanathan, R. Callon
> >> Category : PROPOSED STANDARD
> >> Source : Multiprotocol Label Switching
> >> Area : Routing
> >> Stream : IETF
> >> Verifying Party : IESG
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/mpls <https://clicktime.symantec.com/15t64qhqFgPDanNrpzVmK?h=GB_ps6oh9cKTw4cZmv4jkEBBJQlZrMGRVeZIqCkbPxM=&u=https://www.ietf.org/mailman/listinfo/mpls>
> > 
> > -- 
> > Loa Andersson email: [e-mail] <mailto:[e-mail]>
> > Senior MPLS Expert [e-mail] <mailto:[e-mail]>
> > Bronze Dragon Consulting phone: [phone]
> > 
> 
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://clicktime.symantec.com/15t64qhqFgPDanNrpzVmK?h=GB_ps6oh9cKTw4cZmv4jkEBBJQlZrMGRVeZIqCkbPxM=&u=https://www.ietf.org/mailman/listinfo/mpls>
>   
> Internal All Employees
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://clicktime.symantec.com/15t64qhqFgPDanNrpzVmK?h=GB_ps6oh9cKTw4cZmv4jkEBBJQlZrMGRVeZIqCkbPxM=&u=https://www.ietf.org/mailman/listinfo/mpls>
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://clicktime.symantec.com/15t64qhqFgPDanNrpzVmK?h=GB_ps6oh9cKTw4cZmv4jkEBBJQlZrMGRVeZIqCkbPxM=&u=https://www.ietf.org/mailman/listinfo/mpls>
> 
> 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.
> 
> 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.
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>