Subject: RE: Last calls on Hierarchy, Bundle, and Unnum

From: Jonathan Lang <[email-masked]>
Date: Fri, 15 Feb 2002 11:26:03 -0800

Nabil,

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 10:07 AM
> To: Jonathan Lang
> Cc: 'Yakov Rekhter'; [email-masked]
> Subject: Re: Last calls on Hierarchy, Bundle, and Unnum
> 
> 
> Jonathan,
> 
> I don't think the ERO is carried in the err messages which 
> eventually get to the end nodes so some kind of ERROR_SPEC
> extension is needed in this case - looks like the definitions
> in section 8.2 of the referenced draft (and the functional desc
> draft) cover the requirement. Or did I miss something?
my mistake.  I forgot about the TLVs.  It is covered today.

Thanks,
Jonathan

> 
> There is one issue. Wouldn't it be cleaner if definitions of objects
> relevant to unnumbered interfaces were done in the unnumbered
> draft as opposed to the GMPLS drafts since as mentioned 
> in a previous thread, use of unnumbered is not restricted to 
> GMPLS. 
> 
> Some future person wishing to implement unnumbered interface support
> in a non-gmpls network will have to read 3 RFCs - 2 of them
> not relevant. This is not new for the IETF but I'm not sure
> it's desirable.
> 
> > > > 1. It would be nice if a new ERROR_SPEC c-type is defined for
> > > >    unnumbered links. This ERROR_SPEC could indicate the node
> > > >    and interface where an error occured. e.g in the case of
> > >
> > Section 8.2 of draft-ietf-mpls-generalized-rsvp-te-06.txt 
> talks about
> > Errored Interface Identification, but only defines formats 
> for IPv4 and
> > IPv6.  If needed, this could be extended to address 
> unnumbered.  However,
> > I'm not sure it's needed.  You can already identify the 
> Node with IPv4 or
> > IPv6 addresses.  You can get the unnumbered interface from the ERO.
> 
> ---
> Best,
> Nabil Seddigh
> [email-masked]
>

---

From: Hang Liu <[email-masked]>
Date: Fri, 15 Feb 2002 15:04:21 -0500

Hi,

We have a question about how to carry component interface IDs in RRO. In
section 7 of draft-ietf-mpls-rsvp-unnum-03, the IF_ID seems to be the link
bundle ID for bundled links. Do we need an IF_ID subobject of RRO similar to
IF_ID RSVP_HOP.

Hang Liu

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Friday, February 15, 2002 12:25 PM
To: Jonathan Lang
Cc: Nabil Seddigh; [email-masked]; Kireeti Kompella
Subject: Re: Last calls on Hierarchy, Bundle, and Unnum 

Jonathan,

> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Thursday, February 14, 2002 5:19 PM
> > To: Nabil Seddigh
> > Cc: [email-masked]; Kireeti Kompella; Yakov Rekhter
> > > I have just had a look at the 03 version of the unnumbered links
> > > draft. Seems like I missed last call so maybe this is too 
> > late but...
> > > I have a few suggestions in relation to the draft:
> > > 
> > >    admission control failure. In a number of 
> > >    current RSVP implementations for numbered networks, the 
> > >    ip address of the interface where failure occured is inserted
> > >    into the ERROR_SPEC. It would be nice to have similar information
> > >    for in the unnumbered case. One would then know the exact
> > >    link where the failure occured.
> > 
> > ok.
> > 
> Section 8.2 of draft-ietf-mpls-generalized-rsvp-te-06.txt talks about
> Errored Interface Identification, but only defines formats for IPv4 and
> IPv6.  If needed, this could be extended to address unnumbered.  However,
> I'm not sure it's needed.  You can already identify the Node with IPv4 or

Good point. 

Yakov.