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

[Eric Gray <[e-mail]>]

Hideki,

        Thanks for your detailed review and comments on this text.

        The wording you refer to needs to be clarified.  But then
this section (section 2) is modified to accommodate comments we
received during the last call in any case.

        I believe the intention is either a destination identifier
or downstream mapping TLV will be used.  A source identifier may
also be included.

        Note that both destination identifier and DSMAP/DDMAP TLVs
could be included, but this seems a recipe for a forced failure
as a result of inconsistency in possibly redundant information.

        Inclusion of any or all of these meams that they SHOULD be
used for verification by the receiver.

        For the case where the DSMAP/DDMAP TLV is used, the state-
ment to which you refer applies.  To clarify this, we should add
some text to the effect that "when the DSMAP/DDMAP TLV is used,
..."

        This results in a pile-up of qualifiers, since we already
say "When sending On-demand CV packets using ACH, without IP en-
capsulation, ..." - but it is clear from your question that the
additional qualifier may also be needed.

        Note that - in many RFCs written previously - the text in
any section of the RFC is not meant to be applied except in the
context of that section.  Hence we could say that the qualifier
I describe adding above is implicit from context.

        As far as ignoring it, it is not clear how you came to this
conclusion based on the text.  But I think we can clarify this a
little bit by again making it clear that - control plane checks
include information included in either identifier or DSMAP/DDMAP
TLVs in the non-IP case.

        Note that it's not obvious what else we might refer to as a
"control plane" - for verification purposes - in the non-IP case,
otherwise.  How does one do "signaling" (in the sense that we mean
to apply in the "MPLS control plane") if it is not IP-based?

        In this case, the "control entity" is the entity identified
by either an identifier or a DSMAP/DDMAP TLV.

--
Eric

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, May 17, 2011 5:52 AM
To: Eric Gray
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re[2]: [mpls] Working Group Last Call ondraft-ietf-mpls-tp-on-demand-cv-
Importance: High

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
>> >>>
>> >>
>> >
>