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

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

Tolga, 

See below...

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Tuesday, July 02, 2002 5:55 PM
> To: [email-masked]
> Subject: [Sigtran] m3ua IG-v01: RK for IPSP
> 
> 
> 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.

> 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. 

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

---

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

Javier,

> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2002 4:00 AM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sigtran] m3ua IG-v01: RK for IPSP
>
>
> Tolga,
>
> See below...
>
[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.
> 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.

---

From: "reshma" <[email-masked]>
Date: Wed, 3 Jul 2002 19:05:33 +0530

Hi Tolga,

> 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)?

Thanks,
Reshma

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 3 Jul 2002 10:19:42 -0400

Reshma,

> 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,
> > > >
[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.

---

From: "reshma" <[email-masked]>
Date: Thu, 4 Jul 2002 17:40:51 +0530

Hi Tolga,

> IMO configuring the initiator of dynamic registration makes sense.

[Reshma] I think this must be included in the Implementors guide too.Else
again and again we will end up in same doubts/confusion.

Thanks,
Reshma