Subject: RE: [PWE3] VCCV BFD mode

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 25 May 2006 16:52:53 +0200

Stewart and all,

Please see below the text taken from the -00 version of 
draft-ietf-bfd-mpls (ALL the BFD drafts have expired, and 
I have not found a more recent version anywhere):

<quote>
   The BFD control packet sent by the ingress LSR MUST be a UDP packet
   with a well known destination port TBD and a source port assigned by
   the sender. The source IP address is a routable address of the
   sender. The destination IP address is a (randomly chosen) address
   from 127/8. The IP TTL is set to 1.

   BFD control packets sent by the egress LSR are UDP packets. The
   source IP address is a routable address of the replier; the source
   port is the well-known UDP port TBD.  The destination IP address and
   UDP port are copied from the source IP address and UDP port of the
   control packet received from the ingress LSR. 
<end quote>

This looks unambiguously enough.

The PWE3 VCCV draft is also expired, the most recent I could find is -07.
And it does not even refer to any of the specific BFD drafts, only to the core BFD 
one. The authors' intent  (quoting from Tom's merssage on this thread)
"to use the same target PE address that is used to signal the PW"
is not, to the best of my knowledge, specified anywhere and is in contradiction
with the rules for MPLS BFD.

And, achitecture-wise, I do not see why using the loopback IP address in the 
IP/UDP encapsulation of the PW BFD packets does not mean that we are 
running it between the end points of the PW control plane (IMHO, these are 
routable IP addresses of the PEs).

Regards,
			Sasha

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Thursday, May 25, 2006 3:14 PM
> To: pwe3
> Subject: Re: [PWE3] VCCV BFD mode
> 
> 
> Sasha Vainshtein wrote:
> 
> > Yaakov, Rahul and all.
> > I think  that VCCV in the BFD mode, just as LSP-Ping, shall 
> use Destination IP address from 127/8 (loopback addresses).
> > If this is correct, it would resolve the problem mentioned 
> by Yaakov.
> > 
> > My 2 c
> > 
> > Regards,
> >                                Sasha
> > 
> 
> We need to consider what architecture we want.
> 
> If we run BFD over IP over PW (with the loopback address)
> we are really running it between the control plane endpoints,
> because the layering requires us to remove the PW headers
> and deliver the packet to the object that is addressed
> by the IP address that is carrying the VCCV packet.
> 
> If we omit the IP header we are running BFD strictly between
> the PW demux endpoints and the BFD packet never exits the
> PW environment.
> 
> What would we do if we were running static PWs? In that case
> we strictly do not need an IP address at all, so what IP address
> would we use?
> 
> I think that if we run BFD directly over the PW we
> achieve the best match between the scope of the packet
> and the object we are testing, and at the same time increase
> the flexibility of VCCV to run in a number of tunnel
> enviroments.
> 
> Other views?
> 
> - Stewart
> 
> 
> 
> 
> > 
> > 
> >>-----Original Message-----
> >>From: Yaakov Stein [mailto:[email-masked]]
> >>Sent: Thursday, May 25, 2006 2:52 PM
> >>To: Rahul Aggarwal
> >>Cc: pwe3
> >>Subject: RE: [PWE3] VCCV BFD mode
> >>
> >>
> >>Rahul
> >>
> >>Sorry that my response has been so delayed - 
> >>too much work on non-related topics.
> >>
> >>I will explain the problem I have with the UDP/IP encapsulation.
> >>
> >>In my opinion one of the main advantages in using MS-PWs
> >>is to enable continuous end-to-end OAM at the PW level
> >>by using VCCV.
> >>
> >>But alhtough I have no problem placing BFD messages 
> >>in the VCCV channel, I will in general not know the IP
> >>address of the U-PE.
> >>
> >>So I would need to run the BFD segment by segment,
> >>which defeats the whole purpose.
> >>
> >>BFD should run over the available channel,
> >>which in this case is the MS-PW,
> >>without need for identifiers from higher layers.
> >>
> >>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: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 26 May 2006 10:48:21 -0400

> Sent: Friday, May 26, 2006 10:40 AM
> To: Busschbach, Peter B (Peter)
> Cc: 'Yaakov Stein'; Rahul Aggarwal; pwe3
> Busschbach, Peter B (Peter) wrote:
> 
> >>>BFD message are not addressed to the target node, but have 
> >>
> >>a non-routable address. 
> >> >
> >>
> >>Where is this specified?
> > 
> > 
> > 
> > See draft-ietf-bfd-mpls-02, section 7.
> > 
> > Actually, the text is somewhat ambiguous. It states that 
> the ingress LER uses an adress from 127/8, whereas the egress 
> LER copies the source IP address of the received packet and 
> uses that as destination address in the reply.
> > 
> > My interpretation is that the actual address is only used 
> in the echo mode by the egress LER and that in the case of 
> assynchronous mode both LERs use addresses from 127/8.
> > 
> > 
> >>Thanks
> >>
> >>Stewart
> >>
> > 
> > 
> 
>     "The BFD control packet sent by the ingress LSR MUST be a 
> UDP packet
>     from 127/8. The IP TTL is set to 1."
> 
> So how does this work between two non-adjacent MPLS nodes
> (for example to test a FRR node repair target)?
> 
> What about when you are running between two non-adjacent
> nodes (again perhaps for IPFRR) and you only have
> partial MPLS connectivity?
> 
> Don't you need to be able to set TTL > 1, and use routable
> source and destination addresses?

The draft that I referred to applies to BFD over MPLS or PWs (which, I thought, was the topic of this email thread ;-). There may be other deployments, like the one you mention, in which routable destination IP addresses must be used.