[mpls] 答复: AD review of draft-ietf-mpls-return-path-specified-lsp-ping

[Mach Chen <[e-mail]>]

Adrian,

Cool! I will try to submit the update before the deadline!

Thanks,
Mach

> -----邮件原件-----
> 发件人: Adrian Farrel [mailto:[e-mail]]
> 发送时间: 2012年10月19日 7:12
> 收件人: Mach Chen;
> [e-mail]
> 抄送: [e-mail]; [e-mail]
> 主题: RE: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping
> 
> Hi Mach,
> 
> This looks good.
> 
> > Should the "carry and sub-TLV" be "carry the sub-TLV"?
> Yes. Too many fingers error.
> 
> Otherwise I agree all your proposed changes and answers.
> 
> I'll look for the revised I-D and advance when I see it. Don't forget the
> cut-off date!
> 
> Cheers,
> Adrian
> 
> > -----Original Message-----
> > From: Mach Chen [mailto:[e-mail]]
> > Sent: 18 October 2012 09:56
> > To: [e-mail]; draft-ietf-mpls-return-path-specified-lsp-
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: 答复: [mpls] AD review of
> draft-ietf-mpls-return-path-specified-lsp-ping
> >
> > Adrian,
> >
> > Many thanks for your detail review and comments!
> >
> > Please see my response inline...
> >
> > Best regards,
> > Mach
> >
> > > -----邮件原件-----
> > > 发件人: [e-mail] [mailto:[e-mail]] 代表
> Adrian
> > > Farrel
> > > 发送时间: 2012年10月18日 4:35
> > > 收件人: [e-mail]
> > > 抄送: [e-mail]; [e-mail]
> > > 主题: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping
> > >
> > > Hi,
> > >
> > > I've done my usual AD review of your draft prior to issuing IETF last
> > > call and passing the I-D for IESG evaluation. The main purpose of the
> > > review is to catch issues that might come up in later reviews and to
> > > ensure that the document is ready for publication as and RFC.
> > >
> > > I found Section 4 very good. It completely explains to me what is
> > > going on in the protocol extension, and covered all the corner cases
> > > I could think of. On the other hand, Section 3 made me generate a
> > > really (really, really) long list of relatively minor issues. This
> > > list is so long that I think you need to provide a new revision
> > > before we issue the IETF last call. I will put the I-D into "Revised
> > > I-D Needed" state and wait for the revision.
> > >
> > > As always, all my comments are up for discussion and negotiation.
> > >
> > > Thanks for the work,
> > > Adrian
> > >
> > > ===
> > >
> > > Consistency of references for bidirectional LSP. In Section 1 you have
> > >    In this document, term bidirectional LSP includes the co-routed
> > >    bidirectional LSP defined in [RFC3945]
> > > In Section 2 you have:
> > >    The co-routed bidirectional LSP is defined in [RFC3471]
> > >    and [RFC3473]
> > >
> > OK, will consistently refer to [RFC3945] instead.
> >
> > > ---
> > >
> > > Section 1
> > > s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] session/
> > > s/In this document, term bidirectional LSP/In this document, the term
> > > bidirectional LSP/
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.1
> > >
> > > OLD
> > >    The recommended value of the Reply via Specified Path mode is 5 (This
> > >    is to be confirmed by the IANA).
> > >
> > >        Value    Meaning
> > >        -----    -------
> > >            5     Reply via Specified Path
> > > NEW
> > >    The value of the Reply via Specified Path mode is 5 (This has been
> > >    allocated by IANA using early allocation and is to be confirmed by
> > >    IANA).
> > >
> > >        Value    Meaning
> > >        -----    -------
> > >            5     Reply via Specified Path
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > > OLD
> > >    The Reply Path (RP) TLV is an optional TLV, if the Reply via
> > >    Specified Path mode requested, the Reply Path (RP) TLV MUST be
> > >    included in an echo request message.  It carries the specified return
> > >    paths that the echo reply message is required to follow.  The format
> > >    of Reply Path TLV is as follows:
> > >
> > > NEW
> > >    The Reply Path (RP) TLV is an optional TLV within the LSP Ping
> > >    protocol.  However, if the Reply via Specified Path mode requested as
> > >    described in Section 3.1, the Reply Path (RP) TLV MUST be included in
> > >    an echo request message and its absence is treated as a malformed
> > >    echo request as described in [RFC4379].  Furthermore, if a Reply Path
> > >    (RP) TLV is included in an echo request message, a Reply Path (RP)
> > >    TLV MUST be included in the corresponding echo reply message sent by
> > >    an implementation that is conformant to this specification.
> > >
> > >    The Reply Path (RP) TLV carries the specified return path that the
> > >    echo reply message is required to follow.  The format of Reply Path
> > >    TLV is as follows:
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > > OLD
> > >    Reply Path TLV Type field is 2 octets in length, and the type value
> > >    is TBD by IANA.
> > > NEW
> > >    Reply Path TLV Type field is 2 octets in length, and the type value
> > >    is 21. (This has been allocated by IANA using early allocation and is
> > >    to be confirmed by IANA).
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > > OLD
> > >    Reply Path return code is 2 octets in length.  It is defined for the
> > >    egress LSR of the forward LSP to report the results of Reply Path TLV
> > >    processing and return path selection.  When sending echo request,
> > >    these codes MUST be set to zero.  Reply Path return code only used
> > >    when sending echo reply, and it MUST be ignored when processing
> echo
> > >    request message.  This document defines the following Reply Path
> > >    return codes:
> > > NEW
> > >    The Reply Path return code field is 2 octets in length.  It is
> > >    defined for the egress LSR of the forward LSP to report the results
> > >    of Reply Path TLV processing and return path selection.  This field
> > >    MUST be set to zero in a Reply Path TLV carried on an echo request
> > >    message and MUST be ignored on receipt.  This document defines the
> > >    following Reply Path return codes for inclusion in a Reply Path TLV
> > >    carried on an echo reply:
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > >    Value         Meaning
> > >    ------        ----------------------
> > >    0x0000        No return code
> > >
> > > What does "No return code" mean? I thought it might have been the value
> > > that you should return if the TLV has been successfully processed but
> > > you seem to have 0x0003 for this. So, how is 0x0000 used?
> >
> > It should be named as "Reserved".
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > >    0x0006        The Reply mode in echo request was not set to 5
> (Reply
> > >                  via Specified Path) although Reply Path TLV exists
> >
> >
> > >    0x0007        Reply Path TLV was missing in echo request
> > >
> > > Surely these are malformed echo requests and will be handled with
> > > normal echo replies with return code value 1.
> >
> > Yes, indeed, will remove this two codes.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > >    The A bit and B bit set MUST NOT both be set, otherwise, an echo
> > >    reply with the RP return code set to "Malformed RP TLV was received"
> > >    SHOULD be returned.
> > >
> > > What other options are there? I.e. why "SHOULD" not "MUST"?
> >
> > Actually, there is no other options, MUST should be more precise.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > > OLD
> > >    The Reply Paths field is variable in length, not more than one sub-
> > >    TLV MUST be carried, which describes the specified path that the echo
> > >    reply message is required to follow.  When the Reply Mode field is
> > >    set to "Reply via Specified Path" in an LSP echo request message, the
> > >    Reply Path TLV MUST be present.  The Reply Path TLV SHALL only be
> > >    used in the reply mode defined in this document (Reply via Specified
> > >    Path).
> > > NEW
> > >    The Reply Paths field is variable in length and MUST contain zero or
> > >    one sub-TLV.  The sub-TLV, if present, describes the specified path
> > >    that the echo reply message is required to follow.
> > > END
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > >    When the Reply Mode field is set to "Reply via Specified Path" in an
> > >    LSP echo request message, the Reply Path TLV MUST be present.
> > >
> > > I think this is a duplication of a previous statement and can be removed
> >
> > Yes.
> >
> > >
> > > ---
> > >
> > > Section 3.2
> > >
> > >    The Reply Path TLV SHALL only be
> > >    used in the reply mode defined in this document (Reply via Specified
> > >    Path).
> > >
> > > Why do you need this?  And can it be enforced?
> > > It is very unusual to restrict the use of information in this way. I
> > > understand that you do not have any other use in mind, but is there a
> > > need to make this constraint.
> >
> > This is for resolving one last call comment: how to handle the situation that
> a
> > Reply Path TLV is carried but the reply mode is not set to 5, this should not
> be
> > allowed (implicitly) so far and the echo request should be a Malformed
> message.
> >
> > I personally do not prefer to add this constraint, because we cannot
> guarantee
> > that it will never be used in other modes in the future. I am OK to remove it.
> >
> > >
> > > ---
> > >
> > > Section 3.3
> > >
> > >    In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
> > >    is specified for Vendor Private Use, and MUST NOT be allocated.  This
> > >    document changes that rule to make it not applicable to Reply Path
> > >    TLV and redefines the rule as in Section 6.2 .  If an implementation
> > >    recognizes any specific Vendor Private types as defined in [RFC4379],
> > >    and uses the sub-TLV type specified in this document, care must be
> > >    taken to ensure that the implementation does not confuse the two
> > >    usages.
> > >
> > > I don't think this draft changes the registry for 4379, does it?
> > > This needs a little more care to separate the two uses clearly. How
> > > about...
> >
> > I think it does not change the registry for 4379, but it does changes rule
> that
> > RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that the range of
> > 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private
> Use,
> > this draft changes this.
> >
> > But I agree with your suggestion below :-)
> >
> > >
> > > OLD
> > >    Each of the FEC sub-TLVs (include existing and future defined) for
> > >    the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for
> > >    inclusion in the Reply Path TLV for expressing a specific return
> > >    path.  For these shared sub-TLVs, they share the same registry with
> > >    the Target FEC Stack TLV for the range of 0-31743 and 32768-64511.
> > >
> > >    In addition, this document defines three new sub-TLVs: IPv4 RSVP
> > >    Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV.
> > >    These sub-TLVs are only designed for Reply Path TLV, hence this
> > >    document calls them dedicated sub-TLVs to Reply Path TLV.  For these
> > >    dedicated sub-TLVs, this document will create a new registry (Section
> > >    6.1), the sub-TLV type MUST be allocated from the new registry.
> > >    Detailed definition is in the following sections.
> > >
> > >    In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
> > >    is specified for Vendor Private Use, and MUST NOT be allocated.  This
> > >    document changes that rule to make it not applicable to Reply Path
> > >    TLV and redefines the rule as in Section 6.2 .  If an implementation
> > >    recognizes any specific Vendor Private types as defined in [RFC4379],
> > >    and uses the sub-TLV type specified in this document, care must be
> > >    taken to ensure that the implementation does not confuse the two
> > >    usages.
> > > NEW
> > >    The FECs defined in [RFC4379] provide a good way to identify a
> > >    specific return path.  The FEC sub-TLVs (including existing and
> > >    future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have sub-TLV
> > >    types assigned from a registry with ranges as follows:
> > >
> > >       0-16383       Standards Action mandatory TLV
> > >       16384-31743   Specification Required, Experimental RFC needed
> > >       31744-32767   Vendor Private Use, MUST NOT be allocated
> > >       32768-49161   Standards Action optional TLV
> > >       49162-64511   Specification Required, Experimental RFC needed
> > >       64512-65535   Vendor Private Use, MUST NOT be allocated
> > >
> > >    The Reply Path TLV can carry and sub-TLV defined for use in the
> >
> >
> > Should the "carry and sub-TLV" be "carry the sub-TLV"?
> >
> > >    Target FEC Stack TLV that can be registered.  Thus the ranges
> > >    0-31743 and 32768-64511 are shared by the registries, with the new
> > >    Reply Path Sub-TLVs registry "borrowing" values from the Target FEC
> > >    Stack TLV registry.
> > >
> > >    Allocations from the ranges 31744-32767 and 64512-65535 are not
> > >    recorded in the registry for Target FEC Stack TLVs, so these ranges
> > >    are safely made available in the Reply Path Sub-TLVs registry (see
> > >    Section 6.1) to record sub-TLVs that are specific to the Reply Path
> > >    TLV.  This document defines three sub-TLVs specific to the Reply Path
> > >    TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static
> > >    Tunnel sub-TLV.
> > >
> > >    Note that an implementation that supports specific Vendor Private
> > >    for sub-TLVs of the Target FEC Stack must take care to not confuse
> > >    those values with the same values allocated from the Reply Path Sub-
> > >    TLVs registry.
> > > END
> > >
> > > ---
> > >
> > > Section 3.3
> > >
> > >    2.  Specify a more generic tunnel FEC as return path
> > >
> > > It is clear that 3.3.1 and 3.3.2 define a FEC that is more general than
> > > the FECs in 4379. What is not clear is the use case. I think you need
> > > some text in this document to say what you should do with one of these
> > > FECs since it possibly identifies a set of LSPs.
> >
> > There is another draft (http://tools.ietf.org/html/draft-chen-mpls-bfd-
> > enhancement-00#section-4.2 ) discusses the usage of the generic Tunnel sub-
> > TLV. How about add the following text:
> >
> > One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD
> session
> > on an MPLS Tunnel that has primary and secondary LSPs, especially when
> Make-
> > Before-Break (MBB) is deployed. The usage is discussed in the Section 4.2 of
> [I-
> > D.chen-mpls-bfd-enhancement].
> >
> > >
> > > ---
> > >
> > > Section 3.3.1
> > >
> > > OLD
> > >    The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
> > >    the recommended type value is TBD.
> > > NEW
> > >    The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
> > >    the recommended type value is TBD1.
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.3.1
> > >
> > > It is slightly weird that the bit field in this section allocates the
> > > first two bits while the field in section 3.2 allocates the last two
> > > bits.  This is not significantly important, but is odd.
> >
> > Will change it and make them consistent.
> > >
> > > ---
> > >
> > > Section 3.3.2
> > >
> > > OLD
> > >    The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
> > >    the type value is TBD.
> > > NEW
> > >    The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
> > >    the type value is TBD2.
> > > END
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 3.3.3
> > >
> > > RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is the
> > > MPLS-TP static equivalent of 3.3.1. But you are missing:
> > >
> > > - the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers)
> > > - the MPLS-TP equivalent of the 4379 RSVP LSP FECs
> > >
> > > Do you need them?
> >
> > No, we do not need them, MPLS-TP has not v6 identifiers, and the MPLS-TP
> > equivalent of the 4379 RSVP LSP FECs belongs to the existing sub-TLVs of
> Target
> > FEC TLV and are already defined in TP related RFC.
> >
> > >
> > > ---
> > >
> > > Section 3.3.3
> > >
> > > OLD
> > >    The sub-TLV type value is TBD.
> > > NEW
> > >    The sub-TLV type value is TBD3.
> > > END
> > >
> > OK.
> >
> > > ---
> > >
> > > Section 3.4
> > >
> > > OLD
> > >    The Reply TC TLV Type field is 2 octets in length, and the type value
> > >    is TBD.
> > > NEW
> > >    The Reply TC TLV Type field is 2 octets in length, and the type value
> > >    is TBD4.
> > > END
> > >
> >
> > OK.
> >
> > > ---
> > >
> > > Section 4
> > >
> > >    The procedures defined in this document currently only apply to
> > >    "ping" mode.  The "traceroute" mode is out of scope for this
> > >    document.
> > >
> > > I think this should show up in the Introduction and possibly the
> > > Abstract.
> >
> > OK.
> >
> > >
> > > ---
> > >
> > > Section 6
> > >
> > > Please consider whether you want registries for the bit fields you
> > > define in this document.
> > >
> > > ---
> > >
> > > Section 6.1
> > >
> > > OLD
> > >    TBD     Reply TC TLV                      this document (sect
> 3.4)
> > > NEW
> > >    TBD4    Reply TC TLV                      this document (sect
> 3.4)
> > > END
> > >
> > OK
> >
> > > ---
> > >
> > > Section 6.4
> > >
> > > OLD
> > >    TBD     Reply TC TLV                      this document (sect
> 3.4)
> > > NEW
> > >    TBD4    Reply TC TLV                      this document (sect
> 3.4)
> > > END
> > >
> > OK.
> >
> > > ---
> > >
> > > Section 6.2.1
> > >
> > > OLD
> > >    Sub-type      Value Field             Reference
> > >    -------       -----------             ---------
> > >    TBD           IPv4 RSVP Tunnel        this document (sect 3.3.1)
> > >    TBD           IPv6 RSVP Tunnel        this document (sect 3.3.2)
> > >    TBD           Static Tunnel           this document (sect 3.3.3)
> > > NEW
> > >    Sub-type      Value Field             Reference
> > >    -------       -----------             ---------
> > >    TBD1          IPv4 RSVP Tunnel        this document (sect 3.3.1)
> > >    TBD2          IPv6 RSVP Tunnel        this document (sect 3.3.2)
> > >    TBD3          Static Tunnel           this document (sect 3.3.3)
> > > END
> > >
> > > ---
> > >
> > > Section 6.3
> > >
> > > OLD
> > >    IANA is now requested to assign the previously assigned a new reply
> > >    mode code point (5 - Reply via specified path) from the "Multi-
> > >    Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
> > >    Parameters" registry, the "Reply Mode" sub-registry on a permanent
> > >    basis.
> > > NEW
> > >    IANA has made an early allocation (5 - Reply via specified path) from
> > >    the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
> > >    (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. IANA
> > >    is requested to make this allocation permanent.
> > > END
> >
> > OK.
> >
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls