Subject: Re: -04 version

From: Yakov Rekhter <[email-masked]>
Date: Thu, 14 Mar 2002 10:59:46 -0800

Nabil,

> I suggest adding a section with title error handling - between
> section 6.2 and section 7. Having its own section is good as one
> would typically expect a note on error handling in this kind of
> a draft.  The section could indicate something  like:
> 
>  Section 7.0
>  -----------
>  "In order to indicate the interfaces on which a particular error
>   occured, a new IF_ID ERROR_SPEC object is defined. The definitions 
>   can be found in draft-ietf-mpls-generalized-rsvp-te-06.txt and
>   draft-ietf-mpls-generalized-signaling-07.txt"
> 
> Also section 6.1 indicates that the LSR should return error.
> However, it does not specify whether the PathErr message
> will contain an existing error code or a new one to
> be defined by IANA. Could you clarify.

To address the above I replaced 

   Otherwise, the LSR SHOULD return an error.

with the following:

   Otherwise, the LSR SHOULD return an error using the IF_ID
   ERROR_SPEC object (see [GMPLS-RSVP], [GMPLS-SIG]). The Error
   code in the object is set to [TBD]. The Error value in the object
   is set to [TBD].

As you can see I assume that we are going to get new Error code
and new Error value. But if you think we should use the existing
Error code and/or Error value, please let me know.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 26 Mar 2002 11:35:23 -0800

Nabil,

> Yakov,

-05 version of the draft (just announced) addresses this.

Yakov.

> 
> ---
> Best, 
> Nabil Seddigh
> [email-masked]
> 
> 
> > > 2. Also, if the unnum draft is not going to talk about error spec
> > >   it should reference the draft that defines the new
> > >   error_spec object for unnumbered links -
> > >   draft-ietf-mpls-generalized-rsvp-te-06.txt
> > 
> > please tell me where would you like to insert the reference,
> > and I'll add it.
> > 
> > Yakov.
> >

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 29 Mar 2002 16:30:26 -0500

Yakov,

In addition to the changes mentioned below, there is one more 
fundamental issue with the Unnumbered Interfaces draft. 

From previous discussion on this list, it appears that the 
Interface ID field of the unnumbered ERO subobject is intended
to represent the incoming interface of the next hop router.
If this is the case, it should be explicitly stated at
the beginning of section 6.

If the intention is to leave it open such that it is either
incoming or outgoing interface then a bit from the reserved
field of  the sub-object should indicate which of the two 
choices is being used.

In the absence of one of the above two alternatives, we would
appear to have a case of ambiguity by design - not usually 
preferred when you are standardizing something.

Best,
Nabil Seddigh