Subject: draft-ietf-pwe3-control-protocol-08.txt Generalized FEC clarific ation

From: "Agiwal, Manoj (Manoj)" <[email-masked]>
Date: Tue, 21 Sep 2004 16:11:15 +0530

Hi ,
        This is w.r.t to ATM pseudowires , I wanted some clarification as to
usage of Generalized FEC TLV .

      1.  Does the current draft-ietf-pwe3-control-protocol-08.txt takes
care of support n to 1 cell mode of encapsulation .

       2. Generalised FEC element has SAI and DAI  , Can SAI and DAI
identify Atachment circuit at the end points .

       3.  In case multiple circuits are getting mapped to a pseudowire  ,
Is it possible that label mapping message which 
           carries the psedowire label , can be same for different pairs of
< SAI and DAI > which needs to be mapped to
           a pseudowire and therby supporting n to 1 cell mode of
encapsulation .

      4.  In case a particular Attachment Circuit goes inactive can the
Status message be used along with Generalised FEC to 
           inform the remote end which Attachment Circuit has gone down.

Regards ,
Manoj

---

From: Luca Martini <[email-masked]>
Date: Wed, 22 Sep 2004 15:05:26 -0600

>care of support n to 1 cell mode of encapsulation .
only n=1 mode is defined. There is no definition for more then one ATM 
VC into one PW.

>           a pseudowire and therby supporting n to 1 cell mode of
no.

>           inform the remote end which Attachment Circuit has gone down.
Yes , the document clearly indicates this.

Luca

>Regards ,
>Manoj
>
>       
>
>        
>
>
>        
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>

---

From: [email-masked]
Date: Thu, 23 Sep 2004 16:31:20 +0100

Luca.....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: 23 September 2004 16:00
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'
> Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt 
> Generalized FEC clarific ation
> 
> 
> Peter,
> Given:
> ------------------------------------
> "ATM n-to-one VCC and VPC Cell Transport"
> This mode is similar to the ATM AAL5 VCC transport except 
> that cells are transported. Every cell that is received on a 
> pre-defined ATM PVC, or ATM PVP, at the ingress ATM port on 
> the ingress PE, PE1, is encapsulated according to [ATM], ATM 
> n-to-one cell mode, and sent across the LSP to the egress PE 
> PE2. Grouping of ATM cells is OPTIONAL for transmission at 
> the ingress PE, PE1. If the Egress PE PE2 supports cell 
> concatenation the ingress PE, PE1, MUST only concatenate 
> cells up to the "Maximum Number of concatenated ATM cells in 
> a frame" parameter received as part of the FEC element.
> ---------------------------------------------------------
> 
> In the control protocol draft .... it does say "a pre-defined 
> ATM PVC, 
> or ATM
> PVP"
> that does not mean "one" for me .
> Please note that I am not opposed in principle to having a trunk mode 
> ..... it will need to be a new PW type.
> I would also like to know how a trunk would handle VP 
> failures/alarms ... ( Neil , I'm sure you have an opinion on 
> this point :-) )
NH=> Yes I do (but I'd say its more of a requirement than an opinion)
and Peter should know it by now ;-)
regards, Neil
> 
> Luca
> 
> 
> Busschbach, Peter B (Peter) wrote:
> 
> >  
> >
> >>-----Original Message-----
> >>From: Luca Martini [mailto:[email-masked]]
> >>Sent: Wednesday, September 22, 2004 5:05 PM
> >>To: Agiwal, Manoj (Manoj)
> >>Cc: [email-masked]'
> >>Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt
> >>Generalized
> >>FEC clarific ation
> >>
> >>
> >>
> >>
> >>>       This is w.r.t to ATM pseudowires , I wanted some
> >>>      
> >>>
> >>clarification as to
> >>    
> >>
> >>>     1.  Does the current
> >>draft-ietf-pwe3-control-protocol-08.txt takes
> >>    
> >>
> >Hi Luca,
> >I am not sure I understand this. I don't see anything in the 
> existing 
> >IETF drafts that limits the use of n:1 cell mode encapsulation to a 
> >single VP.
> >
> >The MPLS Forum is working on an "ATM-MPLS Control Plane 
> Interworking" 
> >Implementation Agreement that, among other things, defines 
> the concept of Virtual Trunks. A Virtual Trunk is a bundle of 
> VPs that is encapsulated in a single PW.
> >
> >Currently, a Virtual Trunk setup procedure has not yet been defined, 
> >but there is no reason to believe that the PW Control Protocol with 
> >Generalized FEC could not be used.
> >
> >Peter
> >
> >
> >
> >  
> >
> >>VC into one PW.
> >>
> >>    
> >>
> >>>      3.  In case multiple circuits are getting mapped to a
> >>>      
> >>>
> >>pseudowire  ,
> >>    
> >>
> >>>          carries the psedowire label , can be same for
> >>>      
> >>>
> >>different pairs of
> >>    
> >>
> >>>     4.  In case a particular Attachment Circuit goes
> >>>      
> >>>
> >>inactive can the
> >>    
> >>
> >>>          inform the remote end which Attachment Circuit
> >>>      
> >>>
> >>has gone down.
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>

---

From: [email-masked]
Date: Fri, 24 Sep 2004 08:50:08 +0100

Luca, Peter, (and Tom if tuned in),

I am going to provide further comments on the 'oam message mapping'
draft when I get the chance, but some of the issues I have with this
draft apply here....please see below.

<Snipped>
Luca=>> The question I have is the following:
> Why do we have to transmit status of individual VPs in the 
> LDP control 
> protocol ? 
NH=> You are right Luca, you should not do this.....its the wrong place
for this information.  Also see below.

Luca=>> ATM does a pretty good job already ... If the PW goes down 
> then we have 
> to know the VPs in use , and generate the appropriate OAM F4 
> cells .... 
NH=> Exactly so.  The key point here being that it is the *traffic*
data-plane that is required to detect/handle the defects, not a
control-plane protocol....however, there are some key relationships here
that I will come back on shortly.  But please note this for now:  I not
saying ATM is great solution, in fact I.610 has flaws and Y.1711 is
I.610 done properly.  Y.1711 should apply to *any* co-ps mode technology
as the functional problem being addressed is the same in all co-ps
technology cases.  The fact that each/every technology has does its own
thing here (and ditto for other func components) is what is wrong.

Luca=>> But the PW status down message is already there....

NH=> Defects need detection/handling in the traffic data-plane.  I think
most folks have now worked out why this has been a requirement we have
insisted on right from the beginning.  Further, the OAM used needs to be
agnostic of the method used to set-up the trail, including provisioning
by management (this cannot apply to IP, as the cl-ps mode does not
create trails....it does however apply both the co-cs mode and the co-ps
mode, eg LSPs created by RSVP-TE).

However, it is important that the traffic data-plane OAM
activation/deactivation works in concert with the method of trail
set-up/take-down.  Else we are going to get operational problems.  Now I
have noticed some folks saying that we can use a light-weight OAM
technique like BFD (which is getting close to copying Y.1711 now I'll
grant...has to, the functional problem being addressed is the same).
However, they are also saying they will use a heavy-weight OAM technique
like LSP-Ping to 'bootstrap' BFD.  Huh!?  This makes little sense as we
still need to synchnonise the OAM (BFD here) with trail
set-up/take-down.....so why not get the signalling protocol (can I
suggest RSVP-TE and not LDP) do this this from the outset?

There are many other aspects that need to be done correctly here (like
defect detection/handling must be unidirectional, there is a key
'ordering principle wrt defects/availability/performance, etc)....but
I'll make these remarks against the 'oam message mapping' draft.

Luca=> >>( Neil , I'm sure you have an opinion on this point :-) )
Peter=> >We tried to anticipate Neil's comments. I think we can get away
with 
> >the proposed solution without being reminded of G.805 :-)
NH=> G.805 is irrelevant to this discussion per se.  G.805 is nothing
more that formalising the description of network architecture, ie
turning it from an art into more of a science.  Folks should not deride
it just because they don't understand it or its relevance.  OAM is
simply a functional component of the networking problem-space.  And like
other functional components it is *not* the same for all network modes.
An understanding of func arch allows one to see/understand this quite
easily IMO.

regards, Neil

---

From: "Nurit Sprecher" <[email-masked]>
Date: Tue, 28 Sep 2004 20:15:11 +0200

If N:1 should be used, it definitely should be generalized. However, there are some issues in doing this as follows:
1. PW status notification
a. When notifying a remote peer on a service forwarding error, due for example to a port error, how do you notify it? How can the remote peer distinguish and identify which specific service is affected?
2. AC QoS
a. In TE environment, the service's QoS is of the AC. What is the related QoS in case of a trunk? The QoS is the overall QoS required for the trunk? This is an issue in TE service provisioning, especially in multi-domains, but also in NMS provisioning when attaching a PW to a specific TE Tunnel. A CAC should be done on TE tunnel to verify it has sufficient resources for the service emulated.
3. Etc.

I think that a new PW type should be defined, and a new entity defining the emulated service (trunk?), etc.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mustapha Aissaoui
Sent: Tuesday, September 28, 2004 17:37
To: Busschbach, Peter B (Peter)
Cc: [email-masked]'; 'Luca Martini'
Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt Generalized FEC clarific ation

Peter,
the text proposed by Amulya in his email suggested that he was
trying to generalize the N:1 encapsulation to carry not just VPs
coming on a given port, but a mix of VPs and VCs coming from
different ports.

He was also suggesting to use LDP status notifications to add/remove
an a VC or VP into the already established PW.

That was of course not the Virtual Trunk application you are
describing here and which is being specified in the MFA.

Regards,
Mustapha.

"Busschbach, Peter B (Peter)" wrote:
>
> Luca wrote:
>
> > Yes , I am.  The question I have is the following:
> > ATM does a pretty good job already ... If the PW goes down
> > then we have
> > But the PW status down message is already there....
> >
> > Luca
> >
>
> Luca,
>
> Your comment is related to a discussion on ATM Virtual Trunks and OAM.
>
> Let me explain the broader context. Manoj started this thread with a question about mapping multiple VPs onto a PW. You mentioned that only n=1 is currently supported in the atm-encap draft, upon which I made the point that you could interpret the draft as supporting n>1 as well. I referred to the work that is going on in the MPLS Frame Relay Alliance (MFA).
>
> The MFA is working on an Implementation Agreement on MPL-ATM Control Plane Interworking. Among other things, it defines the concept of Virtual Trunks. A Virtual Trunk is a contiguous set of VPIs with a one ATM signaling and one ATM routing channel that run through the VP with the lowest VPI in the range. The ATM Switches at either end of the Virtual Trunk use the signaling channel to set up VPCs and VCCs through the trunk.
>
> Virtual Trunks are primarily used in the following scenario:
>
> ATM Switch 1   ---1--  PE1 ----2----  PE2 ---3--- ATM Switch 2
>
> Interfaces 1 and 3 are ATM interfaces. 2 is the MPLS core. PE1 and PE2 are responsible for Pseudo Wire Emulation.
>
> A Virtual Trunk extends from ATM Switch 1 to ATM Switch 2. When the VT is provisioned, the PEs learn that all cells with a VPI in the range {L, U} should be mapped onto a specific Pseudo Wire using n:1 cell mode encapsulation. The PEs don't have to know the state of individual VCs. They are not involved in the setup of VPCs and VCCs. The only thing they do is mapping VPIs to Pseudo Wires Labels.
>
> The two ATM Switches behave as if the Virtual Trunk is a regular interface between them. There is one routing channel to exchange topology information and one signaling for connection setup. ATM routing and signaling information is transparent to the LERs.
>
> OAM for Virtual Trunks is still being debated in the MFA. I would rather wait with describing the full solution until we have agreement within the MFA. However, I can respond to your question "Why do we have to transmit status of individual VPs in the LDP control protocol?"
> The answer is, we don't. The primary goal of Virtual Trunks is to define a solution in which the PEs are not aware of the status of individual VPs. Whatever solution the MFA comes up with, it will not require the use of PW Status notification for individual VPs within a Virtual Trunk.
>
> Peter
>
> >
> >
> [snipped to the end]
>