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

[Eric Gray <[e-mail]>]

Hideki,

        This is mostly a semantics issue.

        In this context, if you're doing MEP-to-MIP Ping using
the specification in this draft, you're effectively doing a
single-message traceroute.

        This is because traceroute uses deliberately TTL-limited
Ping, one message at a time.  This is also the only way you
can "Ping" an intermediate maintenance entity - i.e. - by using
TTL-limited LSP Ping.

        This is (I think) the disconnect; there should be no limit
imposed on use of DSMAP/DDMAP TLVs in on-demand CV/Traceroute,
because the same messages is used for both CV and Traceroute.

        Hopefully, this clears up any confusion...

--
Eric

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, March 31, 2011 2:24 AM
To: [e-mail]; Eric Gray; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re[2]: Re[2]: Re[2]: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-demand-cv-
Importance: High

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