Re: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt

Hi Greg, Jeff, et al,

Please find below my comments on draft-mirsky-mpls-bfd-directed.

1) General - clarification

I realize that there's no explicit code point overlap between draft-mirsky-mpls-bfd-directed and draft-chen-mpls-bfd-enhancement: draft-mirsky-mpls-bfd-directed is focused on Segment Routing whilst draft-chen-mpls-bfd-enhancement is focused on existing MPLS technologies. However, both documents are describing how to program the reverse BFD path on the egress LSR via LSP Ping. It would be nice to have one way of doing this, whether the technology is Segment Routing or something else. Can authors of draft-mirsky-mpls-bfd-directed and draft-chen-mpls-bfd-enhancement sync up to come up with a single approach?

2) Section 1 - clarification

   The [RFC5880], [RFC5881], and the [RFC5883] established BFD protocol
   for IP networks and the [RFC5884] set rules of using BFD Asynchronous
   mode over IP/MPLS LSPs.

The described problem is valid, but:
- I don't think the same problem applies to RFC5881 (aka single-hop BFD), as sessions are bound to the interface being monitored.
- The same problem is definitely not applicable to RFC5880 which is the base protocol spec (i.e. does not define any data plane procedures).

Perhaps you can list only RFC5883/RFC5884 or add some clarifications on why RFC5880/RFC5881 are also listed.

3) Section 1 - clarification

   And because BFD control
   packets are not guaranteed to cross the same links and nodes in both
   directions detection of Loss of Continuity (LoC) defect in forward
   direction is not guaranteed or is free of positive negatives.

I tripped over the words "... free of positive negatives" and had to read this multiple times. This is purely a nit comment, but I think what you want to say here is "... free of false negatives"?

4) Section 2

s/BF D/BFD/

[NOTE] Remove space between 'F' and 'D'.

5) Section 2 - some text suggestion

[OLD]
   o  if reverse direction is in Down state, the head-end node would not
      receive indication of forward direction failure from its far-end
      peer.

[NEW]
   o  if reverse direction is in Down state, the head-end node would not
      receive indication of forward direction failure from its far-end
      peer.  The head-end node in this case will detect a problem due to
      lack of expected BFD control packets (i.e. detection timer expiry)
      instead of immediately receiving BFD control packets with explicit
      Down messages from the far-end peer.

6) Section 3.3 - clarification

[snip]
   Initiator MAY include FECs corresponding to some or all of segments
   imposed in the label stack by the initiator to communicate the
   segments traversed.  "

   When LSP ping is used to bootstrap BFD session this document updates
   this and defines that LSP Ping MUST include the FEC corresponding to
   the destination segment and SHOULD NOT include FECs corresponding to
   some or all of segment imposed by the initiator.  Operationally such
   restriction would not cause any problem or uncertainty as LSP ping
   with FECs corresponding to some or all segments or traceroute may
   preceed the LSP ping that bootstraps the BFD session.
[snip]

Right now draft-kumarkini-mpls-spring-lsp-ping states, "MAY include other FECs".
draft-mirsky-mpls-bfd-directed updates this by stating, "SHOULD NOT include other FECs".

It seems to me that the both aren't very different and the proposed mechanism will work whether this change is made or not. Can you clarify why this document makes above update?

7) General - additional reference

With Segment Routing, there can be multiple SR-TE paths between the same source/destination pairs, with subset of SR-TE paths ending with same SID. Thus, there's a strong dependency from this mechanism described to draft-grmas-bfd-rfc5884-clarifications. It might be a good idea that implementation of draft-mirsky-mpls-bfd-directed will require draft-grmas-bfd-rfc5884-clarifications.

Thanks!

-Nobo

> -----Original Message-----
> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gregory Mirsky
> Sent: Thursday, October 23, 2014 4:02 PM
> To: rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org
> Subject: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-
> directed-01.txt
> 
> Dear All,
> a new section 3.3 Bootstrapping BFD session with BFD Reverse Path over
> Segment Routed tunnel been added. Authors always welcome your
> comments and greatly appreciate suggestions. We're looking forward to
> continue discussion at WG meetings at IETF-91.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 23, 2014 12:57 PM
> To: Gregory Mirsky; Jeff Tantsura; Gregory Mirsky; Jeff Tantsura; Ilya
> Varlashkin; Ilya Varlashkin
> Subject: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt
> 
> 
> A new version of I-D, draft-mirsky-mpls-bfd-directed-01.txt
> has been successfully submitted by Greg Mirsky and posted to the IETF
> repository.
> 
> Name:		draft-mirsky-mpls-bfd-directed
> Revision:	01
> Title:		Bidirectional Forwarding Detection (BFD) Directed Return
> Path
> Document date:	2014-10-23
> Group:		Individual Submission
> Pages:		9
> URL:            http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd-
> directed-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-
> directed/
> Htmlized:       http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-bfd-directed-
> 01
> 
> Abstract:
>    Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
>    directional paths.  When a BFD session monitors in its forward
>    direction an explicitly routed path there is a need to be able to
>    direct far-end BFD peer to use specific path as reverse direction of
>    the BFD session.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring