Subject: RE: [PWE3] BFD for MPLS PWs

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 1 Aug 2006 18:05:31 +0200

Tom and all,
Please see some comments inline below.

regards,
                    Sasha    

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 4:50 PM
> To: Sasha Vainshtein
> Cc: Yaakov Stein; [email-masked]; Rahul Aggarwal
> Subject: Re: [PWE3] BFD for MPLS PWs
> 
> 
> 
> On Aug 1, 2006, at 3:31 AM, Sasha Vainshtein wrote:
> 
> > Tom and all,
> > Please see some comments inline below.
> > I've snipped parts of the original thread to make it readable.
> >
> > Regards,
> >                    Sasha
> >
> >> -----Original Message-----
> >> From: Thomas D. Nadeau [mailto:[email-masked]]
> >> Sent: Monday, July 31, 2006 10:48 PM
> >> To: Rahul Aggarwal
> >> Cc: Yaakov Stein; [email-masked]
> >> Subject: Re: [PWE3] BFD for MPLS PWs
> >>
> >>
> >>
> >>> Hi Tom,
> > ... snipped ...
> >>
> >> 	The reasons that were explained during the meeting:
> >>
> >> 	1) sending the IP/UDP header is redundant
> >> 		for SH PWs because the labels or outer l2tpv3 header
> >> 		ID the VCCV payload.
> >>
> > [Sasha] This is only correct if the PW uses a CW. Not all 
> of them do.
> 
> 	If you do not use a PW header, then you cannot use
> VCCV.
>
[Sasha] This is NOT what the latest VCCV draft says:

<quote>
4.2. Out-of-Band VCCV (Type 2)

   A VCCV control channel can alternatively be created by using the 
   MPLS router alert label [RFC3032] immediately above the PW label. 
   It should be noted that this approach MAY result in a differnt
   equal cost multi-path (ECMP) hashing behavior than pseudowire
   PDUs and thus result in the VCCV control channel traffic taking 
   a path which differs from that of the actual data traffic under 
   test.

   This is the preferred mode of VCCV operation when the control word
   is not present. 
<end quote>
> 
> >>
> >> 	2) If you include the 127/ dest. address, then it is
> >> useless other
> >> 		than it prevents errant routing if the PW header
> >> 		is inadvertently stripped.  However, skipping the
> >> 		IP header altogether obviates both problems. It
> >> 		also makes each VCCV/BFD packet shorter.
> >>
> > [Sasha] Can you please explain how skipping the IP header  solves
> > the problem of the PW label being popped in an inappropriate place?
> 
> 	If there is no routable IP header behind the PW header,
> then there is no chance of doing the wrong thing. The dest. IP
> address should be a 127/ address, which should make it un-routable
> anyway.
>
[Sasha] IP header also contains a Sourece IP address which MUST be a routable
address of the sender. So if your VCCV packet ends in a wrong place, you still have the chance
to notofy the sender about a problem. This cannot be achived if the IP header is not
present IMHO.
> 
> >>
> >> 	2) sending the IP/UDP header is useless for MH PWs because
> >> 		the MH PW addressing scheme will not fit into
> >> 		an IPv4 address.  Instead, the outer PW encapsulation
> >> 		identifies the destination.
> >>
> > [Sasha] IMHO Nothing in the IP/UDP proposal prevents you 
> from using  
> > IPv6 headers/addresses as
> > IPv4 and IPv6 packets are easily discriminated using the Version  
> > field.
> 
> 	That isn't my point. The point is that you do not need
> to do the secondary address lookup if its not there.
> 
> > To the best of my recollection, the IPv4 and IPv6 addressing  
> > schemes are explicitly
> > allowed for MS-PWs, and I have not seen any realistic alternative  
> > proposals.
> > I also do not think that the "outer PW encapsulation" defines the  
> > packet destination in MS-PWs.
> >>
> >> 	3) the secondary routing header lookup/processing is
> >> 		a waste of processing cycles since it should
> >> 		always result in the receiving PE. The outer
> >> 		header identifies the PW packet already.
> >>
> > [Sasha] Can you please explain how to you see LSP-Ping being used  
> > in VCCV without IP/UDP headers?
> 
> 	I don't. This is only for the BFD payloads.
>
[Sasha] So you actually propose two different encaps for VCCV: IP-based encap LSP-Ping and "raw" for BFD.
This does not look nice for me, especially as you also want to prohibit BFD for PWs that do not use the CW...

> 	--Tom
> 
> 
> >> 	Conversations with everyone except yourself (I couldn't
> >> find you after PWE3) that objected to the removal of the UDP/IP
> >> header at the meeting, all agreed that this was okay assuming that
> >> we add two new CV types to explicitly identify when the header
> >> is and is not included for BFD messages so that we can support
> >> older implementations. I will have the text for this shortly
> >> and will send it out.
> >>
> >> 	--Tom
> >>
> >>
> >>
> >>> rahul
> >>>
> >>>> 	--Tom
> >>>>
> >>>>
> >>>>
> >>>>> Y(J)S
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> pwe3 mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>
> >>>
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> >> _______________________________________________
> >> 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: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 1 Aug 2006 11:12:17 -0400

>    This is the preferred mode of VCCV operation when the control word

	Using the RA label mode has the distinct possibility of
the packet not being processed in the same manner as the
data for that PW.  That option is there really for backwards
compatibility, but it is not the preferred mode of VCCV as far
as I am concerned.

> to notofy the sender about a problem. This cannot be achived if the  
> IP header is not present IMHO.

	This is only the case for SH PWs, and when using
LSP ping mode. For BFD, there is no way to reply back to
an errand BFD packet other than a local syslog message.

> This does not look nice for me, especially as you also want to  
> prohibit BFD for PWs that do not use the CW...

	Lets forget about the LSP ping mode for a second. For
BFD there are currently 2 options: 1) BFD or 2) BFD + status
codes. What is being proposed are 4 options now: 1) BFD (with
IP headers) 2) BFD (with IP headers) + status 3) BFD (without
IP headers) 4) BFD (without IP headers) + status. The intent
was for options 1/2 to function as-specified today. The latter
two are the optimized modes that are useful for those using the
latest MPLS CW.

	--Tom