Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03

[Eric Gray <[e-mail]>]

Manuel,

        Several of us had an off-line discussion, in which we
concluded that there are no changes required - or even any
that could reasonably be expected to be made - to the draft
"draft-ietf-mpls-tp-on-demand-cv-03" based on per interface
MIP support.

        Whatever technique may be developed to support the
details of per-interface MIP support was something that
could be documented in a follow-on RFC.

        In fact, there is a draft that has been written that
appears to be explicitly for that purpose.  That draft is
one you refer to (i.e. - draft-farrel-mpls-tp-mip-mep-map).

        The details of why this is true, as well as what was
discussed, are below.

        It appears that there are multiple options in how to
proceed (including the one you mention that relies on use
of TTL) and that authors of the draft that will eventually
detail the desired approach have not yet confirmed with the
WG which of all possible approaches might be acceptable to
the WG.

        In our draft, we define information that may be used
to identify a destination interface.  This would allow for
connectivity verification to be done to either the ingress
or egress interface.  As stated earlier on the list, the
intent in using this information is simply to verify that
it has been received by the intended maintenance entity.

        The information in on-demand cv TLVs is not - and
has never been - intended to be used in forwarding.

        The issue raised in discussion was that - if we were
to subsequently decide to try to use these on-demand TLVs
(specifically, the destination identifier TLV) to try to
determine which interface an OAM packet is intended for,
it would not - for certain implementations and approaches
that might be chosen - necessarily result in "shared-fate"
for data and OAM packets, i.e. - IFF the OAM packet were
shunted to a slow-path processor and TLVs had to be checked
to decide that the OAM PDU was actually intended to go to
the egress interface (since it would now have to be sent
to the egress interface).

        We view this as attempting to use the TLVs to decide
how to forward an OAM packet.  We suggested that it would
be more appropriate to put the information the mechanism
(that may be proposed) needs in a more appropriate field of
the message(s) that mechanism would use.

        The objection was raised that this would mean that
potentially the exact same information could be present in
this message twice (if - for example - it was in the field
proposed and also in a TLV).

        It is not clear how this might be considered an issue
given that there is typically not a lot of content in OAM
messages, and - even if there were - source and destination
identifier TLVs are optional.

        Also, in the course of the discussion, it was not
clear that not all possible approaches have been given due
consideration, and it was clear that not all (or possibly
any) of the considered solutions would be guaranteed to be
compatible with every implementation.

        For example, one suggestion that had apparently not
been considered was the use of different channel types to
indicate whether a specific OAM message is intended to be
intercepted by a maintenance entity associated with the
ingress or egress interface.  This suggestion had not been
considered.

        For another example, we pointed out to the authors
that the entire premise - on which the suggested behavior
relies is an assumption that a given device checks for TTL
expiry at the ingress interface.  While this is a common
implementation assumption, it is in no way guaranteed.

        As a result of all of these points, we agreed that
we cannot justify imposing a specific ordering requirement
on the TLVs in the on demand CV messages - hence there is
no change required specifically to address this issue.

--
Eric

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, March 30, 2011 10:32 AM
To: [e-mail]; Eric Gray; [e-mail]
Cc: [e-mail]
Subject: RE: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03
Importance: High


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