Re: [mpls] Working Group Last Call ondraft-ietf-mpls-tp-on-demand-cv-

[<[e-mail]>]

Hi Eric,

It was good opportunity for us to discuss about Per-IF MIP at Pargue.
In that week, you put reply to me on ML as below;

> >>        If you want to include specific interface information,
> >>you can include a DSMAP (or DDMAP) TLV as defined by RFC
> >>4379, and extended by this draft (in combination with the
> >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP).

After that, I'v read both of RFC 4379 and draft-ietf-mpls-on-demand-cv in detail.
As the result, I'd like to clarify some points as below;

(1)draft-on-demand-cv says in 2.1.1. that
  "When sending On-demand CV packets using ACH, without IP
   encapsulation, the following information MUST be included in any
   (source/destination) TLV that is included in the packet.".
  Here, "the following information" is DSMAP/DDMAP address TLV
  which has address type "5".

  Furthermore, the draft also describes in 2.1. that
  "When this address type is used, on receipt of a LSP-Ping echo
   request, interface verification MUST be bypassed.  Thus the receiving
   node SHOULD only perform mpls label control-plane/data-plane
   consistency checks.
  Here, "this address type" is "5".

  In my understanding from these two descriptions,
  a DSMAP/DDMAP MUST be included in an echo request,
  when using ACH without IP/UDP.
  However, on receipt of the echo request,
  the DSMAP/DDMAP MUST be ignored.
  
  is this understanding correct?

(2)If above is yes, is it possible to achieve Per-IF MIP
   by single route-trace as you said?

BR,
Hideki


>Sasha,
>
>        It is not precluded.  As Hideki correctly points out, ingress
>to mid-point connectivity verification is a requirement in RFC 5860.
>
>        Since the same message is used in both Traceroute and CV, in
>the case where you want to do a continuity check from LSP ingress to
>some device between the ingress and egress for the LSP (i.e. - a MIP),
>implementations would do it in the same way that you do Traceroute -
>with the exception that you would do it only with the intended TTL
>(as opposed to starting with 1 and incrementing it until you get a
>("Ping") response from the intended LSP egress.
>
>        As I explained to Hideki, it is largely a matter of personal
>preference whether you think of this as a Traceroute or TTL-limited
>CV message.
>
>        Note that CV is explicitly not included in requirements for
>the case where one might want to test MIP-to-MEP.
>
>--
>Eric
>
>-----Original Message-----
>From: Alexander Vainshtein [mailto:[e-mail]]
>Sent: Thursday, March 31, 2011 2:44 AM
>To: [e-mail]; Eric Gray
>Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
>Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-
>Importance: High
>
>Hideki, Eric, and all,
>I believe that ability to do ping MEP-to-MIP should not be precluded (at least for co-routed bidirectional LSPs).
>
>
>Regards,
>     Sasha
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Thursday, March 31, 2011 8:24 AM
>> To: [e-mail]; [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-
>> demand-cv-
>>
>> Hi Eric and Sam,
>>
>> I'm sorry for my incorrect understanding on DSMAP TLV.
>> According to Sam, We can use DSMAP in both of ping and trace route.
>>
>> However, I have a concern.
>> Eric, you said;
>> >        Ping mode would be strictly MEP-to-MEP.  At least, that
>> >is the way it is intended to work in our draft.
>>
>> On the other hand, RFC5860, MPLS-TP OAM reqs, says;
>> 2.2.3.  Connectivity Verifications
>>    <snipped>
>>    This function SHOULD be performed on-demand between End Points and
>>    Intermediate Points of PWs and LSPs, and between End Points of PWs,
>>    LSPs, and Sections.
>>
>> and;
>>
>> 2.2.4.  Route Tracing
>>    <snipped>
>>    This function SHOULD be performed on-demand.
>>
>>    This function SHOULD be performed between End Points and
>> Intermediate
>>    Points of PWs and LSPs, and between End Points of PWs, LSPs, and
>>    Sections.
>>
>> Why do you restrict ping mode to only for between MEPs?
>> Do you mean that On-demand CV doesn't satisfy all of OAM reqs?
>>
>> BR,
>> Hideki
>>
>> >Hideki,
>> >
>> >        Ping mode would be strictly MEP-to-MEP.  At least, that
>> >is the way it is intended to work in our draft.
>> >
>> >        Why would you need per-interface MIP information in this
>> >case?
>> >
>> >        If someone wanted to do LSP-Ping to a specific interface,
>> >I am uncertain why it would be incorrect to use the DSMAP TLV.
>> >
>> >--
>> >Eric
>> >
>> >-----Original Message-----
>> >From: [e-mail] [mailto:[e-mail]]
>> >Sent: Wednesday, March 30, 2011 5:43 PM
>> >To: Eric Gray; [e-mail]
>> >Cc: [e-mail]; [e-mail]
>> >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-
>> tp-on-demand-cv-03
>> >Importance: High
>> >
>> >Eric,
>> >
>> >In my understanding, DSMAP TLV is only for trace route, isn't it?
>> >We need specific interface information for ping mode of on-demand CV.
>> >
>> >BR,
>> >Hideki
>> >
>> >>Hideki,
>> >>
>> >>        If you want to include specific interface information,
>> >>you can include a DSMAP (or DDMAP) TLV as defined by RFC
>> >>4379, and extended by this draft (in combination with the
>> >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP).
>> >>
>> >>        Would this not do what you're looking for?
>> >>
>> >>--
>> >>Eric
>> >>
>> >>-----Original Message-----
>> >>From: [e-mail] [mailto:[e-mail]]
>> >>Sent: Wednesday, March 30, 2011 11:33 AM
>> >>To: [e-mail]; Eric Gray; [e-mail];
>> [e-mail]
>> >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-
>> on-demand-cv-03
>> >>Importance: High
>> >>
>> >>Hi,
>> >>
>> >>I have one comment on IDs in draft-on-demand-cv.
>> >>The interface-D is missing in the current draft, there is only Node-
>> ID.
>> >>You need at least the interface ID to support per-interface MIP.
>> >>
>> >>BR,
>> >>Hideki
>> >>
>> >>>
>> >>>Dear All,
>> >>>
>> >>>I really appreciate the consideration on the per-interface MIP
>> support and the discussion moving forward.
>> >>>
>> >>>
>> >>>From an operator's perspective, it is very important that the
>> support for per-interface MIPs is covered by the definitions.
>> >>>
>> >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map,
>> there was already a solution proposal, using the TTL. Enhanced
>> solutions have been thorougly discussed during this IETF meeting. It it
>> to be expected that there will be ways to solve both the fast path and
>> fate-sharing requirement.
>> >>>
>> >>>
>> >>>I second the proposal initially made by Rolf, to include additional
>> text to document the per-interface MIP addressing for the on-demand-cv
>> and for other OAM tools.
>> >>>
>> >>>
>> >>>Best regards,
>> >>>Manuel
>> >>>
>> >>>
>> >>>Deutsche Telekom AG
>> >>>Group Technology
>> >>>Manuel Paul
>> >>>SA3-11
>> >>>Goslarer Ufer 35-37, 10589 Berlin
>> >>>[phone] - 4394 (Tel.)
>> >>>[phone] - 4956 (Fax)
>> >>>[phone] (Mobil)
>> >>>E-Mail: mailto:[e-mail]
>> >>>http://www.telekom.com
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of
>> >>>> Rolf Winter
>> >>>> Sent: Monday, March 28, 2011 3:03 PM
>> >>>> To: Eric Gray; [e-mail]
>> >>>> Cc: [e-mail]
>> >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-
>> on-demand-
>> >>>> cv-03
>> >>>>
>> >>>> Eric,
>> >>>>
>> >>>> I generally agree but I think there is one case actually which
>> needs a
>> >>>> closer look in this regard (which I hinted at earlier), which are
>> the per-
>> >>>> interface MIPs. Your TTL expires (the actual addressing bit here),
>> the
>> >>>> identifier tells you it is not intended for the ingress MIP, so it
>> needs
>> >>>> to be forwarded to the egress MIP through the forwarding engine.
>> Now if
>> >>>> you pull the packet out of the fast path and inject it back in, is
>> the OAM
>> >>>> packet still fate sharing? If you can do this in HW on the line
>> card, then
>> >>>> it will and it will just be forwarded as normal. I know this is a
>> >>>> different draft, but this will be in particular important for
>> performance
>> >>>> monitoring.
>> >>>>
>> >>>> Best,
>> >>>>
>> >>>> Rolf
>> >>>>
>> >>>>
>> >>>>
>> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>> Road, London
>> >>>> W3 6BL | Registered in England 2832014
>> >>>>
>> >>>>
>> >>>> > -----Original Message-----
>> >>>> > From: Eric Gray [mailto:[e-mail]]
>> >>>> > Sent: Montag, 28. März 2011 14:45
>> >>>> > To: [e-mail]; Rolf Winter
>> >>>> > Cc: [e-mail]
>> >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-
>> mpls-tp-
>> >>>> > on-demand-cv-03
>> >>>> >
>> >>>> > Hideki,
>> >>>> >
>> >>>> >    What you're saying is true, but not relevant in this
>> >>>> > case.  The "addresses" in this discussion are not used to
>> >>>> > determine how to forward OAM packets.  They are used only
>> >>>> > by the recipient MIP/MEP to verify that the OAM packet was
>> >>>> > properly delivered.
>> >>>> >
>> >>>> >    By the way, this discussion is an indication of the
>> >>>> > confusing injected by calling these things addresses.  My
>> >>>> > mistake and I bring it up now to help to stem the tide of
>> >>>> > further comments resulting from that confusion.
>> >>>> >
>> >>>> >    In the version we post after last call is complete,
>> >>>> > we will be changing the source and destination "address"
>> >>>> > TLVs to source and destination "identifier" TLVs.
>> >>>> >
>> >>>> >    We will also be correcting the reference to DSMAP,
>> >>>> > and DDMAP, address TLVs (which is incorrect, because the
>> >>>> > format for DSMAP/DDMAP doesn't include a "length" field).
>> >>>> >
>> >>>> >    The format of the Downstream Mapping (DSMAP) TLV is
>> >>>> > defined in RFC 4379, and we are not changing the format
>> >>>> > of that TLV.
>> >>>> >
>> >>>> >    These changes are driven by last call comments we
>> >>>> > have already received (see Joel Halpern's comments on the
>> >>>> > mailing list) and are - in part - to correct accidental
>> >>>> > use of the word "address" for source and destination
>> >>>> > identifier TLVs (which is what we had discussed before
>> >>>> > I generated the -03 version among the authors of several
>> >>>> > of the current set of MPLS-TP drafts).
>> >>>> >
>> >>>> >    In the case of source and destination identifiers,
>> >>>> > these will be used exclusively to verify that an OAM PDU
>> >>>> > has been correctly received by its intended recipient.
>> >>>> > Because this is an on-demand connectivity verification
>> >>>> > protocol, that is expected to be used only on those
>> >>>> > occasions when there is a network problem that needs to
>> >>>> > be diagnosed, and the information is not seen (and not
>> >>>> > visible - without layer violations), optimizing these
>> >>>> > objects for software makes sense.
>> >>>> >
>> >>>> >    In addition, since either may be included (which
>> >>>> > includes the possibility of including both), it is the
>> >>>> > case already that we would then need to decide which is
>> >>>> > to go first - assuming we wanted to do this (which we
>> >>>> > do not).
>> >>>> >
>> >>>> > --
>> >>>> > Eric
>> >>>> >
>> >>>> > -----Original Message-----
>> >>>> > From: [e-mail]
>> [mailto:[e-mail]]
>> >>>> > Sent: Monday, March 28, 2011 8:11 AM
>> >>>> > To: Eric Gray; [e-mail]
>> >>>> > Cc: [e-mail]
>> >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-
>> tp-on-
>> >>>> > demand-cv-03
>> >>>> > Importance: High
>> >>>> >
>> >>>> > Hi Eric and Rolf,
>> >>>> >
>> >>>> > I'm sorry for interrupting.
>> >>>> >
>> >>>> > I agree with Rolf regarding the per-interface MIP discussion.
>> >>>> > We have to consider the HW implementation aspect,
>> >>>> > because trapping of an OAM packet is HW rule/functionality even
>> in
>> >>>> > routers.
>> >>>> >
>> >>>> > If every OAM packet is trapped to CPU
>> >>>> > and the OAM packets which should NOT be processed in the
>> Interface
>> >>>> > are returned to Data-plane,
>> >>>> > it is different forwarding path from user packets,
>> >>>> > which is NOT the Connectivity Verification of the user path.
>> >>>> >
>> >>>> > Therefore, we should take the HW aspect and flexibilty into
>> account
>> >>>> > concurrently.
>> >>>> > If an address TLV MUST be the first in TLVs,
>> >>>> > it is enough to make HW implementation easy.
>> >>>> >
>> >>>> > BR,
>> >>>> > Hideki
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > >Rolf,
>> >>>> > >
>> >>>> > >  The words you propose are okay with me.
>> >>>> > >
>> >>>> > >  I thought the MIP/interface and address location issues
>> >>>> > >were separate.
>> >>>> > >
>> >>>> > >  I've personally had problems with protocol specifications
>> >>>> > >that require ordering of TLVs.  In particular, this is not very
>> >>>> > >robust in terms of "future-proofing."  What happens if new TLVs
>> >>>> > >are added later on; for instance, suppose at some point we have
>> >>>> > >multiple "address" TLVs?
>> >>>> > >
>> >>>> > >  Also, the fact that implementations are allowed to attach
>> >>>> > >TLVs in any arbitrary order allows considerable flexibilty in
>> >>>> > >implementation.  Messages can be built in arbitrarily many
>> ways.
>> >>>> > >This too can be a future-proofing issue.
>> >>>> > >
>> >>>> > >  I would prefer not to start down the road of requiring a
>> >>>> > >subset of TLVs to appear in a certain order, and saying we have
>> >>>> > >one TLV that needs to be first is doing just that.
>> >>>> > >
>> >>>> > >--
>> >>>> > >Eric
>> >>>> > >
>> >>>> > >-----Original Message-----
>> >>>> > >From: Rolf Winter [mailto:[e-mail]]
>> >>>> > >Sent: Monday, March 28, 2011 6:19 AM
>> >>>> > >To: Eric Gray
>> >>>> > >Cc: [e-mail]
>> >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-
>> tp-on-
>> >>>> > demand-cv-03
>> >>>> > >Importance: High
>> >>>> > >
>> >>>> > >Hi,
>> >>>> > >
>> >>>> > >I still think there is a logical error. Let me explain. In case
>> there
>> >>>> > is no IP you simply cannot use it. You say you could enable IP
>> but then
>> >>>> > that is not a case where there is no IP. In order to be
>> constructive
>> >>>> > here is a text change suggestion:
>> >>>> > >
>> >>>> > >"In certain MPLS-TP deployment scenarios IP addressing might
>> not be
>> >>>> > available. In those cases On-demand CV and/or route tracing MUST
>> be run
>> >>>> > without IP addressing, using the ACH channel type specified in
>> Section
>> >>>> > 3. In other cases it might be available, however, it may be
>> preferred
>> >>>> > to use some form of non-IP encapsulation. In those cases, the
>> >>>> > procedures as outlined in section 3 SHOULD also be used."
>> >>>> > >
>> >>>> > >Regarding the per-interface MIP discussion. The HW aspect also
>> popped
>> >>>> > up in the PWE3 session and I think this is an important
>> consideration,
>> >>>> > in particular for OAM. Even if we talk about TLVs, we could make
>> it a
>> >>>> > MUST that an Address TLV is always the first one to appear. If
>> you can
>> >>>> > facilitate an easy implementation in hardware, I see no reason
>> to
>> >>>> > deliberately not do it.
>> >>>> > >
>> >>>> > >Best,
>> >>>> > >
>> >>>> > >Rolf
>> >>>> > >
>> >>>> > >
>> >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>> Road,
>> >>>> > London W3 6BL | Registered in England 2832014
>> >>>> > >
>> >>>> > >
>> >>>> > >> -----Original Message-----
>> >>>> > >> From: Eric Gray [mailto:[e-mail]]
>> >>>> > >> Sent: Montag, 28. März 2011 11:43
>> >>>> > >> To: Rolf Winter
>> >>>> > >> Cc: [e-mail]; [e-mail]
>> >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-
>> mpls-tp-on-
>> >>>> > >> demand-cv-03
>> >>>> > >>
>> >>>> > >> Rolf,
>> >>>> > >>
>> >>>> > >>         With regard to the use of SHOULD (verses MUST) - the
>> intent
>> >>>> > >> (according to RFC 2119 - see the quote below) is consistent
>> with
>> >>>> > >> this case.  If - for some reason - one had a really good
>> reason to
>> >>>> > >> use IP addressing in some specific case, one could take steps
>> to
>> >>>> > >> make IP addressing available.
>> >>>> > >>
>> >>>> > >>         This could be said to introduce a logical disconnect,
>> but we
>> >>>> > >> are saved from going down that path by the fact that the
>> statement
>> >>>> > >> also includes the case where (for some reason) there is a
>> case in
>> >>>> > >> which some other addressing scheme might be preferred.  In
>> many of
>> >>>> > >> the cases where another addressing scheme may be preferred,
>> it is
>> >>>> > >> still possible (in fact likely) that IP addressing is
>> available.
>> >>>> > >>
>> >>>> > >>         Otherwise, it would not have been necessary to
>> distinguish
>> >>>> > >> this case from the one in which IP addressing is not
>> available.
>> >>>> > >>
>> >>>> > >>         For the case where IP addressing is not the preferred
>> mode,
>> >>>> > >> we are recommending a mode in which it is not necessary.
>> >>>> > >>
>> >>>> > >>         With regard to having addresses located in the same
>> place,
>> >>>> > >> this protocol is meant for connectivity testing on an on-
>> demand
>> >>>> > >> basis and is therefore not optimized for processing in
>> hardware.
>> >>>> > >>
>> >>>> > >>         Whether addresses or identifiers, if we are talking
>> about
>> >>>> > >> TLV contents, there are issues with trying to guarantee
>> location
>> >>>> > >> of specific content, because of the fact that the TLV in
>> question
>> >>>> > >> will probably follow other TLVs - thus making locations
>> difficult
>> >>>> > >> to predict in any case.
>> >>>> > >>
>> >>>> > >>         With regard to needing more text on per-interface
>> MIPs, do
>> >>>> > >> you have specific suggestions as to what text we might add?
>> >>>> > >>
>> >>>> > >>         I understand (from discussion with WG chairs) that we
>> are
>> >>>> > >> not allowed to explicitly address last call comments during
>> the
>> >>>> > >> IETF meeting in Prague, because the last call is still
>> ongoing
>> >>>> > >> at that time.
>> >>>> > >>
>> >>>> > >> --
>> >>>> > >> Eric
>> >>>> > >>
>> >>>> > >> PS -
>> >>>> > >> From RFC 2119 -
>> >>>> > >> 'SHOULD   This word, or the adjective "RECOMMENDED", mean
>> that there
>> >>>> > >>           may exist valid reasons in particular circumstances
>> to
>> >>>> > >>           ignore a particular item, but the full implications
>> must
>> >>>> > >>           be understood and carefully weighed before choosing
>> a
>> >>>> > >>           different course.'
>> >>>> > >>
>> >>>> > >> -----Original Message-----
>> >>>> > >> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>> >>>> > Of
>> >>>> > >> Rolf Winter
>> >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM
>> >>>> > >> To: [e-mail]; [e-mail]
>> >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-
>> mpls-tp-on-
>> >>>> > >> demand-cv-03
>> >>>> > >>
>> >>>> > >> Hi,
>> >>>> > >>
>> >>>> > >> some comments below:
>> >>>> > >>
>> >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios
>> IP
>> >>>> > >> addressing might not be
>> >>>> > >>    available or it may be preferred to use some form of non-
>> IP
>> >>>> > >>    encapsulation for On-demand CV, route tracing and BFD
>> packets.
>> >>>> > In
>> >>>> > >>    such scenarios, On-demand CV and/or route tracing SHOULD
>> be run
>> >>>> > >>    without IP addressing..."
>> >>>> > >>
>> >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing
>> is
>> >>>> > >> available, this thing MUST be run without IP addressing,
>> mustn't it?
>> >>>> > >>
>> >>>> > >> I think some additional text regarding per-interface MIP
>> addressing
>> >>>> > >> would be nice. As far as I understand the document, all TLVs
>> will be
>> >>>> > >> inside the LSP ping packet (rather than as ACH TLVs).
>> >>>> > >>
>> >>>> > >> Some people had concerns earlier, that addressing information
>> should
>> >>>> > be
>> >>>> > >> in a fixed location for easier processing. Is this the case
>> here I
>> >>>> > >> wonder?
>> >>>> > >>
>> >>>> > >> It would be nice if you could address this in your
>> presentation in
>> >>>> > >> Prague.
>> >>>> > >>
>> >>>> > >> Thanks,
>> >>>> > >>
>> >>>> > >> Rolf
>> >>>> > >>
>> >>>> > >>
>> >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>> Road,
>> >>>> > >> London W3 6BL | Registered in England 2832014
>> >>>> > >>
>> >>>> > >>
>> >>>> > >> > -----Original Message-----
>> >>>> > >> > From: [e-mail] [mailto:[e-mail]]
>> On
>> >>>> > Behalf
>> >>>> > >> Of
>> >>>> > >> > [e-mail]
>> >>>> > >> > Sent: Mittwoch, 16. März 2011 00:26
>> >>>> > >> > To: [e-mail]
>> >>>> > >> > Cc: MPLS-TP ad hoc team
>> >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-
>> tp-on-
>> >>>> > >> demand-
>> >>>> > >> > cv-03
>> >>>> > >> >
>> >>>> > >> > Working Group,
>> >>>> > >> >
>> >>>> > >> > this is to start a 3 week working group last call on
>> >>>> > >> >
>> >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03
>> >>>> > >> >
>> >>>> > >> > Please send comments to the working group mailing list
>> >>>> > >> > [e-mail]
>> >>>> > >> >
>> >>>> > >> > The working group last call ends on April 8, 2011.
>> >>>> > >> >
>> >>>> > >> > /Loa
>> >>>> > >> >
>> >>>> > >> >
>> >>>> > >> >
>> >>>> > >> >
>> >>>> > >> > _______________________________________________
>> >>>> > >> > 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
>> >>>
>> >>
>> >
>