Subject: [mpls] Comment on draft-bitar-mpls-isis-explicit-null-label

From: Sriganesh Kini <[email-masked]>
Date: Sun, 13 Nov 2011 22:37:54 -0500

Guys,

I would encourage you to look at draft- kini-pwe3-encap-efficient-ip- that uses GRE to send Isis. This does not require an extra label.

- Sri

Sent from my iPad

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 14 Nov 2011 04:50:19 -0500

Sri,
I think the draft you referred to is in the context of carrying different
protocols over PWs. In addition you talk about IP/GRE encap for
multi-protcols. One can think about variations.
What we are proposing is a simple way of carrying ISIS (more generically
CLNS packets, as was pointed out by some) and enable the multiplexing of
these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW).
Overhead is smaller that for the GRE encap+PW with less config, and it is
closer to existing implementations. One label that signifies ISIS as the
carried protocol is automatically added upon sending the ISIS packet on
the tunnel and used on Receive to recognize the type of the carried packet
being an ISIS packet. Current methods of forwarding IPv4/IPv6 and MPLS
packets over an MPLS tunnel, from enacp viewpoint, remain as they are.
These packets can be multiplexed with ISIS packets on the same tunnel
using this proposal.

Thanks,
Nabil

On 11/13/11 10:37 PM, "Sriganesh Kini" <[email-masked]> wrote:

>Guys,
>
>I would encourage you to look at draft- kini-pwe3-encap-efficient-ip-
>that uses GRE to send Isis. This does not require an extra label.
>
>
>
>- Sri
>
>Sent from my iPad

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 15 Nov 2011 03:21:59 -0500

Hi Nabil,

See inline 

- Sri

Sent from my iPad

> these packets with MPLS and IP traffic on the same GMPLS tunnel (no PW).

[sri] One of the issues I see with using a fixed Label to indicate protocol type (clns) is that it goes against the mpls arch principles of keeping label value independent of protocol type. 

Another issue is that two network layer protocols (ip and clns) of the same interface are sent with different label stack depths (clns label depth is one more than ip). That strikes me as odd. The other instance where something similar occurs is the alert label, but it doesn't seem like you are defining another alert label.

Also, packets on an interface such as LLDP, how would they be sent ?

Also, why did the "network layer transport" encapsulation not meet your needs ?

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

---

From: George Swallow <[email-masked]>
Date: Tue, 15 Nov 2011 04:43:20 -0500

Sri -

See in-line:

On 11/15/11 3:21 AM, "Sriganesh Kini" <[email-masked]> wrote:

> [sri] One of the issues I see with using a fixed Label to indicate protocol
> type (clns) is that it goes against the mpls arch principles of keeping label
> value independent of protocol type.
> 
We have both IPv4 and IPv6 Explicit Null labels.  This would be a CLNS
Explicit Null.  I don¹t view that as an architectural change.
> 
> Another issue is that two network layer protocols (ip and clns) of the same
> interface are sent with different label stack depths (clns label depth is one
> more than ip). That strikes me as odd. The other instance where something
> similar occurs is the alert label, but it doesn't seem like you are defining
> another alert label.
> 
It is fairly common to send IPv6 on IPv4 TE tunnels by using an IPv6
explicit null.  
> Also, packets on an interface such as LLDP, how would they be sent ?
These are not ethernet links.  How odes LLDP apply?

...George