Subject: RE: Unnumbered interface IDs in RROs

From: Nic Larkin <[email-masked]>
Date: Tue, 22 May 2001 13:34:59 +0100

Hi Arumugam,

Thanks for your response.  I agree that the solution you propose would do
the job of carrying the 32 bit Router ID in an RRO.  However, I think the
one I propose below, namely to use the same format in the RRO as in the ERO,
works better.

- It is useful and convenient for the format of RRO subobjects to be the
same as ERO subobjects.  
  - This applies especially to RSVP LSP pinning, where it should be
straightforward for the ingress to "re-use" the RRO as a pinned ERO.
  - In general, it will help implementations if they can represent hop
information in a consistent way.

- The approach of using the existing IPv4 RRO subobject unnecessarily
overloads its meaning.  The IPv4 RRO subobject is currently defined to carry
  - an IPv4 address, not a Router ID
  - the address of a specific outgoing interface, not the address of an LSR.

Therefore it seems simpler and easier to
- model the unnumbered interface RRO subobject on the ERO subobject
- insert this subobject into the RRO in place of the numbered interface
address subobject.

Any support for this proposal?

Regards,
Nic.

-----Original Message-----
From: Arumugam R [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 7:12 AM
To: Nic Larkin
Cc: Juniper - Kireeti Kompella; [email-masked]; [email-masked]'
Subject: Re: Unnumbered interface IDs in RROs

Hi Nic,

I think the Router ID field is unnecessary in the newly defined RRO
subobject
for unnumbered interface. If you consider the processing of the new
subobject
in lines with that of the label subobject mentioned in rsvp-lsp-tunnel-08
draft
the operation will be quite clear.

i.e. always the new subobject(Type 4) should be accompanied with the
subobject
1 ( IPv4 Address Type 1), which states that always the address added to the
IPv4 subobject should be the Router ID.  Then the need for having an extra
field of "Router ID" is also resolved. I feel that a statement " mandatorily
the unnumbered interface ID subobject (Type 4) has to accompany IPv4
subobject
(Type 1)" will solve the purpose in the draft mpls-rsvp-unnum-01.

Regards
Arumugam R

Nic Larkin wrote:

> Hi Kireeti, Yakov,
>
> Can you help me with a query about draft-ietf-mpls-rsvp-unnum-01?
>
> Section 7 defines the unnumbered interface subobject of the Record Route
> Object.  This subobject has an "Interface ID" field to identify the
> unnumbered link.
>
> My question is: should there also be a "Router ID" field in the definition
> of the Record Route subobject, as per the ERO subobject in section 6?
This
> would be used to identify which LSR the unnumbered interface belongs to,
> e.g. allowing the ingress to construct a strict ERO when doing LSP
Pinning.
>
> Thanks and regards,
> Nic.
>
> Nic Larkin
> Network Convergence Group
> Data Connection Ltd
> Tel:   +44 20 8366 1177           Fax:   +44 20 8363 1533
> Email: [email-masked]     Web:   http://www.dataconnection.com

---

From: Arumugam R <[email-masked]>
Date: Tue, 22 May 2001 20:58:45 +0530

Hi Nic,

I too agree the same. If the authors propose an extension to the new subobject
in the way you are proposing it is welcome, if they don't we can proceed with
the assumption.

As far as our implementation is concerned we always use the Router ID in the RRO
subobject, so updating to this new feature is no big deal, even though the draft
specifies it can be anyone of the outgoing interface address.

Considering the route pinning case, as previously discussed in the mailing list
the RRO contents cannot be straight forwardly used as ERO's since the RRO can
contain some other subobjects too. Since it has to be tailored manually
reusability without tailoring is again a question.

By the way "pinning" you mean "Strict ErHops" since route pinning in case of
loose ErHops is not supported in RSVP (only in CR-LDP) since there is no flag
mentioning the feature in any of the RSVP-TE objects.

Regards
Arumugam

---

From: David Charlap <[email-masked]>
Date: Tue, 22 May 2001 18:34:21 -0400

Arumugam R wrote:
> 
> By the way "pinning" you mean "Strict ErHops" since route pinning
> in case of loose ErHops is not supported in RSVP (only in CR-LDP)
> since there is no flag mentioning the feature in any of the RSVP-TE
> objects.

He's talking about using the RRO to pin a loose ERO.  The technique is
something like:

- ingress router sends Path with loose ERO and RRO
- ingress router eventually receives a Resv with an RRO.
- ingress router (at next Path refresh) uses the received RRO as a
  strict ERO.

This effectively pins the LSP.

-- David