Subject: [PWE3] draft-ietf-mpls-icmp-08

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 16 May 2007 08:32:39 +0300

The IESG has approved the following document:
- 'ICMP Extensions for MultiProtocol Label Switching '
<draft-ietf-mpls-icmp-08.txt>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-08.txt as a
Proposed Standard

Quote from the draft:

   When an LSR receives an undeliverable MPLS encapsulated datagram, it
   removes the entire MPLS label stack, exposing the previously
   encapsulated IP datagram.  The LSR then submits the IP datagram to an
   error processing module.  Error processing can include ICMP message
   generation.

Petty that there wasn't a mention of what to do when
the MPLS packet does not contain IP.

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Wed, 16 May 2007 08:36:24 +0100

Yaakov,

There is also the point that, because merging is allowed in MPLS, a
label does not have consistent semantics.....that is:
-	in the normal forwarding case the label is a (usually swapped)
proxy for a LSP DA
-	but to correctly demerge a label must also now be allowed to
take on the role of a (non-swapped) proxy for a LSP SA.

So, if one has misconnectivity and one does not have consistent label
semantics how can one even make any sense of the label interpretation?
In other words, over/above the case you point out (which is correct IMO)
one cannot be sure of behaviour in any case, eg forward incorrectly at
some point (but not realised as incorrect forwarding at that point) or
black-hole (ie label unknown at some node)....the latter then having the
potential consequence you mention.

Finally, one may not have the same OAM on different LSPs so again this
could be misinterpreted under misconnectivity, eg LSPs supporting
rfc2547-style VPNs do not have the VCCV OAM which is only associated
with PWs.  So again, how is this handled?

These are all examples/consequences of not having consistent CI
(characteristic information) within the MPLS layer network.

regards, Neil

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: 16 May 2007 06:33
> To: [email-masked]
> Subject: [PWE3] draft-ietf-mpls-icmp-08
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-icmp-08.tx
> t as a Proposed Standard
> 
> Quote from the draft:
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 May 2007 10:37:13 +0100

> the MPLS packet does not contain IP.

Well if there is anything useful that can be done we (for some value of 
we) can write a draft.
However it's not clear what you can do, because as Neil reminds us, MPLS 
has label merging
and no return address.

If we really think its a problem I suppose we could include a PE return 
address in the PW header,
but we would have to run on an ACH so that the midpoints would know what 
to do.

However the question is one of whether this and all the reengineering is 
worth pursuing?

BTW there are other problems with the base proposal, in that the IP 
packet below the stack may
be an IP packet with an out of context address. But this in not the list 
to discuss that on....

- Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 16 May 2007 19:21:58 +0300

Neil, 

I quite agree that if the MPLS is not encapsulating IP, then the meaning
is unclear.

So perhaps the draft should simply have said "if the first nibble is not
4 or 6
then the ICMP message should be ignored". 

On the other hand, the draft could have said "if the MPLS is
encapsulating a on-IP payload
(e.g. a PW) then the ping shoud be sent using VCCV (which is beyond the
scope
of this document)."

I wasn't even thinking of  2547-style VPNs.
There, if one removes the entire MPLS stack,
then in general one is left with an ambiguous IP address.
So this is a flaw rather than a lacuna.

I am not sure what we should do about this.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 10:36
To: Yaakov Stein
Cc: [email-masked]
Subject: RE: [PWE3] draft-ietf-mpls-icmp-08

Yaakov,

regards, Neil

> Petty that there wasn't a mention of what to do when the MPLS packet 
> does not contain IP.
> 
> Y(J)S
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 May 2007 14:19:32 -0400

The issue with this draft was that it was originally written
when LDP and TE were basically the only apps being considered, and so
this was intended to debug the IGP LSPs only and not the label
stacks containing more than one label, thus their IP addresses
would be germane to the network where they are intercepted. I am not  
sure
anyone was thinking of L3/L2 VPN or PW applications at that time for  
this
tool, although these issues should have been caught when this document
was progressed recently. I guess no one was paying attention because it
has been sitting in the review process for around 5 years. :P

	To address the issues briefly. It is fortunate that
although this tool is widely deployed, it is largely superseded
by LSP ping/trace these days, and so should not run into issues
in practice.

	I do agree with you that it would be useful to write a
BCP for this explaining these issues and the potential pitfalls
therein.
	
	--Tom

> Well if there is anything useful that can be done we (for some  
> value of we) can write a draft.
> However it's not clear what you can do, because as Neil reminds us,  
> MPLS has label merging
> and no return address.
>
> If we really think its a problem I suppose we could include a PE  
> return address in the PW header,
> but we would have to run on an ACH so that the midpoints would know  
> what to do.
>
> However the question is one of whether this and all the  
> reengineering is worth pursuing?
>
> be an IP packet with an out of context address. But this in not the  
> list to discuss that on....
>
> - Stewart
>
>

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 26 May 2007 01:04:09 -0400

Yaakov,

draft-ietf-mpls-icmp-08 does not define the circumstances under which
ICMPs are generated due to undeliverable MPLS packets/MPLS forwarding
errors, nor the relationship between MPLS and ICMP. It points back to
Section 2.3 (and recursive pointers to Section 2.2 and others) of
RFC3032, that cover the "what to do when" scenarios.

This is, I think, clear in draft-ietf-mpls-icmp-08, in the paragraph
that precedes the one you quoted:

   information to source hosts.  Section 2.3 of [RFC3032] describes the
   interaction between MPLS and ICMP, and Sections 2.4 and 3 of
   [RFC3032] provide applications of that interaction.

And this pointer in turn says:
http://tools.ietf.org/html/rfc3032#section-2.3

   to generate ICMP messages for labeled IP packets.  In order for a
   particular LSR to be able to generate an ICMP packet and have that
   packet sent to the source of the IP packet, two conditions must hold:

      1. it must be possible for that LSR to determine that a particular
         labeled packet is an IP packet;

      2. it must be possible for that LSR to route to the packet's IP
         source address.

So no ICMP unless IP.

[Note also that the lack of return address of the incoming MPLS Label is
covered by label-switching the icmp generated in the forward direction,
http://tools.ietf.org/html/rfc3032#section-2.3.2]

So draft-ietf-mpls-icmp-08 provides the ability to add a piece of
information (the MPLS Label Stack Object) when some ICMPs are generated
(as specified in RFC3032), and does not concern itself with what
triggers (or prevents) the generation of ICMPs. In addition,
draft-ietf-mpls-icmp-08 then states:

http://tools.ietf.org/html/draft-ietf-mpls-icmp-08#section-4
4. Disclaimer

   This memo does not define the general relationship between ICMP and
   MPLS.  Section 2.3 of [RFC3032] defines this relationship.

http://tools.ietf.org/html/draft-ietf-mpls-icmp-08#section-6
6. Security Considerations

   This memo does not specify the conditions that trigger the generation
   of ICMP Messages for Labeled IP Packets.  It does not define the
   interaction between MPLS and ICMP.  However, this document defines an

Please see two more comments inline.

> then the ICMP message should be ignored". 

If you mean "should not be generated", then that's what happens now.

> (e.g. a PW) then the ping shoud be sent using VCCV (which is beyond the

It seems to me that draft-ietf-mpls-icmp-08 would not have been the
right place to suggest this, because of the scope; even more so when the
icmp is not echo (not ping, which is the only one that vccv mentions),
and the message would be generated in the middle of a PW (and not an
endpoint) that does not know VCCV capabilities at disposition (and
cannot even know if CW is in use).

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 27 May 2007 13:45:02 +0300

Carlos, 

I agree that draft-ietf-mpls-icmp-08 did not intend getting
into the issue of when ICMP messages SHOULD be returned.

My concern was that it handles this by quoting in normative fashion
an RFC which is no longer up to date in this very issue.

All the text that says that whether or not ICMP replies are
sent is beyond the scope of this document are fine.

The text that says that the proper handling is according to 3032,
and then compounds the problem by adding the text I quoted,
is questionable.

Y(J)S

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Sun, 27 May 2007 14:05:18 +0300

Yaakov,

Do you imply that RFC 3032 is not up to date? And, if so, do you think
that draft-ietf-mpls-ecmp-bcp-03.txt
 (now in the EDIT state in the RFC Editor queue) should be considered as
an update to RFC 3032 addressing
your worries?

If so, may be it would be not too late to ask the authors to consider
that. 
Currently the text does not even contain a reference to RFC 3032.

Regards,
                      Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Sunday, May 27, 2007 1:45 PM
To: Carlos Pignataro
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] draft-ietf-mpls-icmp-08

Carlos, 

I agree that draft-ietf-mpls-icmp-08 did not intend getting into the
issue of when ICMP messages SHOULD be returned.

My concern was that it handles this by quoting in normative fashion an
RFC which is no longer up to date in this very issue.

All the text that says that whether or not ICMP replies are sent is
beyond the scope of this document are fine.

The text that says that the proper handling is according to 3032, and
then compounds the problem by adding the text I quoted, is questionable.

Y(J)S

---

From: Carlos Pignataro <[email-masked]>
Date: Sun, 27 May 2007 09:53:05 -0400

Yaakov,

> an RFC which is no longer up to date in this very issue.

Why specifically is this handling (in RFC3032 and outside
draft-ietf-mpls-icmp) outdated/obsolete? RFC3032 says that to generate
ICMP messages:

      1. it must be possible for that LSR to determine that a particular
         labeled packet is an IP packet;
...
   Condition 1 is discussed in section 2.2.

And that section in turn mentions:

   For instance, if an
   intermediate LSR determines that a labeled packet is undeliverable,
   it may be desirable for that LSR to generate error messages which are
   specific to the packet's network layer.  The only means the
   intermediate LSR has for identifying the network layer is inspection
   of the top label and the network layer header.

The scenario you presented seems to fall in:

   If a packet cannot be forwarded for some reason (e.g., it exceeds the
   data link MTU), and either its network layer protocol cannot be
   identified, or there are no specified protocol-dependent rules for
   handling the error condition, then the packet MUST be silently
   discarded.

> and then compounds the problem by adding the text I quoted,

In any case, draft-ietf-mpls-icmp-08 does not seem to be underdefined.
And it seems pwe3 could define what an LSR might do if an MPLS packet is
undeliverable and it can determine the contents to be pw.

Thanks,

--Carlos.

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 28 May 2007 17:47:29 +0300

Carlos

> draft-ietf-mpls-icmp) outdated/obsolete? 

3032 states:
   This means that the identity of the network layer protocol
   must be inferable from the value of the label which is popped from
   the bottom of the stack, possibly along with the contents of the
   network layer header itself.

MPLS as presently defined carries 1 of 3 different payload types
  1) MPLS - via label stacking - identifiable via the S bit
  2) IP - identifiable by 4 or 6 in the first nibble after the label
stack
  3) PW - identifiable by 0 or 1 in the first nibble.

So there is no longer a requirement for inferring payload type from the
label.
Instead, one should look at the S bit and first nibble.
This is what I meant by outdated.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 28 May 2007 17:53:11 +0300

Sasha, 

Yes, the ECMP draft goes a long way to solving the problem,
but I am not sure that it is the perfect reference as its purpose
is the definition of ECMP behavior.

It is unfortunate that the CW RFC does not give the first nibble
an explicit name (instead of "first nibble") and set up a registry.
That would solve the problem.

What do you mean that the text does not reference 3032?
draft-ietf-mpls-icmp-08 not only references 3032
it relies on it heavily (see 3rd paragraph of section 2). 

Y(J)S

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Sunday, May 27, 2007 14:05
To: Yaakov Stein
Cc: [email-masked]; [email-masked]; Carlos Pignataro
Subject: RE: [PWE3] draft-ietf-mpls-icmp-08

Yaakov,

Do you imply that RFC 3032 is not up to date? And, if so, do you think
that draft-ietf-mpls-ecmp-bcp-03.txt  (now in the EDIT state in the RFC
Editor queue) should be considered as an update to RFC 3032 addressing
your worries?

Regards,
                      Sasha

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 28 May 2007 17:56:37 +0300

Yaakov,
What I said is that draft-ietf-mpls-ecmp-bcp-03.txt does not refer to
3032 (and hence it is problematic to consider it as an update to
3032:-).

Regards,
                 Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Monday, May 28, 2007 5:53 PM
To: Sasha Vainshtein
Cc: [email-masked]; Carlos Pignataro
Subject: RE: [PWE3] draft-ietf-mpls-icmp-08

Sasha, 

Yes, the ECMP draft goes a long way to solving the problem, but I am not
sure that it is the perfect reference as its purpose is the definition
of ECMP behavior.

It is unfortunate that the CW RFC does not give the first nibble an
explicit name (instead of "first nibble") and set up a registry.
That would solve the problem.

What do you mean that the text does not reference 3032?
draft-ietf-mpls-icmp-08 not only references 3032 it relies on it heavily
(see 3rd paragraph of section 2). 

Y(J)S

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Sunday, May 27, 2007 14:05
To: Yaakov Stein
Cc: [email-masked]; [email-masked]; Carlos Pignataro
Subject: RE: [PWE3] draft-ietf-mpls-icmp-08

Yaakov,

Regards,
                      Sasha