RE: GMPLS topics and issues of study

[Nic Neate <Nic.Neate@dataconnection.com>]

Hi all,

Following on from Richard's comments, as implementers we'd love to see
something on the new charter for some BCPs based on GMPLS
interop/implemenation experience.

In particular, we have also recently hit some issues related to the
Interface IDs and Label Sub-object used in EROs stemming from confusion over
how to interpret RFC 3473.  If anyone can clarify what is and what is not
either allowed or common practice, that would be very useful.

We would like to work with the following simple example, where node A is not
the ingress, but C is the egress.  We've done some interop testing, and
found that in some cases EROs which we considered valid did not work, while
others produced unexpected results.

	Nodes: 	A--------B--------C
	Interfaces:	 A1    B1 B2    C1  
	D/S Labels	    L1       L2

Which of the following EROs, received in a Path message by Node A, would
produce the LSP pictured?

(a)	{A1,L1};{B2,L2}
(b)	{A1,L1};{B2,L2};(C1}
(c)	{B1,L1};(C1,L2}
(d)	{A1,L1};{B1,L1};{B2,L2};(C1,L2}

Further, if some of these configurations are not allowed, where is that
typically policed?  

Regarding option (c), it appears that some vendors expect this construction,
but we're not clear how it can be accurately interpreted.  If it is valid,
how can node A know whether B1 is the incoming or outgoing interface on node
B (and therefore whether is has to process label L1)?  If it is not valid,
can this be policed?

Also, is an explicit hop to the egress always required (omitted in option
(a)).  Does it make sense to include a label on that hop, and if so what
processing should the egress node do?  In option (d) it could arguably just
ignore the label, but that probably is not the case in (c).

Thanks,

Nic



-----Original Message-----
From: Richard Rabbat [mailto:rabbat@fla.fujitsu.com]
Sent: 10 November 2004 21:46
To: ccamp@ops.ietf.org
Cc: 'Richard Rabbat'
Subject: RE: GMPLS topics and issues of study


Please note that the list under "Addressing" that we compiled and sent out
is based on the Isocore interoperability testing.
The other items:
--
RSVP message contents:
1: ERO/RRO: choice of outgoing vs. incoming interface ID
2: Forwarding destination of Path message with ERO
Control channel:
1: Best practice where multiple IP hops lie between adjacent nodes
--
are from another source so we can combine these issues as well.
Richard

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: ccamp@ops.ietf.org
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong,
Lyndon'; 'Hari Rakotoranto'; shiomoto.kohei@lab.ntt.co.jp;
kawashima.yumiko@lab.ntt.co.jp; takeda.tomonori@lab.ntt.co.jp
Subject: GMPLS topics and issues of study


Hi all,

Based on Isocore interoperability testing results from the past few months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific order
under 3 major headings.

Addressing:
1. relationship between TE Router ID and OSPF router ID 
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address 

2: IP reachability (what ID's are reachable IP addresses)

3: what address is used in the signaling message in the ERO/RRO

4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field

5:  what is used in the destination IPv4 address in the session object 

6:  what is used in the sender IPv4 address in sender object template

7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID

RSVP message contents:

1: ERO/RRO: choice of outgoing vs. incoming interface ID

2: Forwarding destination of Path message with ERO

Control channel:

1: Best practice where multiple IP hops lie between adjacent nodes

2: use of redundant/multiple IPCC. best practices 
 
We're in the process of putting together what we hope to be a comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to the
list or contact us directly.

Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja   
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda