Subject: Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths?

From: Linda Dunbar <[email-masked]>
Date: Sun, 08 Nov 2009 07:10:34 -0600

Dave and David, 

Hope you can help me to figure out the following issues with regard to
"draft-ietf-bfd-multihop-8":

*	Multiple BFD sessions between one pair of system was mentioned
several times in the document. Is the purpose of having multiple BFD
sessions between the same pair for traversing different alternative routes
between the same pair? If yes, the document didn't say how to enforce it.
Even the different Destination/Source addresses being used can't guarantee
that those BFD sessions will traverse different paths. Is it out of the
scope of this document?
*	What are the benefits of enforcing BFD sessions between a pair of
nodes to traverse alternative paths between them? I guess by doing so, the
two nodes get to know how many different paths are between them. Who will
use this information? 
*	Your BFD base draft (draft-ietf-bfd-base-09) does state that one of
the goals of BFD is to traverse all possible paths between two nodes. Does
it include the alternative paths between specific Ingress and Egress? 
*	Suggestion if you do think it is necessary to traverse all the
alternative paths between two nodes as indicated in the BFD base document: 

*	Is it possible to create a special BFD session that all intermediate
nodes will forward the BFD to all the paths in the ECMP group? Whenever it
happens, the node will mark a bit to the Discriminator field. By receiving
all the BFD frames with different Discriminator value, the egress node can
figure out how many alternative paths are between them. 

Hope to have more discussion in Hiroshima. 

Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

---

From: Dave Katz <[email-masked]>
Date: Sun, 8 Nov 2009 13:18:39 -0700

On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote:

> Dave and David,
>
> Hope you can help me to figure out the following issues with regard  
> to “draft-ietf-bfd-multihop-8”:
>
> Multiple BFD sessions between one pair of system was mentioned  
> sessions between the same pair for traversing different alternative  
> routes between the same pair? If yes, the document didn’t say how to  
> enforce it. Even the different Destination/Source addresses being  
> used can’t guarantee that those BFD sessions will traverse different  
> paths. Is it out of the scope of this document?

The mention of multiple BFD sessions is primarily for discussion about  
how to demultiplex such sessions, rather than to attempt to deal with  
the liveness of alternate paths.  As you point out, there is no  
mechanism for binding a BFD session to a path, only to its endpoints,  
and even that is somewhat fraught with subtlety (which is why the  
multipoint spec spends most of its time talking about how to demux BFD  
packets.)

As the whole point of BFD is to follow the same paths that data is  
following, sharing fate as much as possible, trying to run BFD over  
inactive alternate paths would be extremely difficult.

Multiple *active* paths may exist (such as an LSP and a routed path)  
and most of the verbiage is to provide a palette of mechanisms that  
can be used to sort the BFD sessions out.

>
> What are the benefits of enforcing BFD sessions between a pair of  
> nodes to traverse alternative paths between them? I guess by doing  
> so, the two nodes get to know how many different paths are between  
> them. Who will use this information?

See above.

>
> Your BFD base draft (draft-ietf-bfd-base-09) does state that one of  
> the goals of BFD is to traverse all possible paths between two  
> nodes. Does it include the alternative paths between specific  
> Ingress and Egress?

I don't believe that it ever says such a thing, and it isn't possible  
in any case.  Can you point at the text that gave you this impression?

>
> Suggestion if you do think it is necessary to traverse all the  
> Is it possible to create a special BFD session that all intermediate  
> nodes will forward the BFD to all the paths in the ECMP group?  
> Whenever it happens, the node will mark a bit to the Discriminator  
> field. By receiving all the BFD frames with different Discriminator  
> value, the egress node can figure out how many alternative paths are  
> between them.

See above.

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 08 Nov 2009 18:48:44 -0600

Dave, 

Thank you very much for the reply. 

What do you think of my suggestion? 

o        Is it possible to create a special BFD session that all
intermediate nodes will forward the BFD to all the paths in the ECMP group?
Whenever it happens, the node will mark a bit to the Discriminator field. By
receiving all the BFD frames with different Discriminator value, the egress
node can figure out how many alternative paths are between them.

Linda Dunbar

  _____  

From: Dave Katz [mailto:[email-masked]] 
Sent: Sunday, November 08, 2009 2:19 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme to
enforce BFD sessions traversing different alternative paths?

Dave and David,

The mention of multiple BFD sessions is primarily for discussion about how
to demultiplex such sessions, rather than to attempt to deal with the
liveness of alternate paths.  As you point out, there is no mechanism for
binding a BFD session to a path, only to its endpoints, and even that is
somewhat fraught with subtlety (which is why the multipoint spec spends most
of its time talking about how to demux BFD packets.)

As the whole point of BFD is to follow the same paths that data is
following, sharing fate as much as possible, trying to run BFD over inactive
alternate paths would be extremely difficult.

Multiple *active* paths may exist (such as an LSP and a routed path) and
most of the verbiage is to provide a palette of mechanisms that can be used
to sort the BFD sessions out.

*          

See above.

*          

*         Your BFD base draft (draft-ietf-bfd-base-09) does state that one
of the goals of BFD is to traverse all possible paths between two nodes.
Does it include the alternative paths between specific Ingress and Egress?

I don't believe that it ever says such a thing, and it isn't possible in any
case.  Can you point at the text that gave you this impression?

*          

o        Is it possible to create a special BFD session that all
intermediate nodes will forward the BFD to all the paths in the ECMP group?
Whenever it happens, the node will mark a bit to the Discriminator field. By
receiving all the BFD frames with different Discriminator value, the egress
node can figure out how many alternative paths are between them.

See above.

o         

Linda Dunbar

---

From: Dave Katz <[email-masked]>
Date: Sun, 8 Nov 2009 20:41:44 -0700

On Nov 8, 2009, at 5:48 PM, Linda Dunbar wrote:

> intermediate nodes will forward the BFD to all the paths in the ECMP  
> group? Whenever it happens, the node will mark a bit to the  
> Discriminator field. By receiving all the BFD frames with different  
> Discriminator value, the egress node can figure out how many  
> alternative paths are between them.

Doing so would probably require reprogramming forwarding hardware, and  
by its nature would stop being BFD as we know it.

Mapping out all possible network paths is well outside the scope of  
the specification, and it doesn't seem as though BFD is particularly  
suited for this task.

It sounds a bit like Token Ring Explorer packets (showing my age) but  
a mechanism to discover topology by brute force would require  
forwarding changes or some other games to be played.

Within a routing domain, such things can be determined analytically  
from link state databases, but this doesn't help in the larger picture.

In any case, it doesn't sound like anything BFD ought to be involved in.

--Dave

> Subject: Re: Should the "draft-ietf-bfd-multihop-8" add the scheme  
> to enforce BFD sessions traversing different alternative paths?
>
>
> ·         Multiple BFD sessions between one pair of system was  
> mentioned several times in the document. Is the purpose of having  
> multiple BFD sessions between the same pair for traversing different  
> alternative routes between the same pair? If yes, the document  
> didn’t say how to enforce it. Even the different Destination/Source  
> addresses being used can’t guarantee that those BFD sessions will  
> traverse different paths. Is it out of the scope of this document?
>
> The mention of multiple BFD sessions is primarily for discussion  
> about how to demultiplex such sessions, rather than to attempt to  
> deal with the liveness of alternate paths.  As you point out, there  
> is no mechanism for binding a BFD session to a path, only to its  
> endpoints, and even that is somewhat fraught with subtlety (which is  
> why the multipoint spec spends most of its time talking about how to  
> demux BFD packets.)
>
> ·
> ·         What are the benefits of enforcing BFD sessions between a  
> pair of nodes to traverse alternative paths between them? I guess by  
> doing so, the two nodes get to know how many different paths are  
> between them. Who will use this information?
>
> See above.
>
>
> ·
> ·         Your BFD base draft (draft-ietf-bfd-base-09) does state  
> that one of the goals of BFD is to traverse all possible paths  
> between two nodes. Does it include the alternative paths between  
> specific Ingress and Egress?
>
> I don't believe that it ever says such a thing, and it isn't  
> possible in any case.  Can you point at the text that gave you this  
> impression?
>
>
>
> ·
> ·         Suggestion if you do think it is necessary to traverse all  
> the alternative paths between two nodes as indicated in the BFD base  
> document:
> intermediate nodes will forward the BFD to all the paths in the ECMP  
> group? Whenever it happens, the node will mark a bit to the  
> Discriminator field. By receiving all the BFD frames with different  
> Discriminator value, the egress node can figure out how many  
> alternative paths are between them.
>
> See above.
>
>
> o
>