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

[Eric Gray <[e-mail]>]

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