[mpls] Re: Proposed changes: Potential MNA technical issue

[Adrian Farrel <[e-mail]>]

Thanks Rakesh, and well done for sticking with this.

 

Can I suggest that, in the new security text you s/from the Customer domain/from any domain with different administrative control/  so that we handle a broader set of circumstances than just the customer-provider interface?

 

Cheers,

Adrian

 

From: Rakesh Gandhi <[e-mail]> 
Sent: 03 March 2025 16:32
To: [e-mail]
Cc: Greg Mirsky <[e-mail]>; [e-mail]
Subject: Re: [mpls] Re: Proposed changes: Potential MNA technical issue

 

Thanks Greg and Adrian.

 

Attaching the work-in-progress draft and diff file with the proposed changes.

 

There is also a proposed update to the Security section based on the comments from Bruno.

 

Thanks,

Rakesh (for co-authors)

 

 

On Mon, Mar 3, 2025 at 11:06 AM Adrian Farrel <[e-mail] <mailto:[e-mail]> > wrote:

Hi,

 

Thanks for the continued work on this.

 

I can get behind it, but I suggest a couple of language tweaks in line.

 

Cheers, 

Adrian

 

From: Greg Mirsky <[e-mail] <mailto:[e-mail]> > 
Sent: 03 March 2025 12:10
To: Rakesh Gandhi <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: [mpls] Re: Proposed changes: Potential MNA technical issue

 

Hi Rakesh,

thank you for the updates. I gave priority to reviewing Section 5.2. Below are my notes and nits:

*	Proposed re-wording:

OLD TEXT:

   The data field carries opcode specific data.  This is ancillary data

   for a network action.  

NEW TEXT:

   The data field carries opcode-specific data that is ancillary data

   for a network action.

*	On the following text:

   The legacy implementations may use the label field (most significant

   20 bits) in all LSEs when computing ECMP decisions and modifying the

   label field might disrupt that packet's flow and result in out-of-

   order delivery of packets.  

I imagine that some implementations are limited in the number of LSEs used to calculate entropy for load-balancing data flows. Also, "flow disruption" sounds a bit overdramatic. Considering these notes, the proposal follows:

NEW TEXT:

   The legacy implementations may use the label field (most significant

   20 bits) in several consecutive LSEs when load-balancing data flows in

   ECMP environment. Modifying the

   label field might alter that packet's path and result in out-of-order delivery of packets.  

Adrian NEW:

   Legacy implementations might use the label field (most significant

   20 bits) in one or more consecutive LSEs when load-balancing data flows in

   An ECMP environment. Modifying the

   first 20 bits in an LSE might alter that packet's path and result in out-of-order delivery of packets.  

*	s/backward/the backward/
*	Some notes on the following text:

   To preserve backward compatibility of

   these implementations, if a network action encodes data that may be

   different on different packets in the same flow or might change

   differently during packet forwarding, then that data MUST NOT be

   carried in the most significant 20 bits of a Format B LSE

   (Section 4.2), a Format C LSE (Section 4.3), or a Format D LSE

   (Section 4.4).  Thus, the available bits for data that can change by

   a transit node in Format A and Format B LSEs are 0, Format C LSE is 7

   (bits 20-22 and 25-28) and Format D LSE is 11 (bits 20-22 and 25-31).

*	I think we care about the stability of the networks and services, not the implementations.
*	In the concluding sentence, the case of data changing among packets in the same flow is missing.

I propose the following editorial update of that text:

NEW TEXT:

   To preserve the stability of the deployed services in ECMP environments

   that use information in the Label field to load-balance data flows,

   if a network action encodes data in the given LSE that may be

   different among packets in the same flow or might change

   during packet forwarding across the MPLS network, then that data MUST NOT be

   carried in the most significant 20 bits of a Format B LSE

   (Section 4.2), a Format C LSE (Section 4.3), or a Format D LSE

   (Section 4.4).  Thus, the available bits for data that can change by

   a transit node or differ among packets of the same flow

   in Format A and Format B LSEs are 0, Format C LSE is 7

   (bits 20-22 and 25-28) and Format D LSE is 11 (bits 20-22 and 25-31).

 

*	In the next paragraph s/backward compatibility/service stability/
*	In the next-to-last paragraph, I propose the following editorial update:

OLD TEXT:

The available mitigations for this ...

NEW TEXT:

The available mitigations for these use cases ...

Adrian SAYS:

You don’t mitigate use cases, you mitigate problems.

*	For the last paragraph, the following updates are proposed:

OLD TEXT:

   In implementation where it is known that only the entropy label-based

   mechanism is used for load-balancing data flows, and it is certain

   that ECMP hashing will not be computed based on the label field of

   the LSEs, then the data in the label field of the LSEs in ISD can

   vary within a data flow without disrupting the flow.

NEW TEXT:

   In network deployments where it is known that a load-balancing of data flows is not used,

   or, otherwise, if only the explicitly signaled entropy value is used, and it is certain

   that the load-balancing path selection will not be based on the Label field of

   the LSEs, then the data in the Label field of the LSEs in ISD MAY be

   mutable within the data flow without causing the out-of-order delivery of packets.

 

Regards,

Greg

 

 

 

On Fri, Feb 28, 2025 at 10:30 PM Rakesh Gandhi <[e-mail] <mailto:[e-mail]> > wrote:

Thanks Greg for the review.

Have shared the updated text in the work in progress document in a separate email sent to the WG list.

 

Regards,

Rakesh

 

 

On Fri, Feb 28, 2025 at 3:44 AM Greg Mirsky <[e-mail] <mailto:[e-mail]> > wrote:

Hi Rakesh,

Thank you for highlighting this text for me. It is very close to what I was looking for. However, the text has no normative language, while the passage about immutability does. Can you help me and share the working version of the draft so I can read the discussion related to the mutability/immutability of ISD MNA ancillary data in its entirety?

 

Regards,

Greg

 

On Thu, Feb 27, 2025 at 7:21 PM Rakesh Gandhi <[e-mail] <mailto:[e-mail]> > wrote:

Hi Greg,

 

I believe this point is covered in the proposed text, no?

 

"

   In networks where it is known that only the entropy label-based mechanism is used for load-balancing data flows, 

   and it is certain that ECMP hashing will not be computed based on the label field of the LSEs,

   then the data in the label field of the LSEs in ISD can be modified by the transit nodes without

   disrupting the data flows.

"

 

Regards,

Rakesh

 

 

 

On Wed, Feb 26, 2025 at 3:03 AM Greg Mirsky <[e-mail] <mailto:[e-mail]> > wrote:

Hi, Rakesh et al.,

I believe that discussing this passage is very important for future-proofing MNA ISD. In my opinion, as I've noted on the thread earlier, some technologies, e.g., DetNet, do not recommend load-balancing of data to maintain predictability of performance characteristics (packet loss, packet delay, and delay variation) of the path. Furthermore, some MPLS networks use or may be using explicitly signaled entropy information for load-balancing data flows. For these cases, AFAICS, all space of ISD MNA ancillary data must be allowed to be muttable. To reflect that, I propose the following:

NEW TEXT:

To preserve backward compatibility with networks that use label information in load-balancing, if a network action encodes data such that packets in the same flow may be originated or modified by intermediate routers in such a way that different packets in the same flow are emitted with different data, that data SHOULD NOT be carried in the most significant 20 bits. In networks that use explicit entropy value in load-balancing data flows or do not load-balance them, the entire space of ancillary data MAY be mutable.

 

With this modification, we acknowledge the existing state of MPLS networks while ensuring that the ISD MNA solution is future-proof.

 

Regards,

Greg

 

On Tue, Feb 25, 2025 at 6:53 PM Rakesh Gandhi <[e-mail] <mailto:[e-mail]> > wrote:

Hi Joel,

 

Thank you for the comment.

 

I think it is the second case in your example that can be an issue for out of order delivery.

 

The proposed text is:

"

  To preserve backward compatibility, if
   a network action encodes data that may be different on different
   packets in the same flow or might change differently during packet forwarding,
   then that data MUST NOT be carried in the most significant 20 bits

 "

 

Do you have suggestions to improve the proposed text below?

 

Thanks,

Rakesh

 

 

On Mon, Feb 24, 2025 at 4:33 PM Joel Halpern <[e-mail] <mailto:[e-mail]> > wrote:

Minor question:  Can someone explain how having those bits change in packet processing (if they change the same way for every packet in the flow) would break ECMP?  It would cause different routers to get different answers, but they already do that.  ( understand why having different packets in the flow show up at the same rotuer with different bits that are used in ECMP causes problems.)

Yours,

Joel

On 2/24/2025 3:47 PM, Rakesh Gandhi wrote:

Thanks Adrian, Loa, Fabian, and Greg for the comments. 

How about revising the proposed text in section 5.2 as follows:

 

5.2.  Data

   The data field carries opcode specific data.  This is ancillary data
   for a network action.  In the case of opcode 1, the data field
   carries Flag-Based Network Action Indicators without ancillary data.

   Some legacy implementations may use the label field (most significant
   20 bits) in all LSEs when computing ECMP decisions and modifying the
   label field might disrupt that packet's flow and might result in out-
   of-order delivery of packets.  To preserve backward compatibility, if
   a network action encodes data that may be different on different
   packets in the same flow or might change differently during packet forwarding,
   then that data MUST NOT be carried in the most significant 20 bits of
   a Format B LSE (Section 4.2), a Format C LSE (Section 4.3), or a
   Format D LSE (Section 4.4).  Thus, the available bits for data that
   can change by a transit node in Format A and Format B LSEs are 0,
   Format C LSE is 7 (bits 20-22 and 25-28) and Format D LSE is 11 (bits
   20-22 and 25-31).

   Similarly, to preserve backward compatibility, such data also MUST
   NOT be carried in the most significant 23 bits of these LSEs when the
   legacy implementation also uses the TC field, in addition to the
   label field, in all LSEs when computing ECMP decisions.

   Note that this is also applicable to opcode 1 Flag-Based Network
   Action Indicators that need to be changed in flight.

   The available mitigations for this are to use additional Format D
   LSEs to carry the data, or to place the data in Post-Stack Data as
   described in [I-D.ietf-mpls-mna-fwk].

   In networks where it is known that only the entropy label-based mechanism
   is used for load-balancing data flows, and it is certain that ECMP
   hashing will not be computed based on the label field of the LSEs,
   then the data in the label field of the LSEs in ISD can be modified
   by the transit nodes without disrupting the data flows.

 

 

Thanks,

Rakesh

 

 

On Mon, Feb 24, 2025 at 9:21 AM Loa Andersson <[e-mail] <mailto:[e-mail]> > wrote:

All,

After counting on my fingers and toes a couple of time, I conclude that 
Fabian is right. It should be:

(*  0 in format A)
  *  0 in Format B
  *  7 in Format C (bit 20-22 and 25-28)
  * 11 in Format D (bit 20-22 and 24-31)

I'm not sure that Format A need to be in the list, but since ...

/Loa


Den 24/02/2025 kl. 14:21, skrev Fabian Ihle:
> Hi Loa,
> 
> I think you're off by one, Format A is the NAS indicator (bSPL or eSPL) 
> and does not hold ancillary data, but having the bit indices explicitly 
> in the draft is a good idea.
> 
> Best,
> 
> Fabian
> 
> On 24.02.25 13:33, Loa Andersson wrote:
>> Fabian, Adrian,
>>
>> If are clarifying, let us go all the way.
>>
>> - 0 for LSE format A
>> - 7 for LSE format B (bit 20-22 and 25-28)
>> - 11 for LSE format C (bit 20-22 and
>>     24-31)
>>
>> /Loa
>>
>>
>> On Mon, 24 Feb 2025 at 13:14, Fabian Ihle <fabian.ihle@uni-  <mailto:fabian.ihle@uni-%20%0b> 
>> tuebingen.de <http://tuebingen.de> > wrote:
>>
>>     Hi Adrian,
>>
>>     I agree that "data found in the last 12 bits" may sound a bit
>>     misleading regarding the S bit. People may think that there are 12
>>     bits available. Maybe something along:
>>
>>        "The transit node MUST NOT modify the first 20 bits of any LSE
>>     in the label stack when the ECMP technique in the network is using
>>     the hashing of the labels on the label stack.
>>
>>              A transit node MAY change the Ancillary Data found in
>>     the/remaining bits of/ an LSE."
>>
>>     We could also list the number of available bits per Format below
>>     this point:
>>
>>       * 0 in Format B
>>       * 7 in Format C
>>       * 11 in Format D
>>
>>     Further, I checked the documentation of multiple devices from
>>     various vendors and they all state to hash only up to the first 20
>>     bits and not the TC field. However, maybe someone can confirm this.
>>
>>     Best,
>>
>>     Fabian
>>
>>     On 22.02.25 12:38, Adrian Farrel wrote:
>>>
>>>     Good catch, Fabian.
>>>
>>>     5.2 which I modified, also used to say “least significant 8 bits”
>>>
>>>     Of course, this represents the bits after the S bit. But there
>>>     are 3 bits before the S bit than can also be safely varied as
>>>     they are out of the overlap with a label.
>>>
>>>     However, it occurs to me now that some implementations may be
>>>     hashing on the TC as well as the label.
>>>
>>>     So we have to jump to 11 (my text) or 8 (original text).
>>>
>>>     I’d prefer to not say “data found in the last 12 bits” in case
>>>     that confuses people around the S bit.
>>>
>>>     Adrian
>>>
>>>     *From:*Fabian Ihle <[e-mail] <mailto:[e-mail]> >
>>>     <mailto:[e-mail] <mailto:[e-mail]> >
>>>     *Sent:* 22 February 2025 11:18
>>>     *To:* [e-mail] <mailto:[e-mail]> ; Rakesh Gandhi (rgandhi) <[e-mail] <mailto:[e-mail]> >
>>>     <mailto:[e-mail] <mailto:[e-mail]> >
>>>     *Subject:* [mpls] Re: Proposed changes: Potential MNA technical issue
>>>
>>>     Hi Rakesh,
>>>
>>>     Section 5.2 says:
>>>
>>>        " [...] if a network action encodes data that may be different
>>>     on different packets in the
>>>        same flow or might change during packet forwarding, then that data
>>>        MUST NOT be in the most significant *20 bits* [...]"
>>>
>>>     whereas Section 9.2 says:
>>>
>>>        "A transit node MAY change the Ancillary Data found in the least
>>>        significant *8 bits* of an LSE."
>>>
>>>     This ignores the remaining 4 bits in the middle. I think this
>>>     should be changed to
>>>
>>>        "A transit node MAY change the Ancillary Data found in the least
>>>        significant *12 bits* of an LSE." (excluding the BoS bit of
>>>     course)
>>>
>>>     Here is an image from our paper (https://arxiv.org/
>>>     pdf/2410.20400) illustrating the bits that are available for
>>>     variable bits (hatched). Currently the draft only considers bit
>>>     24 - 31 in Section 9.2.
>>>
>>>     Best,
>>>
>>>     Fabian
>>>
>>>     On 21.02.25 19:02, Rakesh Gandhi wrote:
>>>
>>>         Hi Adrian,
>>>
>>>         Thanks for suggesting the text.
>>>
>>>         Attaching the work-in-progress draft for review before posting.
>>>
>>>         Hi WG,
>>>
>>>         Please advise if there are any pending comments to address.
>>>
>>>         Regards,
>>>
>>>         Rakesh (for authors)
>>>
>>>         On Fri, Feb 21, 2025 at 11:24 AM Adrian Farrel
>>>         <[e-mail] <mailto:[e-mail]> > wrote:
>>>
>>>             Hi, I think we have some agreement on the text changes
>>>             necessary.
>>>
>>>             Since 5.2 is such a short section, it is probably easiest
>>>             if I supply the changed text for the whole section.
>>>
>>>             OLD
>>>             5.2.  Data
>>>
>>>                The data field carries opcode specific data.  This is
>>>             ancillary data
>>>                for a network action.  In the case of opcode 1, data
>>>             field carries
>>>                Flag-Based Network Action Indicators without ancillary
>>>             data.
>>>
>>>                To preserve backward compatibility, if a network
>>>             action encodes data
>>>                that will change during packet forwarding, then that
>>>             data MUST be in
>>>                the least significant 4 bits in the data field of a
>>>             Format C LSE
>>>                (Section 4.3) or the least significant 8 bits of a
>>>             Format D LSE
>>>                (Section 4.4).  Some legacy implementations may use
>>>             the label field
>>>                in all LSEs when computing ECMP decisions and
>>>             modifying the label
>>>                field might disrupt that packet's flow.
>>>
>>>                This is also applicable to opcode 1 Flag-Based Network
>>>             Action
>>>                Indicators those need to be changed in flight.
>>>             NEW
>>>             5.2.  Data
>>>
>>>                The data field carries opcode specific data.  This is
>>>             ancillary data
>>>                for a network action.  In the case of opcode 1, the
>>>             data field carries
>>>                Flag-Based Network Action Indicators without ancillary
>>>             data.
>>>
>>>                Some legacy implementations may use the label field in
>>>             all LSEs
>>>                when computing ECMP decisions and modifying the label
>>>             field
>>>                might disrupt that packet's flow.  To preserve backward
>>>                compatibility, if a network action encodes data that
>>>             may be
>>>                different on different packets in the same flow or
>>>             might change
>>>                during packet forwarding, then that data MUST NOT be
>>>             in the
>>>                most significant 20 bits of a Format B LSE (Section
>>>             4.2), a
>>>                Format C LSE (Section 4.3), or a Format D LSE (Section
>>>             4.4).  Thus,
>>>                this is also applicable to opcode 1 Flag-Based Network
>>>             Action
>>>                Indicators that need to be changed in flight.
>>>
>>>                The available mitigations for this are to use
>>>             additional Format D
>>>                LSEs to carry the data, or to place the data in Post-
>>>             Stack Data as
>>>                described in [draft-ietf-mpls-mna-fwk].
>>>             END
>>>
>>>             Cheers,
>>>             Adrian
>>>
>>>             -----Original Message-----
>>>             From: Adrian Farrel <[e-mail] <mailto:[e-mail]> >
>>>             Sent: 20 February 2025 21:48
>>>             To: 'Tony Li' <[e-mail] <mailto:[e-mail]> >
>>>             Cc: 'mpls' <[e-mail] <mailto:[e-mail]> >
>>>             Subject: [mpls] Re: Potential MNA technical issue
>>>
>>>             No, I personally don't have a problem with that solution.
>>>             Others may have, I don't know.
>>>
>>>             The text could, perhaps, be a little clearer in 5.2 to
>>>             direct applications to use PSD. Yeah, I know one could
>>>             possibly work out that having a lot of LSEs is not very
>>>             wise (especially as we have a limit to the number of LSEs
>>>             we can support because of the size of the NASL). Just a
>>>             few words of advice: nothing heavy.
>>>
>>>             And the fixes for points 1 and 2.
>>>
>>>             A
>>>
>>>             -----Original Message-----
>>>             From: Tony Li <[e-mail] <mailto:[e-mail]> > On Behalf Of Tony Li
>>>             Sent: 20 February 2025 21:27
>>>             To: Adrian Farrel <[e-mail] <mailto:[e-mail]> >
>>>             Cc: mpls <[e-mail] <mailto:[e-mail]> >
>>>             Subject: Re: [mpls] Potential MNA technical issue
>>>
>>>             [WG chair hat: off]
>>>
>>>             Hi Adrian,
>>>
>>>             I recall that we discussed this before and we reached the
>>>             conclusion that actions that needed
>>>             more variable data should go the post-stack route. Do you
>>>             have a problem with that?
>>>
>>>             Regards,
>>>             Tony
>>>
>>>
>>>             > On Feb 20, 2025, at 12:58 PM, Adrian Farrel - adrian at
>>>             olddog.co.uk <http://olddog.co.uk>  <http://olddog.co.uk>
>>>             <[e-mail] <mailto:[e-mail]> > wrote:
>>>             >
>>>             > Hi all,
>>>             >
>>>             > I thought the virtual interim was useful in airing some
>>>             opinions.
>>>             >
>>>             > I exchanged a few emails with Jie to try to better
>>>             understand his concerns,
>>>             > and then Stewart and I sat down for a couple of hours
>>>             to work through all of
>>>             > the possibilities.
>>>             >
>>>             > This is mainly thinking aloud.
>>>             >
>>>             > A big question surrounds how the NAS might be parsed by
>>>             a non-MNA node.
>>>             >
>>>             > The first part of the question is "What happens if a
>>>             non-MNA node encounters
>>>             > the MNA label?" Well, it shouldn't! The MNA label
>>>             should only rise to the
>>>             > top of stack at nodes known to be MNA capable. But, if
>>>             it does, the MNA
>>>             > label is an SPL, and processing unknown SPLs at the top
>>>             of stack is well
>>>             > defined.
>>>             >
>>>             > The next part of this question is "What if part of the
>>>             NSA looks like an
>>>             > SPL?" The most concerning case we have at the moment is
>>>             if it looks like an
>>>             > ELI to a non-MNA node that searches ahead for an
>>>             entropy label.
>>>             > This question is covered in the draft in two places:
>>>             > 6.1 tells us that Opcode 0 is not to be used. That
>>>             means that LSE formats B
>>>             > and C can never be mistaken for bSPLs because they
>>>             don't start with eight 0
>>>             > bits.
>>>             > 4.4 tells us that format D LSEs must always start with
>>>             a 1 so they can never
>>>             > be mistaken for bSPLs.
>>>             > So all good here.
>>>             >
>>>             > The last part of the question is "Suppose a (legacy)
>>>             node does ECMP hashing
>>>             > by reading the first n labels on the stack?"
>>>             > Since it doesn't know about MNA, it will find Opcodes
>>>             and ISD and treat them
>>>             > as labels.
>>>             > This is not a problem in itself, but if the ISD can
>>>             vary from packet to
>>>             > packet in a flow, it can lead to packets taking
>>>             different paths.
>>>             > This question is covered in section 5.2 which tells us
>>>             to be careful which
>>>             > ISD bits are allowed to vary.
>>>             >
>>>             > But it was in re-reading 5.2 that Stewart and I had
>>>             some worries.
>>>             >
>>>             > 1. The text says:
>>>             >       if a network action encodes data
>>>             >       that will change during packet forwarding
>>>             >    While this may be interesting for OAM, what is more
>>>             interesting is when
>>>             > the
>>>             >    data is different on different packets in the same
>>>             flow. So probably
>>>             > change
>>>             >    this to:
>>>             >       if a network action encodes data
>>>             >       that may be different on different packets in the
>>>             same flow
>>>             >
>>>             > 2. s/Indicators those need/Indicators that need/
>>>             >
>>>             > 3. There are not many bits that are allowed to contain
>>>             variable data.
>>>             >     This is a bit grim. We reckon that:
>>>             >     - No bits in a type B LSE can be variable
>>>             >     - Only 7 bits in a type C LSE can be variable
>>>             >     - Just 11 bits in a type D LSE can be variable
>>>             >     If you wanted to carry something like a time stamp
>>>             (RFC 8877) you need
>>>             > 32 bits
>>>             >     or even 64 bits. That would need 4 or 7 LSEs (BDDD
>>>             or BDDDDDD/BCDDDDD)
>>>             >     instead of 2 or 3 (BD or BDD/BCD).
>>>             >     There are some possible mitigations:
>>>             >     - Use an entropy label. This allows any
>>>             implementation that supports
>>>             > entropy
>>>             >        labels to not hash. But:
>>>             >         * it costs two additional LSEs
>>>             >         * it doesn't help with implementations that
>>>             don't support entropy
>>>             > labels
>>>             >     - Stop hashing when you reach an SPL.
>>>             >       This advice would work for new implementations,
>>>             but it doesn't help
>>>             > with
>>>             >       existing implementations which will hash their
>>>             way through into the
>>>             > NAS.
>>>             >     - Follow the draft and restrict where variable data
>>>             is placed.
>>>             >         * Use lots of LSEs. Not a very good answer.
>>>             >         * Don't send much variable data. A bit of an
>>>             unfortunate
>>>             > limitation.
>>>             >         * Put variable data post-stack.
>>>             >     - Decide that we don't care about legacy nodes.
>>>             This is not ideal, but
>>>             > an
>>>             >       operator might know about the nodes in their
>>>             network. If this is the
>>>             >       choice, then the document would need to be clear.
>>>             >     - Choose a behaviour based on knowledge of the
>>>             nodes in the network
>>>             >       and the (potential) path of the LSP. This
>>>             approach would require
>>>             >       capabilities to be advertised (perhaps alongside
>>>             the RLD ).
>>>             >
>>>             > Cheers,
>>>             > Adrian
>>>             >
>>>             > _______________________________________________
>>>             > mpls mailing list -- [e-mail] <mailto:[e-mail]> 
>>>             > To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
>>>
>>>             _______________________________________________
>>>             mpls mailing list -- [e-mail] <mailto:[e-mail]> 
>>>             To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
>>>
>>>             _______________________________________________
>>>             mpls mailing list -- [e-mail] <mailto:[e-mail]> 
>>>             To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
>>>
>>>
>>>
>>>         _______________________________________________
>>>
>>>         mpls mailing list [e-mail] <mailto:[e-mail]> 
>>>
>>>         To unsubscribe send an email [e-mail] <mailto:[e-mail]> 
>>>
>>>     -- 
>>>     Fabian Ihle
>>>     Universität Tübingen
>>>     Fachbereich Informatik Lehrstuhl Kommunikationsnetze
>>>     Wilhelm-Schickard-Institut für Informatik
>>>     Sand 13, 72076 Tübingen <https://www.google.com/maps/search/Sand+13,+72076+T%C3%BCbingen?entry=gmail <https://www.google.com/maps/search/Sand+13,+72076+T%C3%BCbingen?entry=gmail&source=g> &source=g> 
>>>       
>>>     Raum: B303
>>>     Telefonnr.: [phone]
>>>     E-Mail:[e-mail] <mailto:[e-mail]> 
>>>     Internet:uni-tuebingen.de <http://uni-tuebingen.de>  <http://uni-tuebingen.de>
>>
>>     -- 
>>     Fabian Ihle
>>     Universität Tübingen
>>     Fachbereich Informatik Lehrstuhl Kommunikationsnetze
>>     Wilhelm-Schickard-Institut für Informatik
>>     Sand 13, 72076 Tübingen <https://www.google.com/maps/search/Sand+13,+72076+T%C3%BCbingen?entry=gmail <https://www.google.com/maps/search/Sand+13,+72076+T%C3%BCbingen?entry=gmail&source=g> &source=g> 
>>
>>     Raum: B303
>>     Telefonnr.: [phone]
>>     E-Mail:[e-mail] <mailto:[e-mail]> 
>>     Internet:uni-tuebingen.de <http://uni-tuebingen.de>  <http://uni-tuebingen.de>
>>
>>     _______________________________________________
>>     mpls mailing list -- [e-mail] <mailto:[e-mail]> 
>>     To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
>>
> -- 
> Fabian Ihle
> Universität Tübingen
> Fachbereich Informatik Lehrstuhl Kommunikationsnetze
> Wilhelm-Schickard-Institut für Informatik
> Sand 13, 72076 Tübingen
> 
> Raum: B303
> Telefonnr.: [phone]
> E-Mail:[e-mail] <mailto:[e-mail]> 
> Internet: uni-tuebingen.de <http://uni-tuebingen.de> 
> 
> 
> _______________________________________________
> mpls mailing list -- [e-mail] <mailto:[e-mail]> 
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail] <mailto:[e-mail]> 
[e-mail] <mailto:[e-mail]> 

_______________________________________________
mpls mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

 

_______________________________________________
mpls mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
mpls mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>