The MPLS WG Archive

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

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?

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
nseddigh@tropicnetworks.com