RE: correct Error code

according to your diagram, can u explain the one-to-one relationship
between RC and RK ?

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Thu, 29 Mar 2007, Tolga Asveren wrote:

> Hi Andrew,
> 
> I don't think it is addressed :-). The point I tried to make was, if RC is
> configured per ASP, considering RC values for other ASPs as the the "same"
> RC doesn't sound correct. For example:
> 
>  +-------+   +-------+
>  |  ASP1 |   |  ASP2 |
>  +------++   ++------+
>         |     |
>         |     |
>         |     |
>         |     |
>         |     |
>        ++-----++
>        |  SGP  |
>        +-------+
>      Configuration for ASP1:
>        RC1: DPC=1-1-1, RC=1
> 
>      Configuration for ASP2:
>        RC2: DPC=2-2-2  RC=1
> 
> RC1 and RC2 are using the same "RC" value but they are not referring to the
> same RK. Basically, the concept of "RC being defined for some other ASP",
> doesn't fit well to the ASP/SGP relationship IMHO, because I would expect RC
> to be defined per ASP (at least from protocol semantics perspective,
> otherwise how local configuration is entered to the system is something
> obviously implementation dependent)
> 
> 
>   Thanks,
>   Tolga
> 
> 
> 
> > -----Original Message-----
> > From: Andrew Booth [mailto:[email protected]]
> > Sent: Thursday, March 29, 2007 2:32 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > Subject: Re: [Sigtran] correct Error code
> >
> >
> > Hi Tolga,
> >
> > It's a subtle point about the definitions.  My personal views are
> > unchanged, but I think this argument is being addressed in the other
> > branch of this thread.
> >
> > My intended contribution just that the RFC appears to have some text
> > missing in one of the critical passages, that could perhaps be addressed
> > if there is ever another rev of M3UA.
> >
> > Andrew
> >
> > Tolga Asveren wrote:
> > > If RC is configured statically per ASP on SGP, I wouldn't think
> > it is wrong
> > > to say that it is invalid for that particular ASP. The peers
> > are ASPs and
> > > SGPs in that relationship.
> > >
> > >    Thanks,
> > >    Tolga
> > >
> > >
> > >> -----Original Message-----
> > >> From: Andrew Booth [mailto:[email protected]]
> > >> Sent: Thursday, March 29, 2007 8:55 AM
> > >> To: Aditya; [email protected]
> > >> Subject: Re: [Sigtran] correct Error code
> > >>
> > >>
> > >> Hi,
> > >>
> > >> I agree with Brian.  The RC is not invalid, the SGP is just
> > refusing the
> > >> ASP ACTIVE.  Hence "Refused Management Blocking" is appropriate.
> > >>
> > >> As an aside, I think the text of the pertinent paragraph is missing
> > >> something.  The meaning is fairly clear, but it should probably read:
> > >>
> > >> If for any local reason the SGP will not act on the ASP ACTIVE request
> > >> (e.g., management lockout) the SGP responds to an ASP Active message
> > >> with an Error message with reason "Refused Management Blocking".
> > >>
> > >> Andrew
> > >>
> > >> Brian F. G. Bidulock wrote:
> > >>
> > >>> Aditya,
> > >>>
> > >>> The RC is not invalid: the ASP is merely not permitted to
> > >>>
> > >> activate for it.
> > >>
> > >>> In this case it is management blocked.  The peer should be welcome to
> > >>> retry, because at some point in the future it might be
> > >>>
> > >> permitted to activate
> > >>
> > >>> for the AS (e.g. the permission might have only been revoked
> > >>>
> > >> temporarily).
> > >>
> > >>> Sending "Invalid Routing Context" would make the peer believe that the
> > >>> corresponding RK is not provisioned (which it is) and might
> > result in a
> > >>> dynamic registration attempt (which is inappropriate).
> > >>>
> > >>> Besides, if "Invalid Routing Context" is returned, it violates
> > >>>
> > >> the MUST in
> > >>
> > >>> this passage:
> > >>>
> > >>>
> > >>>
> > >>>>      - If the RC parameter is included in the ASP Active
> > >>>>
> > >> message and the
> > >>
> > >>>>      corresponding RK has been previously defined (by either static
> > >>>>      configuration or dynamic registration), the peer node
> > MUST respond
> > >>>>      with an ASP Active Ack message. If for any local reason (e.g.,
> > >>>>      management lockout) the SGP responds to an ASP Active
> > message with
> > >>>>      an Error message with reason "Refused Management Blocking".
> > >>>>
> > >>>>
> > >>> --brian
> > >>>
> > >>> Aditya wrote:                                     (Thu, 29 Mar
> > >>>
> > >> 2007 05:53:59)
> > >>
> > >>>>    Brian,
> > >>>>    RFC  4666  mentions Invalid Routing Context to be sent if a
> > >>>>
> > >> message is
> > >>
> > >>>>    received  from  a  peer  with an invalid(unconfigured)
> > >>>>
> > >> Routing Context
> > >>
> > >>>>    value. Your analysis makes me think that only unconfigured
> > >>>>
> > >> RC is to be
> > >>
> > >>>>    treated  as  Invalid.  Isnt  the  RC  invalid in the
> > >>>>
> > >> example mentioned
> > >>
> > >>>>    below.
> > >>>>    I  may be wrong but sending ERR management Locked message
> > >>>>
> > >> somehow does
> > >>
> > >>>>    not  inform  the  peer that there is something wrong at its
> > >>>>
> > >> end. IMHO,
> > >>
> > >>>>    "Invalid Routing Context" seems like an appropriate
> > >>>>
> > >> message, since the
> > >>
> > >>>>    RC is INVALID in this case. The RC being configured does
> > >>>>
> > >> not take away
> > >>
> > >>>>    from the fact that it is invalid.
> > >>>>    Does  RFC  4666  state  anywhere that only unconfigured
> > >>>>
> > >> RC's are to be
> > >>
> > >>>>    treated as Invalid? I mean, does it define Invalid RC in
> > any sense.
> > >>>>    Aditya
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >> _______________________________________________
> > >> Sigtran mailing list
> > >> [email protected]
> > >> https://www1.ietf.org/mailman/listinfo/sigtran
> > >>
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>