Subject: RE: [Sigtran] m3ua IG-v01: RK for IPSP

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 3 Jul 2002 12:16:09 -0400

Javier,

> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2002 11:50 AM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] m3ua IG-v01: RK for IPSP
>
>
> Tolga,
>
> I don't see any major problem in removing them. I just thought we
> all agreed that communication in a SPC granularity was the better
> choice. Also the preconfiguration of RC can be left as an
> implementation option and keep it out of the text.
[TOLGA] Altough for practical purposes I also would agree that mostly PC
granularity will be used, I think we shouldn't put any restrictions about
the use of sub-PC granularity RKs for the IPSP model. My personal preference
would be to remove those sentences (or maybe rewording carefully)
>
> Cheers // Javier.
>
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Wednesday, July 03, 2002 4:20 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] m3ua IG-v01: RK for IPSP
> >
> >
> > Reshma,
> >
> > > -----Original Message-----
> > > From: reshma [mailto:[email-masked]]
> > > Sent: Wednesday, July 03, 2002 9:36 AM
> > > To: Tolga Asveren; [email-masked]
> > > Subject: Re: [Sigtran] m3ua IG-v01: RK for IPSP
> > >
> > >
> > > Hi Tolga,
> > >
> > > > > > Javier,
> > > > > >
> > > > > > In section 4.4.3, why do we have the sentence "In the case of
> > > > > > RC use, RCs
> > > > > > SHOULD be previously agreed between both peers"? This
> > > > > > sentence limits the
> > > > > > use of dynamic registration for IPSP to the case where
> > > > > > traffic belonging to
> > > > > > only one RK is carried over an association.
> > > > >
> > > > > Not really. This means that the RK in both ends are
> > configured to
> > > > > use the same RC number.
> > > > [TOLGA] IMO,  the sentence "In the case of RC use, RCs SHOULD be
> > > previously
> > > > agreed between both peers" means, when there is a need
> > for RC, it should
> > > be
> > > > configured. When dynamic registration is used, the registration
> > > procedure
> > > > itself guarantees that both sides are using the same RC value
> > > for the same
> > > > RK and in such a case. I don't think this sentence is
> > needed at all.
> > > > >
> > > [Reshma] But whether ther should be any configuration to say
> > > which IPSP will
> > > do Registration and which will not(in case of dynamic)?
> > [TOLGA] Maybe. If the peers are carefull enough not to
> > dynamically register
> > to a remote peer if it already did so, there shouldn't be a need to
> > preconfigure which one should do dynamic registration, but
> > there is also a
> > change of collision of REGREQ from both sides. So, at the end
> > I would say,
> > IMO configuring the initiator of dynamic registration makes sense.
> > >
> > > Thanks,
> > > Reshma
> > >
> > > > >
> > > > > > And also again in the same
> > > > > > section, why are we trying to limit use of dynamic
> > > registration to PC
> > > > > > granularity?
> > > > > >
> > > > >
> > > > > It is just a MAY, an option. It is not limited. Nevertheless it
> > > > > is difficult to exchange two separate RKs in a single exchange
> > > > > REG-REQ. The way to achieve it is including origination and
> > > > > destination in the same and then the two RKs are
> > implicitly defined.
> > > > [TOLGA] IMO, this sentence is also unnecessary and even
> > misleading. Also
> > > > with one REGREQ, it is possible to have one sub-PC
> > granularity RK. For
> > > > example:
> > > >                           1-1-1 CIC=101-200
> > > >   +------+               +------+
> > > >   |      |               |      |
> > > >   | IPSP1+---------------+IPSP2 |
> > > >   |      |               |      |
> > > >   +---+--+               +------+
> > > >       |
> > > >       |
> > > >       |
> > > >       |                   1-1-1 CIC=0-100
> > > >       |                  +------+
> > > >       +------------------+      |
> > > >                          |IPSP3 |
> > > >                          |      |
> > > >                          +------+
> > > >
> > > > IPSP2 and IPSP3 know that IPSP1 is serving for 2-2-2. So, they
> > > want to use
> > > > dynamic registration. IPSP2 will form its RK parameter as
> > 1-1-1/2-2-2
> > > > CIC=0-100 and IPSP3 as 1-1-1/2-2-2 CIC=101-200 in the
> > REGREQ message. If
> > > > this sentence with MAY is there, then one should also
> > list everything
> > > > possible again with a MAY sentence, so I think it is better to
> > > delete this
> > > > sentence.
> > > > >
> > > > >
> > > > > Cheers // Javier.
> > > > >
> > > > >
> > > > >
> > > > > >    Tolga
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 3 Jul 2002 17:50:09 +0200

Tolga, 

I don't see any major problem in removing them. I just thought we all agreed that communication in a SPC granularity was the better choice. Also the preconfiguration of RC can be left as an implementation option and keep it out of the text.

Cheers // Javier.