Subject: RE: [Sigtran] M3UA Plugtest - Day 4 summary

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 7 Mar 2002 19:14:00 +0100

Hi Brian, 

Yes. One of the possible solutions is that the ASP sending the first ASPDN also changes the peer state upon receiving ASPDN_ACK to ASP_DOWN state...

Another solution is changing the definition of the ASP_DOWN state, what IMHO is not desired to have compatibility with the future M3UA standard...

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 7:02 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: Vats, Umesh; 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] M3UA Plugtest - Day 4 summary
> 
> 
> Javier,
> 
> But you don't have one ASP in the double-ended case: you have
> two.  As such, you have two ASP states.  Only one of them is
> down for the first ASPDN/Ack exchange, it takes another ASPDN/Ack
> exchange to take the other down.
> 
> --brian
> 
> Javier Pastor-Balbas (ECE) wrote:                          
> (Thu, 07 Mar 2002 18:53:05)
> > Brian,
> > 
> > I see your point but, having double ASPDN seems not to have 
> sense as I said
> > in my mail below. At least with the current definition of 
> ASP_DOWN state...
> > 
> > Cheers // Javier.
> > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Thursday, March 07, 2002 6:51 PM
> > > To: Javier Pastor-Balbas (ECE)
> > > Cc: Vats, Umesh; 'Tolga Asveren'; [email-masked]
> > > Subject: Re: [Sigtran] M3UA Plugtest - Day 4 summary
> > > 
> > > 
> > > Javier,
> > > 
> > > I still am not convinced that double-ended operation can 
> work at all.
> > > However, in trying to make it work, it should not be a 
> mixture between
> > > double-ended and single-ended.  This means that all 
> procedures need to
> > > be doubled.
> > > 
> > > --brian
> > > 
> > > Javier Pastor-Balbas (ECE) wrote:                          
> > > (Thu, 07 Mar 2002 17:14:26)
> > > > Hi, 
> > > > 
> > > > I'm happy we come back to this discussion. And I also 
> > > support the double
> > > > ASPUP exchange as in the beginning of times I did  ;-).
> > > > 
> > > > But regarding the double ASPDN... I'm not sure that this 
> > > double exchange
> > > > makes sense. When IPSP_B receives ASPDN from IPSP_A and 
> sends back
> > > > ASPDN_ACK,  IPSP_B moves IPSP_A state to ASP_DOWN and 
> > > therefore IPSP_A is
> > > > seen as unavailable and should not be sent any M3UA 
> > > messages with the
> > > > exception of heartbeat messages.
> > > > 
> > > > Cheers // Javier.
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Thursday, March 07, 2002 3:06 AM
> > > > > To: Vats, Umesh
> > > > > Cc: 'Tolga Asveren'; [email-masked]
> > > > > Subject: Re: [Sigtran] M3UA Plugtest - Day 4 summary
> > > > > 
> > > > > 
> > > > > Umesh,
> > > > > 
> > > > > I think that you will find that double ASPDN/Ack is still
> > > > > necessary.  This is because the sender of the ASPDN must
> > > > > be still prepared to receive data before (and even for some
> > > > > time after) receiving an ASPDN Ack.  Orderly shutdown in 
> > > > > both directions cannot be accomplished with a simple two
> > > > > message exchange.
> > > > > 
> > > > > In the AS/SG case, the SGP receiving an ASPDN will deactivate
> > > > > all AS associated with the ASP before replying with an ASPDN
> > > > > Ack.  This means that all traffic to and from the SGP for the
> > > > > AS will stop.  That is not necessarily the case in IPSP
> > > > > operation, and particularly in double-ended operation where
> > > > > uni-direction traffic flow is possible.  Therefore, the
> > > > > ASPDN/Ack must be double-ended as well because ASPDN can be
> > > > > used in place of ASPIA.
> > > > > 
> > > > > --brian
> > > > > 
> > > > > Vats, Umesh wrote:                                          
> > > > > (Wed, 06 Mar 2002 17:55:46)
> > > > > > Hi  Tolga
> > > > > > 
> > > > > > I agree with you that ASPUP and ASPUP-Ack should be sent 
> > > > > > by both the IPSPs in double ended mode. The figure given 
> > > > > > below as specified in draft 12 needs to corrected.
> > > > > > 
> > > > > > This is needed because the IPSPs may want to send ASP Ids
> > > > > > in the NOTFY messages to each other. Without dual ASPUP 
> > > > > > exchange, this is not possible.
> > > > > > 
> > > > > > But single exchange of ASPDN/ASPDN-ACK messgages is 
> sufficient.
> > > > > > As  ASPDN/ASPDN-Ack messages are not related with any 
> > > RC or ASP-Id, 
> > > > > > dual exchange is redundant.
> > > > > > 
> > > > > > Umesh
> > > > > >  
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > Sent: Wednesday, March 06, 2002 2:12 PM
> > > > > > To: [email-masked]
> > > > > > Subject: RE: [Sigtran] M3UA Plugtest - Day 4 summary
> > > > > > 
> > > > > > 
> > > > > > Yes, in m3uav12 5.5.2 it is shown as optional but it isn't. 
> > > > > Because this is
> > > > > > a scenario for double-message approach. Similarly, ASPDN 
> > > > > and ASPDN-ACK,
> > > > > > which are shown as optional are not optional but mandatory.
> > > > > > 
> > > > > >      Tolga
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Tomar, Nitin [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, March 06, 2002 4:49 PM
> > > > > > > To: 'Tolga Asveren'; [email-masked]
> > > > > > > Subject: RE: [Sigtran] M3UA Plugtest - Day 4 summary
> > > > > > >
> > > > > > >
> > > > > > > Hi Tolga,
> > > > > > >   I agree that NTFY from IPSP-B to IPSP-A should be after 
> > > > > receiving
> > > > > > > ASPUP-ACK (only if IPSP-B
> > > > > > >   sends ASPUP message) from IPSP-A,
> > > > > > >   but can you please explain me why ASPUP/ASPUP-ACK is 
> > > > > not optional but
> > > > > > > mandatory (draft 12
> > > > > > >   shows it as optional).
> > > > > > >
> > > > > > > - Nitin.
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > > > > > Sent: Wednesday, March 06, 2002 1:12 PM
> > > > > > > > To: Tomar, Nitin; [email-masked]
> > > > > > > > Subject: RE: [Sigtran] M3UA Plugtest - Day 4 summary
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > In my opinion, the presented scenario does not follow 
> > > > > double-message
> > > > > > > > approach. How can IPSP-A can send NTFY to IPSP-B, before
> > > > > > > > sending ASPUP and
> > > > > > > > receiving ASPUP-ACK from it? And also, it this 
> scenario is
> > > > > > > > intended for
> > > > > > > > double-excahnge scenario (it says 5.5.2. Dopuble 
> > > > > exchange) , second
> > > > > > > > ASPUP/ASPUP-ACK is not optional but mandatory.
> > > > > > > >
> > > > > > > >     Tolga
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]]On Behalf Of
> > > > > > > > > Tomar, Nitin
> > > > > > > > > Sent: Wednesday, March 06, 2002 3:43 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Subject: RE: [Sigtran] M3UA Plugtest - Day 4 summary
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Ken,
> > > > > > > > >
> > > > > > > > > Please find the text on Notify message (as agreed 
> > > > > during testing at
> > > > > > > > > plugtest)
> > > > > > > > > for IPSP double exchange behavior.
> > > > > > > > >
> > > > > > > > > - Nitin.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > << snip>>
> > > > > > > > >
> > > > > > > > > 2)  IPSP update
> > > > > > > > >
> > > > > > > > > IPSP testing has occurred between different 
> > > > > implementations.  Nitin
> > > > > > > > > from Trillium will suggest text on the list to clarify
> > > > > > > > Notify message.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 5.5.2 Double exchange:
> > > > > > > > >
> > > > > > > > >             IPSP-A                           IPSP-B
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<-------------ASP Up------------|
> > > > > > > > >
> > > > > > > > >               |-----------ASP Up Ack---------->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |---- NTFY (AS_Inactive)(RCb)--->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<--- NTFY (AS-Inactive)(RCa)----|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |-------------ASP Up------------>|  
> > > (optional)
> > > > > > > > >
> > > > > > > > >               |<----------ASP Up Ack-----------|  
> > > (optional)
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<------- ASP Active(RCb)--------|  RC:
> > > > > > > > Routing Context
> > > > > > > > >
> > > > > > > > >               |-----ASP Active Ack (RCb)------>|      
> > > > > (optional)
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |----- NTFY (AS_Active)(RCb) --->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |------- ASP Active(RCa)-------->|  RC:
> > > > > > > > Routing Context
> > > > > > > > >
> > > > > > > > >               |<-----ASP Active Ack (RCa)------|      
> > > > > (optional)
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<---- NTFY (AS_Active)(RCa)-----|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<=========  DATA (RCa) =========|
> > > > > > > > >
> > > > > > > > >               |==========  DATA (RCb) ========>|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<-----ASP Inactive (RCb)--------|  RC:
> > > > > > > > Routing Context
> > > > > > > > >               |----ASP Inactive Ack (RCb)----->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |----- NTFY(AS_Inactive)(RCb)--->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |------ASP Inactive (RCa)------->|  RC:
> > > > > > > > Routing Context
> > > > > > > > >               |<----ASP Inactive Ack (RCa)-----|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<---- NTFY(AS_Inactive)(RCa)----|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |<-----------ASP Down------------|
> > > > > > > > >
> > > > > > > > >               |---------ASP Down Ack---------->|
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >               |------------ASP Down----------->|  
> > > (optional)
> > > > > > > > >
> > > > > > > > >               |<--------ASP Down Ack-----------|  
> > > (optional)
> > > > > > > > >
> > > > > > > > >               |                                |
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >   Note: RC is optional in Notify message.
> > > > > > > > >
> > > > > > > > > << snip >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > 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
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Mar 2002 12:20:06 -0600

Javier,

You cannot couple the states of the ASPs without coupling
the states of the AS.  If the ASPs have coupled state, then
you have the single-ended approach which is consistent with
the standard.

--brian

Javier Pastor-Balbas (ECE) wrote:                          (Thu, 07 Mar 2002 19:14:00)
> Hi Brian, 
> 
> Yes. One of the possible solutions is that the ASP sending the first ASPDN
> also changes the peer state upon receiving ASPDN_ACK to ASP_DOWN state...
> 
> Another solution is changing the definition of the ASP_DOWN state, what IMHO
> is not desired to have compatibility with the future M3UA standard...
> 
> Cheers // Javier.
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/