[mpls] FW: Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-

[Eric Gray <[e-mail]>]

Resending this message in plain text (too big)...
________________________________

From: Eric Gray [mailto:[e-mail]]
Sent: Friday, April 01, 2011 6:41 AM
To: Greg Mirsky; Alexander Vainshtein
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-


Out of curiosity, where would you expand it (i.e. - where would you suggest we
say this)?

________________________________

From: Greg Mirsky [mailto:[e-mail]]
Sent: Thursday, March 31, 2011 3:10 AM
To: Alexander Vainshtein
Cc: [e-mail]; Eric Gray; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-


Dear Sasha and All,
considering that LSP ping can specify the return path for the LSP Echo Reply, I'd expand capability to LSP ping MEP-to-MIP to all MPLS-TP constructs, bi-directional as well as unidirectional. The return path might be directed over an LSP which is in reverse direction that is not necessarily is associated with LSP that been tested by LSP Echo Request.

Regards,
Greg


On Wed, Mar 30, 2011 at 11:43 PM, Alexander Vainshtein <[e-mail]> wrote:


        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:%2B49%2030%203497%20-%204394>  (Tel.)
        > >>>[phone] - 4956 <tel:%2B49%2030%203497%20-%204956>  (Fax)
        > >>>[phone] <tel:%2B49%20171%20%208634032>  (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
        > >>>
        > >>
        > >
        _______________________________________________
        mpls mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/mpls