Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03

From: [email-masked]
Date: Wed, 16 Mar 2011 00:26:15 +0100

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
[email-masked]

The working group last call ends on April 8, 2011.

/Loa

---

From: Rolf Winter <[email-masked]>
Date: Tue, 22 Mar 2011 08:56:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Mittwoch, 16. März 2011 00:26
> To: [email-masked]
> Cc: MPLS-TP ad hoc team
> Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-
> cv-03
> 
> Working Group,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Fri, 25 Mar 2011 20:52:06 +0900

Hi Authers of draft-on-demand-cv,

I agree with Rolf regarding MIP addressing and its TLV location.

In order to identify a per-interface MIP,
the target TLV of MIP ID is needed.
And, fixed location of MIP ID TLV in Ping packet
makes HW implementation easier.

Furthermore, ping extention of TTL TLV has been
WG doc as draft-ietf-mpls-lsp-ping-ttl-tlv-00.
This extention enables LSP ping between LSRs(MIPs).
I expect this extention will be applied to MPLS-TP On-demand CV between MIPs,
because MPLS-TP on-demand CV is based on MPLS LSP Ping.
Do you consider this extension for draft-on-demand-cv at this point?
If yes, not only the target TLV of MIP ID but also the source TLV of MIP ID
is needed to execute on-demand CV between per-interface MIPs.

Thanks,
Hideki

---

From: Eric Gray <[email-masked]>
Date: Mon, 28 Mar 2011 05:43:01 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Tuesday, March 22, 2011 4:57 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03

Hi,

some comments below:

Thanks,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Mon, 28 Mar 2011 10:19:04 +0000

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

> From: Eric Gray [mailto:[email-masked]]
> Sent: Montag, 28. März 2011 11:43
> To: Rolf Winter
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-
> demand-cv-03
> 
> Rolf,
> 
> Rolf Winter
> 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?
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
>

---

From: Eric Gray <[email-masked]>
Date: Mon, 28 Mar 2011 07:41:52 -0400

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:[email-masked]] 
Sent: Monday, March 28, 2011 6:19 AM
To: Eric Gray
Cc: [email-masked]
Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03
Importance: High

Hi,

Best,

Rolf

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 21:10:31 +0900

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

---

From: Eric Gray <[email-masked]>
Date: Mon, 28 Mar 2011 08:44:32 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 8:11 AM
To: Eric Gray; [email-masked]
Cc: [email-masked]
Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03
Importance: High

Hi Eric and Rolf,

BR,
Hideki

---

From: Rolf Winter <[email-masked]>
Date: Mon, 28 Mar 2011 13:02:49 +0000

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

> Sent: Montag, 28. März 2011 14:45
> To: [email-masked]; Rolf Winter
> Cc: [email-masked]
> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-
> on-demand-cv-03
> 
> Hideki,
> 
> >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
> >
> >
> >> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> > [email-masked]

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 22:43:35 +0900

Hi Eric,

What I'd like to say was explaned by Rolf.
My concern is whether the OAM packet is fate sharing with user packet or NOT.
If draft-on-demand-cv doesn't care anything for fate sharing 
in the case of per-interface MIP,
the per-interface MIP can NOT be implemented by HW reasonably.

BR,
Hideki

---

From: Sami Boutros <[email-masked]>
Date: Mon, 28 Mar 2011 13:08:34 -0700

At 06:02 AM 3/28/2011, Rolf Winter wrote:
>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.

It can still fate share based on the 
implementation, if the packet get injected via 
the same HW path, and be punted again on the Egress LineCard.

>I know this is a different draft, but this will 
>be in particular important for performance monitoring.

I assume you will put the egress MIP in loopback for this monitoring..

Thanks,

Sami

>Best,
>
>Rolf
>
>
>
>NEC Europe Limited | Registered Office: NEC 
>House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>
>

---

From: Sami Boutros <[email-masked]>
Date: Mon, 28 Mar 2011 13:33:15 -0700

>the per-interface MIP can NOT be implemented by HW reasonably.

Keep in mind that a node decrement TTL once, and 
this per-interface MIP seems to require a node to decrement twice..

Thanks,

Sami

>BR,
>Hideki
>
> >Eric,
> >
> >I generally agree but I think there is one 
> case actually which needs a closer look in this 
> 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
> >
> >
> >

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Mar 2011 15:04:43 -0700

Hi Sami,
alternative to decrementing TTL for out-MIP approach, to use reserved
Outgoing MIP Label (OML), presented in draft-farrel-mpls-tp-mip-mep-map-03.
Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV Header per
RFC 5586 OML might be the better solution to address out-MIP.

Regards,
Greg

On Mon, Mar 28, 2011 at 1:33 PM, Sami Boutros <[email-masked]> wrote:

> Keep in mind that a node decrement TTL once, and this per-interface MIP
> seems to require a node to decrement twice..
>
> Thanks,
>
> Sami
>
>
>  BR,
>> Hideki
>>
>> >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

---

From: Rolf Winter <[email-masked]>
Date: Tue, 29 Mar 2011 07:25:27 +0000

Hi Sami,

see inline.

> this per-interface MIP seems to require a node to decrement twice..

I don't think this is a good idea. This is not how the TTL works today. I think this is very unwise and touching a pretty fundamental principle here. FWIW, we have proposed an alternative and presented it the last IETF. Unfortunately, we have received little feedback on it. But I think the discussion we have right now is good and not too late. The OAM framework document includes per-interface MIPs and I think the group needs to start thinking hard now to make sure this is thought about before we finish off all these OAM tools. This way we do not need to come back later and change things. I don't think it will be overly hard, we just need to agree on something.

Best,

Rolf

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 16:33:22 +0900

Hi Sami,

I don't think that the per-interface MIP requires a node to decrement TTL twice.
I have proposed draft-mip-mep-map to avoid twice decrement of TTL.
However, we, authers, don't push specific solution for per-interface MIP at this point,
which presented by Rolf at previous meeting at Beijing.

We have several options to identify per-interface MIP without twice decrement of TTL;
(1)MIP ID in ACH-TLV
(2)MIP ID in Ping address TLV
(3)OML
(4)GAL TTL(I proposed before, but now removed from our draft)

We can discuss the best solution in this meeting.

BR,
Hideki

---

From: Sami Boutros <[email-masked]>
Date: Tue, 29 Mar 2011 00:51:52 -0700

Agreed folks,

The solution options you propose on the draft 
would work and will be transparent to the
on-demand-cv draft.

Thanks,

Sami
At 12:33 AM 3/29/2011, [email-masked] wrote:
>However, we, authers, don't push specific 
>solution for per-interface MIP at this point,
>We have several options to identify 
>per-interface MIP without twice decrement of TTL;
>(1)MIP ID in ACH-TLV
> >>> >> >> Subject: Re: [mpls] Working Group Las 
> Call on draft-ietf-mpls-tp-on-
> >>> >> >> demand-cv-03
> >>> >> >>
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> some comments below:
> >>> >> >>
> >>> >> >> Some people had concerns earlier, 
> that addressing information should
> >>> >> be

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Mar 2011 03:56:13 -0400

Which meeting are you referring to?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 3:33 AM
To: [email-masked]; [email-masked]
Cc: Eric Gray; [email-masked]; [email-masked]
Subject: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03

Hi Sami,

BR,
Hideki

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Mar 2011 04:03:44 -0400

Rolf,

	There is no case here to support your argument that TTL is
always only decremented by one.  We should discuss this (as has 
been proposed), however - if you read the Routing Requirements 
RFC (RFC 1812) - you will find that the actual requirement is for 
a "forwarder" to decrement TTL "by at least one."

	I can think of several scenarios where a single forwarder
might be configured to decrement TTL by more than one for some
set of packets.

--
Eric

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 3:25 AM
To: Sami Boutros; [email-masked]; Eric Gray
Cc: [email-masked]
Subject: RE: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03
Importance: High

Hi Sami,

see inline.

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Tue, 29 Mar 2011 08:01:45 +0000

Sami,

yes and no. So far you define an ID inside the OAM message. The draft we refer to does something else. So if things evolve strictly separately, in the best case we have the same ID twice in a packet. In the worst case, we will run into something that will at some point resemble the VCCV type discussion earlier this week. Again, I don't think it is hard, we just need to agree on something. I'd also like to point out that the underlying issue is wider than the on-demand-cv draft really. Any OAM that need to interact with MIPs needs to address the same issue. So if we could get a wider set of people into this discussion an move forward, that would be really helpful. 

Best,

Rolf

> From: Sami Boutros [mailto:[email-masked]]
> Sent: Dienstag, 29. März 2011 09:52
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Rolf Winter; [email-masked]
> Subject: Re[2]: [mpls] Working Group Las Cal londraft-ietf-mpls-tp- on-
> demand-cv-03
> 
> Agreed folks,
> 
> > >>> My concern is whether the OAM packet is fate sharing with user
> packet or
> > >>> NOT.
> > >>> >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-
> mpls-tp-on-
> > >>> >> demand-cv-03
> > >>> >> Importance: High
> > >>> >>
> > >>> >> Hi Eric and Rolf,
> > >>> >>
> > >>> >> because trapping of an OAM packet is HW rule/functionality
> even in
> > >>> >> routers.
> > >>> >>
> > >>> >> Therefore, we should take the HW aspect and flexibilty into
> account
> > >>> >> concurrently.
> > >>> >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios
> IP
> > >>> >> >> addressing might not be
> > >>> >> >>    encapsulation for On-demand CV, route tracing and BFD
> packets.
> > >>> >> In
> > >>> >> >> It would be nice if you could address this in your
> presentation in
> > >>> >> >> Prague.
> > >>> >> >>
> > >>> >> >> Thanks,
> > >>> >> >>
> > >>> >> >> Rolf
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> > Subject: [mpls] Working Group Las Call on draft-ietf-
> mpls-tp-on-
> > >>> >> >> demand-
> > >>> >> >> > cv-03
> > >>> >> >> >
> > >>> >> >> > Working Group,
> > >>> >> >> >

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 17:12:10 +0900

Eric,

I'm sorry, we don't refer to specific meeting at this point.
Correctly,
if we have a meeting in this week,
we can discuss what the best solution is.

Let's schedule the meeting.

BR,
Hideki

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 29 Mar 2011 10:16:41 +0200

Eric, and all,
I suggest that we should look at the diagrams in RFC 3443.
They explicitly show that TTL is decremented by 1 by each LSR that the MPLS packet crosses... 

Regards,
     Sasha

> Eric Gray
> Sent: Tuesday, March 29, 2011 10:04 AM
> To: Rolf Winter; Sami Boutros; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-
> demand-cv-03
> 
> Rolf,
> 
> I don't think this is a good idea. This is not how the TTL works today.
> I think this is very unwise and touching a pretty fundamental principle
> here. FWIW, we have proposed an alternative and presented it the last
> IETF. Unfortunately, we have received little feedback on it. But I
> think the discussion we have right now is good and not too late. The
> OAM framework document includes per-interface MIPs and I think the
> group needs to start thinking hard now to make sure this is thought
> about before we finish off all these OAM tools. This way we do not need
> to come back later and change things. I don't think it will be overly
> hard, we just need to agree on something.
> 
> Best,
> 
> Rolf
>

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Mar 2011 04:28:03 -0400

Sami,

        I could see a case for decrementing TTL twice in order
to achieve this approach, but this would only be workable in
practice if the device _always_ decrements PDUs in the LSP
affected by this once at ingress port and again at egress
port.

        Otherwise, there is an obvious case in which treatment
of OAM packets on this LSP is conspicuously different from
treatment of data packets (i.e. OAM packets are decremented
twice in the same node where data packets are decremented
only once in the same LSP).

        I don't see decrementing TTL twice as a requirement,
but - then - I am not at all sure why we would be doing a
trace-route that attempts to discern not only what nodes a
specific LSP traverses, but also what ports on each node.

        That seems to be going well beyond the usual use of
trace-route.  Perhaps I missed an MPLS-TP requirement that
explicitly compels us to do this?

--
Eric

-----Original Message-----
From: Sami Boutros [mailto:[email-masked]]
Sent: Monday, March 28, 2011 4:33 PM
To: [email-masked]; Eric Gray; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03
Importance: High

Thanks,

Sami

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Mar 2011 05:11:04 -0400

Sasha,

	This is definitely starting to wander off-topic.

	I'm pretty sure that particular aspect of the diagrams 
is intended as an example.

	It is clearly possible that TTL may be decremented by
more than one by something that otherwise looks like one
forwarding device. 

	One of the continuing issues with using ASCII art in
figures is that it is relatively painful to represent the
symbol for "greater-than-or-equal-to", so people frequently
use the path of least resistance and use "=" instead...  

	I am also pretty sure that it is a generic abuse of TTL 
to use it to try to infer the number of devices on a path.

	This could be a problem if you have a sender that uses
their "knowledge" of the network topology to set a starting
TTL value.  I think this would be a mistake, but it should 
be a correctable mistake and it would certainly be an easily
detectable problem.

	One (really old, so I may be dating myself) example of
a very reasonable case for decrementing by more than one at
a forwarder is if that forwarder is using a low-speed link
to forward.  In this case, a relatively small number of PDUS
can completely consune the available bandwidth on that link
if allowed to re-traverse the link a significant number of 
times.

	I have certainly run trace-route in the past and seen
the same node show up more than once in the path (which is
an indication that the node decrements TTL by more than one.

	Originally (really dating myself now), it was also an
explicit requirement that a device would decrement TTL by 
the larger of "1", or the number of seconds that packet was
queued while being processed by the device.  At today's line
rates, this is not a realistic consideration unless a device
has an outrageously huge set of packet buffers, however.

	But it might not be unreasonable for a device to use a
higher value than one to decrement TTL in cases where a set 
of packets are experiencing unusually long processing delays,
as this might have something to do with congestion and a
larger decrement for queues experiencing congestion would
"punish" looping traffic more severely than other traffic.

--
Eric

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 4:17 AM
To: Eric Gray
Cc: [email-masked]; Rolf Winter; Sami Boutros; [email-masked]
Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03
Importance: High

Eric, and all,

Regards,
     Sasha

---

From: <[email-masked]>
Date: Wed, 30 Mar 2011 16:31:30 +0200

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
+49 30 3497 - 4394 (Tel.)
+49 30 3497 - 4956 (Fax)
+49 171  8634032 (Mobil)
E-Mail: mailto:[email-masked]
http://www.telekom.com    

> Sent: Monday, March 28, 2011 3:03 PM
> To: Eric Gray; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-
> cv-03
> 
> Eric,
> 
> 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
> 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
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 00:32:50 +0900

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

---

From: Yoshinori KOIKE <[email-masked]>
Date: Thu, 31 Mar 2011 00:48:51 +0900

Dear all,

I agree with Manuel. It is important to agree with the
solution which achieves per-interface model as soon as
possible.

I think that enhancing the draft-farrel-mpls-tp-mip-mep-map
is the best way at the moment.

Best regards,

Yoshinori

-- 
**************************************
Yoshinori Koike
Optical Transmission Systems Development Project
First Promotion Project
NTT Network Service Systems Laboratories
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
Telephone: +81 422 59 6723
Facsimile: +81 422 59 3494
Email: [email-masked]
**************************************

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 30 Mar 2011 18:01:47 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yoshinori KOIKE
Sent: Wednesday, March 30, 2011 6:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03

Dear all,

Best regards,

Yoshinori

---

From: Eric Gray <[email-masked]>
Date: Wed, 30 Mar 2011 12:14:47 -0400

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 10:32 AM
To: [email-masked]; Eric Gray; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03
Importance: High

Dear All,

Best regards,
Manuel

Deutsche Telekom AG
Group Technology
Manuel Paul
SA3-11

---

From: Eric Gray <[email-masked]>
Date: Wed, 30 Mar 2011 12:21:48 -0400

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 11:33 AM
To: [email-masked]; Eric Gray; [email-masked]; [email-masked]
Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03
Importance: High

Hi,

BR,
Hideki

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 06:43:10 +0900

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

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 30 Mar 2011 16:08:45 -0700

DSMAP or DDMAP could be used for both ping and trace. Nothing restricts using the tlv for ping.

-sam

Sent from my iPad

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 Mar 2011 01:25:31 -0400

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 5:43 PM
To: Eric Gray; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp-on-demand-cv-03
Importance: High

Eric,

BR,
Hideki

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 15:23:46 +0900

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 08:43:53 +0200

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

> [email-masked]
> Sent: Thursday, March 31, 2011 8:24 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-
> demand-cv-
>
> Hi Eric and Sam,
>
> >>>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
> Behalf Of
> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London
> >>>> W3 6BL | Registered in England 2832014
> >>>>
> >>>>
> >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-
> tp-on-
> >>>> > demand-cv-03
> >>>> > Importance: High
> >>>> >
> >>>> > Hi Eric and Rolf,
> >>>> >
> >>>> > because trapping of an OAM packet is HW rule/functionality even
> in
> >>>> > routers.
> >>>> >
> >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-
> mpls-tp-on-
> >>>> > >> demand-cv-03
> >>>> > >>
> >>>> > >> Hi,
> >>>> > >>
> >>>> > >> some comments below:
> >>>> > >>
> >>>> > >> Some people had concerns earlier, that addressing information
> should
> >>>> > be
> >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-
> tp-on-
> >>>> > >> demand-
> >>>> > >> > cv-03
> >>>> > >> >
> >>>> > >> > Working Group,
> >>>> > >> >

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 Mar 2011 03:48:04 -0400

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 31, 2011 2:24 AM
To: [email-masked]; Eric Gray; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re[2]: Re[2]: Re[2]: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-demand-cv-
Importance: High

Hi Eric and Sam,

and;

2.2.4.  Route Tracing
   <snipped>

BR,
Hideki

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 Mar 2011 04:00:29 -0400

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:[email-masked]]
Sent: Thursday, March 31, 2011 2:44 AM
To: [email-masked]; Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv-
Importance: High

Hideki, Eric, and all,

Regards,
     Sasha

> Road,
> Road,

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 17:13:39 +0900

Eric,

Thank you for clarifications.
I understand on-demand CV can be applied to both MEP-to-MEP and MEP-to-MIP.

We, especially myself, have to discard the terminology related to LSP ping
such as ping mode or Traceroute mode,
because it's very confusing in MPLS-TP.
We need the terminology according to RFCs of MPLS-TP, at least to RFC5860.

BR,
Hideki

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 04:34:41 -0400

As long as there is an option to implement per-node model, then I agree.

I would like to remind the strong advocates of per-interface model
that the large ILM and counter set duplicated on ingress and egress
doubles the size of an SRAM on-chip.  What you will probably get from
equipment vendors is an option to use all that ILM and counter SRAM on
the ingress side or use half for ingress and half for egress and get
half the ILM size.  For some product, notably purpose built LSR only
(no 4M IP routes) the ILM is perhaps the largest SRAM structure so
doubling SRAM size reduces space/power density at least somewhat).

That said, both per-node and per-interface model should be supported
in the TP documents to allow this sort of tradeoff to be decided at
deployment time by the provider.

Curtis

In message <[email-masked]>
"Sprecher, Nurit (NSN - IL/Hod HaSharon)" writes:

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yoshinori KOIKE
Sent: Wednesday, March 30, 2011 6:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03

Dear all,

Best regards,

Yoshinori

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 04:44:08 -0400

In message <[email-masked]>

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