Should the "draft-ietf-bfd-multihop-8" add the scheme to enforce BFD sessions traversing different alternative paths?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

 


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.