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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Alexander Vainshtein writes:
>  
> 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


Sasha,

Ping to a MIP is effectively traceroute.  Think of it as addressing
the Nth node (using TTL), where a common case is where the Nth node
identifies itself, but where other OAM riding on ping encapsulation
could also be carried.

Curtis


> > -----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
> > >>>
> > >>
> > >
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls