Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt

[Eric Rosen <[e-mail]>]

Many thanks for your review and comments!

  Section 1 

    When an MP-LSP is being set up, the procedures of [RFC6826] and
    [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP In-Band
    Signaling", allow the Egress LSRs of the MP-LSP to encode the identifier
    of an IP multicast tree in the "Opaque Value" field of the mLDP FEC
    Element that identifies the MP-LSP.

Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] should be
Lizhong> moved to the next section, right? This section is talking about
Lizhong> RFC6826.

I think the material in this paragraph is applicable in VRF context as well
as in non-VRF context.  Thus it is appropriate to reference both RFC 6826
(which discusses in-band signaling in non-VRF context) and RFC 7246
(formerly draft-ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses
in-band signaling in VRF context.

The material in the following paragraph only applies in VRF context.  I will
add a reference to RFC 7246 to that paragraph.


  Section 3.2 

    Please note that, as always, the structure of the Opaque Value TLVs does
    not actually affect the operation of mLDP, but only affects the
    interface between mLDP and IP multicast at the Ingress LSR.

Lizhong> the interface between mLDP and IP multicast at the egress LSR is
Lizhong> also affected. So it is better to say "...at the Ingress and Egress
Lizhong> LSR".

How about:

    Please note that, as always, the structure of an Opaque Value TLV does
    not affect the operation of mLDP.  The structure is meaningful only to
    the IP multicast modules at the ingress and egress LSRs.


  Section 3.2 

    Note that the Bidir TLVs do not have a "Source Address" sub-field, and
    hence the notion of a wildcard source is not applicable to them.

Lizhong> since Bidir TLV is out of the scope, then it is not necessary to
Lizhong> have the above note.

Section 3.2 states earlier that procedures for the use of the wildcard group
in the Bidir TLVs are out of scope.  The sentence cited above says that the
Bidir TLVs cannot have a wildcard source.  I think it is useful to make both
statements, since neither one implies the other.

  Section 3.3 

    However, if an Ingress LSR supports [RFC6826] and/or
    [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support this
    document, it has no choice but to treat any such received FEC elements
    as invalid; the procedures specified in [RFC6826] and
    [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the Opaque
    values contain zeroes in the Source Address or Group Address sub-fields.
    
Lizhong> I went throught RFC6826 and RFC7246, there is no definition of
Lizhong> "zeroes". Then the above statement will be treated as an update to
Lizhong> RFC6826 and RFC7246. If that is true, then the draft header needs
Lizhong> to indicate that update.

I believe you are correct.  I will add this to the draft header and the
abstract.

  Section 5. 

    If PIM is not enabled for the identified group, the Ingress LSR acts as
    if it had received a (*,G) IGMP/MLD report from a downstream node, and
    the procedures as defined in [RFC4605] are followed.

Lizhong> It seems the dataplane processing is missing here. E.g., add
Lizhong> something like, the ingress LSR should forward the specified
Lizhong> multicast stream to the downstream node through the MP-LSP
Lizhong> identified by the Opaque Value TLV. That is not described in
Lizhong> RFC4605.

This is discussed in section 4.2 of the document; I think it will be
adequate to just add a reference here to section 4.2.