Re: [mpls] FW: I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.txt

[Mach Chen <[e-mail]>]

Hi Loa,

I think that the document is ready for WG AP.

Best regards,
Mach

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Tuesday, October 19, 2021 11:43 PM
> To: Shraddha Hegde <shraddha=[e-mail]>;
> [e-mail]; Mach Chen <[e-mail]>;
> [e-mail]; Greg Mirsky <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [mpls] FW: I-D Action:
> draft-ninan-mpls-spring-inter-domain-oam-03.txt
> 
> Shraddha,
> 
> I made a mistake when I started the MPLS-RT review of this document.
> 
> I forgot add myself as Shepherd. Consequently I have not received the
> normal pings and also dropped a number of mails.
> 
> Going back over the over the mail archives I see that the authors are ready
> for WGAP.
> 
> I do not have a clear statement from the reviewers that they think the
> document is ready. Per above I might have missed some crucial mails.
> 
> Huub, Greg and Mach,
> 
> Can you confirm that your comments has been sufficiently addressed, and
> that we can go to WGAP?
> 
> /Loa
> 
> On 19/10/2021 06:50, Shraddha Hegde wrote:
> > Chairs,
> >
> > Authors believe all comments raised in MPLS-RT review have been
> > addressed and draft-ninan-mpls-spring-inter-domain-oam-04 draft is
> > ready for adoption call.
> >
> > Request chairs to proceed with next step.
> >
> > Rgds
> >
> > Shraddha
> >
> > Juniper Business Use Only
> >
> > *From:* Greg Mirsky <[e-mail]>
> > *Sent:* Wednesday, September 29, 2021 8:13 AM
> > *To:* Shraddha Hegde <[e-mail]>
> > *Cc:* [e-mail]; Mach Chen <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail]
> > *Subject:* Re: [mpls] I-D Action:
> > draft-ninan-mpls-spring-inter-domain-oam-03.txt
> >
> > *[External Email. Be cautious of content]*
> >
> > Hi Shraddha,
> >
> > I appreciate the work you and other authors put into addressing my
> > comments. I think that some of them can be discussed at a later time.
> > At this time I support the WG AP on
> draft-ninan-mpls-spring-inter-domain-oam.
> >
> > Regards,
> >
> > Greg
> >
> > On Tue, Sep 28, 2021 at 10:09 AM Shraddha Hegde
> > <shraddha=[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Dear MPLS-RT reviewers,
> >
> >     I believe draft-ninan-mpls-spring-inter-domain-oam-04 addressed all
> >     the comments received so far.
> >
> >     Are there any more comments you would like to be addressed before
> >     starting adoption call?
> >
> >     Rgds
> >
> >     Shraddha
> >
> >     Juniper Business Use Only
> >
> >     *From:* [e-mail]
> <mailto:[e-mail]>
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Sent:* Sunday, July 25, 2021 8:18 AM
> >     *To:* Shraddha Hegde <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Cc:* [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]>
> >     *Subject:* Re:[mpls] I-D Action:
> >     draft-ninan-mpls-spring-inter-domain-oam-03.txt
> >
> >     *[External Email. Be cautious of content]*
> >
> >     Hi Shraddha,
> >
> >     thank you for your work addressing my comments and clarifying
> >     questions I had.
> >
> >     I believe that RFC 7743 is not saying what you think it is saying,
> >     i.e., that the processing at a relay node must involve a particular
> >     part of the system. I believe that that is an implementation detail
> >     left out of RFC 7743. That is why I don't see that the proposed
> >     mechanism has a sufficient advantage compared to RFC 7743. At the
> >     same time, draft-ninan-mpls-spring-inter-domain-oam defines the
> >     traceroute operation, which is left outside the scope in RFC 7743.
> >     Perhaps that is the benefit, sufficient advancement for the MPLS WG
> >     to adopt and work on the newly proposed mechanism?
> >
> >     Regards,
> >
> >     Greg Mirsky
> >
> >     Sr. Standardization Expert
> >     预研标准部/有线研究院/有线产品经营部Standard Preresearch
> >     Dept./Wireline Product R&D Institute/Wireline Product Operation
> > Division
> >
> >
> >
> >
> >     E: [e-mail] <mailto:[e-mail]>
> >     www.zte.com.cn
> >
> >
> <https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!NEt6yMaO-gk!S-
> i
> >
> lgxGLQvsXoVQRq-MuYNFsLCpiqAn178MUHnRC5y477BnUsVWA_oSonGwxLJ
> X7$>
> >
> >     Original Mail
> >
> >     *Sender: *ShraddhaHegde
> >
> >     *To: *gregory mirsky10211915;
> >
> >     *CC: *[e-mail];[e-mail]
> >
> <mailto:[e-mail];[e-mail]> ;[e-mail]
> >     <mailto:[e-mail]>;[e-mail]
> >     <mailto:[e-mail]>;[e-mail]
> >     <mailto:[e-mail]>;
> >
> >     *Date: *2021/07/12 05:21
> >
> >     *Subject: RE: Re:[mpls] I-D Action:
> >     draft-ninan-mpls-spring-inter-domain-oam-03.txt*
> >
> >     Hi Greg,
> >
> >     Thanks for your comments.
> >
> >     Snipped...
> >
> >
> GIM>> I see that the new text again characterizes RFC 7743 as req
> uiring that an ASBR passes an echo reply to the control plane. Firstl
> y, taking a packet out of the fast path processing does not automat
> ically mean that it is punted to the control plane (what is the cont
> rol plane of a networking system?). Also, the new text suggests that
>  the mechanism described in the draft "simplifies operations to a gr
> eater extent in SR networks". It is not clear how that is achieved. I
> s that the result of transporting an echo reply over the MPLS data
>  plane rather than, as defined in RFC 7743, IP network? If that is
> what you see as the advantage, could you please expand on why a
> nd in which case transporting the echo reply through MPLS simplifie
> s operations in a multi-domain SR network?
> >
> <Shraddha> In terms of simplified operations what I meant was any
>  MPLS capable node can be used in return path and not necessarily
>  an echo-reply relay capable node.
> >
> If every node is echo-reply relay capable, there is no big advantage
> for operations. I agree with that. I have removed that sentence and
>  also modified the statement regarding control plane.
> >
> Pls check the latest version and let me know if it looks good now.
> >
> >
> GIM>> As I've noted earlier, it is not clear how ASBR responds if t
> he local policy prohibits it from participating in the described tracero
> ute mode.
> >
> <Shraddha> That’s a good point. I have added this scenario and int
> roduced a new return code in the reply path TLV to indicate this. B
> asically if ASBR's local
> >
> Policy does not allow it to send return path TLV, traceroute procedu
> re for dynamic path building will encounter error and other means s
> uch as static
> >
> Return path through supporting ASBR need to be used by the opera
> tor.
> >
> >
> >
> GIM>> I think that the new text requires thorough analysis of how
> the Downstream Detailed Mapping TLV is handled by the remote do
> main. You would agree that exposing the inner topology to an exter
> nal system poses a severe security risk.
> >
> <Shraddha> The procedures in this document are expected to be use
> d across multiple domains that are under same administration or clo
> sely co-operating administration.
> >
> >                              Exposing internal domain detail
> s to a legitimate source is not a problem but these procedures can
>  be used by an attacker to get internal
> >
> Domain information which is a security risk. I have updated security
>  consideration section and pointed to RFC 4379 that proposes possi
> ble security mechanisms.
> >
> >
> Yes I agree that there is scope for more discussion on this topic an
> d probably more comprehensive security measures to be added.
> >
> Have posted latest revision and attached the diff here in this thread
> .
> >
> >
> >     Rgds
> >     Shraddha
> >
> >
> >
> >     Juniper Business Use Only
> >
> >     -----Original Message-----
> >     From: [e-mail]
> >     <mailto:[e-mail]> <[e-mail]
> >     <mailto:[e-mail]>>
> >     Sent: Tuesday, June 22, 2021 7:21 AM
> >     To: Shraddha Hegde <[e-mail]
> <mailto:[e-mail]>>
> >     Cc: [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]>
> >     Subject: Re:[mpls] I-D Action:
> > draft-ninan-mpls-spring-inter-domain-oam-03.txt
> >
> >     [External Email. Be cautious of content]
> >
> >
> >     Hi Shraddha,
> >
> thank you for helping me with detailed clarifications. (Apologies for
> using plain text mode but we've noticed a problem our mailer expo
> ses in the mailarchive). Please find my follow-up notes in-lined under
>  GIM>> tag.
> >
> >     Regards,
> >     Greg Mirsky
> >     Sr. Standardization Expert
> >     预研标准部/有线研究院/有线产品经营
> 部  Standard Preresearch Dept.
> >
> /Wireline Product R&D Institute/Wireline Product Operation Division
> >     E: [e-mail] <mailto:[e-mail]>
> >     www.zte.com.cn
> >
> <https://urldefense.com/v3/__http:/www.zte.com.cn__;!!NEt6yMaO-gk!V5
> MV0a785OzuCBbf-lgU7LxtncroCaUmnJp_c2F6Unh-AmeTC4mM6j5vqvPswG
> uT$>
> >     ------------------Original Mail------------------
> >     Sender: ShraddhaHegde
> >     To: gregory mirsky10211915;
> >     CC: [e-mail];[e-mail]
> >
> <mailto:[e-mail];[e-mail]> ;[e-mail]
> >     <mailto:[e-mail]>;[e-mail]
> >     <mailto:[e-mail]>;[e-mail]
> >     <mailto:[e-mail]>;
> >     Date: 2021/06/14 22:25
> >
> Subject: RE: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-o
> am-03.txt
> >
> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\
> :* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}" _
> ue_custom_node_="true"> Hi Greg, Thank you for the follow-up.
> >     Pls see inline for replies.
> >     -----Original Message-----
> >     From: [e-mail]
> >     <mailto:[e-mail]> <[e-mail]
> >     <mailto:[e-mail]>>
> >     Sent: Monday, June 14, 2021 5:50 AM
> >     To: Shraddha Hegde <[e-mail]
> <mailto:[e-mail]>>
> >     Cc: [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]>
> >
> Subject: Re:[mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-
> 03.txt
> >
> [External Email. Be cautious of content] Hi Shraddha and Authors, th
> ank you for updating the draft. I've reviewed the new version and c
> ouldn't find most of my comments addressed. Could you kindly help
>  by pointing to the specific changes in the draft that, in your opini
> on, address my comments @
> >
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/mpls/w
> md0wbToaCEtDhgd2gFcX2HzG90/__;!!NEt6yMaO-gk!Rw6JdmD9WO__g0Gz
> LwDiRtgamBQBekpwXb-QKJzwwfZB14cHNoFoYk7utpZBQaKX$
> >
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/mpls/w
> md0wbToaCEtDhgd2gFcX2HzG90/__;!!NEt6yMaO-gk!Rw6JdmD9WO__g0Gz
> LwDiRtgamBQBekpwXb-QKJzwwfZB14cHNoFoYk7utpZBQaKX$>  ?
> >     <Shraddha>
> >
> Comment: I couldn't find a sufficient technical explanation for introd
> ucing a new mechanism for the inter-domain ping/traceroute in addit
> ion to the one described Addressed in section: 1 Introduction
> >     Diff:
> >
> GIM>> I see that the new text again characterizes RFC 7743 as req
> uiring that an ASBR passes an echo reply to the control plane. Firstl
> y, taking a packet out of the fast path processing does not automat
> ically mean that it is punted to the control plane (what is the cont
> rol plane of a networking system?). Also, the new text suggests that
>  the mechanism described in the draft "simplifies operations to a gr
> eater extent in SR networks". It is not clear how that is achieved. I
> s that the result of transporting an echo reply over the MPLS data
>  plane rather than, as defined in RFC 7743, IP network? If that is
> what you see as the advantage, could you please expand on why a
> nd in which case transporting the echo reply through MPLS simplifie
> s operations in a multi-domain SR network?
> >
> Comment: Three types of SID sub-TLVs are defined, but only use of
> one is mentioned in the document.
> >     Addressed in section: 8
> >     Diff:
> >
> Comment: I couldn't find an explanation of the relationship between
>  IPv4/IPv6 Node Address and SID in Type 3 and Type 4 sub-TLVs, re
> spectively
> >
> §            Also, in which scenario the SID field in Type 3 and
>  Type 4 sub-TLVs is recommended?
> >
> Addressed in section: I would recommend reading  sections 6, 7 an
> d 8 to get the complete description of how Type 3 and type 4 can
>  be used.
> >     Diff:
> >
> GIM>> The new text suggests that a local policy controls whether a
> n ASBR cooperates with the described traceroute mode. I can assum
> e that the policy would, for security reasons, prevent ASBR from par
> ticipating. I couldn't find an explanation in the draft of what happen
> s in that case.
> >
> Comment: And further, traceroute mode is called out of the scope o
> f RFC 7743. I've read the explanation of traceroute in the draft, and
>  I don't think it is a work Addressed in section: section 7.2
> >     Diff:
> >
> As I've noted, I am not sure what is referred to as "the control pl
> ane" in the draft in describing the solution defined in RFC 7743. RF
> C 7743 itself does not, as I understand it, require that an Echo Rep
> ly is sent to the control plane  at any step.
> >
> <shraddha> RFC 7743 describes how to relay the echo-reply in secti
> on 4.4.
> >
> The relaying node receives the echo-reply packet with destination set
>  to relay node. Then the relaying node need To examine the "Relay
>  Node Address stack TLV" to find the next relay node or the initiat
> or and send either relayed- Echo-reply or a normal echo-reply based
>  on whether there are further relay nodes to be visited.
> >
> My understanding is that this complex operation of finding the next
>  relay node from the packet and replacing That into the destination
>  address of the packet would require packet to be sent to control
> plane and cannot be done in forwarding plane.
> >
> GIM>> I think that when some processing is done outside of the fa
> st path that is not necessarily means that that function must be co
> mpleted in the control plane (which is still not clear what the "cont
> rol plane" means in the context of this draft). I can imagine that th
> at extra processing is done as bump-in-a-wire as the rate of echo re
> plies is controlled.
> >
> >       Also relay node receives the packet with destination address
>  set to the relay node. The normal behaviour  of a router for self
> addressed packets is to send the packet to control plane, the draft
> does not talk about
> >
> GIM>> Though that might be the case, implementations are using sp
> ecial cases to optimize some scenarios.
> >
> >
> Any forwarding plane behaviour change with respect to self destined
>  packets.
> >
> If you have an implementation that does that, perhaps we can look
>  at whether that is indeed the property of the solution or is imple
> mentation-specific.
> >
> <shraddha> I would like to understand if you have an implementatio
> n where the  relayed echo-reply processing on the relay node is do
> ne in forwarding plane. The RFC does not specify explicitly that  rel
> ay node processing is to  be done in forwarding plane also does n
> ot Provide enough details that would be needed to process the "rel
> ay node address stack TLV"  in forwarding plane.
> >
> Also, I'm still concern with the specification for traceroute mode in
> the draft. I have a couple of additional notes to add:
> >
> - RFC 7110, as well as RFC 7743 (I've pointed that out in my first
>  comments), has traceroute outside the scope; <Shraddha> This draft
>  has addressed traceroute and provided enough details on how trace
> route procedure Works. Let me know if you have specific questions
> on traceroute procedure.
> >
> GIM>> As I've noted earlier, it is not clear how ASBR responds if t
> he local policy prohibits it from participating in the described tracero
> ute mode.
> >
> >
> Do you have a concern with this draft addressing traceroute? As lon
> g as this draft provides a workable Solution it should not matter w
> hether previous RFCs in the area addressed traceroute or not!
> >
> - RFC 8029 (Section 4.3) recommends using the Downstream Detailed
>  Mapping TLV. I couldn't find that TLV being mentioned in the draft.
>  If you believe that TLV must not be used, could you list reasons f
> or not using the Downstream Detailed  Mapping TLV?
> >
> <Shraddha> Downstream Detailed Mapping TLV is very much used.
> >
> Section 6.2 specifies no changes to RFC 8029/RFC 8287 procedures.
> >
> The change is only in processing additional reply path TLV when it c
> omes in echo-request And also in adding this Return path TLV while
>  sending echo-reply.
> >
> " The responder MUST follow the normal FEC validation procedures
> as described in [RFC8029] and [RFC8287] and this document does n
> ot suggest any change to those procedures."
> >
> >
> If  it is not clear enough, I can update the text as below " The re
> sponder MUST follow the normal FEC validation procedures and echo
> -reply building procedures as  described in [RFC8029] and [RFC8287]
>  and this document does not suggest any change to those procedur
> es."
> >
> >     Let me know if that works for you.
> >
> GIM>> I think that the new text requires thorough analysis of how
> the Downstream Detailed Mapping TLV is handled by the remote do
> main. You would agree that exposing the inner topology to an exter
> nal system poses a severe security risk.
> >     Regards,
> >     Greg Mirsky
> >     Sr. Standardization Expert
> >     预研标准部/有线研究院/有线产品经营
> 部   Standard Preresearch Dept.
> >
> /Wireline Product R&D Institute/Wireline Product Operation Division
> >     E: [e-mail] <mailto:[e-mail]>
> >     www.zte.com.cn
> >
> <https://urldefense.com/v3/__http:/www.zte.com.cn__;!!NEt6yMaO-gk!V5
> MV0a785OzuCBbf-lgU7LxtncroCaUmnJp_c2F6Unh-AmeTC4mM6j5vqvPswG
> uT$>
> >     ------------------Original Mail------------------
> >     Sender: ShraddhaHegde
> >     To: [e-mail];[e-mail]
> >     <mailto:[e-mail];[e-mail]> ;Mach Chen;gregory
> >     mirsky10211915;[e-mail]
> >
> <mailto:[e-mail]>;[e-mail]
> m
> >     <mailto:[e-mail]>;
> >     Date: 2021/06/11 01:34
> >
> Subject: RE: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam
> -03.txt
> >     Hi All,
> >
> New version of draft-ninan-mpls-spring-inter-domain-oam is posted add
> ressing comments from MPLS-RT review.
> >
> Pls take a look and let me know if you have further comments.
> >     Rgds
> >     Shraddha
> >     Juniper Business Use Only
> >     -----Original Message-----
> >     From: mpls  On Behalf Of [e-mail]
> >     <mailto:[e-mail]>
> >     Sent: Friday, June 11, 2021 2:00 PM
> >     To: [e-mail] <mailto:[e-mail]>
> >     Cc: [e-mail] <mailto:[e-mail]>
> >
> Subject: [mpls] I-D Action: draft-ninan-mpls-spring-inter-domain-oam-03.
> txt
> >
> [External Email. Be cautious of content] A New Internet-Draft is avail
> able from the on-line Internet-Drafts directories.
> >
> This draft is a work item of the Multiprotocol Label Switching WG
> of the IETF.
> >
> Title           : PMS/Head-end based MPLS Ping and Traceroute i
> n Inter-domain SR Networks
> >     Authors         : Shraddha Hegde
> >     Kapil Arora
> >     Mukul Srivastava
> >     Samson Ninan
> >     Nagendra Kumar
> >
> Filename        : draft-ninan-mpls-spring-inter-domain-oam-03.txt
> >     Pages           : 21
> >     Date            : 2021-06-11
> >     Abstract:
> >
> Segment Routing (SR) architecture leverages source routing and tunne
> ling paradigms and can be directly applied to the use of a Multipro
> tocol Label Switching (MPLS) data plane.  A network may consist of
>  multiple IGP domains or multiple  ASes under the control of same
>  organization.  It is useful to have the LSP Ping and traceroute pro
> cedures when an SR end-to-end path spans across multiple ASes or
> domains.  This document describes mechanisms to facilitae LSP ping
> and traceroute in inter-AS/inter-domain  SR networks in an efficient
> manner with simple OAM protocol extension which uses dataplane fo
> rwarding alone for sending echo reply.
> >     The IETF datatracker status page for this draft is:
> >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ninan-m
> pls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_
> nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TuJNnI5%7B0%7Dlt;br
> >
> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-nin
> >
> an-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb
> 3iz7
> > _nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5TuJNnI5%7B0%7Dlt;br>>
> >
> >     There is also an htmlized version available at:
> >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ni
> nan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC
> 6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5VMFXpJm%7B0%7Dlt;br
> >
> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf
> >
> t-ninan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnD
> KCC
> >
> 6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5VMFXpJm%7B0%7Dlt;br
> >>
> >
> >     A diff from the previous version is available at:
> >
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ninan-
> mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3
> iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5QEnIeV0%7B0%7Dlt;br
> >
> > <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ni
> >
> nan-mpls-spring-inter-domain-oam-03__;!!NEt6yMaO-gk!WjDBRkDAvnDKCC
> 6tb3
> > iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS5QEnIeV0%7B0%7Dlt;br>>
> >
> >     Internet-Drafts are also available by anonymous FTP at:
> >
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!NEt6yM
> aO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3dfGS
> 5T0hqLuk%7B0%7Dlt;br
> >
> > <https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!NE
> >
> t6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeABzFQV3
> dfGS5T0h
> > qLuk%7B0%7Dlt;br>>
> >
> >     _______________________________________________
> >     mpls mailing list
> >     [e-mail] <mailto:[e-mail]>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls_
> _;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeAB
> zFQV3dfGS5TdmWWCx%7B0%7Dlt;br
> >
> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls
> >
> __;!!NEt6yMaO-gk!WjDBRkDAvnDKCC6tb3iz7_nNl8kTHr2mV0bTh80i0AzKeA
> BzFQV3d
> > fGS5TdmWWCx%7B0%7Dlt;br>>
> >
> >
> >     Juniper Business Use Only
> >
> >     _______________________________________________
> >     mpls mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/mpls
> >
> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls
> >
> __;!!NEt6yMaO-gk!V5MV0a785OzuCBbf-lgU7LxtncroCaUmnJp_c2F6Unh-Am
> eTC4mM6
> > j5vqrpwKt22$>
> >
> >
> > _______________________________________________
> > 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]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls