Subject: RE: GMPLS topics and issues of study

From: Nic Neate <[email-masked]>
Date: Mon, 15 Nov 2004 17:13:22 -0000

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:[email-masked]]
Sent: 10 November 2004 21:46
To: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: [email-masked]
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong,
Lyndon'; 'Hari Rakotoranto'; [email-masked];
[email-masked]; [email-masked]
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Nov 2004 12:34:30 -0000

Nic,

> interop/implemenation experience.

Noted.

> either allowed or common practice, that would be very useful.

Of course, you have to return to basics with the processing rules of section 4.3.4 in RFC3209 in order to understand what is expected. I agree wholeheartedly that this could be clearer.

> produce the LSP pictured?

This is acceptable because (we assume) the Session identifies C as the destination. It might, however, be construed as unhelpful to prematurely terminate the ERO.
We can treat it exactly as case (b)

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

Note that this is illegal according to RFC3209 4.3.4.1 1)
      If the node is not part of the abstract node described
      by the first subobject, it has received the message in error and
      SHOULD return a "Bad initial subobject" error. 
The ERO received by A MUST contain a first subobject that identifies A in some manner.
This is policed by A.

> (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}

With the exception that it would be good for the ERO to begin with an incoming interface on A or some other expression of A (for example {A}), this qualifies as the belts and braces (aka suspenders) approach. Note, however, that it is not necessary to duplicate the labels because they will be processed on the upstream node (creating a Label Set object).
Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.

> B (and therefore whether is has to process label L1)?  If it is not valid,

In order the discuss this, we must assume that the ERO looked like {A};{B1,L1};{C1,L2}
A's job is to route to the abstract node identified by the next subobject.
Thus, it must route to B1. One may assume that in a normal topology it will not try to do this through B2.
Further, A is not supposed to look beyond the first non-local sub-object. Therefore, the DS label will not be processed until the ERO reaches B. This is not the end of the world because it is a DS label and is in the purview of node B.

It is, however, perhaps easier to consider the case where upstream labels are used as well. This makes life a little clearer, because the US label MUST be processed by the US node. So the ERO {A};{B1,L1,L1'};etc. would not cut the mustard.

In fact, RFC3473 is quite clear in the intention that label subobjects (for DS labels) should be mapped to Label Set objects. This means that they must be processed by the US node. This in turn means that they must be present in a subobject immediately following an outgoing interfcase subobject.

So, option (c) will not (perhaps!) achieve the required results. This is not a matter for policing, since the ERO is valid in its way.

> ignore the label, but that probably is not the case in (c).

As above:
1. It is helpful to include the destination in the ERO.
2. The label subobject is not supposed to be processed by the DS node.

Please note that if any work is done to clarify all of this it MUST follow the "conservative on what you send, liberal on what you receive" principle. We cannot have a set of rules developed that will break existing implementations. Rather we should seek rules that cause future implementations to converge while stating how existing implementations will understand each other.

Adrian