Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?)

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 7 May 2003 18:37:19 -0700 (PDT)

Mustapha,

[clipped]

> PWE3 work, I propose to address the issues raised in 2 phases:
> 
> Phase 1: 
> the current scope of the PWE3 working group is to provide for a PW
> between two endpoints of the same type (e.g., FR-MPLS-FR). In this
> environment, the native service OAM and link management achieves all
> what is needed and we do not need to define a specific PW OAM. At

In this environment there is still a need for a PW OAM. Please see section
3 of:

draft-nadeau-pwe3-vccv-00.txt

Regards,
rahul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 09:38:10 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mustapha Aissaoui
> Sent: Wednesday, May 07, 2003 6:42 PM
> To: David Allan
> Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; 
> Danny McPherson; [email-masked]
> Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?)
> 
> 
> Dave and all,
> I agree with your assessment. Given that we want to progress 
> the PWE3 work, I propose to address the issues raised in 2 phases:
> 
> Phase 1: 
> the current scope of the PWE3 working group is to provide for 
> a PW between two endpoints of the same type (e.g., 
> FR-MPLS-FR). In this environment, the native service OAM and 
> link management achieves all what is needed and we do not 
> need to define a specific PW OAM. At the PSN level, 

	I suggest that you read the MPLS OAM 
requirements in draft-ietf-mpls-oam-requirements-00.txt, 
as well as the justifications for VCCV in 
draft-nadeau-pwe3-vccv-00.txt and then tell the
25 or so service providers that were polled for
these requirements about how it is so
clear that there is no need to have such a mechanism.

> OAM can 
> be achieved using either IP tools such as LSP-Ping, or Y.1711 
> tools. Any OAM specific issues with the PSN are clearly 
> outside the scope of the PWE3. 

 	Use of just LSP-ping for PWs is not going to cut 
the mustard for two reasons, which I will explain
below. I believe that LSP ping/ICMP ping/native OAM
and VCCV need to be used in conjunction to satisfy
the requirements specified in the OAM requirements.

	1) Use of VCCV allows you to get as close to the
		disposition point as possible; LSP 
		or ICMP ping doesn't necessarily do 
		this in all cases.

	2) VCCV is a generic CV mechanism for IETF defined
		PWs regardless of the underlying PSN technology
		that allows CV traffic to flow on EXACTLY the
		same path as the data plane.

		This is important because tools designed to 
		test/debug/verify PWs can be written more
		generally.  This is also important because
		there are cases where using regular ICMP-ping
		will not follow the same data plane path over
		the IP tunnel.

	Also, pitching Y.1711 as a possible alternative is
irresponsible. It is badly broken for LDP-based networks
and has been shown to be quite difficult to implement
besides, so lets not go there. Of course, its proponents 
are working feverishly to patch it up within the ITU
so that they can ask service providers to replace all
of their hardware (again) to support the ultimate OAM
swiss army knife. I assert that it is certainly 
not ready and should not be considered as an acceptable
approach.

> The only requirement is to 
> address the IP aliasing issue. The most straighforward way to 
> resolve it is to make sure that all CWs have the nibble 
> following immediately the bottom label set to a value 
> different of 4, 6, or 8 (zero seems to be the accepted 
> value). This means that the SONET encapsulation would have to 
> go with Option 3 in Andy's three proposals.
> 
> Phase 2: 
> the work of the PWE3 may expand to support endpoints of 
> different types (e.g., FR-MPLS-Ethernet). In this scenario, 
> if the native service is terminated locally at each PE, then 
> clearly there is a need for the following: a. the ability to 
> define a PW specific OAM and link management functions and 
> inteoperate it with the native service OAM and link 
> management. b. the ability to self-identify the protocol 
> carried in a single PW. 

> A PW can carry both user packets and 
> OAM packets and we want them to share the same path in the 
> presence of ECMP. 

	Again, read the OAM requirements referenced above. 
OAM traffic MUST be carried on the same data path regardless 
of whether ECMP is active or not.  Are you suggesting that
we should ignore that 25 SPs have told us?

	--Tom

> A PW can also carry both a end-user bridged 
> and a routed PDU (multiprotocol PW). This is where the 
> MPLS/PW PID is useful but it should be addressed in a much 
> wider scope than the current PWE3 issues.
> 
> Let me know what you think.
> Mustapha.
> ------------
> > David Allan wrote:
> > 
> > We do have two separate problems....
> > 
> > 1) Is a means of identifying a generic payload. This would 
> appear to 
> > potentially require additional services such as sequencing 
> etc. stuff 
> > already dealt with in the exissting PWE control words. This would 
> > include ordering, and if this was preserved in the presence of 
> > proprietary ECMP so much the better.
> > 
> > 2) A means of instrumenting PWs such that packets fate 
> shares with  PW 
> > forwarding. Tom has proposed VCCV which needs an available 
> bit in the 
> > CW and control handshaking to agree on what the bit means. 
> The PPP DLL 
> > approach (Georges proposal) or my proposal permits the 
> instrumenting 
> > protocol to self identify and therefore IMHO is preferable.
> > 
> > But I am skeptical that simply having a protocol identifier 
> means a PW 
> > can carry anything. Its not designed with the requisite 
> attributes for 
> > service bearing. If we want "carry anything" with ordering 
> > fragmentation etc. we have more to do.
> > 
> > my 2 cents
> > Dave
> > 
> > > -----Original Message-----
> > > From: Sasha Vainshtein [mailto:[email-masked]]
> > > Sent: Tuesday, May 06, 2003 4:00 AM
> > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson
> > > Cc: [email-masked]
> > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?)
> > >
> > >
> > > Hi all,
> > >
> > > I believe that George's comment has been very much in place.
> > >
> > > The "MPLS PID" story looks to me like following:
> > >
> > > 1. There was a recognized but, for some reasons, undeclared need
> > 
> > >    to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts
> > >    complied with this, and some did not; some others simply
> > >    declared that the CW is optional.
> > >
> > > 2. At some (rather late) stage, the need has been declared,
> > >    explained (which is always good!) and proposed as part of
> > >    the standard (moving the architecture document int the
> > >    Standards Track).
> > >
> > > 3. In order to minimize impact on some pre-standard
> > implementations
> > >    that have either utilized the 1st nibble of the CW or used
> > RTP
> > >    (or both), an optional opaque 32-bit word has between the PW
> > label
> > >    (at the bottom of the label stack) and a the CW/RTP header
> > has been
> > >    proposed as the simplest way out. The only requirement for
> > this
> > >    block of data has been to keep its 1st nibble zeroed.
> > >
> > > 4. After that, this patch has been somehow "promoted" to the
> > title
> > >    and associated status of of "MPLS PID". And this promotion
> > has
> > >    triggered a long discussion of its possible uses far beyond
> > the
> > >    original patchy fuctionality.
> > >
> > > 5. The proposals mentioned in is discussion are, IMO, paramount
> > >    to an alternative PWE3 architecture (including allocation
> > >    of a PWE3 protocol number in IP header etc.). They also
> > include
> > >    amendments to Y.1711 which is presumably out of scope of PWE3
> > 
> > >    (and IETF in general) etc.
> > >    And somehow the fact that existing LSRs carry IP traffic over
> > 
> > >    LSPs without any MPLS PID and will hardly be ever retrofitted
> > 
> > >    has been happily ignored by some of the participants.
> > >
> > > IMHO the best way out of the confusion would be to demote 
> "MPLS PID" 
> > > to what it really is - a patch solving the ECMP problem for the 
> > > following three cases (and just for these
> > cases):
> > >
> > > o     PW encapsulations that do not mandate a CW, so that
> > payload
> > > immediately
> > >       follows the PW label. In other words, make SOME CW
> > mandatory.
> > > o     PW encapsulations that mandate a CW but utilize its 1st
> > nibble.
> > >       They would prepend an opaque 32-bit word with the 
> zeroed 1st 
> > > nibble
> > >       by default, reserving an option to drop it if ECMP 
> is not used 
> > > in
> > >       the core network.
> > > o     PW encapsulations that use RTP. They may follow the
> > > same rules as in
> > >       the previous case, or may use weaker rules because 
> the first 
> > > nibble
> > >       of an RTP header distinguishes it from IPv4/IPv6 
> headers and 
> > > this
> > >       is probably sufficient for ECMP.
> > >
> > > I think that building theories/architectures on patches is 
> > > counter-productive.
> > >
> > > With best regards,
> > >                                    Sasha Vainshtein
> > > email:     [email-masked] <mailto:[email-masked]>
> > > tel:       +972-3-7659993 (office)
> > >            +972-8-9254948 (res.)
> > >            +972-58-674833 (cell.)
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>