Subject: Some comments on draft-vasseur-mpls-nodeid-subobject-00.txt

From: Philip Matthews <[email-masked]>
Date: Tue, 1 Apr 2003 11:45:53 -0500

Jean Philippe:

Here are some comments on your document:
draft-vasseur-mpls-nodeid-subobject-00.txt.

1) It wasn't clear to me whether this draft is proposing that a router push
   both its interface address and its nodeid, or just push its nodeid.

   I personally feel that both addresses should be included,
   as the interface address information can be useful for debugging.
   In particular, interface information is useful when there are parallel
   links between two routers and the links are not bundled for some reason.
   (The operator might do this, for example, because he/she wants to be able
   to explicitly specify which link to take when routing LSPs between the
   two routers. Or, because the links are in two different SRLGs and the
operator
   wants to expose that fact. Or, because the links run between routers from
   different vendors, and POS bundling has not yet been standardized).

2) On the assumption that both addresses should be included, then I am not
sure
   that a bit in the Flags field should be used to distinguish the two types
   of objects. My concern is that an implementation that does NOT understand
   your new flag might get confused when parsing the RRO. The implementation
   probably would not break, but if it tries to count the number of routers
in
   the path, or give the operator a more "parsed" view of the path, then it
   would get the wrong impression.

   My suggestion is to use a new value in the Type field instead. That way,
   routers that did not understand this subobject would just skip over it.

Hope these comments are clear (and useful) ...

- Philip

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 01 Apr 2003 20:22:54 -0500

Hi Philip,

>    as the interface address information can be useful for debugging.

That's perfectly correct.

>    probably would not break, but if it tries to count the number of 
> routers in

Well I don't think so, by the way counting the number of RRO IPv4 subobject 
does not provide any information of the number of hops ...
If the RRO is used for debugging purposes, this flag will help in giving a 
more accurate info.

>Hope these comments are clear (and useful) ...

Sure, I just think that we should keep the flag instead of specifying new type.

Thanks for your comment.

JP.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 2 Apr 2003 10:15:31 -0500

> That's perfectly correct.

From your comment,  I take it that the intent is to
push BOTH the interface address AND the node id.

What is the order of the various subobjects? The draft says:
        "The node-id subobject is added into the RECORD_ROUTE object after
the
         Label Record subobject. "
Does this mean:
  (a) a router pushes first a Label subobject, then a nodeid subobject,
      and then finally a interface address subobject
      (so the order in the RRO is  <interface address> <node id> <label>)
OR
  (b) the node id appears after the Label subobject
      (so the order in the RRO is <interface address> <label> <node id>) ?

operator 
>   2) On the assumption that both addresses should be included, then I am
not sure 
routers in 
> Well I don't think so, by the way counting the number of RRO IPv4
subobject does not provide any > information of the number of hops ... 
more accurate info.

Let me try to state this again ...
Say the RRO looks as follow (here I am assuming that you wish the node id
subobject to
appear after the interface address subobject):
   ...  <I: 10.2.1.1> <N: 10.0.0.1> <L: 1000> <I: 10.2.2.1> <N: 10.0.0.2>
<L: 1002> ...
where "I" means interface address, "N" means node id, and "L" means label.

Say (as you propose) that a flag in the RRO is used to distinguish the 
Interface Address subobject from the Node Id subobject.
Say also that some router in the path does not understand this flag.
Then this router will mistakenly interprete node id subobjects
as additional interface address subobjects.
This router would see twice as many routers in the above path as there
actually are, and would display the path as follows: 

     router #1
         outgoing interface:   10.2.1.1
         label distributed upstream:  (info not available)
     router #2
         outgoing interface:   10.0.0.1
         label distributed upstream:   1000
     router #3
	   outgoing interface:   10.2.2.1
         label distributed upstream:  (info not available)        
     router #4
         outgoing interface:   10.0.0.2
         label distributed upstream:   1002

Am I missing something?

> Sure, I just think that we should keep the flag instead of specifying new
type.

What goal are you trying to achieve by using a flag in the Interface Address
subobject
rather than a new type value? Given that there are only 8 bits in the field,
and
four of them are already allocated, you must have a strong reason for
wanting to
use up one of the 4 remaining bits.

- Philip