Re: [mpls] MPLS client layer over an IGP underlying network

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Shahram Davari
> 发送时间: 2012年12月21日 1:31
> 收件人: Lucy yong
> 抄送: [e-mail]; [e-mail];
> [e-mail]
> 主题: Re: [mpls] MPLS client layer over an IGP underlying network
> 
> Please don't mix up things. The MPLS protocol design I agree must be done by
> MPLS WG. But the question is whether your proposal meets the network
> virtualization requirements.

Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over IP encapsulation mechanisms have been discussed before?

Since MPLS-in-UDP is just intended to be used in the scenarios where MPLS-in-GRE/IP has been used and is to be used, MPLS-in-UDP should be discussed in the same WG where MPLS-in-GRE/IP has been discussed.

Xiaohu

> The NVO3 task is to document the issues, requirements and framework for
> NvO3. Then if MPLS over IP looks like a suitable solution that meets the
> requirements such as the scale, mobility, etc, then they will ask MPLS WG for
> protocol design.
> 
> So before proceeding this draft, I think you should take it to NVO3 WG and
> convince them this solution meets their requirements and framework.
> 
> We don't want IETF do design N number of solutions for the same problem, do
> we?
> 
> -Shahram
> 
> 
> 
> Regards,
> Shahram
> 
> 
> On Dec 20, 2012, at 8:56 AM, "Lucy yong" <[e-mail]> wrote:
> 
> > Network virtualization overlay is discussed under nvo3 WG. This does not
> mean that nvo3 WG has to design a new protocol for a underlying network or a
> new protocol for a overlay network. In fact, people there aim on leverage
> standard network protocols to accomplish them. IMO: these expansions on an
> existing standard protocol have to be worked out in the protocol WG group, it
> should not give nvo3 WG free right to enhance these protocols. For a brand
> new protocol for network virtualization overlay, nvo3 WG may be the place to
> start.
> >
> > Lucy
> >
> >> -----Original Message-----
> >> From: Shahram Davari [mailto:[e-mail]]
> >> Sent: Thursday, December 20, 2012 10:34 AM
> >> To: Lucy yong
> >> Cc: Shane Amante; [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: Re: [mpls] MPLS client layer over an IGP underlying network
> >>
> >> Network virtualization overlay must be discussed and consented  in NVO3
> >> WG.
> >>
> >> Regards,
> >> Shahram
> >>
> >>
> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" <[e-mail]> wrote:
> >>
> >>> Hi Shane,
> >>>
> >>> I understand operator concern on a new encapsulation to an existing
> >> network.
> >>>
> >>> However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS
> >> network at all.
> >>> MPLS-in-UDP is to enable MPLS client layer to be decoupled from MPLS
> >> server layer and use MPLS client layer as overlay network and an IGP as
> >> a underlying network for transport. Such application is for DC. You may
> >> argue why not use the GRE which is for MPLS layer over an IGP underling
> >> network. We have pointed out in the draft that current routers in DC
> >> barely support GRE based load balancing and MPLS-in-GRE are barely used
> >> in SP networks too. Most of routers in DC perform upd port based load
> >> balancing now.
> >>>
> >>> From the architecture perspective, the UDP encapsulation has
> >> advantage over GRE encapsulation too. In UDP encapsulation, the frame
> >> header decouples the overlay and underlying network clearly, i.e. outer
> >> header and overlay header. UDP belongs to outer header, which
> >> underlying network uses only. However, GRE header has the fields for
> >> the overlay network and uses the key field for flow entropy. For load
> >> balancing, it requires the underlying network uses GRE header too. In
> >> short, GRE ties the overlay and underlying networks together. Since it
> >> has not used a lot, people are not aware of the disadvantage of such
> >> coupling.
> >>>
> >>> As the industry moves toward network virtualization overlay and
> >> decouples overlay networks from the underlying network. A clear
> >> separation of overlay header and underlying header is a "MUST" in my
> >> opinion. If we count GRE as the overlay header, then for IPv4
> >> underlying network, there is no field for the flow entropy. This is the
> >> reason we propose the UDP encapsulation: for an IGP based underlying
> >> network. In fact, it can support any overlay network beside MPLS client
> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >>>
> >>> You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-in-L2TP-
> >> in-UDP schema also provides a overlay (L2TP) and underlying (IP)
> >> network decoupling. L2TP protocol (rfc3931) provides good security
> >> mechanism and has the embedded control function too. Therefore,
> someone
> >> can use it for MPLS client layer over Internet. To have MPLS client
> >> layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP is a
> >> overkill and too complex. Here we need a schema to support IGP
> >> underlying transport without touching a overlay header. UDP
> >> encapsulation is the best choice to accomplish that and minimize the
> >> changes on existing routers, e.g. change at edge routers, no change on
> >> transit routers.
> >>>
> >>> Regards,
> >>> Lucy
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Xuxiaohu [mailto:[e-mail]]
> >>>> Sent: Thursday, December 20, 2012 4:14 AM
> >>>> To: Shane Amante
> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> >> [e-mail];
> >>>> [e-mail]; [e-mail]
> >>>> Subject: Discussion on how to transport MPLS over UDP tunnels
> >>>>
> >>>> Hi Shane,
> >>>>
> >>>> Thanks for your further comments and please see my response inline.
> >>>>
> >>>> Note: I changed the subject line according to Loa's suggestion.
> >>>>
> >>>>> -----邮件原件-----
> >>>>> 发件人: Shane Amante [mailto:[e-mail]]
> >>>>> 发送时间: 2012年12月19日 22:38
> >>>>> 收件人: Xuxiaohu
> >>>>> 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> >>>> [e-mail];
> >>>>> [e-mail]; [e-mail]
> >>>>> 主题: Re: [mpls] poll to see if we have support to make draft-xu-
> >>>> mpls-in-udp an
> >>>>> mpls working group document
> >>>>>
> >>>>> Xiaohu,
> >>>>>
> >>>>> On Dec 18, 2012, at 11:50 PM, Xuxiaohu <[e-mail]>
> wrote:
> >>>>> -----邮件原件-----
> >>>>>>> 发件人: Shane Amante [mailto:[e-mail]]
> >>>>>>> 发送时间: 2012年12月19日 11:58
> >>>>>>> 收件人: Rogers, Josh
> >>>>>>> 抄送: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-
> >>>> [e-mail];
> >>>>>>> [e-mail]; [e-mail]
> >>>>>>> 主题: Re: [mpls] poll to see if we have support to make draft-xu-
> >>>> mpls-in-udp
> >>>>> an
> >>>>>>> mpls working group document
> >>>>>>>
> >>>>>>>
> >>>>>>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh"
> >>>> <[e-mail]>
> >>>>>>> wrote:
> >>>>>>>> I share your SP perspective, and do not see the problem this
> >>>> solution
> >>>>>>>> addresses in practice any longer.
> >>>>>>>
> >>>>>>> +1.  Please do not define yet another MPLS-over-IP encapsulation.
> >>>> The
> >>>>> IETF
> >>>>>>> already standardized MPLS over GRE.  The IETF has also
> >>>> standardized
> >>>>> MPLS
> >>>>>>> over L2TPv3/UDP/IP, which had seen some deployment in at least
> >> one,
> >>>> very
> >>>>>>> large operator network that I'm aware of to support carriage of
> >>>> L3VPN over
> >>>>> an
> >>>>>>> IP-only network.
> >>>>>>
> >>>>>> Hi Shane,
> >>>>>>
> >>>>>> Thank you for telling us there are actual deployments of MPLS over
> >>>> IP in at
> >>>>> least one, very large operator network. This fact must be very
> >>>> valuable to those
> >>>>> people who had believed there is no application of MPLS over IP in
> >>>> today's SP
> >>>>> networks.
> >>>>>>
> >>>>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
> >>>>>>> [NOTE: the dates the above were published was back in the 2006
> >>>>> timeframe!]
> >>>>>>>   RFC 4665 for requirements related to VPLS that say that VPLS
> >>>> may be
> >>>>>>> carried over L2TPv3
> >>>>>>>   And, here's evidence showing that at least one vendor has
> >>>>> implemented
> >>>>>>> IPVPN's over L2TPv3:
> >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html
> >>>>>>
> >>>>>> Thanks again for sharing the above information. As mentioned in
> >>>> this draft
> >>>>> AND other drafts, the mechanism of performing hash calculation on
> >> the
> >>>> Session
> >>>>> ID field in the L2TPv3 header or the Key field in the GRE header as
> >>>> defined in
> >>>>> [RFC 5640] is not widely supported by existing core routers so far.
> >>>>>
> >>>>> FWIW, I have had success, in the relatively recent past, in
> >>>> requesting a core
> >>>>> router vendor to support changes to the input-keys used in hash
> >>>> calculations in
> >>>>> _existing_ hardware, already deployed (extensively) throughout my
> >>>> network.
> >>>>> Further, I suspect that most large network operators are savvy
> >> folks
> >>>> and
> >>>>> understand the internal architecture of their HW fairly well.  As a
> >>>> result, those
> >>>>> same operators know what is and is not technically possible in this
> >>>> regard.
> >>>>> Thus, it may be a question of "methods" necessary to convince their
> >>>> HW
> >>>>> supplier(s) to make appropriate changes in their equipment to
> >> achieve
> >>>> their
> >>>>> business goals.  :-)  However, this may not even be necessary ...
> >> see
> >>>> below.
> >>>>
> >>>> Could you please briefly explain how to make the above change in
> >>>> EXISTING hardware of already deployed core routers?
> >>>>
> >>>>>> In contrast, most existing core routers are already capable of
> >>>> balancing IP
> >>>>> traffic flows based on the hash of the five-tuple of UDP packets.
> >> By
> >>>> using the
> >>>>> MPLS-in-UDP encapsulation, the already available load-balancing
> >>>> capability of
> >>>>> most existing core routers can be leveraged without requiring any
> >>>> change to
> >>>>> them. That is the major motivation of this draft.
> >>>>>
> >>>>> If this is a concern, then why not encapsulate the traffic in
> >>>> MPLS/L2TPv3, which
> >>>>> uses UDP/IP, in the first place?
> >>>>
> >>>> If I understand it correctly, you prefer to use MPLS-in-L2TPv3-in-
> >> UDP
> >>>> instead of MPLS-in-UDP, right?
> >>>>
> >>>>> IMHO, a better proposal may be to consider a [minor] (?) change to
> >>>> RFC 3931,
> >>>>> which would allow the connection used for data packets (not control
> >>>> packets)
> >>>>> to use a varying set of source ports (or, source IP addresses),
> >> based
> >>>> on a hash
> >>>>> calculation, to achieve better load-balancing over existing
> >> equipment
> >>>> in an
> >>>>> IP-only core.  L2TP end-system implementations would be better off
> >>>> just using
> >>>>> the "Session ID" (and "Cookie") fields as the demultiplexor to
> >>>> associate
> >>>>> incoming packets with the associated L2TP Control Channel.  In fact,
> >>>> it's not
> >>>>> clear to me that existing implementations may /already/ do this,
> >>>> making any
> >>>>> "check" on the incoming source port unnecessary for L2TP end-system
> >>>>> implementations.
> >>>>>
> >>>>> The beauty of the above approach is:
> >>>>> 1) I would think that the above is most likely a change that is
> >>>> limited to the
> >>>>> "control channel" (software) of existing L2TP end-system
> >>>> implementations.
> >>>>> Heck, it may even be backwards compatible with existing L2TPv3
> >>>>> implementations.  (L2TPv3 implementors would need to comment on
> >> that).
> >>>>
> >>>> IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,  the hardware
> >> of
> >>>> PE routers needs to be upgraded, e.g., ingress PE routers need to
> >> fill
> >>>> in an entropy value in the source port field of UDP headers.
> >>>>
> >>>>> 2) There is a substantial added security one gets by using "Session
> >>>> ID" and
> >>>>> "Cookie" fields to ensure the received L2TPv3 packet is intended
> >> for
> >>>> the
> >>>>> identified session.  Quoting from Section 8.2 of RFC 3931:
> >>>>> ---snip---
> >>>>>  L2TPv3 provides traffic separation for its VPNs via a 32-bit
> >>>> Session
> >>>>>  ID in the L2TPv3 data header.  When present, the L2TPv3 Cookie
> >>>>>  (described in Section 4.1), provides an additional check to
> >> ensure
> >>>>>  that an arriving packet is intended for the identified session.
> >>>>>  Thus, use of a Cookie with the Session ID provides an extra
> >>>> guarantee
> >>>>>  that the Session ID lookup was performed properly and that the
> >>>>>  Session ID itself was not corrupted in transit.
> >>>>> ---snip---
> >>>>> ... in regard to this question alone, I know the Security Area
> >> folks
> >>>> have, in the
> >>>>> past, had /substantial/ concerns about encapsulation of MPLS over
> >> IP
> >>>> transport.
> >>>>> In fact, this is why you see text in Section 7.6, "Security", of
> >> RFC
> >>>> 4665.
> >>>>> (There's likely similar language in other drafts that use MPLS for
> >>>> transport).
> >>>>> While I'm not sure that Security Area folks pay much attention to
> >>>> daily traffic on
> >>>>> the MPLS WG mailing list, I'm fairly confident this concern will
> >>>> arise if/when this
> >>>>> draft goes to the IESG ...
> >>>>
> >>>> If I understand it correctly, the reason for your preference of
> >> MPLS-
> >>>> in-L2TPv3-in-UDP is that it has an added security feature. If that
> >> is
> >>>> so concerned, can you explain why MPLS-in-GRE is far more popular
> >> than
> >>>> MPLS-in-L2TP in practice?
> >>>>
> >>>> Best regards,
> >>>> Xiaohu
> >>>>
> >>>>> 3) Finally, this approach only affects the end-systems that
> >> implement
> >>>> L2TP, for
> >>>>> tunneling of MPLS/IP, and does not require an entire industry to
> >>>> support
> >>>>> MPLS/UDP encapsulation in their product lines.
> >>>>>
> >>>>> -shane
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Xiaohu
> >>>>>>
> >>>>>>> If there was market demand for MPLS over IP, then clearly it
> >> would
> >>>> have
> >>>>> been
> >>>>>>> more widely implemented by equipment vendors, with either MPLS
> >>>> over
> >>>>> GRE or
> >>>>>>> MPLS over L2TPv3.  (Where there's a will, there's a way).  I
> >> would
> >>>> note
> >>>>> that
> >>>>>>> the most likely reasons this did not pan out was there are
> >> several,
> >>>> practical
> >>>>>>> operational benefits one gets from going with native MPLS
> >>>>>>> encapsulation/switching within the data plane, namely:
> >>>>>>> - MPLS Fast Re-Route
> >>>>>>> - MPLS Traffic Engineering
> >>>>>>> ... to name, but a few.  Those have tended to be quite compelling
> >>>>> arguments
> >>>>>>> to 'upgrade' network HW to support MPLS encapsulation/switching.
> >>>>>>>
> >>>>>>> -shane
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Josh
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/18/12 12:31 AM, "Shahram Davari" <[e-mail]>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> For service provider domain, MPLS over IP is legacy and there
> >> is
> >>>> no need
> >>>>>>>>> to improve it.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Shahram
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <[e-mail]>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Shahram,
> >>>>>>>>>>
> >>>>>>>>>> This draft is ONLY intended to provide a MPLS-over-IP
> >>>> encapsulation
> >>>>>>>>>> method with a better load-balancing applicability so far to
> >>>> those
> >>>>>>>>>> operators who happen to require transporting MPLS application
> >>>> traffic
> >>>>>>>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE
> >> and
> >>>>> VXLAN
> >>>>>>>>>> each have their own advocators and use cases. If you
> >> absolutely
> >>>> believe
> >>>>>>>>>> it's meaningless of transporting MPLS application traffic
> >>>> across IP
> >>>>>>>>>> networks and therefore those existing RFCs related to MPLS
> >> over
> >>>> IP
> >>>>>>>>>> tunneling mechanisms should be moved to Historic status,
> >> please
> >>>> say
> >>>>> so.
> >>>>>>>>>>
> >>>>>>>>>> By the way, it seems this
> >>>>>>>>>> (http://www.ietf.org/mail-
> >>>> archive/web/nvo3/current/msg01864.html) is
> >>>>>>>>>> just the right thread suitable for you to make the following
> >>>> argument
> >>>>>>>>>> (i.e., whether or not MPLS-based VPN is applicable to data
> >>>> centers). I
> >>>>>>>>>> had thought you would speak up at that time. Sadly,
> >>>> surprisingly silent
> >>>>>>>>>> till now.
> >>>>>>>>>>
> >>>>>>>>>> Sigh, I didn't intend to say the above otherwise.
> >>>>>>>>>>
> >>>>>>>>>> Xiaohu
> >>>>>>>>>>
> >>>>>>>>>>> -----邮件原件-----
> >>>>>>>>>>> 发件人: [e-mail] [mailto:[e-mail]]
> >> 代
> >>>> 表
> >>>>>>> S.
> >>>>>>>>>>> Davari
> >>>>>>>>>>> 发送时间: 2012年12月15日 13:34
> >>>>>>>>>>> 收件人: Loa Andersson
> >>>>>>>>>>> 抄送: [e-mail]; [e-mail];
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>> 主题: Re: [mpls] poll to see if we have support to make
> >>>>>>>>>>> draft-xu-mpls-in-udp an
> >>>>>>>>>>> mpls working group document
> >>>>>>>>>>>
> >>>>>>>>>>> I don't support this draft since it has no application in
> >>>> today's
> >>>>>>>>>>> modern metro
> >>>>>>>>>>> and core, where MPLS is dominant, and its only practical
> >>>> application
> >>>>>>>>>>> in in data
> >>>>>>>>>>> center, which already is crowded with other solutions such as
> >>>> NVGRE
> >>>>> and
> >>>>>>>>>>> VXLAN.
> >>>>>>>>>>>
> >>>>>>>>>>> It seems the authors are trying to bypass the NVO3 solution
> >>>> selection
> >>>>>>>>>>> process
> >>>>>>>>>>> by advancing the draft in MPLS WG.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Shahram
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <[e-mail]> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Working group,
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is to start a "two week" poll on adopting
> >>>>>>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document.
> >>>>>>>>>>>> Due to the holiday season this poll has been extended with
> >>>> one week.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please send your comments (support/not support) to the mpls
> >>>>> working
> >>>>>>>>>>>> group mailing list (mpls at ietf.org) Please give an
> >>>> technical
> >>>>>>>>>>>> motivation for your support/not support, especially if you
> >>>> think that
> >>>>>>>>>>>> the document should not be adopted as a working group
> >>>> document.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This poll ends January 07, 2013.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There is one IPR claim against this document -
> >>>>>>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
> >>>>>>>>>>>>
> >>>>>>>>>>>> All the active co-authors has stated on the working group
> >>>> mailing list
> >>>>>>>>>>>> that they are not aware of any other IPR claims than those
> >>>> already
> >>>>>>>>>>>> disclosed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> However, up to version -03 (the document that we used for
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll)
> >>>>>>>>>>>> Marshall Eubanks was listed as one of the authors. Marshall
> >>>> has
> >>>>>>>>>>>> discontinued all interactions with the IETF, including the
> >>>> author team
> >>>>>>>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has
> >>>> tried to
> >>>>>>>>>>>> contact Marshall by other means, to try get a response on
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll.
> >>>>>>>>>>>> We have had no success in this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> From version -04 the authors decided to remove Marshall as a
> >>>>>>>>>>>> co-author.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Loa
> >>>>>>>>>>>> (mpls wg co-chair)
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Loa Andersson                         email:
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>>> Sr Strategy and Standards Manager            [e-mail]
> >>>>>>>>>>>> Ericsson Inc                          phone: [phone]
> 52
> >> 13
> >>>>>>>>>>>>                                        [phone]
> 13
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> mpls mailing list
> >>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> mpls mailing list
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> mpls mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>> _______________________________________________
> >>>>>>>>> mpls mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This E-mail and any of its attachments may contain Time Warner
> >>>> Cable
> >>>>>>> proprietary information, which is privileged, confidential, or
> >>>> subject to
> >>>>>>> copyright belonging to Time Warner Cable. This E-mail is intended
> >>>> solely for
> >>>>> the
> >>>>>>> use of the individual or entity to which it is addressed. If you
> >>>> are not the
> >>>>>>> intended recipient of this E-mail, you are hereby notified that
> >>>> any
> >>>>> dissemination,
> >>>>>>> distribution, copying, or action taken in relation to the
> >> contents
> >>>> of and
> >>>>>>> attachments to this E-mail is strictly prohibited and may be
> >>>> unlawful. If you
> >>>>>>> have received this E-mail in error, please notify the sender
> >>>> immediately and
> >>>>>>> permanently delete the original and any copy of this E-mail and
> >>>> any printout.
> >>>>>>>> _______________________________________________
> >>>>>>>> mpls mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>
> >>> _______________________________________________
> >>> mpls mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls