Subject: Re: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft? (fwd)

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 13 Jun 2005 11:25:01 -0700 (PDT)

---------- Forwarded message ----------
Date: Thu, 9 Jun 2005 23:38:35 -0700 (PDT)
From: Rahul Aggarwal <[email-masked]>
To: Thomas D. Nadeau <[email-masked]>
Cc: pwe3 <[email-masked]>, Stewart Bryant <[email-masked]>
Subject: Re: [PWE3] draft-martini-pwe3-pw-switching-03.txt as WG draft?

Hi Tom,

> 	Rahul,
>
> 	Our draft does not concern itself with signaling;
> its based

To take just a few examples do you think section 6.1.4 [PW switching
point TLV]; section 6.1.7 [PW Loop Detection]; section 8.1 [PW Status]
specify signaling behaviour ?

> on static provisioning.

Let's face it, this is one of the MS-PW solution
documents. Its using *one possible* solution. The fact that the draft
uses manual provisioning doesn't give it a special status in the WG. It
should be treated like other MS-PW solution documents.

rahul

>We can add whatever signaling protocols
> the PWE3 WG endorses in the future.
>
> 	--Tom
>
> >
> > Hi Stewart,
> >
> > On Mon, 6 Jun 2005, Stewart Bryant wrote:
> >
> >>
> >> The authors of
> >>
> >> draft-martini-pwe3-pw-switching-03.txt
> >>
> >> have asked that the draft be adopted as a WG draft.
> >>
> >> What is the consensus of the PWE3 WG?
> >>
> >
> > The above draft is one of the candidate solutions in the MH-PW solution
> > space.
> >
> > To quote you and Danny from your email that described the way forward
> > after the discussion on draft-raggarwa-rsvpte-pw:
> >
> > "The issue then becomes one of how to move forward.
> >
> > There are a number of candidate signaling protocols, and
> > we propose that we set a limit of three weeks before the
> > next IETF (i.e. -00 cutoff) for any further candidate
> > proposals to address the MS-PW signaling requirements.
> >
> > Evaluating the candidate signaling protocols and testing the
> > consensus of the WG on the best way to proceed will be
> > the major work item at the next IETF.
> >
> > Stewart/Danny"
> >
> > The above implies that *no* candidate signaling solution will be
> > adopted by the WG in the domain of MH-PWs till all the candidate
> > signaling protocols are discussed in the next IETF.
> >
> > So let us first discuss all the MH-PW signaling solutions
> > and the applicability of each before deciding which one to adopt and
> > for
> > which set of requirements. Until then this draft or other drafts in the
> > MH-PW solution space, should not be adopted as WG documents.
> >
> > Thanks,
> > rahul
> >
> >> - Stewart
> >>
> >>
> >>
> >> _______________________________________________
> >> pwe3 mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iD8DBQFCpyIuHwfkLUURkkwRApZcAKCPN2O10wjXvAkgRVmnJUy6D4pVnACgiLQW
> SSbvGedJuh6+XidXUCvA0hk=
> =xkdA
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

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

---

From: [email-masked]
Date: Wed, 15 Jun 2005 09:11:47 +0100

Luca, Rahul....I have a few observations for your consideration:

Luca Martini wrote 15 June 2005 01:06
<snip>
> Rahul,
> 
> This is not an  MS-PW solution other then Interworking of the control 
> planes.
NH=> This cannot be correct.  When 2 technologies are interworked in a
peer-partition relationship (which is quite different to a client/server
relationship) one needs to consider all the functional components of
both the traffic data-plane and the control-plane.  This is not a
trivial issue.  Further, when the 2 technologies do NOT belong to the
same mode you will find a very large 'disconnect' in functions (and
often technology-specific features) that make the notion of
peer-partition interworking quite an irrational topic to pursue (cf
interworking an SDH VC4 with ethernet say if not obviously true).  But
even when the 2 technologies do belong to the same network mode things
are far from straightforward....in fact, it is my opinion that peer
partition i/w only really makes sense when ALL the functional components
are essentially identical in BOTH the traffic data-plane and the
control-plane....and now what we have reached is a public service E-NNI
or I-NNI case (the difference being what is allowed to be
advertised/controlled across the interface (usually reachability vs
reachability+topology respectively wrt routing, and a restriction on
messages wrt signalling).....this is dependent on whether it is the same
party (I-NNI) or a different party (E-NNI) owning the network on either
side of the interface.

> we are getting lost in terminology.
NH=> Well, I could suggest this is because there is very little
architectural rigour being applied and that there seems a dearth of
understanding of functional architecture (there for sure seems to be a
lack of understanding that the 3 network modes need treating rather
differently).  However, once one starts with a flawed foundation (eg
XoverIP(cl-ps)==XoverMPLS(co-ps)) then it must be quite tempting to add
further tweaks 'just to keep it going'.

> The automatic path selection that you can achieve by 
> different schemes , 
> RSVP, routing protocol etc. etc. *is * what will be discussed at the 
> next meeting.
NH=> I don't think one should confuse signalling and routing functions
like this....they are quite different.  ALL scalable WAN technologies,
irrespective of mode, MUST have an addressing scheme and routing
process.  Of course only the co modes require a NETWORKING signalling
component.....and I emphasise the word NETWORKING here to make the point
that this is not the same as a session protocol which only touches the
end-nodes, whereas a proper signalling protocol will touch all nodes
along the routing chosen in that layer network.

> Whether we abandon all current protocols to setup PWs *is not* for 
> discussion. ( or at least i do not think i heard anything along these 
> lines ...)
> 
> Are you suggesting that we completely abandon all pwe3 work to date , 
> and L2TPEXT WG work ?
NH=> I think this is the crux of the problem, ie to even contemplate
doing things right would mean a massive re-set....I fear the rubicon was
passed a long time ago.
BTW - The XoverIP(l2tpv3) stuff is fine IFF you recognise it for what it
is, ie it is NOT the same as Xover_co-ps nor indeed Xover_co-cs.
> 
> If not , then we need a document that explains how different 
> PW control 
> protocols are talking to each other.
NH=> This is a quite different issue (to the client/server case
above).....and this is making an assumption that peer-partition i/w is
required.  Well, I suppose it is now.  But we should at least recognise
that this is a self-inflicted consequence of assuming that XoverIP MUST
== XoverMPLS, ie we have created a new (PW) layter network.
> 
> I see no reason why we need to stop this work to wait for the 
> discussion 
> at the next IETF. Besides , if the WG should decide to go a different 
> route at a future time , we can change this draft , or drop 
> it completely.
> 
> Can this document be used to build MS-PW solution ? I would 
> think yes. However this is not the part of the solution that 
> we have discussed on 
> this list or in the last IETF PWE3 meeting.
> 
> This document does not restrict any of the MS-PW automatic path 
> selection solution space. If we go with RSVP , we will need a 
> method to 
> interwork RSVP with LDP , and with L2TPV3. This is what this document 
> describes.
NH=> We can't stop here  We will need to interwork all functional
components of both data and control planes.....and in cases where there
is a functional/feature mismatch we will need to terminate that
function/feature on it's side of the interface because there will be no
logical mapping (in case this is not obvious cf the BECN function in FR
that does not exist in ATM wrt ATM/FR peer-partition i/w).  There will
also be some rather interesting issues arising when one looks at OAM i/w
and fault-handling across such an interface {Hint - there should be no
mapping of defects between server layer peer-partitions}
> 
> >>This is the basis for Interworking the control plane of many PWs , 
> >>such as L2TPv3 , LDP( FEC 128/129) , and static PWs.
> >>    
> >>
> >
> >Other than MS-PWs, is there another application for such 
> inter-working 
> >?
> >
> >  
> >
> The application is to enable PWs to connect among 
> heterogeneous PSNs , 
> IP and MPLS.
NH=> Can I ask 'why' this is required, ie where is it planned for this
to happen, eg:
-	(public) Internet?...think not
-	(private) intra-operator?....think not (I mean why add this
interworking grief?)
-	(private) inter-operator?....seems the only logical case
....or is it just a recognition that this is a (technical) consequence
of the creation of this new PW layer network because an MPLS server
layer is indeed different to an IP server layer?

As an aside observation...I do find it rather odd that when dealing with
the co-cs mode (case of GMPLS) there was such strong opinion that
RSVP-TE be chosen over CR-LDP, and yet when exactly the same situation
arises for the co-ps mode (the 'situation' being the difference between
a signalling and session protocol noted earlier) converse logic seems to
be being applied.  Speaking as an operator, there is little merit in
having lots of different spins of the SAME functional component (nor
indeed lots of same-mode technologies...though we do need all 3 modes
working in concert).  And whilst a signalling component applied to a
co-cs mode layer network is for sure acting in a different layer network
space to a signalling component applied to a co-ps mode layer network,
there is no reason why the SAME signalling component basis should not be
used in each case.

regards, Neil
> 
> >>Regardless of what protocol we choose to signal multi hop PWs , we 
> >>must have a document that defines the control plane signaling 
> >>Interworking between different PW setup protocols.
> >>
> >>    
> >>
> >
> >And what is the reason for defining such inter-working other than to 
> >setup MS-PWs ?
> >
> >  
> >
> The reason is to have the ability to connect PWs running on different 
> PSNs, and using different PW setup and maintenance protocols, such as 
> LDP fec 128 , static , LDP FEC 129, and possibly even RSVP.
> 
> Luca
> 
> >rahul
> >
> >  
> >
> >>Luca
> >>
> >>
> >>
> >>Rahul Aggarwal wrote:
> >>
> >>    
> >>
> >>>Hi Stewart,
> >>>
> >>>The above draft is one of the candidate solutions in the MH-PW 
> >>>solution space.
> >>>
> >>>we propose that we set a limit of three weeks before the next IETF 
> >>>(i.e. -00 cutoff) for any further candidate proposals to 
> address the 
> >>>MS-PW signaling requirements.
> >>>
> >>>consensus of the WG on the best way to proceed will be the 
> major work 
> >>>item at the next IETF.
> >>>
> >>>Stewart/Danny"
> >>>
> >>>So let us first discuss all the MH-PW signaling solutions and the 
> >>>applicability of each before deciding which one to adopt and for 
> >>>which set of requirements. Until then this draft or other 
> drafts in 
> >>>the MH-PW solution space, should not be adopted as WG documents.
> >>>
> >>>Thanks,
> >>>rahul
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>>>- Stewart
> >>>>
> >>>>
> >>>>