Re: [Gen-art] Gen-art LC review of draft-ietf-l2tpext-sbfd-discriminator-03

Wed, 13 Apr 2016 12:36:02 -0700 

Elwyn,

This is a great review. Thank you.

Please see inline.

Deborah,

We will be queueing edits, let me know when you’d want us to post an updated 
revision.

> On Apr 10, 2016, at 1:26 PM, Elwyn Davies <[email protected]> wrote:
> 
> 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.
> 

I hope you are feeling better!

> 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.
> 

These items, with the exception of the acronym expansion, have already been 
discussed. See below line-by-line responses to each of these potential issues, 
as well as a set of HTML diffs from the working copy, FYI.

> 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.

Thanks for raising this — although this was discussed and addressed, it might 
not be self-evident. See the next comment.

> 
> 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

Indeed, this is the relevant paragraph.

This paragraph was also added to other related documents (ISIS, OSPF), and goes 
hand-in-hand with the following paragraph from draft-ietf-bfd-seamless-base-08:
   The use of multiple S-BFD
   discriminators by a single network node is therefore discouraged
   until a means of learning the mapping is defined.

Now, that said, it is clear that if it created confusion in this review, this 
can also create future confusion.

> (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).
> 

To really minimize the chance of that future confusion, I agree with your 
suggestion. I added such sentence and reworded the paragraph a bit. Further 
comments on the proposed text most welcome.

> 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)”.

Acronyms expanded. Since the Abstract should not have citations, I am hesitant 
to add anything else. It is clearly in the Introduction.

> 
> 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.
> 

S1.1 already specifies expectations to readers, which include these L2TP 
messages:

1.1.  Terminology

   The reader is expected to be very familiar with the terminology and
   protocol constructs defined in S-BFD (see Section 2 of
   [I-D.ietf-bfd-seamless-base]) and L2TPv3 (see Section 1.3 of
   [RFC3931]).

But sure, will expand on first use as well.

> s2.1: Need to expand AVP and ID.
> 

Seems a bit repetitive, but done.

Thanks,

— Carlos.

>
Title: Diff: draft-ietf-l2tpext-sbfd-discriminator-03.txt - draft-ietf-l2tpext-sbfd-discriminator-04.txt
 draft-ietf-l2tpext-sbfd-discriminator-03.txt   draft-ietf-l2tpext-sbfd-discriminator-04.txt 
Networking Working Group V. Govindan Networking Working Group V. Govindan
Internet-Draft C. Pignataro Internet-Draft C. Pignataro
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: September 19, 2016 March 18, 2016 Expires: October 15, 2016 April 13, 2016
Advertising S-BFD Discriminators in L2TPv3 Advertising S-BFD Discriminators in L2TPv3
draft-ietf-l2tpext-sbfd-discriminator-03 draft-ietf-l2tpext-sbfd-discriminator-04
Abstract Abstract
This document defines a new AVP that allows L2TP Control Connection This document defines a new Attribute Value Pair (AVP) that allows
Endpoints (LCCEs) to advertise one or more Seamless BFD (S-BFD) L2TP Control Connection Endpoints (LCCEs) to advertise one or more
Discriminator values using L2TPv3. Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator
values using L2TPv3.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2016. This Internet-Draft will expire on October 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. S-BFD Target Discriminator ID AVP . . . . . . . . . . . . . . 2 2. S-BFD Target Discriminator ID AVP . . . . . . . . . . . . . . 2
2.1. Encoding Format . . . . . . . . . . . . . . . . . . . . . 3 2.1. Encoding Format . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 4 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
[I-D.ietf-bfd-seamless-base] defines a simplified mechanism to use [I-D.ietf-bfd-seamless-base] defines a simplified mechanism to use
Bidirectional Forwarding Detection (BFD) [RFC5880], referred to as Bidirectional Forwarding Detection (BFD) [RFC5880], referred to as
Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD
mechanisms depend on network nodes knowing the BFD discriminators mechanisms depend on network nodes knowing the BFD discriminators
which each node in the network has reserved for this purpose. S-BFD which each node in the network has reserved for this purpose. S-BFD
requires the usage of unique discriminators within an administrative requires the usage of unique discriminators within an administrative
domain. The use of Layer Two Tunneling Protocol - Version 3 (L2TPv3) domain. The use of Layer Two Tunneling Protocol - Version 3 (L2TPv3)
skipping to change at page 2, line 45 skipping to change at page 2, line 48
1.1. Terminology 1.1. Terminology
The reader is expected to be very familiar with the terminology and The reader is expected to be very familiar with the terminology and
protocol constructs defined in S-BFD (see Section 2 of protocol constructs defined in S-BFD (see Section 2 of
[I-D.ietf-bfd-seamless-base]) and L2TPv3 (see Section 1.3 of [I-D.ietf-bfd-seamless-base]) and L2TPv3 (see Section 1.3 of
[RFC3931]). [RFC3931]).
2. S-BFD Target Discriminator ID AVP 2. S-BFD Target Discriminator ID AVP
The "S-BFD Target Discriminator ID" AVP is exchanged using the ICRQ, The "S-BFD Target Discriminator ID" AVP is exchanged using the ICRQ
ICRP, OCRQ, and OCRP control messages during session negotiations. (Incoming-Call-Request), ICRP (Incoming-Call-Reply), OCRQ (Outgoing-
Call-Request), and OCRP (Outgoing-Call-Reply) control messages during
session negotiations.
2.1. Encoding Format 2.1. Encoding Format
The S-BFD Target Discriminator ID AVP, Attribute Type "TBA by IANA", The S-BFD Target Discriminator Identifier (ID) Attribute Value Pair
is an identifier used to advertise the S-BFD Target Discriminator(s) (AVP), Attribute Type "TBA by IANA", is an identifier used to
supported by an LCCE for the S-BFD Reflector operation. This AVP advertise the S-BFD Target Discriminator(s) supported by an LCCE for
indicates that the advertiser implements an S-BFD reflector the S-BFD Reflector operation. This AVP indicates that the
supporting the specified target discriminator(s) and is ready for advertiser implements an S-BFD reflector supporting the specified
S-BFD Reflector operation. The receiving LCCE MAY use this AVP if it target discriminator(s) and is ready for S-BFD Reflector operation.
wants to monitor connectivity to the advertising LCCE using S-BFD. The receiving LCCE MAY use this AVP if it wants to monitor
connectivity to the advertising LCCE using S-BFD.
The Attribute Value field for this AVP has the following format: The Attribute Value field for this AVP has the following format:
S-BFD Target Discriminator ID (ICRQ, ICRP, OCRQ, OCRP): S-BFD Target Discriminator ID (ICRQ, ICRP, OCRQ, OCRP):
No. of octets No. of octets
+-----------------------------+ +-----------------------------+
| Discriminator Value(s) | 4/Discriminator | Discriminator Value(s) | 4/Discriminator
: : : :
+-----------------------------+ +-----------------------------+
An LCCE MAY include the S-BFD Discriminator Advertisement AVP in a An LCCE MAY include the S-BFD Discriminator Advertisement AVP in a
L2TP Control Protocol message (ICRQ, ICRP, OCRQ, OCRP) [RFC3931]. L2TP Control Protocol message (ICRQ, ICRP, OCRQ, OCRP) [RFC3931]. If
Multiple S-BFD Discriminators AVPs MAY be advertised by a LCCE. If
the other LCCE does not wish to monitor connectivity using S-BFD, it the other LCCE does not wish to monitor connectivity using S-BFD, it
MAY safely discard this AVP without affecting the rest of session MAY safely discard this AVP without affecting the rest of session
negotiation. While [I-D.ietf-bfd-seamless-base] concerns itself with negotiation. While [I-D.ietf-bfd-seamless-base] concerns itself with
the advertisement of only one discriminator unless the mapping to the advertisement of only one discriminator unless the mapping to
discriminators to entities is specified, the AVP encoding allows the discriminators to entities is specified, the AVP encoding allows the
specification of an arbitrary number of discrminators (at least one) specification of an arbitrary number of S-BFD Discriminators (at
for extensibility. When multiple S-BFD discriminators are least one) for extensibility.
advertised, the mechanism to choose a subset of specific
discriminator(s) is out of scope for this document. When an LCCE uses the S-BFD Target Discriminator ID AVP, multiple
S-BFD Discriminators MAY be included, and at least one S-BFD
Discriminator MUST be included. When one S-BFD Discriminator is
advertised, such S-BFD Discriminator is associated with the L2TPv3
Session. When multiple S-BFD discriminators are advertised, the
mechanism to choose a subset of specific discriminator(s) is out of
scope for this document.
The S-BFD Target Discriminator ID AVP allows for advertising at least The S-BFD Target Discriminator ID AVP allows for advertising at least
one S-BFD Discriminator value: one S-BFD Discriminator value:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 1 | | Discriminator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 2 (Optional) | | Discriminator 2 (Optional) |
skipping to change at page 5, line 5 skipping to change at page 5, line 18
Sowinski for providing core inputs for the document and for Sowinski for providing core inputs for the document and for
performing thorough reviews and providing number of comments. performing thorough reviews and providing number of comments.
Authors would like to thank Nagendra Kumar for his reviews. Authors would like to thank Nagendra Kumar for his reviews.
6. Contributing Authors 6. Contributing Authors
Mallik Mudigonda Mallik Mudigonda
Cisco Systems Cisco Systems
Email: [email protected] Email: [email protected]
7. Normative References 7. References
7.1. Normative References
[I-D.ietf-bfd-seamless-base] [I-D.ietf-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-ietf-bfd-seamless-base-08 (work in (S-BFD)", draft-ietf-bfd-seamless-base-08 (work in
progress), February 2016. progress), February 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 5, line 28 skipping to change at page 5, line 43
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, DOI 10.17487/RFC3438, December Update", BCP 68, RFC 3438, DOI 10.17487/RFC3438, December
2002, <http://www.rfc-editor.org/info/rfc3438>. 2002, <http://www.rfc-editor.org/info/rfc3438>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>. <http://www.rfc-editor.org/info/rfc3931>.
7.2. Informative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. <http://www.rfc-editor.org/info/rfc5880>.
Authors' Addresses Authors' Addresses
Vengada Prasad Govindan Vengada Prasad Govindan
Cisco Systems, Inc. Cisco Systems, Inc.
Email: [email protected] Email: [email protected]
 End of changes. 11 change blocks. 
26 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ 


Attachment:
signature.asc

Description: Message signed with OpenPGP using GPGMail


_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art






















					Reply via email to