The MPLS WG Archive

[Arumugam R <arumugamr@future.futsoft.com>]

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

Nic Larkin wrote:

> 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:arumugamr@future.futsoft.com]
> Sent: Tuesday, May 22, 2001 7:12 AM
> To: Nic Larkin
> Cc: Juniper - Kireeti Kompella; yakov@juniper.net; 'mpls@uu.net'
> 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: npl@dataconnection.com     Web:   http://www.dataconnection.com

begin:vcard 
n:Ramasamy;Arumugam
tel;home:6223683
tel;work:4330550 Extn- 363
x-mozilla-html:FALSE
url:www.futsoft.com
org:Future Software;Products
version:2.1
email;internet:arumugamr@future.futsoft.com
title:Senior Software Engineer
adr;quoted-printable:;;480 Mount Road,=0D=0ANandanam,=0D=0A;Chennai;Tamil Nadu;600 035;India
fn:Aru
end:vcard