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

From: "Vats, Umesh" <[email-masked]>
Date: Thu, 7 Mar 2002 10:09:48 -0800

Brian,

I didn't understand this concept of two ASPs.
For same traffic, separate RCs are there but the
ASP UP/DOWN states need to be maintained only for one
peer process.

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 10:02 AM
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:18:02 -0600

Umesh,

The AS state is doubled.  ASP state interacts with
AS state.  Doubling AS state without doubling ASP
state does not make sense.

For example, IPSP1 can be ASP-UP and be ASP-ACTIVE
for a number of AS.  When IPSP2 sends ASPDN, it is
sending it for its own ASP state in the AS which it
serves.  To take the IPSP1 ASP state down, it would
have to send unsolicited ASPDN Ack or wait for an
ASPDN from IPSP2.

--brian

Vats, Umesh wrote:                                          (Thu, 07 Mar 2002 10:09:48)

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