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

[<[e-mail]>]

Eric,

Thank you very much for your prompt response.
I expect to add some text to this draft as you said.

BR,
Hideki


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