Subject: [mpls] draft-amante-oam-ng-requirements-01

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 16 Mar 2008 09:00:58 -0700

Hi Shane,

I noted that your draft was presented at the MPLS-WG meeting. I can
acknowledge the problem in a lot of other fields you state and a
simpler solution you can use for IPv6.

Similar problems of the data packet and ICMP going through different
path occurs when we use policy based routing, like in case of IPsec.
If the tunnel selector is the 5-tuple the ICMP packet and the data
packets actually go through different tunnels across the internet.
Besides 5-tuple the DSCP value could also be used to send packets
across different IPsec tunnels (or ECMP paths), so carrying that value
too will help.

We can have similar issues for the case of fragments or encrypted
upper layer header field.

A simpler solution for the same can be the use of the Flow Label for
IPv6. If we use the same flow label as data packets for the the ICMP
packets and use the Flow label for instead of the upper protocol and
ports( for all purposes like ECMP etc), we will not have the issue at
all.

Thanks,
Vishwas
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Shane Amante <[email-masked]>
Date: Mon, 17 Mar 2008 20:22:32 -0600

Hi Vishwas,

> ports( for all purposes like ECMP etc), we will not have the issue at

I'm not sure that completely solves the problem.  First, I think that  
assumes use of the IPv6 flow-label is widely implemented and  
deployed.  (FWIW, I'd be curious to hear of or see pointers to  
implementations and deployments that support IPv6 flow-label).   
Second, that doesn't really solve the problems identified in the  
draft.  Specifically, ICMPv6 would not only have to follow the same  
data-path as user-data packets, but also (and most importantly!)  
return the 'component-link' interface name information to the  
originator of the ping6/traceroute6.  This would allow the customer  
and/or SP to (rapidly) identify the **specific component-link**,  
within a LAG or ECMP bundle, that could be causing problems and fix  
it.  ICMPv6 doesn't currently support this latter functionality, which  
is the main purpose of this draft.

-shane

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 17 Mar 2008 20:01:36 -0700

Hi Shane,

Besides the comments you replied to, I also raised the fact that a
similar issue happens in case of IPsec and other policy based routing
cases (where the ICMP and data packets may travel different paths).

Besides that I had brought forward to put the DSCP value too in the
ICMP for IPv4 solution.

>  implementations and deployments that support IPv6 flow-label).
I agree about the deployment. The reason it is not deployed is because
there aren't many use case of the same. I thought this use case is the
exact case for the use of the Flow label. We are anyway trying to make
changes to the packets.

I agree if there is more information to carry back. We can use both
the solutions simultaneously or use some extensions to ICMP you
describe. I am just dividing the solution into the two different
pieces.

Thanks,
Vishwas

---

From: Shane Amante <[email-masked]>
Date: Tue, 18 Mar 2008 08:27:51 -0600

Hi Vishwas,

> cases (where the ICMP and data packets may travel different paths).

I apologize for not replying to these comments.

Again, what we've currently specified in the draft are two things:
1)  It's recommended we request a reserved MPLS label or other codepoint 
so that the forwarding plane of intermediate devices may be able to 
quickly and easily identify "ng-oam" packets (the draft doesn't say 
whether the ng-oam packets should be ICMP or UDP, etc. -- that's 
ultimately up to the solution designers, so long as it meets the 
reqmt's); and,
2)  It must be possible for operators to, for example, specify the 
5-tuple (in the case of IPv4) in the data/payload portion of an ng-oam 
packet.  The idea is the contents of the data/payload portion of the 
ng-oam packet would be fed to the hashing algorithm to ensure that the 
ng-oam packets follow the same data-plane path as regular user-data packets.

> Besides that I had brought forward to put the DSCP value too in the

I'm not aware of any implementations that use DSCP value as input to 
load-hashing algorithms for LAG's or ECMP paths, so I'm not clear what 
value this would hold in the context of problems this draft is 
attempting to point out and drive solutions for.

> exact case for the use of the Flow label. We are anyway trying to make

Understood.

> describe. I am just dividing the solution into the two different

Understood.  However, the solution you've proposed solves a limited 
subset of the requirements outlined in the current draft.

Finally, may I suggest two things:
1)  Since this discussion seems IP-centric, can we move it entirely off 
the MPLS WG mailing list and over to the OPSAWG mailing list 
([email-masked]), which is where the requirements draft is most likely 
going to be taken up?
2)  If you wish to discuss IPv4 or IPv6 solutions (based of the this 
reqmt's draft), then they are more likely appropriate for INTAREA WG 
mailing list ([email-masked]) and discussions of the same should be 
brought up there instead of MPLS?

Thanks,

-shane