Subject: [mpls] questions about draft-ietf-mpls-tp-te-mib-01 and RFC 6370

From: Francesco Fondelli <[email-masked]>
Date: Wed, 1 Feb 2012 10:24:57 +0100

Hi all,

1)

--- quote from RFC 6370, Section 5.1

  At each end point, a tunnel is uniquely identified by the end point's
  Node_ID and a locally assigned tunnel number.  Specifically, a
  "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
  within the context of the Node_ID.

---

  RFC says "At each end point"... what about transit nodes?  In a
classic MPLS-TE management plane (3812 + 3813) context a tunnel is
identified by {mplsTunnelIngressLSRId, mplsTunnelEgressLSRId,
mplsTunnelIndex}.  This 3-tuple is the same on head (ingress),
tail (egress) and transit nodes.

  May I assume that the Tunnel_ID definition (i.e. A1-{Node_ID::Tunnel_Num}::
Z9-{Node_ID::Tunnel_Num}) is applicable/valid also for the identification
of a tunnel at a transit node ?  Was this the intention of RFC 6370
authors ?

2)

  In case the Tunnel_ID as described in RFC 6370 section 5.1 is OK for
identification of tunnels at transit routers then I'd like to understand
how to accommodate these bits

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}

or at the LSP_ID granularity these bits

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num

into a single mplsTunnelTable/mplsTunnelExtTable entry in case i)
mplsTunnelRole == transit and ii) the LSP is co-routed bidirectional.

  This question is primarily intended for draft-ietf-mpls-tp-te-mib-01
authors.  An example would be of great help.

thanks a lot
ciao
FF

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 3 Feb 2012 14:52:49 -0800

Francesco,

Please find answers, inline,  to your questions.

Cheers
-sam

> of a tunnel at a transit node ?  Was this the intention of RFC 6370
Yes, that is our understanding as well.
> authors.  An example would be of great help.
Short answer is, the example in the MIB doesn't describe completely the case of co-routed bi-directional tunnels.

Long answer is, we know the problem and wanting to publish a newer version with all the necessary info and examples. But we are waiting for WG chairs to make a call on the read-write objects within the MIB, so that all the necessary changes could be taken care off in the new version. Having said that, the this is what we planned to change in order to support co-routed and associated tunnels.

Co-routed bi-directional tunnels: 
-------------------------------------------
This will be modeled similar to GMPLS mib. i.e. there will be one instance of tunnel table and two separate instances of XC table, one per each direction. The row pointer object in the XC table will point to the tunnel instance. In this case, both XC table instances will point to the same Tunnel instance.

Tunnel table:
Entry1=>1[id],1[instance],10[ingress],20[egress]
                       |
                       | Row Pointer
                       v
XCTable(1[xcIndex].1[inIndex].1[outIndex])

XC Table:
Entry1=>1.1.1 - Forward direction
Entry2=>1.2.2 - Reverse direction

Associated bi-directional tunnels: 
--------------------------------------------
This is similar to the example laid out in the existing version of the MIB. There will be one instance of tunnel table and XC table per direction. There will be a new row pointer object within XC table which will point to the row instance of the reverse/opposite direction. In the case of co-routed tunnels, this object could be NULL or point to self.

Tunnel table (Forward direction)
Entry1=>1[id],1[instance],10[ingress],20[egress]
                       |
                       | Row Pointer
                       v
XCTable(1[xcIndex].1[inIndex].1[outIndex])
 
XC Table:
Entry1=>1.1.1 - Forward direction

Tunnel table (Reverse direction)
Entry2=>2[id],1[instance],20[ingress],10[egress]
                       |
                       | Row Pointer
                       v
XCTable(1[xcIndex].1[inIndex].1[outIndex])
 
XC Table:
Entry2=>2.1.1 - Reverse direction

This should be clearly identified with an example in the new version of the MIB.

HTH,
-sam
> 
> 
> 
> thanks a lot
> ciao
> FF
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Francesco Fondelli <[email-masked]>
Date: Mon, 6 Feb 2012 11:41:46 +0100

Hi Sam, all,

very clear, thank you very much.  So... given the example Sam
provided and the Section 5.3 of RFC 6370 may I assume that
in case of bidi co-routed A1-Tunnel_Num is (must? MUST? should?
SHOULD? be) equal to Z9-Tunnel_Num ?

thank you
ciao
FF

On Fri, Feb 3, 2012 at 11:52 PM, Sam Aldrin <[email-masked]> wrote:
> Francesco,
>
> Please find answers, inline, ?to your questions.
>
> Cheers
> -sam
>
> ?At each end point, a tunnel is uniquely identified by the end point's
> ?Node_ID and a locally assigned tunnel number. ?Specifically, a
> ?"Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
> ?within the context of the Node_ID.
>
> ---
>
> ?RFC says "At each end point"... what about transit nodes? ?In a
> mplsTunnelIndex}. ?This 3-tuple is the same on head (ingress),
> ?May I assume that the Tunnel_ID definition (i.e. A1-{Node_ID::Tunnel_Num}::
> of a tunnel at a transit node ? ?Was this the intention of RFC 6370
> authors ?
>
> ?In case the Tunnel_ID as described in RFC 6370 section 5.1 is OK for
> ?This question is primarily intended for draft-ietf-mpls-tp-te-mib-01
> authors. ?An example would be of great help.
>
> Long answer is, we know the problem and wanting to publish a newer version
> with all the necessary info and examples. But we are waiting for WG chairs
> to make a call on the read-write objects within the MIB, so that all the
> necessary changes could be taken care off in the new version. Having said
> that, the this is what we planned to change in order to support co-routed
> and associated tunnels.
>
> Co-routed bi-directional tunnels:?
> This will be modeled similar to GMPLS mib. i.e. there will be one instance
> of tunnel table and two separate instances of XC table, one per each
> direction. The row pointer object in the XC table will point to the tunnel
> instance. In this case, both XC table instances will point to the same
> Tunnel instance.
>
> Tunnel table:
> ? ? ? ? ? ? ? ? ? ? ? ?|
> ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer
> ? ? ? ? ? ? ? ? ? ? ? ?v
> Associated bi-directional tunnels:?
> This is similar to the example laid out in the existing version of the MIB.
> There will be one instance of tunnel table and XC table per direction. There
> will be a new row pointer object within XC table which will point to the row
> instance of the reverse/opposite direction. In the case of co-routed
> tunnels, this object could be NULL or point to self.
>
> ? ? ? ? ? ? ? ? ? ? ? ?|
> ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer
> ? ? ? ? ? ? ? ? ? ? ? ?v
> ?
> ? ? ? ? ? ? ? ? ? ? ? ?|
> ? ? ? ? ? ? ? ? ? ? ? ?| Row Pointer
> ? ? ? ? ? ? ? ? ? ? ? ?v
> ?