Subject: Few clarifications in CR-LDP-3

From: [email-masked]
Date: Thu, 7 Oct 1999 16:57:34 +0800

Hi,

Clarification #1
Page 4 of the CR-LDP draft 3
---------------------------------------------------------------
"2.1 Strict and Loose Explicit Routes

   Like any other LSP a CR-LSP is a path through an MPLS network. The
   difference is that while other paths are setup solely based on
   information in routing tables or from a management system, the
   constraint-based route is calculated at one point at the edge of
   network based on criteria, including but not limited to routing
   information. The intention is that this functionality shall give
   desired special characteristics to the LSP in order to better
   support the traffic sent over the LSP. The reason for setting up CR-
   LSPs might be that one wants to assign certain bandwidth or other
   Service Class characteristics to the LSP, or that one wants to make
   sure that alternative routes use physically separate paths through
   the network.

   An explicit route is represented in a Label Request Message as a
   list of nodes or groups of nodes along the constraint-based route.
   When the CR-LSP is established, all or a subset of the nodes in a
   group may be traversed by the LSP.  Certain operations to be
   performed along the path can also be encoded in the constraint-based
   route."

Can the first paragraph under section 2.1 be moved under Section 2 "Constraint-based Routing Overview"?
I felt this as that paragraph is talking generally about CR-LSPs and not "explicitly" about Explicit Routes

Clarification #2
------------------------
!!This may not be related directly to the CR-LDP draft!!
Consider IP source routing.
Under normal Source routing, the Source route is filled into the IP options area of the IP
header by the originator of the packet. Intermediate routers process the source route
options and update the respective fields (like pointer, source route and record fields, etc)
and the packet reaches the destination.

But with Label Switching if we assume that the Ingress LSR looks into the
IP header (Source Route Options) and sends it on the associated CR-LSP,
it finally would reach the Egressfor the CR-LSP.
The receiving LSR would receive it and then try to forward it based
on the IP header. It would look finally into the Source Route options
and try to do Source Routing and fail.

The question now is that whether it necessary for the Ingress
LSR to remove the Source Route Options from the IP header
before label switching the packet to avoid the above mentioned problems?
Wouldn't this help in reducing the packet overhead?

Again, how would the receiver know while replying, that it has to use
Source Routing (CR-LSP) ? Is it through configuration?

Thanks in advance,
chetan

---

From: Eric Gray <[email-masked]>
Date: Fri, 08 Oct 1999 10:19:03 -0400

Chetan,

> Page 4 of the CR-LDP draft 3

I personally don't care one way or the other on this,
but would not churn the document JUST for this change.

> Clarification #2

Well, first of all, I don't know of anyone that actually
uses the source routing option in IP.  Secondly, if one 
wanted to use an LSP to provide new support for source 
routing, one would need to adjust the IP header accordingly 
- that is, before inserting packets into the explicitly 
routed LSP, they will need to perform the processing - 
that would normally have been done at each hop - at the 
ingress LSR which is inserting the packets.

Pre-processing the packet in this way would result in the
packet being egressed at the end of the explicitly routed
LSP in the same condition it would have been in were it
actually processed at each hop - assuming that it would
have been processed at ANY hop, rather than simply being
dropped. :-) 

> chetan

Eric Gray