RE: [PWE3] BFD for MPLS PWs

Yaakov and all,
Please see a brief comment inline. I've snipped the fragments where 
we seem to be in agreement.

Regards,
                     Sasha

> -----Original Message-----
> From: Yaakov Stein [mailto:yaakov_s@rad.com]
> Sent: Monday, July 31, 2006 8:33 PM
> To: Sasha Vainshtein
> Cc: rahul@juniper.net; pwe3@ietf.org
> Subject: RE: [PWE3] BFD for MPLS PWs
> 
> 
> Sasha,  
> 
... snipped ...
> 
> > It should be also noted that the PW Associated Channel does not always
> > use the first nibble of the CW for discrimination. 
> > The most obvious use case is represented by the PWs that do not use
> > CW, e.g., Ethernet PWs.  
> > (AFAIK, all existing implementations support Ethernet PWs without CW
> > in accordance with RFC 4448 and most do not support CW). 
> 
> A historical mistake that should be rectified by using the CW whenever
> one wants to use VCCV.
>
[Sasha] Mistake or not, this is the fact on the ground. I do not see retrofitting multiple
already deployed services carrying live customer traffic and generating substantial
revenue for the operators as a realistic development. Especially since the OA&M
problem can be amended by other means. (Not to mention the problems with 
revoking/modifying a Standards Track RFC that has only been published 4 months ago 
after 6 years' delay.)
>
> > If we agree that IP (and only IP) packets are carried over the
> > Associated Channel, 
> > we can then use IP protocol numbers and, where appropriate, 
> > well-known
>  >UDP ports for additional discrimination. 
> 
> But I, for one, do not agree.
> 
> I believe we should expand the possibilities of the PWACH code points
> instead,
> and avoid the needless and confusing IP header.
>
[Sasha]  IMHO the WG should select one of the two approaches for discriminating
various types of payload carried in the ACh:

- Always use IP (so that the type is not needed) and then use IP tools (protocol
  numbers, ports etc.) for dicrimination

OR

- Restrict VCCV to PWs that use a CW and always use the type  field in the CW for
  discrimination.

The advantage of the 1st method its inherent ability to verify PW connectivity as it operates in a 
meaningful way even if the PW label has been popped in a wrong place. I do not see
how this can be achieved with the 2nd method. In addition, it is fully compatible with the existing
and deployed PW implementations.

The advantage of the 2nd method is that it that produces shorter OA&M packets and simplifies,
to some extent, demultiplexing of OA&M packets.

>
> > One of the possible applications would be the proposal to 
> carry Y.1731 (Ethernet OAM) PDUs over VCCV.
> > It would looks somewhat bizarre, IMHO, if this proposal were not
> > applicable to Ethernet PWs, 
> > and one way to resolve this controversy could be by encapsulating
> > these PDUs into IP packets 
> > with EtherIP  (RFC 3378) protocol number.
> 
> Inelegant to say the least.
[Sasha] I agree. But then the original proposal included quite a few elements that look
inelegant to me:
- meaningless MAC addresses
- MEG IDs (in the CC PDUs) that must be somehow forced to ne the same along a given
  (possibly, multi-segment) PW
- MEP IDs (that must uniquely identify each switching/termination point within the given PW) etc.
Adding/removing a fixed well-defined header on top of all of these looks relatively cheap to me.
> 
> Y(J)S
> 
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3