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

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 16 May 2007 19:44:44 +0300

Yaakov,
Did you possibly want to say that 

	IF a labeled packet cannot be delivered (presumably because its
top label is invalid?)
	AND the first nibble immediately after the bottom of the label
stack is neither 4 nor 6
	THEN the packet should be silently discarded?

IMO this would be compliant with RFC 3031, Section 3.18 "Invalid
Incoming Label"  while the draft in question employs an option
(specified in the same section) to forward the datagram below the label
stack as unlabeled using IP forwarding rules.
The correction you presumably propose would introduce the minimal
safeguard mentioned in this section (".. can be safely forwarded as
unlabeled...") .

Maybe we should send this comment to the authors of the draft and to the
MPLS WG?

Regards,
                  Sasha  

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

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,

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
> 
> 
> 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.tx
> t 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
> 

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

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

---

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

Sasha, 

My intent was that if the first nibble is not 4 or 6
then the packet should be discarded (i.e. no answer to the ICMP).

According to the draft (as I quoted), if there is an MPLS error, 
you don't look further at the MPLS labels, but rather dump the entire
stack and look only at the IP address. This tacitly assumes that
there IS an IP address (which is not the case for PWs).

Furthermore, as Neil pointed out, even when there IS an IP address,
it may not be a public one, and so the behavior is questionable.

I am not sure that forwarding this as a comment to the authors / WG 
is a useful step after the IESG approval. 

Y(J)S

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

Yaakov,

Regards,
                  Sasha  

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

Neil, 

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