Last Call Review of draft-ietf-l2tpext-sbfd-discriminator-03
review-ietf-l2tpext-sbfd-discriminator-03-genart-lc-davies-2016-04-10-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

Apologies for the slightly late review - I was stricken by a stomach bug.

For more information, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-l2tpext-sbfd-discriminator-03.txt
Reviewer: Elwyn Davies
Review Date: 2016/04/10
IETF LC End Date: 2016/04/05
IESG Telechat date: (if known) -



Summary: Almost ready. There are a number of acronyms that need 


expansion and I am unclear how an implementation of S-BFD getting its 


discriminators via L2TPv3 would know what entities the advertised 


discriminators (whether one or many) should be associated with. This 


probably just needs a single sentence to sort it out, but I found the 


existing wording to be either inappropriate or just plain wrong.




Nearly Major Issue:
Question:


The format allows multiple discriminators to be sent in one message.  


Looking at the S-BFD base draft (s3), it is implied that if a S-BFD 


module is dealing with multiple discriminators they would be associated 


with multiple different entities.  How would the receiver know what 


entity each of the discriminators was supposed to be associated with?  


It seems to me that the receiver would want to know this but I may not 


have understood what is going on here.  I guess one way would be to use 


a part of the discriminator bit pattern but I don't know if this might 


make it more difficult to achieve uniqueness in a domain.  Alternatively 


a purpose  provided field could be sent in addition to each 


discriminator, or different AVP IDs used for well-known purposes.




The sentence at the end of para 4 of s2.1:



When multiple S-BFD discriminators are
   advertised, the mechanism to choose a subset of specific
   discriminator(s) is out of scope for this document.



 may be associated with this question but I am not sure


(1) which end is supposed to be choosing - is the Initiator choosing 


which to advertise or the Responder choosing which to 'do something 


with', and


(2) it seems to me that the L2TPv3 receiver or its associated S-BFD 


module would be deciding on some well-defined basis which entities were 


associated with which designator rather than just making an arbitrary 


choice.






I suggest that a sentence indicating how the association of 


discriminators to entities is done (or even that it needs to be done but 


how it is done is out of scope) needs to be added, and the sentence 


above needs to be clarified or subsumed in this new part (unless either 


of the more draconian alternatives suggested above is thought to be 


appropriate).




Minor issues:
None

Nits/editorial comments:


Abstract:  I'm afraid you are going to have expand the acronyms AVP, 


L2TP and BFD here.  References to RFC 5880 and the new S-BFD draft RFC 


would also be helpful - in the form "(RFC 5880, 


I-D.ietf-bfd-seamless-base)".






s1.1: The  L2TP message names used in s2.1 and elsewhere (ICRQ, ICRP, 


OCRQ, OCRP)  need to be expanded  - here would be as good as anywhere.




s2.1: Need to expand AVP and ID.